使用 Azure Data Lake Storage Gen2 的最佳做法
本文提供最佳做法指導方針，協助您最佳化效能、降低成本，以及保護啟用 Data Lake Storage Gen2 的 Azure 儲存體帳戶。
如需有關結構化資料湖的一般建議，請參閱下列文章：
尋找文件
Azure Data Lake Storage Gen2 不是專用的服務或帳戶類型。 它是一組支援高輸送量分析工作負載的功能。 Data Lake Storage Gen2 文件提供使用這些功能的最佳做法和指引。 如需帳戶管理的所有其他層面，例如設定網路安全性、設計高可用性和災害復原，請參閱 Blob 儲存體文件內容。
評估功能支援和已知問題
當您將帳戶設定為使用 Blob 儲存體功能時，請使用下列模式。
請參閱 Azure 儲存體帳戶中的 Blob 儲存體功能支援一文，以判斷您的帳戶是否完全支援某項功能。 在啟用 Data Lake Storage Gen2 的帳戶中，尚不支援某些功能或部分支援某些功能。 功能支援會一直擴充，因此請務必定期檢閱本文中的更新資訊。
請參閱使用 Azure Data Lake Storage Gen2 的已知問題一文，了解您要使用的功能是否有任何限制或特殊指引。
掃描功能文章，以取得啟用 Data Lake Storage Gen2 的帳戶專屬指引。
了解文件中使用的術語
當您在內容集之間移動時，您會發現有些術語略有不同。 例如，Blob 儲存體文件中強調說明的內容即使用 blob 一詞代替檔案。 從技術上來說，擷取至儲存體帳戶的檔案會變成帳戶中的 blob。 因此，這是正確的用詞。 不過，如果您習慣使用「檔案」一詞，則 Blob 一詞可能會造成混淆。 您也會看到文件中使用容器一詞來參照檔案系統。 請將這些字詞視為同義詞。
考慮進階版
如果您的工作負載需要低一致性延遲，且/或每秒需要大量的輸入輸出作業 (IOP)，請考慮使用進階版區塊 blob 儲存體帳戶。 這種類型的帳戶可透過高效能硬體提供資料。 資料會儲存在固態硬碟 (SSD) ，其已針對低延遲進行優化。 相較於傳統硬碟，SSD 提供更高的輸送量。 進階效能的儲存成本較高，但交易成本較低。 因此，如果您的工作負載執行大量交易，進階效能區塊 Blob 帳戶可能經濟實惠。
如果您的儲存體帳戶要用於分析，則強烈建議您使用 Azure Data Lake Storage Gen2 以及進階版區塊 Blob 儲存體帳戶。 使用進階版區塊 blob 儲存體帳戶以及啟用 Data Lake Storage 的帳戶此一組合，稱為 Azure Data Lake Storage 進階層。
最佳化資料擷取
從來源系統擷取資料時，來源硬體、來源網路硬體或儲存體帳戶的網路連線可能會是瓶頸。
來源硬體
無論您是在 Azure 中使用內部部署機器還是虛擬機器 (VM)，請務必謹慎選取適當的硬體。 若是磁碟硬體，請考慮使用固態硬碟 (SSD)，然後挑選主軸速度更快的磁碟硬體。 若是網路硬體，請盡可能使用最快速的網路介面控制器 (NIC)。 在 Azure 上，我們建議使用 Azure D14 VM，配備功能強大的適用磁碟和網路硬體。
儲存體帳戶的網路連線能力
您的來源資料與儲存體帳戶之間的網路連線有時可能是瓶頸。 當您的來源資料是內部部署時，請考慮使用與 Azure ExpressRoute 的專用連結。 如果您的來源資料是在 Azure 中，當資料所在的 Azure 區域與啟用 Data Lake Storage Gen2 的帳戶相同時，效能最佳。
設定最大平行處理的資料擷取工具
若要達到最佳效能，請盡可能平行執行最大量的讀取和寫入，以使用所有可用的輸送量。
下表彙總了幾個常用擷取工具的重要設定。
| 工具 | 設定 |
|---|---|
| DistCp | -m (mapper) |
| Azure Data Factory | parallelCopies |
| Sqoop | fs.azure.block.size、-m (mapper) |
注意
擷取作業的整體效能取決於您用來擷取資料的工具特有的其他因素。 如需最佳最新指引，請參閱您要使用的每項工具適合的文件。
您可以調整帳戶以提供所有分析案例需要的輸送量。 依預設，啟用 Data Lake Storage Gen2 的帳戶會在其預設設定中提供足夠的輸送量，以滿足各種使用案例類別的需求。 如果您遇到預設限制，您可以聯絡 Azure 支援，設定帳戶提供更多輸送量。
結構資料集
考慮預先規劃資料的結構。 檔案格式、檔案大小和目錄結構都會影響效能和成本。
檔案格式
您可以擷取各種格式的資料。 資料可能會以人類可讀取的格式 (例如 JSON、CSV 或 XML) 或壓縮的二進位格式 (例如 .tar.gz) 來顯示。 資料也有各種不同的大小。 資料可以由大型檔案組成 (數 TB)，例如從內部部署系統匯出 SQL 資料表的資料。 資料也可能有大量小型檔案組成 (數 KB)，例如來自物聯網 (IoT) 解決方案的即時事件資料。 您可以選擇適當的檔案格式和檔案大小，以最佳化效率和成本。
Hadoop 支援的一組檔案格式，可以最佳化結構化資料的儲存和處理。 一些常見的格式有 Avro、arquet 和最佳化資料列單欄式 (ORC) 格式。 這些格式都是機器可讀取的二進位檔案格式， 其會進行壓縮以協助您管理檔案大小， 且每個檔案均有內嵌的結構描述，可用於自行說明。 這些格式之間的差異在於資料的儲存方式。 Avro 會以資料列格式儲存資料，而 Parquet 和 ORC 格式會以單欄式格式儲存資料。
如果 I/O 模式的大量寫入作業較多，或查詢模式偏好完整擷取多列記錄，請考慮使用 Avro 檔案格式。 例如，Avro 格式適用於訊息匯流排，例如事件中樞或 Kafka，可連續寫入多個事件/訊息。
如果 I/O 模式的大量讀取作業較多，或查詢模式著重於記錄中的資料行子集，請考慮使用 Parquet 和 ORC 檔案格式。 讀取交易可以最佳化以擷取特定資料行，而不是讀取整個記錄。
Apache Parquet 是一種開放原始碼檔案格式，可最佳化讀取大量分析管線。 Parquet 的單欄式儲存結構可讓您略過不相關的資料。 您的查詢會更有效率，因為可以縮小從儲存體傳送到分析引擎的資料範圍。 此外，因為將類似的資料類型 (指資料行的資料) 儲存在一起，所以 Parquet 支援有效資料壓縮和編碼配置，以降低資料儲存成本。 Azure Synapse Analytics、Azure Databricks 和 Azure Data Factory 之類服務的原生函式可利用 Parquet 檔案格式。
檔案大小
較大的檔案可提高效能並降低成本。
一般而言，分析引擎 (例如 HDInsight) 會產生每個檔案的額外負荷，涉及的工作包括列出、檢查存取，以及執行各種中繼資料作業。 如果您將資料儲存為許多小型檔案，這可能會對效能造成負面影響。 一般情況下，將您的資料組織成較大大小的檔案，以提升效能 (大小可從 256 MB 到 100 GB)。 某些引擎和應用程式可能無法有效率地處理大小超過 100 GB 的檔案。
增加檔案大小也可降低交易成本。 讀取和寫入作業會以 4 MB 增量方式計費，因此無論檔案是否包含 4 MB 或只有幾 KB，您都必須支付作業的費用。 如需價格資訊，請參閱 Azure Data Lake Storage 價格。
有時候，資料管線對於具有大量小型檔案的未經處理資料，具有受限制的控制權。 一般來說，建議系統要有某種程許可以將小型檔案彙總成較大的檔案，以供下游應用程式使用。 如果您要即時處理資料，可以使用即時串流引擎 (例如 Azure 串流分析或 Spark 串流) 搭配訊息代理程式 (例如事件中樞或 Apache Kafka)，將您的資料儲存為較大的檔案。 當您將小型檔案彙總成較大的檔案時，請考慮以讀取最佳化格式 (例如 Apache Parquet) 儲存以供下游處理使用。
目錄結構
每個工作負載對於資料的使用方式都有不同的需求，但在使用物聯網 (IoT)、批次案例或最佳化時間序列資料時，必須考慮一些常見的配置。
IoT 結構
在 IoT 工作負載中，可能會有大量要擷取的資料，而且範圍橫跨大量產品、裝置、組織和取用者。 請務必為下游取用者預先規劃目錄配置，以利組織、保護和有效率地處理資料。 一般可考慮的範本可能會使用下列配置：
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
例如，為英國境內的飛機引擎置入遙測資料可能如以下結構所示：
- UK/Planes/BA1293/Engine1/2017/08/11/12/
在此範例中，將日期放在目錄結構的結尾，您就可以使用 ACL，更輕鬆地保護特定使用者和群組的區域和主體。 如果您一開始就放置資料結構，就會比較難保護這些區域和主體。 例如，如果您只想要提供 UK 資料或特定平面的存取權，您必須在每個小時目錄下的大量目錄套用不同的權限。 隨著時間推移，此結構也會以指數方式增加目錄數量。
批次作業結構
批次處理中常用的方法是將資料放入 "in" 目錄中。 然後，資料處理好後，將新的資料放入 "out" 目錄，以供下游程序使用。 此目錄結構有時會用於需要對個別檔案進行處理的作業，而且可能不需要大量平行處理大型資料集。 如同上述建議的 IoT 結構，好的目錄結構都使用區域和內容這類事項 (例如，組織、產品或生產者) 作為父層級目錄。 請考慮在結構中使用日期和時間，可在處理時具有較佳的組織性、可篩選的搜尋、安全性及自動化。 日期結構的細微性層級取決於資料上傳或處理的間隔，例如每小時、每天或甚至是每個月。
有時後，檔案處理會因為資料損毀或未預期的格式而不成功。 在這種情況下，/bad 資料夾就會對目錄結構大有助益，可以將檔案移至該資料夾並進行進一步檢查。 批次作業可能也會處理這些「不良」檔案的報告或通知，以進行手動介入。 請參考下列的範本結構：
- {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/
例如，一間行銷公司每天從他們位於北美洲的客戶接收消費者更新的資料擷取。 而處理前和處理後的資料可能會看起來像以下程式碼片段：
- NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
- NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv
對於直接將批次資料處理至 Hive 或傳統 SQL 資料庫的常見案例，則不需要 /in 或 /out 目錄，因為輸出已進入 Hive 資料表或外部資料庫的個別資料夾中。 例如，每日從客戶擷取的資料會進入各自的目錄。 然後，服務 (例如 Azure Data Factory、Apache Oozie 或 Apache Airflow) 會觸發每日 Hive 或 Spark 工作，以處理資料並將寫入 Hive 資料表。
時間序列資料結構
對於 Hive 工作負載，時間序列資料的磁碟分割剪除有助於某些查詢僅讀取資料的子集，進而改善效能。
擷取時間序列資料的這些管線，通常會以結構化的檔案和資料夾命名方式來處理檔案。 以下是常見的範例，依日期結構化資料：
/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv
請注意，日期時間資訊會同時在資料夾和檔案名稱中顯示。
對於日期和時間，以下是常見的模式
/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv
同樣地，您對於資料夾和檔案組織的選擇，應該針對較大的檔案大小以及每個資料夾中合理的檔案數目進行最佳化。
設定安全性
首先，查看 Blob 儲存體的安全性建議一文中的建議。 您可以找到有關如何保護資料免於意外或惡意刪除、保護防火牆後的資料，以及使用 Microsoft Entra ID 做為身分識別管理基礎的最佳做法指引。
然後，請參閱 Azure Data Lake Storage Gen2 中的存取控制模型一文，以取得啟用 Data Lake Storage Gen2 的帳戶專用指引。 本文可協助您了解如何使用 Azure 角色型存取控制 (Azure RBAC) 角色以及存取控制清單 (ACL)，以在階層式檔案系統中強制執行目錄和檔案的安全性權限。
擷取、處理和分析
若要將資料擷取到啟用 Data Lake Storage Gen2 的帳戶，有許多不同的資料來源和各種不同的擷取方式。
例如，您可以從 HDInsight 和 Hadoop 叢集擷取大型資料集，或用於建立應用程式原型的小型特定資料集。 您可以擷取由各種來源 (例如應用程式、裝置和感應器) 產生的串流資料。 對於這類型的資料，您可以使用各種工具，按照事件即時擷取和處理資料，然後將資料分批寫入帳戶。 您也可以擷取包含資訊 (例如，網頁要求的歷程) Web 伺服器記錄。 針對記錄資料，請考慮撰寫自訂指令碼或應用程式來上傳這些資料，這樣一來，您就可以彈性選擇將資料上傳元件納入較大的大型資料應用程式中。
一旦帳戶中有可用的資料，您就可以對該資料執行分析、建立視覺效果，甚至將資料下載到本機電腦或其他存放庫 (例如 Azure SQL 資料庫或 SQL Server 執行個體)。
下表建議可用來擷取、分析、視覺化及下載資料的工具。 使用下表中的連結，尋找如何設定及使用每項工具的指引。
| 目的 | 工具與工具指引 |
|---|---|
| 擷取特定資料 | Azure 入口網站、Azure PowerShell、Azure CLI、REST、Azure 儲存體總管、Apache DistCp、AzCopy |
| 擷取關聯式資料 | Azure Data Factory |
| 擷取 Web 伺服器記錄 | Azure PowerShell、Azure CLI、REST、Azure SDK (.NET、Java、Python 及 Node.js)、Azure Data Factory |
| 從 HDInsight 叢集擷取 | Azure Data Factory、Apache DistCp、AzCopy |
| 從 Hadoop 叢集擷取 | Azure Data Factory、Apache DistCp、適用於 Azure 的 WANdisco LiveData Migrator、Azure 資料箱 |
| 擷取大型資料集 (數 TB) | Azure ExpressRoute |
| 處理和分析資料 | Azure Synapse Analytics、Azure HDInsight、Databricks |
| 顯現資料 | Power BI、Azure Data Lake Storage 查詢加速 |
| 下載資料 | Azure 入口網站、PowerShell、Azure CLI、REST、Azure SDK (.NET、Java、Python 及 Node.js)、Azure 儲存體總管、AzCopy、Azure Data Factory、Apache DistCp |
注意
此表格並未反映支援 Data Lake Storage Gen2 的 Azure 服務完整清單。 如需支援的 Azure 服務清單及其服務層級，請參閱支援 Azure Data Lake Storage Gen2 的 Azure 服務。
監視遙測
監視使用和效能是操作服務的重要一環。 範例包括頻繁的作業、具有高延遲的作業，或導致服務端節流的作業。
儲存體帳戶的所有遙測資料都可透過 Azure 監視器的 Azure 儲存體記錄取得。 這項功能會整合您的儲存體帳戶與記錄分析和事件中樞，同時讓您將記錄封存至另一個儲存體帳戶。 若要查看計量和資源記錄及其相關結構描述的完整清單，請參閱 Azure 儲存體監視資料參考。
您選擇用來儲存記錄的位置，取決於您打算如何存取記錄。 例如，如果您想要以近乎即時的方式存取記錄，而且要能將記錄中的事件關聯到 Azure 監視器中的其他計量，則可以將記錄儲存在 Log Analytics 工作區中。 然後，使用 KQL 和作者查詢來查詢您的記錄，這會列舉工作區中的 StorageBlobLogs 資料表。
如果您想要儲存近乎即時的查詢記錄並長期保留，則可以設定診斷設定，將記錄傳送至 Log Analytics 工作區和儲存體帳戶。
如果您想要透過其他查詢引擎 (例如 Splunk) 存取記錄，您可以設定診斷設定，將記錄傳送至事件中樞，並將記錄從事件中樞擷取至您選擇的目的地。
您可以透過 Azure 入口網站、PowerShell、Azure CLI 和 Azure Resource Manager 範本，啟用 Azure 監視器中的 Azure 儲存體記錄。 對於大規模部署，Azure 原則可以與完整的補救工作支援搭配使用。 如需詳細資訊，請參閱 ciphertxt/AzureStoragePolicy。