Event Hub，Stream Analytics和Data Lake管道问题

Question

在阅读了这篇article之后，我决定开始构建一系列数据摄取。一切都很好。我能够将数据发送到Event Hub，由Stream Analytics提取并发送到Data Lake。但是，对于一些对我来说很奇怪的事情，我有一些问题。如果有比我更有经验的人能够回答，我将不胜感激。

以下是我的Stream Analytics中的SQL

SELECT
    *
INTO
    [my-data-lake]
FROM
    [my-event-hub]

现在，对于问题：

1. 我应该将100％的数据存储在一个文件中，尝试将其拆分为多个文件，还是尝试实现每个文件一个文件？ Stream Analytics将所有数据存储在单个文件中，作为一个巨大的JSON数组。我尝试将{date}和{time}设置为变量，但它每天仍然是一个巨大的单个文件。
2. 有没有办法强制Stream Analytics在自己的文件中写入Event Hub中的每个条目？或者可能会限制文件的大小？
3. 有没有办法从Stream Analytics设置文件的名称？如果是这样，如果名称已存在，是否有办法覆盖文件？
4. 我还注意到文件一旦创建就可以使用，它是实时编写的，我可以在下载/显示文件时看到其中的数据截断。此外，在它完成之前，它不是有效的JSON。如果我在编写Data Lake文件（通过U-SQL）时会发生什么？它是否足够聪明，可以忽略最后一个条目，或者将其理解为一个不完整的对象数组？
5. 将JSON数据作为数组或每个对象存储在新行中是否更好？

也许我对我的问题采取了不好的方法，但我在Google Datastore中有一个庞大的数据集（来自Google的NoSQL解决方案）。我只能访问具有有限权限的帐户的数据存储区。我需要将这些数据存储在Data Lake上。因此，我创建了一个应用程序，将数据从数据存储区流式传输到事件中心，由Stream Analytics提取，后者记录了Data Lake中的文件。这是我第一次使用这三种技术，但似乎是最好的解决方案。这是我对ETL混乱的替代方案。

我很抱歉提出这么多问题。我希望有人帮助我。

提前致谢。

Answer 1

我只会回答文件方面：

1. 与许多非常小的文件相比，生成较大的文件以供日后处理通常更好。鉴于您使用的是JSON，我建议将文件限制为JSON提取器能够管理的大小，而不会耗尽内存（如果您决定使用基于DOM的解析器）。

2. 我会把它留给ASA专家。

3. 同上。

4. 答案取决于ASA如何编写JSON。客户端可以附加到文件，U-SQL应该只能看到已在密封扩展区中添加的文件中的数据。因此，如果ASA确保扩展区与JSON文档的末尾对齐，那么您应该只看到有效的JSON文档。如果没有，那么你可能会失败。

5. 这取决于您计划如何处理数据。请注意，如果您将其作为数组的一部分编写，则必须等到数组“关闭”，否则您的JSON解析器很可能会失败。对于并行化并且更加灵活＆＃34;，我可能每行都会获得一个JSON文档。