大數據架構設計用來處理對傳統數據庫系統而言太大或太複雜的數據的引入、處理和分析。組織進入大數據領域的門檻各不相同，具體取決於用戶的權限及其工具的功能。對某些組織來說，大數據可能意味着數百個 GB 的數據，而對另一些組織來說，大數據則意味着數百個 TB 的數據。隨着處理大數據集的工具的發展，大數據的涵義也在不斷地變化。慢慢地，這個術語更多的是指通過高級分析從數據集獲取的價值，而不是嚴格地指數據的大小，雖然這種情況下的數據往往是很大的。
多年來，數據格局一直在變。數據的功能和預期功能一直在變。存儲成本在大幅下降，而數據的收集手段則在增多。一些數據會瞬間出現，需要不斷地進行收集和觀察。另一些數據出現速度較慢，但卻是很大型的區塊，通常是以數十年的歷史數據的形式出現。你面對的可能是高級分析問題，也可能是需要機器學習的問題。這些都是大數據架構尋求解決的難題。
大數據解決方案通常涉及一個或多個以下類型的工作負荷：
靜態大數據源的批處理。
移動中的大數據的實時處理。
大數據的交互式瀏覽。
預測分析和機器學習。
需要解決以下難題時，可以考慮使用大數據架構：
存儲和處理對傳統數據庫而言數量太大的數據。
轉換非結構化數據以進行分析和報告。
實時或者以較低的延遲捕獲、處理和分析無限的數據流。
大數據架構的組件
下圖顯示了組成大數據架構的邏輯組件。單個解決方案可能不會包含此圖中的每個項目。
大多數大數據架構都包括下列組件中的一些或全部：
如果你對大數據開發感興趣，想系統學習大數據的話，可以加入大數據技術學習交流扣羣：數字522+數字189+307，私信管理員即可免費領取開發工具以及入門學習資料
數據源。所有大數據解決方案一開始都有一個或多個數據源。示例包括：
應用程序數據存儲，例如關係數據庫。
應用程序生成的靜態文件，例如 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 查詢提供託管流處理服務，這些查詢對無限的流進行操作。還可以在 HDInsight 羣集中使用開源 Apache 流式處理技術，例如 Storm 和 Spark 流式處理。
分析數據存儲。許多大數據解決方案會先準備用於分析的數據，然後以結構化格式提供已處理的數據供分析工具查詢。如大多數傳統業務智能 (BI) 解決方案中所見，用來爲這些查詢提供服務的分析數據存儲可以是 Kimball 樣式的關係數據倉庫。或者，數據也可以通過低延遲 NoSQL 技術（如 HBase）或 Interactive Hive 數據庫中呈現，該數據庫提供分佈式數據存儲中數據文件的元數據抽象。Azure SQL 數據倉庫爲大規模、基於雲的數據倉庫提供託管服務。HDInsight 支持交互式 Hive、HBase 和 Spark SQL，也可以使用這些技術來提供用於分析的數據。
分析和報告。大多數大數據解決方案的目的是通過分析和報告提供對數據的見解。若要使用戶能夠對數據進行分析，架構可以包括一個數據建模層，例如 Azure Analysis Services 中的多維 OLAP 多維數據集或表格數據模型。它還可以使用 Microsoft Power BI 或 Microsoft Excel 中的建模和可視化技術支持自助式 BI。分析和報告還可以採用適用於數據科學家或數據分析人員的交互式數據瀏覽形式。對於這些方案，許多 Azure 服務都支持分析筆記本（例如 Jupyter），這允許這些用戶通過 Python 或 R 利用其現有技能。對於大規模數據瀏覽，可以使用 Microsoft R Server，可以獨立使用，也可以將其與 Spark 一起使用。
業務流程。大多數大數據解決方案都包括重複的數據處理操作（封裝在工作流中），這些操作對源數據進行轉換、在多個源和接收器之間移動數據、將已處理的數據加載到分析數據存儲中，或者直接將結果推送到報表或儀表板。若要自動執行這些工作流，可以使用諸如 Azure 數據工廠或 Apache Oozie 和 Sqoop 的業務流程技術。
Lambda 架構
使用極大型數據集時，運行客戶端所需的查詢類型可能需要很長時間。這些查詢無法實時執行，並且通常需要 MapReduce之類的算法跨整個數據集進行並行操作。然後，結果會與原始數據分開存儲，用於查詢。
此方法的一個缺點是會造成延遲 — 如果處理需要數小時，則查詢返回的結果可能是數小時之前的數據的結果。最好是能夠獲取一些實時結果（也許準確性稍欠），然後將這些結果與批處理分析結果結合在一起。
lambda 架構首先由 Nathan Marz 提出，通過創建兩個數據流路徑來解決此問題。所有進入系統的數據都經過這兩個路徑：
批處理層（冷路徑）以原始形式存儲所有傳入數據，對數據進行批處理。該處理的結果作爲批處理視圖存儲。
速度層（熱路徑）可實時分析數據。設計此層是爲了降低延遲，但代價是準確性也會降低。
批處理層將結果饋送到服務層中，後者會編制批處理視圖的索引，以便提高查詢效率。速度層會根據最新數據使用增量更新來更新服務層。
流入熱路徑的數據受速度層提出的延遲要求約束，因此可以儘快處理。通常情況下，這需要犧牲一定程度的準確性，以便數據儘快就緒。例如，在使用某個 IoT 方案時，需要通過大量的溫度傳感器發送遙測數據。可以使用速度層來處理傳入數據的滑動時間窗口。
另一方面，流入冷路徑中的數據不受這些相同的低延遲要求約束。這樣可以跨大型數據集進行高精度計算，這樣的計算可能很耗時。
熱路徑和冷路徑最終在分析客戶端應用程序處會合。如果需要實時顯示時間性要求高但準確性要求可能不高的數據，客戶端會從熱路徑獲取結果。否則，客戶端會從冷路徑選擇結果來顯示時間性要求不高但準確性要求高的數據。換言之，一開始可以使用時限相對較短的熱路徑的數據作爲結果，稍後再使用冷路徑的準確性較高的數據對結果進行更新。
存儲在批處理層的原始數據是不可變的。傳入數據始終追加到現有數據上，不覆蓋以前的數據。對特定基準的值進行更改時，所做的更改會作爲帶時間戳的新事件記錄來存儲。這樣就可以選擇歷史記錄中任意時間點的已收集數據重新進行計算。根據最初的原始數據重新計算批處理視圖這一功能很重要，因爲這樣就可以隨着系統的發展不斷創建新視圖。
Kappa 架構
Lambda 架構的一個缺點是複雜。處理邏輯顯示在冷路徑和熱路徑兩個不同的位置，而且使用不同的框架。這樣會導致計算邏輯重複，而且兩個路徑的架構管理起來也很複雜。
Kappa 架構由 Jay Kreps 提出，用於替代 Lambda 架構。它具有與 lambda 體系結構相同的基本目標，但有一個重要區別：所有數據流經一個路徑，使用一個流處理系統。
某些方面與 Lambda 架構的批處理層有些類似，那就是，事件數據不可變，而且全都可以收集，而不是隻能收集一部分。數據作爲事件流引入到能容錯的分佈式統一日誌中。這些事件按順序排列。一個事件的當前狀態只在追加新事件的情況下更改。與 Lambda 架構的速度層類似，所有事件處理均在輸入流的基礎上進行，作爲實時視圖保存。
如需重新計算整個數據集（相當於 Lambda 中批處理層執行的操作），只需重播該流即可，通常可使用並行方式及時完成計算。
物聯網 (IoT)
從實用角度來看，物聯網 (IoT) 囊括連接到 Internet 的任何設備， 其中包括電腦、移動電話、智能表、智能調溫器、智能致冷器、聯網汽車、植入式心臟監測儀，以及任何其他可以連接到 Internet 並可發送或接收數據的設備。連接的設備數與日俱增，從其收集的數據量也是如此。通常情況下，此類數據是在受到嚴格約束且有時候延遲很嚴重的環境中收集的。另外一些情況下，數據是在低延遲環境中通過數千甚至數百萬臺設備發送的，這就要求能夠快速引入數據並對其進行相應的處理。因此，爲了應對這些約束和特殊要求，需要正確地進行規劃。
事件驅動的架構是 IoT 解決方案的中心環節。下列圖表顯示 IoT 可能出現的邏輯架構。此圖表強調架構的事件流式傳輸組件。
雲網關使用可靠、低延遲的消息傳遞系統在雲邊界引入設備事件。
設備可能會直接將事件發送到雲網關，或通過現場網關發送。現場網關是一種專用設備或軟件，通常與接收事件並將事件轉接到雲網關的設備位於同一位置。現場網關也可預處理原始設備事件，執行過濾、聚合或協議轉換等功能。
引入後，事件將通過一個或多個流處理器，此處理器可將數據路由到存儲等位置，也可執行分析和其他處理。
下面是一些常見的處理類型。（此列表並未囊括所有類型。）
將事件數據寫入冷存儲，用於存檔或批處理分析。
熱路徑分析，實時（或近乎實時）分析事件流，以檢測異常，識別滾動時間範圍內的模式，或者在流中出現特殊情況時觸發警報。
處理設備中特殊類型的非遙測消息，例如通知和警報。
機器學習。
具有灰色陰影的框表示 IoT 系統的組件，雖然這些組件與事件流式傳輸沒有直接關係，但爲了完整起見，仍在此處提出。
設備註冊表是預配設備的數據庫，包括設備 ID 和常見的設備元數據，如位置信息。
預配 API 是一種常見的外部接口，用於預配和註冊新設備。
某些 IoT 解決方案可使命令和控制消息發送到設備。