Data Lake 區域和容器

發行項
10/10/2023

在將資料放入資料湖之前，請務必先規劃資料結構。當您有方案時，可以有效地使用安全性、資料分割和處理。

如需 Data Lake 的概觀，請參閱 Azure Data Lake 儲存體概觀以進行雲端規模分析。

概觀

您的三個 Data Lake 帳戶應該與一般 Data Lake 層一致。

Lake number	圖層	容器編號	容器名稱
1	Raw	1	登陸
1	Raw	2	一致性
2	擴充	1	標準化
2	策展	2	資料產品
3	部署	1	分析沙箱
3	部署	#	Synapse 主要儲存體編號

上表顯示我們建議每個資料登陸區域的標準容器數目。這項建議的例外狀況是容器中的資料需要不同的虛刪除原則。這些需求會決定您對更多容器的需求。

注意

每個資料登陸區域都會說明三個數據湖。 Data Lake 橫跨三個 Data Lake 帳戶、多個容器和資料夾，但它代表資料登陸區域的一個邏輯資料湖。

視您的需求而定，您可能會想要將原始、擴充和策劃的圖層合併成一個儲存體帳戶。為數據取用者保留另一個名為「開發」的儲存體帳戶，以帶來其他有用的資料產品。

如需分隔 Data Lake 帳戶的詳細資訊，請參閱邏輯 Data Lake 中的儲存體帳戶。

使用階層式名稱空間功能啟用Azure 儲存體，可讓您有效率地管理檔案。階層式名稱空間功能會將帳戶內的物件和檔案組織成目錄階層和巢狀子目錄。此階層的組織方式與電腦上的檔案系統相同。

當資料無從驗證的擷取引擎或上線應用程式註冊新的記錄系統時，它會在原始、擴充和標準化的資料層中建立容器中所需的資料夾。如果來源對齊的資料應用程式內嵌資料，您的資料應用程式小組需要您的資料登陸區域小組來建立資料夾和安全性群組。將服務主體名稱或受控識別放入正確的群組，並指派許可權等級。為您的資料登陸區域和資料應用程式小組記錄此程式。

如需小組的詳細資訊，請參閱瞭解 Azure 中雲端規模分析的角色和小組。

每個資料產品都應該在資料產品容器中具有資料產品小組所擁有的兩個資料夾。

在標準化容器的擴充層中，每個來源系統有兩個資料夾，除以分類。透過此結構，您的小組可以個別儲存具有不同安全性和資料分類的資料，並指派不同的安全性存取權。

您的標準化容器需要機密或低於 資料的一般資料夾 ，以及 個人資料的敏感性 資料夾。使用存取控制清單控制這些資料夾的存取權。您可以建立資料集並移除所有個人資料，並將其儲存在一般資料夾中。您可以有另一個資料集，其中包含敏感性個人資料資料夾中的所有個人資料。

ACL 和 Microsoft Entra 群組的組合會限制資料存取。這些清單和群組可控制其他群組可以和無法存取的內容。資料擁有者和資料應用程式小組可以核准或拒絕其資料資產的存取權。

如需詳細資訊，請參閱資料存取管理和受限制的資料。

警告

某些軟體產品不支援掛接 Data Lake 容器的根目錄。由於這項限制，原始、策劃、擴充和開發層中的每個 Data Lake 容器都應該包含一個分支至多個資料夾的單一資料夾。請仔細設定資料夾許可權。當您從根目錄建立新資料夾時，父目錄的預設 ACL 會決定子目錄的預設 ACL 並存取 ACL。子檔案的 ACL 沒有預設的 ACL。

如需詳細資訊，請參閱 Azure Data Lake 儲存體 Gen2 中的存取控制清單（ACL）。

原始層或資料湖一

將原始層視為儲存其自然和原始狀態資料的水庫。它未經過濾和未淨化。您可以將資料儲存為其原始格式，例如 JSON 或 CSV。或者，將檔案內容儲存為壓縮檔案格式的資料行，例如 Avro、Parquet 或 Databricks Delta Lake，可能很符合成本效益。

此原始資料是不可變的。將您的原始資料鎖定，如果您授與任何取用者的許可權，自動化或人為，請確定它們是唯讀的。您可以使用每個來源系統一個資料夾來組織此層。將每個擷取進程寫入權限授與只有其相關聯的資料夾。

當您從來源系統將資料載入原始區域時，您可以選擇執行下列動作：

完整載入 以擷取完整的資料集。
差異載入 僅載入已變更的資料。

在資料夾結構中指出您選擇的載入模式，以簡化資料取用者的使用。

每個來源對齊資料應用程式的來源系統原始資料，或自動擷取引擎來源會落在完整資料夾或差異資料夾中。每個擷取程式都應該只有其相關聯資料夾的寫入權限。

完整載入和差異負載之間的差異如下：

完整載入 - 如果下列狀況，可以從來源完成資料上線：
- 來源的資料量很小。
- 來源系統不會維護時間戳記欄位，可識別是否已新增、更新或刪除資料。
- 來源系統每次都會覆寫完整的資料。
差異載入 - 來源的累加式資料可在下列狀況下上線：
- 來源的資料量很大。
- 來源系統會維護時間戳記欄位，以識別資料是否已新增、更新或刪除。
- 來源系統會建立及更新資料變更的檔案。

原始資料湖是由登陸和一致性容器所組成。每個容器都會使用其用途專屬的 100% 必要資料夾結構。

登陸容器配置

您的登陸容器會保留給來自已辨識來源系統的原始資料。您的資料無從驗證擷取引擎或來源對齊的資料應用程式會載入資料，其格式為未變更且原始支援的格式。

.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full

原始層一致性容器

原始層包含符合資料品質的資料。當資料複製到登陸容器時，會觸發資料處理和計算，將資料從登陸容器複製到一致性容器。在第一個階段中，資料會轉換成差異湖格式，並在輸入資料夾中登陸。當資料品質執行時，傳遞的記錄會複製到輸出檔案夾中。失敗登陸錯誤資料夾中的記錄。

.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}

提示

想想您可能需要從頭開始重建分析平臺的案例。請考慮重建下游讀取資料存放區所需的最細微資料。請確定您已針對重要元件備妥商務持續性和災害復原計畫。

擴充層或資料湖 2

將擴充層視為過濾層。它去除了殘留物，也可以涉及濃縮。

您的標準化容器會保存記錄和主機的系統。資料夾會先依主旨區域分割，再依實體分割。資料可在合併的資料分割資料表中取得，這些資料表已針對分析耗用量優化。

標準化容器

.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}

注意

此資料層會被視為銀層或讀取資料來源。此層中的資料沒有套用資料品質、差異湖轉換和資料類型對齊以外的轉換。

下圖顯示從來源資料到標準化容器的資料湖和容器流程。

策展圖層或資料湖二

您的策展層是您耗用量層。其已針對分析進行優化，而不是資料擷取或處理。策劃層可能會將資料儲存在反正規化的資料超市或星型架構中。

來自標準化容器的資料會轉換成提供給資料取用者的高價值資料產品。此資料具有結構。它可以依目前提供給取用者，例如資料科學筆記本，或透過另一個讀取資料存放區，例如 Azure SQL 資料庫。

使用 Spark 或 Data Factory 之類的工具進行維度模型化，而不是在您的資料庫引擎內執行。如果您想要讓您的湖成為單一事實來源，這種工具的使用就成為關鍵點。

如果您在 Lake 外部進行維度模型化，您可能會想要將模型發佈回您的 Lake 以取得一致性。此層不是資料倉儲的取代專案。其效能通常不適用於回應式儀表板或使用者和取用者互動式分析。此層最適合執行大規模、即興查詢或分析的內部分析師和資料科學家，或適用于沒有時間敏感報告需求的進階分析師。因為資料湖中的儲存體成本比資料倉儲低，所以在 Lake 中保留細微、低階的資料可能會符合成本效益。將匯總的資料儲存在您的倉儲中。使用 Spark 或 Azure Data Factory 產生這些匯總。將資料湖保存在資料湖中，再將其載入至資料倉儲。

此區域中的資料資產通常會受到高度控管且記錄良好。依部門或功能指派許可權，並依取用者群組或資料超市組織許可權。

資料產品容器

.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}

提示

當您將資料登陸到另一個讀取資料存放區時，例如 Azure SQL 資料庫，請確定您有該資料複本位於您策劃的資料中。您的資料產品使用者會引導您主要讀取資料存放區或 Azure SQL 資料庫實例，但如果您將資料提供給 Data Lake 中，也可以使用額外的工具來探索資料。

開發層或資料湖三

您的資料取用者可以將其他實用的資料產品，以及內嵌至標準化容器的資料。

在此案例中，您的資料平臺可以為這些取用者配置分析沙箱區域。在沙箱中，他們可以使用他們帶來的策劃資料和資料產品來產生寶貴的見解。例如，如果資料科學小組想要判斷新區域的最佳產品放置策略，他們可以從該區域的類似產品帶來其他資料產品，例如客戶人口統計和使用方式資料。小組可以使用此資料中的高價值銷售見解來分析產品市場適合和供應專案策略。

注意

分析沙箱區域是個人或一小群共同作業者的工作區。沙箱區域的資料夾有一組特殊的原則，可防止嘗試使用此區域作為生產解決方案的一部分。這些原則會限制可用的儲存體總計，以及可儲存資料的時間長度。

這些資料產品通常品質與精確度不明。它們仍分類為數據產品，但暫時性且僅與使用資料的使用者群組相關。

當這些資料產品成熟時，您的企業可以將這些資料產品提升到您策劃的資料層。若要讓資料產品小組負責新的資料產品，請為小組提供您策劃的資料區域專用資料夾。他們可以將新結果儲存在資料夾中，並與整個組織的其他小組共用。

注意

針對您建立的每個 Azure Synapse 工作區，請使用 Data Lake 3 建立容器作為主要儲存體。此容器會阻止 Azure Synapse 工作區干擾您策劃和擴充區域的輸送量限制。

流入產品和分析沙箱的資料流程範例

下圖會編譯本文中的資訊，並示範資料如何流向資料產品和分析沙箱。

下一步

Azure Data Lake 儲存體的重要考慮