我正在设计数据工厂管道，以将数据从Azure SQL DB加载到Azure数据工厂。
我最初的加载/POC是一小部分数据，能够从SQL表加载到Azure DL。
现在，我想使用DF从SQL DB加载到Azure DL中的表数量巨大(甚至超过十亿(。MS文档提到了两个选项，即水印列和更改跟踪。假设我有一个"cust_transaction"表，它有数百万行，如果我加载到DL，那么它就会加载为"cust_ransaction.txt"。问题。
1( 将源数据从SQL DB增量加载到数据湖中的文件中的最佳设计是什么？
2( 如何将文件拆分或分区为更小的文件？
3( 我应该如何将源数据中的delta合并并加载到文件中？谢谢
您将需要多个文件。通常，我的数据湖有多个区域。第一个区域是Raw。它包含组织到实体/年/月/日文件夹中的源数据的副本，其中实体是SQL数据库中的一个表。通常，这些文件是增量加载。实体的每个增量加载都有一个类似于entity_YYYYMMDDHMMSS.txt的文件名(可能还有更多的信息(，而不仅仅是entity.txt。文件名中的时间戳是增量切片的末尾(数据中可能的最大插入或更新时间(，而不是尽可能地只是当前时间(有时它们相对相同，这并不重要，但我倾向于为批处理中的所有表获得一致的增量切片结束时间(。您可以通过参数化数据集中的文件夹和文件来实现文件名中的日期文件夹和时间戳。
Melissa Coates有两篇关于Azure数据湖的好文章：数据湖中的区域和数据湖用例与规划。她的命名惯例与我的有点不同，但我们都会告诉你要保持一致。我会先将增量加载文件放在Raw中。它应该反映从源加载的增量数据。如果您需要一个合并版本，可以使用数据工厂或U-SQL(或您选择的工具(完成，并在标准化原始区域中着陆。数据湖中的小文件存在一些性能问题，因此整合可能很好，但这完全取决于您在将数据放到那里后计划如何处理。大多数用户不会访问原始区域中的数据，而是使用标准化原始区域或Curated区域的数据。此外，我希望Raw是一个不可变的存档，我可以从中重新生成其他区域的数据，所以我倾向于在它落地时将其留在文件中。但如果你发现你需要在那里进行整合，那也没关系。
更改跟踪是获取更改的可靠方法，但我不喜欢他们示例中的命名约定/文件组织。我会确保你的文件名上有实体名和时间戳。它们有Incremental-[PipelineRunID]。我更喜欢[Entity]_[YYYYMMDDHHMMSS]_[TriggerID].txt(或者关闭运行ID(，因为它对其他人来说信息更丰富。我还倾向于使用触发器ID，而不是管道RunID。触发器ID跨该触发器实例(批处理(中执行的所有包，而管道RunID特定于该管道。
如果你不能进行更改跟踪，水印是好的。我通常无法将更改跟踪添加到我的源中，必须使用水印。问题是您相信应用程序的修改日期是准确的。是否有更新行而不更改修改日期的情况？当插入一行时，修改的日期是否也会更新，或者您是否必须检查两列才能获得所有新的和更改的行？当我们不能使用变更跟踪时，这些都是我们必须考虑的问题。
总结：
- 增量加载并智能命名增量文件
- 如果您需要数据湖中的表的当前版本，则该文件是标准化原始区域或Curated区域中的一个单独文件