具有文件分區的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特定於該管道。

如果您無法進行更改跟蹤，則可以使用水印。 我通常無法將更改跟蹤添加到源中，而必須添加水印。 問題是您相信該應用程序的修改日期是正確的。 有沒有什么時候更新過一行並且修改過的日期沒有更改？ 當插入一行時，修改日期也會更新嗎？還是您需要檢查兩列以獲取所有新行和更改過的行？ 這些是我們無法使用變更跟蹤時必須考慮的事項。

總結一下：

• 增量加載並智能地命名增量文件
• 如果您需要數據湖中表的當前版本，則在“標准原始區域”或“策划區域”中這是一個單獨的文件。