大數據與現有的科技手段結合，對大多數產業而言都能產生巨大的經濟及社會價值。這也是當下許多企業，在大數據上深耕的原因。大數據分析場景需要解決哪些技術挑戰?目前，有哪些主流大數據架構模式及其發展?今天，我們都會一一解讀，并介紹如何結合云上存儲、計算組件，實現更優的通用大數據架構模式，美國服務器租用，以及該模式可以涵蓋的典型數據處理場景。
大數據處理的挑戰
現在已經有越來越多的行業和技術領域需求大數據分析系統，例如金融行業需要使用大數據系統結合 VaR(value at risk) 或者機器學習方案進行信貸風控，零售、餐飲行業需要大數據系統實現輔助銷售決策，各種 IOT 場景需要大數據系統持續聚合和分析時序數據，各大科技公司需要建立大數據分析中臺等等。
抽象來看，支撐這些場景需求的分析系統，面臨大致相同的技術挑戰： 業務分析的數據范圍橫跨實時數據和歷史數據，既需要低延遲的實時數據分析，也需要對 PB 級的歷史數據進行探索性的數據分析; 可靠性和可擴展性問題，用戶可能會存儲海量的歷史數據，同時數據規模有持續增長的趨勢，需要引入分布式存儲系統來滿足可靠性和可擴展性需求，同時保證成本可控; 技術棧深，需要組合流式組件、存儲系統、計算組件和; 可運維性要求高，復雜的大數據架構難以維護和管控;
Lambda 架構
Lambda 架構是目前影響最深刻的大數據處理架構，它的核心思想是將不可變的數據以追加的方式并行寫到批和流處理系統內，隨后將相同的計算邏輯分別在流和批系統中實現，并且在查詢階段合并流和批的計算視圖并展示給用戶。Lambda的提出者 Nathan Marz 還假定了批處理相對簡單不易出現錯誤，而流處理相對不太可靠，因此流處理器可以使用近似算法，快速產生對視圖的近似更新，而批處理系統會采用較慢的精確算法，產生相同視圖的校正版本。
圖 1 Lambda架構示例
Lambda架構典型數據流程是()：
所有的數據需要分別寫入批處理層和流處理層; 批處理層兩個職責：(i)管理 master dataset (存儲不可變、追加寫的全量數據)，(ii)預計算batch view; 服務層對 batch view 建立索引，以支持低延遲、ad-hoc 方式查詢 view; 流計算層作為速度層，對實時數據計算近似的 real-time view，作為高延遲batch view 的補償快速視圖; 所有的查詢需要合并 batch view 和 real-time view;
Lambda 架構設計推廣了在不可變的事件流上生成視圖，并且可以在必要時重新處理事件的原則，該原則保證了系統隨需求演進時，始終可以創建相應的新視圖出來，切實可行地滿足了不斷變化的歷史數據和實時數據分析需求。
Lambda 架構的四個挑戰
Lambda 架構非常復雜，在數據寫入、存儲、對接計算組件以及展示層都有復雜的子課題需要優化： 寫入層上，Lambda 沒有對數據寫入進行抽象，而是將雙寫流批系統的一致性問題反推給了寫入數據的上層應用; 存儲上，以 HDFS 為代表的master dataset 不支持數據更新，云服務器租用，持續更新的數據源只能以定期拷貝全量 snapshot 到 HDFS 的方式保持數據更新，數據延遲和成本比較大; 計算邏輯需要分別在流批框架中實現和運行，而在類似 Storm 的流計算框架和Hadoop MR 的批處理框架做 job 開發、調試、問題調查都是比較復雜的;
結果視圖需要支持低延遲的查詢分析，通常還需要將數據派生到列存分析系統，并保證成本可控。
流批融合的 Lambda 架構
針對 Lambda 架構的問題3，計算邏輯需要分別在流批框架中實現和運行的問題，不少計算引擎已經開始往流批統一的方向去發展，例如 Spark 和 Flink，從而簡化lambda 架構中的計算部分。實現流批統一通常需要支持：
以相同的處理引擎來處理實時事件和歷史回放事件; 支持 exactly once 語義，保證有無故障情況下計算結果完全相同; 支持以事件發生時間而不是處理時間進行窗口化。
Kappa架構
Kappa 架構由 Jay Kreps 提出，不同于 Lambda 同時計算流計算和批計算并合并視圖，Kappa 只會通過流計算一條的數據鏈路計算并產生視圖。Kappa 同樣采用了重新處理事件的原則，對于歷史數據分析類的需求，Kappa 要求數據的長期存儲能夠以有序 log 流的方式重新流入流計算引擎，重新產生歷史數據的視圖。
