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