巨量數據架構會管理對傳統資料庫系統而言太大或複雜數據的擷取、處理和分析。 進入巨量數據領域的閾值會因組織的工具和使用者功能而有所不同。 有些組織會管理數百 GB 的數據，而其他組織則管理數百 TB 的數據。 隨著使用巨量數據集的工具演進，巨量數據的定義會從專注於數據大小轉向強調衍生自進階分析的值。 雖然這些類型的案例往往具有大量數據。
多年來，數據環境已變更。 您可以執行的動作，或預期會隨著數據變更。 記憶體的成本大幅下降，而數據收集的方法仍在繼續擴大。 某些數據會以快速的速度抵達，而且需要持續收集和觀察。 其他數據的速度會變慢，但在大塊中，而且通常是幾十年的歷史數據的形式。 您可能會遇到進階分析問題，或需要機器學習來解決的問題。 巨量數據架構會努力解決這些挑戰。
巨量數據解決方案通常涉及下列一或多個工作負載類型：
- 巨量數據源靜態狀態的批處理
- 即時處理移動中的巨量數據
- 巨量數據的互動式探索
- 預測性分析和機器學習
當您需要執行下列工作時，請考慮巨量數據架構：
- 在資料量龐大的情況下將數據儲存和處理，超出了傳統資料庫的能力範圍。
- 轉換非結構化數據以進行分析和報告
- 即時或低延遲擷取、處理和分析未系結的數據串流
巨量數據架構的元件
下圖顯示巨量數據架構的邏輯元件。 個別解決方案可能不會包含此圖表中的每個專案。
大部分的巨量數據架構都包含下列部分或所有元件：
數據源： 所有巨量數據解決方案都是從一或多個數據源開始。 範例包括：
- 應用程式資料存放區，例如關係資料庫。
- 應用程式產生的靜態檔案，例如 Web 伺服器記錄檔。
- 實時數據源，例如物聯網 （IoT） 裝置。
數據記憶體： 批處理作業的數據通常會儲存在分散式檔案存放區中，以各種格式保存大量大型檔案。 這種存放區通常稱為 Data Lake。 實作此記憶體的選項包括 Azure Data Lake Store、Azure 記憶體中的 Blob 容器，或 Microsoft Fabric 中的 OneLake。
批處理： 數據集很大，因此巨量數據解決方案通常會使用長時間執行的批次作業來處理數據檔，以篩選、匯總，否則準備數據以供分析。 這些作業通常涉及讀取來源檔案、處理來源檔案，以及將輸出寫入新檔案。 您可以使用下列選項：
在 Azure Data Lake Analytics 中執行 U-SQL 作業。
在 Azure HDInsight Hadoop 叢集中使用 Hive、Pig 或自定義 MapReduce 作業。
在 HDInsight Spark 叢集中使用 Java、Scala 或 Python 程式。
在 Azure Databricks 筆記本中使用 Python、Scala 或 SQL 語言。
在網狀架構筆記本中使用 Python、Scala 或 SQL 語言。
即時訊息擷取： 如果解決方案包含即時來源，架構必須擷取並儲存即時訊息以進行串流處理。 例如，您可以有簡單的數據存放區來收集傳入訊息進行處理。 不過，許多解決方案都需要訊息擷取存放區作為訊息的緩衝區，並支援向外延展處理、可靠傳遞和其他消息佇列語意。 串流架構的這個部分通常稱為 數據流緩衝。 選項包括 Azure 事件中樞、Azure IoT 中樞 和 Kafka。
串流處理： 解決方案擷取即時訊息之後，它必須篩選、匯總及準備數據進行分析來處理它們。 然後，處理過的數據流數據會寫入輸出接收。
Azure 串流分析是受控串流處理服務，會使用持續執行的 SQL 查詢，在未繫結的數據流上運作。
您可以在 HDInsight 叢集或 Azure Databricks 中使用開放原始碼 Apache 串流技術，例如 Spark 串流。
Azure Functions 是無伺服器計算服務，可執行事件驅動程序代碼，非常適合輕量型串流處理工作。
Fabric 支援使用事件串流和 Spark 處理進行實時數據處理。
機器學習： 若要從批次或串流處理分析備妥的數據，您可以使用機器學習演算法來建置預測結果或分類數據的模型。 這些模型可以在大型數據集上定型。 您可以使用產生的模型來分析新的資料並進行預測。
使用 Azure Machine Learning 來執行這些工作。 Machine Learning 提供建置、定型和部署模型的工具。 或者，您可以使用 Azure AI 服務的預先建置 API 來執行常見的機器學習工作，例如視覺、語音、語言和決策工作。
分析數據存放區： 許多巨量數據解決方案會準備數據以供分析，然後以結構化格式提供已處理的數據，分析工具可以查詢。 提供這些查詢的分析數據存放區可以是 Kimball 樣式的關係型數據倉儲。 大部分的傳統商業智慧 （BI） 解決方案都會使用這種類型的數據倉儲。 或者，您可以透過低延遲 NoSQL 技術來呈現數據，例如 HBase 或互動式 Hive 資料庫，以提供分散式數據存放區中數據檔的元數據抽象概念。
Azure Synapse Analytics 是適用於大規模雲端式數據倉儲的受控服務。
HDInsight 支援互動式 Hive、HBase 和 Spark SQL。 這些工具可以提供數據以供分析。
網狀架構提供各種數據存放區，包括 SQL 資料庫、數據倉儲、湖倉和事件倉儲。 這些工具可以提供數據以供分析。
Azure 提供其他分析數據存放區，例如 Azure Databricks、Azure 數據總管、Azure SQL Database 和 Azure Cosmos DB。
分析和報告： 大部分的巨量數據解決方案都致力於透過分析和報告來提供數據的深入解析。 為了讓用戶能夠分析數據，架構可能包含數據模型層，例如 Azure Analysis Services 中的多維度在線分析處理 Cube 或表格式數據模型。 它也可以使用Power BI或Excel中的模型化和視覺效果技術來支援自助BI。
數據科學家或數據分析師也可以透過互動式數據探索來分析和報告。 在這些案例中，許多 Azure 服務都支援分析筆記本，例如 Jupyter，讓這些用戶能夠搭配 Python 或 Microsoft R 使用其現有的技能。若要進行大規模的數據探索，您可以使用獨立或 Spark Microsoft R Server。 您也可以使用 Fabric 來編輯數據模型，以提供數據模型化和分析的彈性和效率。
協調： 大部分的巨量數據解決方案包含在工作流程中封裝的重複性的數據處理操作。 工作會執行下列工作：
- 轉換源數據
- 在多個來源和匯入端之間移動數據
- 將已處理的數據載入分析資料存放區
- 將結果直接推送至報表或儀錶板
若要將這些工作流程自動化，請使用協調流程技術，例如 Azure Data Factory、Fabric 或 Apache Oozie 和 Apache Sqoop。
Lambda 架構
當您使用大型數據集時，可能需要很長的時間才能執行用戶端所需的查詢類型。 無法即時執行這些查詢。 而且它們通常需要 MapReduce 等演算法，以平行方式在整個數據集上運作。 查詢結果會與原始數據分開儲存，並用於進一步查詢。
此方法的其中一個缺點是其引進延遲。 如果處理需要數小時的時間，查詢可能會傳回數小時舊的結果。 在理想情況下，您應該即時取得一些結果，可能遺失精確度，並結合這些結果與批次分析的結果。
Lambda 架構可藉由建立數據流的兩個路徑來解決此問題。 進入系統的所有數據都會經歷下列兩個路徑：
批次層 （冷路徑） 會以原始形式儲存所有傳入數據，並針對數據執行批處理。 此處理的結果會儲存為批次檢視。
速度層（熱路徑）即時分析數據。 此層是針對低延遲而設計，但代價是精確度。
批次層會饋送至 服務層 ，以編製批次檢視的索引，以便進行有效率的查詢。 速度層會根據最新的數據，使用累加式更新來更新服務層。
由於速度層施加的延遲需求，流入熱路徑的數據必須快速處理。 快速處理可確保數據已準備好立即使用，但可能會造成不準確。 例如，假設有IoT案例，其中許多溫度感測器會傳送遙測數據。 速度層可能會處理傳入數據的滑動時間範圍。
流入冷路徑的數據不受限於相同的低延遲需求。 冷路徑可跨大型數據集提供高精確度計算，但可能需要很長的時間。
最後，經常性存取和冷路徑會交集於分析用戶端應用程式。 如果客戶端需要即時顯示數據，但這些數據可能即時較不精確，它會從熱路徑獲取其結果。 否則，用戶端會從冷路徑中選取結果，以便顯示較不及時但更精確的數據。 換句話說，經常性路徑有相對較小的時間範圍的數據，之後結果就可以從冷路徑更新更精確的數據。
儲存在批次層的原始數據是不可變的。 傳入數據會附加至現有的數據，而且不會覆寫先前的數據。 特定日期值的變更會儲存為新的時間戳事件記錄。 時間戳事件記錄允許在任何時間點重新計算所收集的數據歷程記錄。 從原始原始數據重新計算批次檢視的能力很重要，因為它可讓您在系統發展時建立新的檢視。
Kappa 架構
Lambda 架構的缺點是其複雜性。 處理邏輯會出現在兩個不同的位置，即冷和熱路徑，透過不同的架構。 這個過程會導致兩條路徑的計算邏輯重複，以及架構管理變得複雜。
Kappa 架構是 Lambda 架構的替代方案。 其基本目標與 Lambda 架構相同，但所有數據都會透過串流處理系統透過單一路徑流動。
與 Lambda 架構的批次層類似，事件數據是不可變的，而且會收集所有數據，而不是數據子集。 數據會擷取為事件串流，並擷取到分散式容錯整合記錄。 這些事件會排序，而且事件的目前狀態只會由附加的新事件變更。 與 Lambda 架構的速度層類似，所有事件處理都會在輸入數據流上執行，並保存為即時檢視。
如果您需要重新計算整個數據集（相當於 Batch 層在 Lambda 架構中的用途），您可以重新執行數據流。 此程式通常會使用平行處理原則及時完成計算。
湖倉架構
Data Lake 是集中式數據存放庫，可儲存結構化數據（資料庫數據表）、半結構化數據（XML 檔案），以及非結構化數據（影像和音訊檔案）。 此數據是原始的原始原始格式，且不需要預先定義的架構。 數據湖可以處理大量數據，因此適用於巨量數據處理和分析。 Data Lake 使用低成本的記憶體解決方案，可提供符合成本效益的方式來儲存大量數據。
數據倉儲是集中式存放庫，可儲存結構化和半結構化數據以供報告、分析和 BI 之用。 數據倉儲可藉由提供數據一致且全面的檢視，協助您做出明智的決策。
Lakehouse 架構結合了 Data Lake 和數據倉儲的最佳元素。 此模式旨在提供支持結構化和非結構化數據的統一平臺，以啟用有效率的數據管理和分析。 這些系統通常會使用開放式格式的低成本雲端記憶體，例如 Parquet 或 Optimized Row Columnar，來儲存原始和已處理的數據。
Lakehouse 架構的常見使用案例包括：
整合分析： 適用於需要單一平臺進行歷程記錄和實時數據分析的組織
機器學習： 整合數據管理功能，支援進階分析和機器學習工作負載
數據控管： 確保大型數據集的合規性和數據品質
物聯網
IoT 代表任何連線到因特網並傳送或接收數據的裝置。 IoT 裝置包括計算機、行動電話、智慧手錶、智慧控溫器、智慧冰箱、聯網汽車和心臟監控植入物。
連線的裝置數目每天都會成長，而且它們產生的數據量也是如此。 此數據通常會在具有重大限制且有時高延遲的環境中收集。 在其他情況下，數以千計的裝置會從低延遲環境傳送數據，這需要快速擷取和處理。 您必須正確規劃以處理這些條件約束和唯一需求。
事件驅動架構是IoT解決方案的核心。 下圖顯示IoT的邏輯架構。 此圖表強調架構的事件串流元件。
雲端閘道會透過可靠的低延遲傳訊系統，擷取雲端界限上的裝置事件。
裝置可能會直接將事件傳送至雲端閘道或透過 現場閘道。 現場閘道是特殊的裝置或軟體，通常與裝置共置，可接收事件，並將其轉送至雲端閘道。 現場閘道也可以預先處理原始裝置事件，包括執行篩選、匯總或通訊協定轉換函式。
擷取之後，事件會經過一或多個 串流處理器 ，以將數據路由傳送至目的地，例如記憶體，或執行分析和其他處理。
常見的處理類型包括：
將事件數據寫入冷記憶體以進行封存或批次分析。
熱路徑分析。 近乎即時地分析事件串流，以偵測異常、辨識滾動時間範圍中的模式，或在數據流中發生特定狀況時觸發警示。
處理來自裝置的特殊非對稱訊息類型，例如通知和警示。
機器學習。
在上圖中，灰色方塊是與事件串流不直接相關的IoT系統元件。 它們會包含在圖表中，以取得完整性。
裝置登錄是已布建裝置的資料庫，包括裝置標識碼，通常是裝置元數據，例如位置。
佈署 API 是用來佈署和註冊新裝置的常用外部介面。
某些IoT解決方案允許 將命令和控制訊息 傳送至裝置。