我正在设计数据工厂管道以将数据从 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) 我应该如何将源数据中的增量合并并加载到文件中？ 谢谢。
【问题讨论】：
标签： azure azure-data-lake
您将需要多个文件。通常，我的数据湖有多个区域。第一个区域是 Raw。它包含组织到实体/年/月/日文件夹中的源数据的副本，其中实体是 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 中。它应该反映从源加载的增量数据。如果您需要合并版本，可以使用数据工厂或 U-SQL（或您选择的工具）完成并登陆标准化原始区域。有一些 performance issues 带有数据湖中的小文件，因此整合可能会很好，但这完全取决于您将数据放到那里后打算如何处理数据。大多数用户不会访问 RAW 区域中的数据，而是使用来自标准化原始区域或策划区域的数据。另外，我希望 Raw 成为一个不可变的存档，我可以从中重新生成其他区域的数据，所以我倾向于在它登陆时将它留在文件中。但如果你发现你需要在那里整合，那很好。
更改跟踪是获取更改的可靠方法，但我不喜欢他们在example 中的命名约定/文件组织。我会确保您的文件名上有实体名称和时间戳。他们有增量 - [PipelineRunID]。我更喜欢[Entity]_[YYYYMMDDHHMMSS]_[TriggerID].txt（或关闭运行 ID），因为它对其他人提供更多信息。我也倾向于使用触发器 ID 而不是管道 RunID。触发器 ID 跨在该触发器实例（批处理）中执行的所有包中，而管道 RunID 特定于该管道。
如果您无法进行更改跟踪，则水印很好。我通常无法将更改跟踪添加到我的源中，并且必须使用水印。问题是您相信应用程序的修改日期是准确的。是否有过更新行而修改日期未更改的情况？插入一行时，修改日期是否也更新了，还是您必须检查两列才能获取所有新行和更改行？当我们不能使用变更跟踪时，这些是我们必须考虑的事情。
总结一下：
【讨论】：