編輯

共用方式為

巨量數據架構樣式

Azure Data Lake Analytics
Azure IoT

巨量數據架構的設計訴求是處理對傳統資料庫系統而言太大或複雜數據的擷取、處理和分析。

巨量數據架構樣式的邏輯圖表

巨量數據解決方案通常涉及下列一或多種工作負載類型：

  • 待用巨量數據源的批處理。
  • 即時處理移動中的巨量數據。
  • 巨量數據的互動式探索。
  • 預測性分析和機器學習。

大部分的巨量數據架構都包含下列部分或所有元件：

  • 數據源：所有巨量數據解決方案都是以一或多個數據源開頭。 範例包括：

    • 應用程式資料存放區，例如關係資料庫。
    • 應用程式所產生的靜態檔案，例如 Web 伺服器記錄檔。
    • 實時數據源，例如IoT裝置。

  • 數據記憶體：批處理作業的數據通常會儲存在分散式檔案存放區中，以各種格式保存大量大型檔案。 這類存放區通常稱為 Data Lake。 實作此記憶體的選項包括 Azure 記憶體中的 Azure Data Lake Store 或 Blob 容器。

  • 批處理：因為數據集太大，所以巨量數據解決方案通常必須使用長時間執行的批次作業來處理數據檔，才能篩選、匯總，否則準備數據以供分析。 這些作業通常涉及讀取來源檔案、處理來源檔案，以及將輸出寫入新檔案。 選項包括使用數據流、Microsoft Fabric 中的數據管線。

  • 即時訊息擷取：如果解決方案包含即時來源，架構必須包含擷取和儲存即時訊息以進行串流處理的方法。 這可能是簡單的數據存放區，其中傳入訊息會放入資料夾進行處理。 不過，許多解決方案都需要訊息擷取存放區作為訊息的緩衝區，並支援向外延展處理、可靠傳遞和其他消息佇列語意。 選項包括 Azure 事件中樞、Azure IoT 中樞和 Kafka。

  • 串流處理：擷取即時訊息之後，解決方案必須藉由篩選、匯總，以及準備數據進行分析來處理它們。 然後，處理過的數據流數據會寫入輸出接收。 Azure 串流分析會根據在未系結數據流上運作的永久執行 SQL 查詢，提供受控串流處理服務。 另一個選項是在 Microsoft Fabric 中使用即時智慧，可讓您在擷取數據時執行 KQL 查詢。

  • 分析數據存放區：許多巨量數據解決方案會準備數據進行分析，然後使用分析工具以結構化格式提供已處理的數據。 用來提供這些查詢的分析數據存放區可以是 Kimball 樣式的關係型數據倉儲，如大多數傳統商業智慧 （BI） 解決方案或具有獎章架構的 Lakehouse （Bronze、Silver 和 Gold） 中所見。 Azure Synapse Analytics 為大規模雲端式數據倉儲提供受控服務。 或者，Microsoft Fabric 提供您兩個選項 -- 倉儲和 Lakehouse -- 可分別使用 SQL 和 Spark 進行查詢。

  • 分析和報告：大部分巨量數據解決方案的目標是透過分析和報告來提供數據的見解。 為了讓用戶能夠分析數據，架構可能包含數據模型層，例如 Azure Analysis Services 中的多維度 OLAP Cube 或表格式數據模型。 它也可能支援自助 BI，在 Microsoft Power BI 或 Microsoft Excel 中使用模型化和視覺效果技術。 分析與報告也可以採用數據科學家或數據分析師的互動式數據探索形式。 在這些案例中，Microsoft Fabric 會提供筆記本之類的工具，讓使用者可以選擇 SQL 或他們所選擇的程式設計語言。

  • 協調流程：大部分的巨量數據解決方案都包含重複的數據處理作業、封裝在工作流程中、轉換源數據、在多個來源和接收之間移動數據、將數據載入分析數據存放區，或將結果直接推送至報表或儀錶板。 若要將這些工作流程自動化，您可以使用協調流程技術，例如 Azure Data Factory 或Microsoft網狀架構管線。

Azure 包含許多可用於巨量數據架構的服務。 它們大致分為兩個類別：

  • 受控服務，包括Microsoft網狀架構、Azure Data Lake Store、Azure Synapse Analytics、Azure 串流分析、Azure 事件中樞、Azure IoT 中樞和 Azure Data Factory。
  • 以 Apache Hadoop 平台為基礎的開放原始碼技術，包括 HDFS、HBase、Hive、Spark 和 Kafka。 這些技術可在 Azure HDInsight 服務中使用。

這些選項並非互斥，許多解決方案會結合開放原始碼技術與 Azure 服務。

使用此架構的時機

當您需要下列專案時，請考慮此架構樣式：

  • 儲存和處理磁碟區中的數據對於傳統資料庫而言太大。
  • 轉換非結構化數據以進行分析和報告。
  • 實時擷取、處理和分析未系結的數據串流，或低延遲。
  • 使用 Azure Machine Learning 或 Azure 認知服務。

好處

  • 技術選擇。 您可以混合和比對 HDInsight 叢集中的 Azure 受控服務和 Apache 技術，以利用現有的技能或技術投資。
  • 透過平行處理原則效能。 巨量數據解決方案會利用平行處理原則，以達到大量數據的高效能解決方案。
  • 彈性調整。 巨量數據架構中的所有元件都支援向外延展布建，讓您可以將解決方案調整為小型或大型工作負載，並只支付您使用的資源。
  • 與現有解決方案的互操作性。 巨量數據架構的元件也用於IoT處理和企業BI解決方案，讓您跨數據工作負載建立整合式解決方案。

挑戰

  • 複雜度。 巨量數據解決方案可能非常複雜，具有許多元件來處理來自多個數據源的數據擷取。 建置、測試及疑難解答巨量數據程式可能很困難。 此外，可能有多個系統必須用來優化效能的組態設定。
  • Skillset。 許多巨量數據技術都高度特製化，並使用不是較一般應用程式架構的典型架構和語言。 另一方面，巨量數據技術正在發展以更既定語言為基礎的新 API。
  • 技術成熟度。 巨量數據中使用的許多技術正在演進。 雖然Hive和spark等核心Hadoop技術已經穩定下來，但差異或冰山等新興技術卻帶來了廣泛的變化和增強功能。 相較於其他 Azure 服務，例如Microsoft Fabric 等受控服務相對年輕，而且可能會隨著時間而發展。
  • 安全性。 巨量數據解決方案通常依賴將所有靜態數據儲存在集中式數據湖中。 保護此數據的存取可能具有挑戰性，特別是當多個應用程式和平台必須內嵌和取用數據時。

最佳做法

  • 利用平行處理原則。 大部分的巨量數據處理技術會將工作負載分散到多個處理單位。 這需要建立靜態數據檔，並以可分割的格式儲存。 HDFS 等分散式文件系統可以優化讀取和寫入效能，而實際處理是由多個叢集節點平行執行，進而降低整體作業時間。 強烈建議使用可分割的數據格式，例如 Parquet。

  • 分割數據。 批處理通常會以週期性排程發生，例如每周或每月。 根據符合處理排程的時態期間，分割數據檔和數據結構，例如數據表。 這可簡化數據擷取和作業排程，並讓您更輕鬆地針對失敗進行疑難解答。 此外，Hive、spark 或 SQL 查詢中使用的數據分割數據表可以大幅改善查詢效能。

  • 套用讀取架構語意。 使用 Data Lake 可讓您結合多種格式檔案的記憶體，無論是結構化、半結構化還是非結構化。 使用 讀取架構 語意，此語意會在處理數據時將架構投影到數據上，而不是儲存數據時。 這會在解決方案中建置彈性，並防止數據驗證和類型檢查所造成的數據擷取期間發生瓶頸。

  • 就地處理數據。 傳統的 BI 解決方案通常會使用擷取、轉換和載入 （ETL） 程式將資料移至數據倉儲。 使用較大的磁碟區數據，以及更多樣化的格式，巨量數據解決方案通常會使用 ETL 的變化，例如轉換、擷取和載入 （TEL）。 使用這種方法，數據會在分散式數據存放區內進行處理，並將它轉換成所需的結構，再將轉換的數據移至分析數據存放區。

  • 平衡使用率和時間成本。 對於批處理作業，請務必考慮兩個因素：計算節點的每單位成本，以及使用這些節點完成作業的每分鐘成本。 例如，批次作業可能需要八個小時，且有四個叢集節點。 不過，作業可能只會在前兩個小時內使用這四個節點，之後只需要兩個節點。 在此情況下，在兩個節點上執行整個作業會增加作業總時間，但不會加倍，因此總成本會降低。 在某些商務案例中，較久的處理時間可能會比使用使用量過低的叢集資源成本更高。

  • 個別資源。 盡可能以工作負載為基礎來分隔資源，以避免在等候其他資源時使用一個工作負載等案例。

  • 協調數據擷取。 在某些情況下，現有的商務應用程式可能會將數據檔直接寫入 Azure 記憶體 Blob 容器中，以供下游服務取用，例如 Microsoft Fabric。 不過，您通常需要將內部部署或外部數據源的數據擷取協調到 Data Lake。 使用協調流程工作流程或管線，例如 Azure Data Factory 或 Microsoft Fabric 所支援的工作流程或管線，以可預測且集中管理的方式達成此目的。

  • 提早清除敏感數據，。 數據擷取工作流程應該在程式初期清除敏感數據，以避免將數據儲存在 Data Lake 中。

IoT 架構

物聯網 （IoT） 是巨量數據解決方案的特製化子集。 下圖顯示IoT的可能邏輯架構。 此圖表強調架構的事件串流元件。

IoT 架構 圖表

雲端閘道會使用可靠、低延遲的傳訊系統， 擷取雲端界限上的裝置事件。

裝置可能會直接將事件傳送至雲端閘道，或透過 現場閘道。 現場閘道是特製化裝置或軟體，通常與裝置共置，可接收事件，並將其轉送至雲端網關。 現場閘道也可以預先處理原始裝置事件，並執行篩選、匯總或通訊協議轉換等功能。

擷取之後，事件會經過一或多個 串流處理器，以將數據路由傳送（例如，傳送至記憶體），或執行分析和其他處理。

以下是一些常見的處理類型。 （這份名單肯定不是詳盡的。

  • 將事件數據寫入冷記憶體，以進行封存或批次分析。

  • 經常性路徑分析、在 （近） 即時分析事件串流、偵測異常、在輪流時間範圍中辨識模式，或在串流中發生特定狀況時觸發警示。

  • 處理來自裝置的特殊非遙測訊息類型，例如通知和警示。

  • 機器學習。

陰影灰色的方塊會顯示與事件串流不直接相關的IoT系統元件，但此處包含完整性。

  • 裝置登錄 是布建裝置的資料庫，包括裝置標識碼，通常是裝置元數據，例如位置。

  • 布建 API 是布建和註冊新裝置的常見外部介面。

  • 某些 IoT 解決方案允許 命令和控制訊息 傳送至裝置。

本節提出了IoT的高階檢視，而且需要考慮許多細微之處和挑戰。 如需詳細資訊，請參閱IoT 架構。

後續步驟