19.1　傳統數據處理系統存在的問題

1.傳統數據庫的數據過載問題
傳統應用的數據系統架構設計時，應用直接訪問數據庫系統。當用戶訪問量增加時，數據庫無法支撐日益增長的用戶請求的負載，從而導致數據庫服務器無法及時響應用戶請求，出現超時的錯誤。關于這個問題的常用解決方法如下:

• (1)增加異步處理隊列，通過工作處理層批量處理異步處理隊列中的數據修改請求。
• (2)建立數據庫水平分區，通常建立 Key 分區，以主鍵/唯一鍵 Hash 值作為 Key。
• (3)建立數據庫分片或重新分片，通常專門編寫腳本來自動完成，且要進行充分測試。
• (4)引入讀寫分離技術，主數據庫處理寫請求，通過復制機制分發至從數據庫。
• (5)引入分庫分表技術，按照業務上下文邊界拆分數據組織結構，拆分單數據庫壓力。

2.大數據的特點
大數據具有體量大、時效性強的特點，并非構造單調，而是類型多樣; 處理大數據時，傳統數據處理系統因數據過載，來源復雜，類型多樣等諸多原因性能低下，需要采用以新式計算架構和智能算法為代表的新技術;大數據的應用重在發掘數據間的相關性，而非傳統邏輯上的因果關系; 因 此，大數據的目的和價值就在于 發現新的知識，洞悉并進行科學決策。現代大數據處理技術，主要分為以下幾種:

• (1)基于分布式文件系統 Hadoop。
• (2)使用 Map/Reduce 或 Spark 數據處理技術。
• (3)使用 Kafka 數據傳輸消息隊列及 Avro 二進制格式。

3.大數據利用過程
大數據的利用過程分為: 采集、清洗、統計和挖掘 4 個過程。

19.2　大數據處理系統架構分析

19.2.1　大數據處理系統面臨挑戰

大數據處理系統面臨的挑戰主要有:

• 1)如何利用信息技術等手段處理非結構化和半結構化數據。
• 2)如何探索大數據復雜性、不確定性特征描述的刻畫方法及大數據的系統建模。
• 3)數據異構性與決策異構性的關系對大數據知識發現與管理決策的影響。

19.2.2　大數據處理系統架構特征

大數據處理系統應具有的屬性和特征包括: 魯棒性和容錯性、低延遲、橫向擴展(通過增強機器性能擴展)、通用、可擴展、即席查詢(用戶按照自己的要求進行查詢)、最少維護和可調試。

1.魯棒性和容錯性 (Robust and Fault-tolerant)：對于大規模的分布式系統來說，人和機器的錯誤每天都可能會 發生，如何應對人和機器的錯誤，讓系統能夠從錯誤中快速恢復尤其重要。
2.低延遲讀取和更新能力 (Low Latency Reads and Updates)：許多應用程序要求數據系統擁有幾毫秒到幾百毫秒的低延遲讀取和更新能力。有的應用程序允許幾個小時的延遲更新，但是只要有低延遲讀取與更新的需求，系統就應該在保證魯棒性 的前提下實現。
3.橫向擴容 (Scalable)：當數據量/負載增大時，可擴展性的系統通過增加更多的機器資源來維持性能。也就是常說的系統需要線性可擴展，通常采用scaleout(通過增加機器的個數)而不是scaleup(通過增 強機器的性能)。
4.通用性 (General) 系統需要支持絕大多數應用程序，包括金融領域、社交網絡、電子商務數據分析等。
5.延展性 (Extensible) 在新的功能需求出現時，系統需要能夠將新功能添加到系統中。同時，系統的大規模遷移能力是設計者需要考慮的因素之一，這也是可延展性的體現。
6.即席查詢能力 (Allows Ad Hoc Queries) 用戶在使用系統時，應當可以按照自己的要求進行即席查詢 (Ad Hoc)。 這使用戶可以通過系統多樣化數據處理，產生更高的應用價值。
7.最少維護能力 (Minimal Maintenance) 系統需要在大多數時間下保持平穩運行。使用機制簡單的組件和算法讓系統底層擁有低復 雜度，是減少系統維護次數的重要途徑。 Marz認為大數據系統設計不能再基于傳統架構的增量 更新設計，要通過減少復雜性以減少發生錯誤的幾率、避免繁重操作。
8.可調試性 (Debuggable)系統在運行中產生的每一個值，需要有可用途徑進行追蹤，并且要能夠明確這些值是如何 產生的。

19.3　Lambda架構

19.3.1　Lambda架構對大數據處理系統的理解

Lambda 架構是 一種用于同時處理離線和實時數據的、可容錯的、可擴展的分布式系統，它 具備強魯棒性，提供低延遲和持續更新。

19.3.2　Lambda架構應用場景

1.機器學習中的Lambda架構
機器學習可以受益于由 Lambda架構構 建的數據系統、所處理的各類數據。據此，機器學習算法可以提出各種問題，并逐漸對輸入到 系統中的數據進行模式識別。

2.物聯網的 Lambda架構
如果說機器學習利用的是 Lambda 架構的輸出，那么物聯網則更多地作為數據系統的輸入。

3.流處理和Lambda架構挑戰
在實際應用中，由于實時處理流以毫秒為單位，持續產生用于更新視圖的數據流，是一個 非常復雜的過程。因此，將基于文檔的數據庫、索引以及查詢系統配合在一起使用，是一種比較好的選擇。

19.3.3　Lambda架構介紹

Lambda 架構如圖:

Lambda 架構分為以下 3 層:

• (1)批處理層。該層核心功能是 存儲主數據集，主數據集數據具有 原始、不可變、真實 的特征。批處理層周期性地將增量數據轉儲至主數據集，并在主數據集上執行批處理，生成批視圖。架構實現方面可以使用 Hadoop HDFS 或 HBase 存儲主數據集，再利用 Spark 或 MapReduce 執行周期批處理，之后使用 MapReduce 創建批視圖。
• (2)加速層。該層的核心功能是 處理增量實時數據，生成實時視圖，快速執行即席查詢。架構實現方面可以使用 Hadoop HDFS 或 HBase 存儲實時數據，利用 Spark 或 Storm 實現實時數據處理和實時視圖。
• (3)服務層。該層的核心功能是 響應用戶請求，合并批視圖和實時視圖中的結果數據集得到最終數據集。具體來說就是接收用戶請求，通過索引加速訪問批視圖，直接訪問實時視圖，然后合并兩個視圖的結果數據集生成最終數據集，響應用戶請求。架構實現方面可以使用 HBase 或 Cassandra 作為服務層，通過 Hive 創建可查詢的視圖。

19.3.4 　Lambda架構的實現

如圖，在這種Lambda架構實現中，Hadoop(HDFS) 用于存儲主數據集，Spark(或 Storm) 可構成速度層 (Speed Layer)，HBase (或Cassandra) 作為服務層，由Hive創建可查詢的視圖。

• Hadoop是被設計成適合運行在通用硬件上的分布式文件系統 (Distributed File System)。
• Apache Spark是專為大規模數據處理而設計的快速通用的計算引擎。
• HBase-Hadoop Database, 是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統，利用HBase技術可在廉價 PCServer上搭建起大規模結構化存儲集群。

19.3.5　Lambda架構優缺點

Lambda 架構的優點: 容錯性好，查詢靈活度高，彈性伸縮，易于擴展。
Lambda 架構的缺點: 編碼量大，持續處理成本高，重新部署和遷移成本高。

19.3.6　Lambda與其他架構模式對比

Lambda架構的誕生離不開很多現有設計思想和架構的鋪墊，如事件溯源 (Event Sourcing) 架構和命令查詢職責分離 (Command Query Responsibility Segregation,CQRS) 架構， Lambda架構的設計思想和這兩者有一定程度的相似。

1.事件溯源(Event Sourcing)本質上是一種數據持久化的方式，其由三個核心觀點構成:

• (1)整個系統以事件為驅動，所有業務都由事件驅動來完成。
• (2)事件是核心，系統的數據以事件為基礎，事件要保存在某種存儲上。
• (3)業務數據只是一些由事件產生的視圖，不一定要保存到數據庫中。

Lambda架構中數據集的存儲使用的概念與事件溯源中的思想完全一致，二者都是在使用統一的數據模型對數據處理事件本身進行定義。

2.CQRS架構分離了對于數據進行的讀操作(查詢)和寫(修改)操作。其將能夠改變數據模型狀態的命令和對于模型狀態的查詢操作實現了分離。這是領域驅動設計 (Domain-Driven Design,DDD) 的一個架構模式，主要用來解決 數據庫報表的輸出處理方式。Lambda 架構中，數據的修改通過批處理和流處理實現，通過寫操作將數據轉換成查詢時所對應的View。

19.4　Kappa架構

19.4.1　Kappa架構下對大數據處理系統的理解

為了設計出能滿足前述的大數據關鍵特性的系統，我們需要對數據系統有本質性的理解。 我們可將數據系統簡單理解為: 數據系統=數據+查詢 進而從 數據和查詢 兩方面來認識大數據系統的本質。

1.數據的特性
數據是一個不可分割的單位，數據有兩個關鍵的性質: When和 What。

• (1)When。When是指數據是與時間相關的，數據一定是在某個時間點產生的。
• (2)What。What 是指數據的本身。由于數據跟某個時間點相關，所以數據的本身是不可變的 (Immutable), 過往的數據已經成為事實 (Fact), 你不可能回到過去的某個時間點去改變數據事實。

2.數據的存儲
Lamba架構中對數據的存儲采用的方式是: 數據不可變， 存儲所有數據。

19.4.2　Kappa架構介紹

Kappa 架構是在 Lambda 架構的基礎上進行了優化，刪除了 Batch Layer 的架構，將數據通道以消息隊列進行替代。Kappa 架構本質上是 通過改進 Lambda 架構中的加速層，使它既能夠進行實時數據處理， 同時也有能力在業務邏輯更新的情況下重新處理以前處理過的歷史數據，如圖：

Kappa 架構分為如下 2 層:

• (1)實時層。該層核心功能是處理輸入數據，生成實時視圖。具體來說是采用流式處理引擎 逐條處理輸入數據，生成實時視圖。架構實現方式是采用 Apache Kafka 回訪數據，然后采用 Flink 或 Spark Streaming 進行處理。
• (2)服務層。該層核心功能是使用實時視圖中的結果數據集響應用戶請求。實踐中使用數據 湖中的存儲作為服務層。

19.4.3　Kappa架構的實現

下面以Apache Kafka為例來講述整個全新架構的過程：部署 Apache Kafka, 并設置數據日志的保留期 (Retention Period)。 這里的保留期指的是你希望能夠重新處理的歷史數據的時間區間。例如：

• 如果你希望重新處理最多一年的歷史數據， 那就可以把Apache Kafka中的保留期設置為365天。
• 如果你希望能夠處理所有的歷史數據，那就可以把 Apache Kafka 中的保留期設置為“永久 (Forever)”。
• 如果我們需要改進現有的邏輯算法，那就表示我們需要對歷史數據進行重新處理。

19.4.4　Kappa架構的優缺點

Kappa 架構的優點是 將離線和實時處理代碼進行了統一，方便維護。避免了 Lambda架構中與離線數據合并的問題，查詢歷史數據的時候只需要重放存儲的歷史數據即可 。

缺點是 消息中間件有性能瓶頸、數據關聯時處理開銷大、拋棄了離線計算的可靠性。

19.4.5　常見Kappa架構變形

Kappa 架構常見變形是
1、Kappa+架構，如圖 ：

Kappa+是Uber提出流式數據處理架構，它的核心思想是 讓流計算框架直接讀HDFS里的數據倉庫數據，一并實現實時計算和歷史數據backfll計算，不需要為backfll作業長期保存日志或者把數據拷貝回消息隊列。

2、混合分析系統 Kappa 架構，如圖：

在基于使用Kafka +Flink構建Kappa流計算數據架構，針對Kappa架構分析能力不足的問題，再利用Kafka對接組合 Elastic- Search 實時分析引擎，部分彌補其數據分析能力。但是ElasticSearch也只適合對合理數據量級的熱點數據進行索引，無法覆蓋所有批處理相關的分析需求，這種混合架構某種意義上屬于Kappa和Lambda間的折中方案。

19.5　Lambda架構與Kappa架構的對比和設計選擇

19.5.1　Lambda架構與Kappa架構的特性對比

Lambda 架構與 Kappa 架構的對比，見表：

對比內容	Lambda 架構	Kappa 架構
復雜度與開發維護成本	維護兩套系統(引擎)，復雜度高，成本高	維護一套系統(引擎)，復雜度低，成本低
計算開銷	周期性批處理計算，持續實時計算計算開銷大	必要時進行全量計算，計算開銷相對較小
實時性	滿足實時性	滿足實時性
歷史數據處理能力	批式全量處理，吞吐量大；歷史數據處理能力強；批視圖與實時視圖存在沖突可能	流式全量處理，吞吐量相對較低 歷史數據處理能力相對較弱

對于兩種架構設計的選擇可以從以下 4 個方面考慮，見表

19.5.2　Lambda架構與Kappa架構的設計選擇

對于兩種架構設計的選擇可以從以下 4 個方面考慮，見表

設計考慮	Lambda 架構	Kappa 架構
業務需求與技術要求	依賴 Hadoop、Spark、Storm 技術	依賴 Flink 計算引擎，偏流式計算
復雜度	實時處理和離線處理結果可能不一致	頻繁修改算法模型參數
開發維護成本	成本預算充足	成本預算有限
歷史數據處理能力	頻繁使用海量歷史數據	僅使用小規模數據集

19.6　大數據架構設計案例分析

19.6.1　Lambda架構在某網奧運中的大數據應用

某網采用以 Lambda 架構搭建的大數據平臺處理里約奧運會大規模視頻網絡觀看數據，具體平臺架構設計如圖 ：

對于圖中的數據計算層可以分為 離線計算、實時計算、合并計算 3 個部分。

• (1)離線計算部分: 用于存儲持續增長的批量離線數據，并且會周期性地使用 Spark 和 Map/Reduce 進行批處理，將批處理結果更新到批視圖之后使用 Impala 或者 Hive 建立數據倉庫， 將結果寫入 HDFS 中。
• (2)實時計算部分: 采用 Spark Streaming，只處理實時增量數據，將處理后的結果更新到實時視圖。
• (3)合并計算部分: 合并批視圖和實時視圖中的結果，生成最終數據集，將最終數據集寫入 HBase 據庫中用于響應用戶的查詢請求。

19.6.2　Lambda架構在某網廣告平臺的應用與演進

某網基于 Lambda 架構的廣告平臺，分為 批處理層(Batch Layer)、加速層(Speed Layer)、服 務層(Serving Layer)，某網廣告平臺 Lambda 架構如圖：

實時處理過程如下:
(1)批處理層: 每天凌晨將 Kafka 中瀏覽、下單等消息同步到 HDFS 中，將 HDFS 中數據解析為 Hive 表，然后使用 HQL 或 Spark SQL 計算分區統計結果 Hive 表，將 Hive 表轉儲到 MySQL 中作為批視圖。
(2)加速層: 使用 Spark Streaming 實時監聽 Kafka 下單、付款等消息，計算每個追蹤鏈接維度的實時數據，將實時計算結果存儲在 Redis 中作為實時視圖。
(3)服務層: 采用 Java Web 服務，對外提供 HTTP 接口，Java Web 服務讀取 MySQL 批視圖表和 Redis 實時視圖表。

19.6.3　某證券公司大數據系統

某證券公司智能決策大數據系統是一個基于 Kappa 架構的實時日志分析平臺，如圖：

具體的實時處理過程如下:
(1)日志采集: 用統一的數據處理引擎 Filebeat 實時采集日志并推送給 Kafka 緩存。
(2)日志清洗解析: 利用基于大數據計算集群的 Flink 計算框架實時讀取 Kafka 消息并進行清洗，解析日志文本轉換成指標。
(3)日志存儲: 日志轉儲到 ElasticSearch 日志庫，指標轉儲到 OpenTSDB 指標庫。
(4)日志監控: 單獨設置告警消息隊列，保持監控消息時序管理和實時推送。

19.6.4　某電商智能決策大數據系統

該智能決策大數據平臺基于 Kappa 架構，使用統一的數據處理引擎 Funk 可實時處理流數據，并將其存儲到數據倉庫工具 Hive 與分布式緩存 Tair 中，以供后續決策服務的使用。如圖：

實時處理的過程如下:
(1)數據采集: B 端實時采集用戶點擊、下單、廣告曝光、出價等數據然后推送給 Kafka 緩存。
(2)數據清洗聚合: 由 Flink 實時讀取 Kafka 消息，按需過濾參與業務需求的指標，將聚合時間段的數據轉換成指標。
(3)數據存儲: Flink 將計算結果轉儲至 Hive 日志庫，將模型需要的參數轉儲至實時計算數據庫 Tair 緩存，然后后續決策服務從 Tair 中獲取數據進行模型訓練。