使用文件分区的 Azure Data Lake 增量加载

Question

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

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

现在，我想使用 DF 将大量表(甚至超过 10 亿)从 SQL DB 加载到 Azure DL。MS 文档提到了两个选项，即水印列和更改跟踪。假设我有一个包含数百万行的“cust_transaction”表，如果我加载到 DL，那么它会加载为“cust_transaction.txt”。问题。

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

2) 如何将文件拆分或分区为更小的文件？

3) 我应该如何将源数据中的增量合并并加载到文件中？谢谢。

Answer 1

您将需要多个文件。通常，我的数据湖有多个区域。第一个区域是原始区域。它包含组织到实体/年/月/日文件夹中的源数据的副本，其中实体是 SQL 数据库中的表。通常，这些文件是增量加载。实体的每个增量加载都有一个类似于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 。她的命名约定与我的有点不同，但我们都会告诉你要保持一致。我首先会将增量加载文件放入原始文件中。它应该反射(reflect)从源加载的增量数据。如果您需要一个合并版本，可以使用数据工厂或 U-SQL(或您选择的工具)来完成，并放置在标准化原始区域中。有一些performance issues对于数据湖中的小文件，因此整合可能会很好，但这完全取决于您计划在将数据放在那里后如何处理数据。大多数用户不会访问 RAW 区域中的数据，而是使用标准化原始区域或策划区域中的数据。另外，我希望 Raw 成为一个不可变的存档，我可以从中重新生成其他区域中的数据，因此我倾向于将其保留在文件中。但如果你发现你需要在那里巩固，那就没问题了。

更改跟踪是获取更改的可靠方法，但我不喜欢他们 example 中的命名约定/文件组织。 。我会确保您的文件名上有实体名称和时间戳。他们有增量 - [PipelineRunID]。我更喜欢 [Entity]_[YYYYMMDDHHMMSS]_[TriggerID].txt (或保留运行 ID)，因为它对其他人来说信息更丰富。我还倾向于使用触发器 ID 而不是管道 RunID。触发器 ID 跨在该触发器实例(批处理)中执行的所有包，而管道 RunID 特定于该管道。

如果您无法进行更改跟踪，则水印没问题。我通常无法向我的源添加更改跟踪，并且必须使用水印。问题在于您相信应用程序的修改日期是准确的。是否存在更新行而修改日期未更改的情况？插入行时，修改日期是否也会更新，或者您是否必须检查两列才能获取所有新行和更改的行？当我们无法使用变更跟踪时，这些是我们必须考虑的事情。

总结:

• 增量加载并智能命名增量文件
• 如果您需要数据湖中表格的当前版本，则该文件是标准化原始区域或精选区域中的单独文件。