我正在设计Data Factory管道，以将数据从Azure SQL DB加载到Azure Data Factory。
我的初始加载/ POC是一小部分数据，并且能够从SQL表加载到Azure DL。
现在，我想使用DF从SQL DB加载到Azure DL的表数量非常大（甚至超过十亿）。 MS文档提到了两个选项，即水印列和更改跟踪。 假设我有一个“ cust_transaction”表，该表具有数百万行，如果我加载到DL，则它将作为“ cust_transaction.txt”加载。 问题。
1）从SQL DB将源数据增量加载到数据湖中该文件的最佳设计是什么？
2）如何将文件拆分或分割为较小的文件？
3）如何合并源数据中的增量并将其加载到文件中？ 谢谢。
答案 0 :(得分：2)
您将需要多个文件。通常，我的数据湖有多个区域。第一个区域是Raw。它包含组织到entity / year / month / day文件夹中的源数据的副本，其中，entity是SQL DB中的表。通常，这些文件是增量负载。实体的每个增量加载都具有类似于Entity_YYYYMMDDHHMMSS.txt的文件名（甚至可能包含更多信息），而不仅仅是Entity.txt。文件名中的时间戳记是增量片的结尾（数据中可能的最大插入或更新时间），而不是可能的时候只是当前时间（有时它们是相对相同的，没关系，但是我倾向于获得我批次中所有表的一致增量切片结束时间）。您可以通过parameterizing the folder and file in the dataset在文件名中获得日期文件夹和时间戳。
Melissa Coates在Azure Data Lake上有两篇不错的文章：Zones in a Data Lake和Data Lake Use Cases and Planning。她的命名约定与我的命名约定有所不同，但是我们两个都告诉您保持一致。我将首先在Raw中加载增量加载文件。它应反映从源加载的增量数据。如果您需要合并的版本，则可以使用Data Factory或U-SQL（或您选择的工具）来完成并合并到Standardized Raw区域中。在数据湖中有一些performance issues带有小文件，因此合并可能会很好，但是这完全取决于您将数据放到那里后打算如何处理。大多数用户不会使用RAW区域中的数据，而是使用标准化原始或策展区域中的数据。另外，我希望Raw成为一个不变的档案，我可以从该档案中重新生成其他区域中的数据，因此我倾向于在着陆时将其保留在文件中。但是，如果您发现需要在那儿进行整合，那很好。
更改跟踪是获取更改的可靠方法，但是我不喜欢他们的example中的命名约定/文件组织。我将确保您的文件名上具有实体名称和时间戳。它们具有增量-[PipelineRunID]。我希望使用[Entity]_[YYYYMMDDHHMMSS]_[TriggerID].txt（或保留运行ID），因为它对其他人更有帮助。我也倾向于使用触发器ID而不是管道RunID。触发器ID遍历在该触发器实例（批处理）中执行的所有程序包，而管道RunID特定于该管道。
如果您无法进行更改跟踪，则可以使用水印。我通常无法将更改跟踪添加到源中，而必须添加水印。问题是您相信该应用程序的修改日期是正确的。有没有什么时候更新过一行并且修改过的日期没有更改？当插入一行时，修改日期也会更新吗？还是您需要检查两列以获取所有新行和更改过的行？这些是我们无法使用变更跟踪时必须考虑的事项。
总结：