具有文件分区的Azure Data Lake增量加载

Question

我正在设计数据工厂管道，以将数据从Azure SQL DB加载到Azure数据工厂。

我最初的加载/ POC是一小部分数据，并且能够从SQL表加载到Azure DL。

现在，我想使用DF从SQL DB加载到Azure DL的表数量巨大（甚至超过十亿）。 MS docs提到了两个选项，即水印列和更改跟踪。 假设我有一个“ cust_transaction”表，该表具有数百万行，如果我加载到DL，则它将作为“ cust_transaction.txt”加载。 问题。

1）将SQL DB中的源数据增量加载到数据湖中的该文件中的最佳设计是什么？

2）如何将文件分割或分割为较小的文件？

3）如何合并源数据中的增量并将其加载到文件中？ 谢谢。

Answer 1

您将需要多个文件。 通常，我的数据湖有多个区域。 第一个区域是Raw。 它包含组织到entity / year / month / day文件夹中的源数据的副本，其中，entity是SQL DB中的表。 通常，这些文件是增量负载。 实体的每个增量加载都具有类似于Entity_YYYYMMDDHHMMSS.txt的文件名（甚至可能包含更多信息），而不仅仅是Entity.txt。 文件名中的时间戳记是增量片的结尾（数据中可能的最大插入或更新时间），而不是可能的时候只是当前时间（有时它们是相对相同的，没关系，但是我倾向于获得我批次中所有表的一致增量切片结束时间）。 通过参数化数据集中的文件夹和文件，可以在文件名中获得日期文件夹和时间戳。

梅利莎·科茨（Melissa Coates）在Azure Data Lake上有两篇不错的文章：Data Lake中的区域和Data Lake用例与计划 。 她的命名约定与我的命名约定有所不同，但是我们两个都告诉您保持一致。 我将首先在Raw中加载增量加载文件。 它应反映从源加载的增量数据。 如果您需要合并的版本，则可以使用Data Factory或U-SQL（或您选择的工具）来完成并合并到Standardized Raw区域中。 数据湖中的小文件存在一些性能问题 ，因此合并可能会很好，但是这完全取决于您将数据放到那里后打算如何处理 。 大多数用户不会使用RAW区域中的数据，而是使用标准化原始或策展区域中的数据。 另外，我希望Raw成为一个不变的档案，我可以从该档案中重新生成其他区域中的数据，因此我倾向于在着陆时将其保留在文件中。 但是，如果您发现需要在那儿进行整合，那很好。

更改跟踪是获取更改的可靠方法，但是我不喜欢其示例中的命名约定/文件组织。 我将确保您的文件名上具有实体名称和时间戳。 它们具有增量-[PipelineRunID]。 我希望使用[Entity]_[YYYYMMDDHHMMSS]_[TriggerID].txt （或保留运行ID），因为它对其他人更有帮助。 我也倾向于使用触发器ID而不是管道RunID。 触发器ID遍历在该触发器实例（批处理）中执行的所有程序包，而管道RunID特定于该管道。

如果您无法进行更改跟踪，则可以使用水印。 我通常无法将更改跟踪添加到源中，而必须添加水印。 问题是您相信该应用程序的修改日期是正确的。 有没有什么时候更新过一行并且修改过的日期没有更改？ 当插入一行时，修改日期也会更新吗？还是您需要检查两列以获取所有新行和更改过的行？ 这些是我们无法使用变更跟踪时必须考虑的事项。

总结一下：

• 增量加载并智能地命名增量文件
• 如果您需要数据湖中表的当前版本，则在“标准原始区域”或“策划区域”中这是一个单独的文件。