一文讀懂大數據實時計算

​

本文分為四個章節介紹實時計算，第一節介紹實時計算出現的原因及概念；第二節介紹實時計算的應用場景；第三節介紹實時計算常見的架構；第四節是實時數倉解決方案。

一、實時計算

實時計算一般都是針對海量數據進行的，並且要求為秒級。由於大數據興起之初，Hadoop並沒有給出實時計算解決方案，隨后Storm，SparkStreaming，Flink等實時計算框架應運而生，而Kafka，ES的興起使得實時計算領域的技術越來越完善，而隨着物聯網，機器學習等技術的推廣，實時流式計算將在這些領域得到充分的應用。

實時計算的三個特征：

1. 無限數據：無限數據指的是一種不斷增長的，基本上無限的數據集。這些通常被稱為“流數據”，而與之相對的是有限的數據集。

2. 無界數據處理：一種持續的數據處理模式,能夠通過處理引擎重復的去處理上面的無限數據，是能夠突破有限數據處理引擎的瓶頸的。

3. 低延遲：延遲是多少並沒有明確的定義。但我們都知道數據的價值將隨着時間的流逝降低，時效性將是需要持續解決的問題。

現在大數據應用比較火爆的領域，比如推薦系統在實踐之初受技術所限，可能要一分鍾，一小時，甚至更久對用戶進行推薦，這遠遠不能滿足需要，我們需要更快的完成對數據的處理，而不是進行離線的批處理。

二、實時計算應用場景

隨着實時技術發展趨於成熟，實時計算應用越來越廣泛，以下僅列舉常見的幾種實時計算的應用常見：

1. 實時智能推薦

​

智能推薦會根據用戶歷史的購買或瀏覽行為，通過推薦算法訓練模型，預測用戶未來可能會購買的物品或喜愛的資訊。對個人來說，推薦系統起着信息過濾的作用，對Web/App服務端來說，推薦系統起着滿足用戶個性化需求，提升用戶滿意度的作用。推薦系統本身也在飛速發展，除了算法越來越完善，對時延的要求也越來越苛刻和實時化。利用Flink流計算幫助用戶構建更加實時的智能推薦系統，對用戶行為指標進行實時計算，對模型進行實時更新，對用戶指標進行實時預測，並將預測的信息推送給Web/App端，幫助用戶獲取想要的商品信息，另一方面也幫助企業提升銷售額，創造更大的商業價值。

2. 實時欺詐檢測

​

在金融領域的業務中，常常出現各種類型的欺詐行為，例如信用卡欺詐，信貸申請欺詐等，而如何保證用戶和公司的資金安全，是近年來許多金融公司及銀行共同面對的挑戰。隨着不法分子欺詐手段的不斷升級，傳統的反欺詐手段已經不足以解決目前所面臨的問題。以往可能需要幾個小時才能通過交易數據計算出用戶的行為指標，然后通過規則判別出具有欺詐行為嫌疑的用戶，再進行案件調查處理，在這種情況下資金可能早已被不法分子轉移，從而給企業和用戶造成大量的經濟損失。而運用Flink流式計算技術能夠在毫秒內就完成對欺詐行為判斷指標的計算，然后實時對交易流水進行實時攔截，避免因為處理不及時而導致的經濟損失。

3. 輿情分析

​

有的客戶需要做輿情分析，要求所有數據存放若干年，輿情數據每日數據量可能超百萬，年數據量可達到幾十億的數據。而且爬蟲爬過來的數據是輿情，通過大數據技術進行分詞之后得到的可能是大段的網友評論，客戶往往要求對輿情進行查詢，做全文本搜索，並要求響應時間控制在秒級。爬蟲將數據爬到大數據平台的Kafka里，在里面做Flink流處理，去重去噪做語音分析，寫到ElasticSearch里。大數據的一個特點是多數據源，大數據平台能根據不同的場景選擇不同的數據源。

4. 復雜事件處理

​

對於復雜事件處理，比較常見的集中於工業領域，例如對車載傳感器，機械設備等實時故障檢測，這些業務類型通常數據量都非常大，且對數據處理的時效性要求非常高。通過利用Flink提供的CEP進行時間模式的抽取，同時應用Flink的Sql進行事件數據的轉換，在流式系統中構建實施規則引擎，一旦事件觸發報警規則，便立即將告警結果通知至下游通知系統，從而實現對設備故障快速預警檢測，車輛狀態監控等目的。

5. 實時機器學習

​

實時機器學習是一個更寬泛的概念，傳統靜態的機器學習主要側重於靜態的模型和歷史數據進行訓練並提供預測。很多時候用戶的短期行為，對模型有修正作用，或者說是對業務判斷有預測作用。對系統來說，需要采集用戶最近的行為並進行特征工程，然后給到實時機器學習系統進行機器學習。如果動態地實施新規則，或是推出新廣告，就會有很大的參考價值。

三、實時計算架構

我們先來看一張大數據平台的實時架構圖：

​

• 數據同步：

在上面這張架構圖中，數據從Web平台中產生，通過數據同步系統導入到大數據平台，由於數據源不同，這里的數據同步系統實際上是多個相關系統的組合。數據庫同步通常用 Sqoop，日志同步可以選擇 Flume等，不同的數據源產生的數據質量可能差別很大，數據庫中的格式化數據直接導入大數據系統即可，而日志和爬蟲產生的數據就需要進行大量的清洗、轉化處理才能有效使用。

• 數據存儲：

該層對原始數據、清洗關聯后的明細數據進行存儲，基於統一的實時數據模型分層理念，將不同應用場景的數據分別存儲在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存儲中。

• 數據計算：

計算層主要使用 Flink、Spark、Presto 以及 ClickHouse 自帶的計算能力等四種計算引擎，Flink 計算引擎主要用於實時數據同步、 流式 ETL、關鍵系統秒級實時指標計算場景，Spark SQL 主要用於復雜多維分析的准實時指標計算需求場景，Presto 和 ClickHouse 主要滿足多維自助分析、對查詢響應時間要求不太高的場景。

• 實時應用：

以統一查詢服務對各個業務線數據場景進行支持，業務主要包括實時大屏、實時數據產品、實時 OLAP、實時特征等。

當然一個好的大數據平台不能缺少元數據管理及數據治理：

1. 元數據及指標管理：主要對實時的Kafka表、Kudu表、Clickhouse表、Hive表等進行統一管理，以數倉模型中表的命名方式規范表的命名，明確每張表的字段含義、使用方，指標管理則是盡量通過指標管理系統將所有的實時指標統一管理起來，明確計算口徑，提供給不同的業務方使用；

2. 數據質量及血緣分析：數據質量分為平台監控和數據監控兩個部分，血緣分析則主要是對實時數據依賴關系、實時任務的依賴關系進行分析。

以上架構只是大數據平台通用的數據模型，如果要具體的建設，需要考慮以下情況，業務需求需要實時還是准實時即可，數據時效性是秒級還是分鍾級等。

• 在調度開銷方面，准實時數據是批處理過程，因此仍然需要調度系統支持，調度頻率較高，而實時數據卻沒有調度開銷；

• 在業務靈活性方面，因為准實時數據是基於 ETL 或 OLAP 引擎實現，靈活性優於基於流計算的方式；

• 在對數據晚到的容忍度方面，因為准實時數據可以基於一個周期內的數據進行全量計算，因此對於數據晚到的容忍度也是比較高的，而實時數據使用的是增量計算，對於數據晚到的容忍度更低一些；

• 在適用場景方面，准實時數據主要用於有實時性要求但不太高、涉及多表關聯和業務變更頻繁的場景，如交易類型的實時分析，實時數據則更適用於實時性要求高、數據量大的場景，如實時特征、流量類型實時分析等場景。

實時架構

在某些場景中，數據的價值隨着時間的推移而逐漸減少。所以在傳統大數據離線數倉的基礎上，逐漸對數據的實時性提出了更高的要求。

於是隨之誕生了大數據實時數倉，並且衍生出了兩種技術架構Lambda和Kappa。

1. Lambda架構

先來看下Lambda架構圖：

​

Lambda架構圖

數據從底層的數據源開始，經過Kafka、Flume等數據組件進行收集，然后分成兩條線進行計算：

• 一條線是進入流式計算平台（例如 Storm、Flink或者SparkStreaming），去計算實時的一些指標；

• 另一條線進入批量數據處理離線計算平台（例如Mapreduce、Hive，Spark SQL），去計算T+1的相關業務指標，這些指標需要隔日才能看見。

為什么Lambda架構要分成兩條線計算？

假如整個系統只有一個批處理層，會導致用戶必須等待很久才能獲取計算結果，一般有幾個小時的延遲。電商數據分析部門只能查看前一天的統計分析結果，無法獲取當前的結果，這對於實時決策來說有一個巨大的時間鴻溝，很可能導致管理者錯過最佳決策時機。

Lambda架構屬於較早的一種架構方式，早期的流處理不如現在這樣成熟，在准確性、擴展性和容錯性上，流處理層無法直接取代批處理層，只能給用戶提供一個近似結果，還不能為用戶提供一個一致准確的結果。因此Lambda架構中，出現了批處理和流處理並存的現象。

在 Lambda 架構中，每層都有自己所肩負的任務。

1. 批處理層存儲管理主數據集（不可變的數據集）和預先批處理計算好的視圖：

批處理層使用可處理大量數據的分布式處理系統預先計算結果。它通過處理所有的已有歷史數據來實現數據的准確性。這意味着它是基於完整的數據集來重新計算的，能夠修復任何錯誤，然后更新現有的數據視圖。輸出通常存儲在只讀數據庫中，更新則完全取代現有的預先計算好的視圖。

2. 流處理層會實時處理新來的大數據：

流處理層通過提供最新數據的實時視圖來最小化延遲。流處理層所生成的數據視圖可能不如批處理層最終生成的視圖那樣准確或完整，但它們幾乎在收到數據后立即可用。而當同樣的數據在批處理層處理完成后，在速度層的數據就可以被替代掉了。

那Lambda架構有沒有缺點呢？

Lambda架構經歷多年的發展，其優點是穩定，對於實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了數據行業的早期發展，但是它也有一些致命缺點，並在大數據3.0時代越來越不適應數據分析業務的需求。缺點如下：

• 使用兩套大數據處理引擎：維護兩個復雜的分布式系統，成本非常高。

• 批量計算在計算窗口內無法完成：在IOT時代，數據量級越來越大，經常發現夜間只有4、5個小時的時間窗口，已經無法完成白天20多個小時累計的數據，保證早上上班前准時出數據已成為每個大數據團隊頭疼的問題。

• 數據源變化都要重新開發，開發周期長：每次數據源的格式變化，業務的邏輯變化都需要針對ETL和Streaming做開發修改，整體開發周期很長，業務反應不夠迅速。

導致 Lambda 架構的缺點根本原因是要同時維護兩套系統架構：批處理層和速度層。我們已經知道，在架構中加入批處理層是因為從批處理層得到的結果具有高准確性，而加入速度層是因為它在處理大規模數據時具有低延時性。

那我們能不能改進其中某一層的架構，讓它具有另外一層架構的特性呢？

例如，改進批處理層的系統讓它具有更低的延時性，又或者是改進速度層的系統，讓它產生的數據視圖更具准確性和更加接近歷史數據呢？

另外一種在大規模數據處理中常用的架構——Kappa 架構，便是在這樣的思考下誕生的。

2. Kappa架構

Kafka的創始人Jay Kreps認為在很多場景下，維護一套Lambda架構的大數據處理平台耗時耗力，於是提出在某些場景下，沒有必要維護一個批處理層，直接使用一個流處理層即可滿足需求，即下圖所示的Kappa架構：

​

Kappa架構

這種架構只關注流式計算，數據以流的方式被采集過來，實時計算引擎將計算結果放入數據服務層以供查詢。可以認為Kappa架構是Lambda架構的一個簡化版本，只是去除掉了Lambda架構中的離線批處理部分；

Kappa架構的興起主要有兩個原因：

• Kafka不僅起到消息隊列的作用，也可以保存更長時間的歷史數據，以替代Lambda架構中批處理層數據倉庫部分。流處理引擎以一個更早的時間作為起點開始消費，起到了批處理的作用。

• Flink流處理引擎解決了事件亂序下計算結果的准確性問題。

Kappa架構相對更簡單，實時性更好，所需的計算資源遠小於Lambda架構，隨着實時處理的需求在不斷增長，更多的企業開始使用Kappa架構。但這不意味着kappa架構能夠取代Lambda架構。

Lambda和kappa架構都有各自的適用領域；例如流處理與批處理分析流程比較統一，且允許一定的容錯，用Kappa比較合適，少量關鍵指標（例如交易金額、業績統計等）使用Lambda架構進行批量計算，增加一次校對過程。

還有一些比較復雜的場景，批處理與流處理產生不同的結果（使用不同的機器學習模型，專家系統，或者實時計算難以處理的復雜計算），可能更適合Lambda架構。

四、實時數倉解決方案

實時數倉分層架構為了避免面向需求響應的煙囪式構建，實時數倉也引入了類似於離線數倉的分層理念，主要是為了提高模型的復用率，同時也要考慮易用性、一致性以及計算成本。

當然實時數倉的分層架構在設計上並不會像離線數倉那么復雜，避免數據在流轉過程中造成的不必要的延時響應；

實時數倉分層架構圖：

​

實時數倉分層架構

1. ODS層：以Kafka為支撐，將所有需要實時處理的相關數據放到Kafka隊列中來實現貼源數據層；

2. DWD層：實時計算訂閱業務數據消息隊列，然后通過數據清洗、多數據源join、流式數據與離線維度信息等的組合，將一些相同粒度的業務系統、維表中的維度屬性全部關聯到一起，增加數據易用性和復用性，得到最終的實時明細數據；

3. DIM層：存放用於關聯查詢的維度信息，可以根據數據現狀來選擇存儲介質，例如使用HBase或者Mysql

4. DWS層：輕度匯總層是為了便於面向AdHoc查詢或者Olap分析構建的輕度匯總結果集合，適合數據維度、指標信息比較多的情況，為了方便根據自定義條件的快速篩選和指標聚合，推薦使用MPP類型數據庫進行存儲，此層可視場景情況決定是否構建；

5. APP層：面向實時數據場景需求構建的高度匯總層，可以根據不同的數據應用場景決定使用存儲介質或者引擎；例如面向業務歷史明細、BI支持等Olap分析場景，可以使用Druid、Greenplum，面向實時監控大屏、高並發匯總指標等需求，可以使用KV模式的HBase；數據量較小的時候，也可以使用Mysql來進行存儲。

這里要注意下，其實APP層已經脫離了數倉，這里雖然作為了數倉的獨立分層，但是實際APP層的數據已經分布存儲在各種介質中用於使用。

基於Flink 構建的實時數倉

隨着業務場景的豐富，更多的實時需求不斷涌現，在追求實時任務高吞吐低延遲的同時，對計算過程中間狀態管理，靈活時間窗口支持，以及 exactly once 語義保障的訴求也越來越多。

為什么選擇Flink實時計算平台？之所以選擇用Flink替代原有Storm、SparkStreaming是基於以下原因考慮的，這也是實時數倉關注的核心問題：

1. 高吞吐、低延時；

2. 端到端的 Exactly-once，保證了數據的准確性；

3. 可容錯的狀態管理，實時數倉里面會進行很多的聚合計算，這些都需要對於狀態進行訪問和管理；

4. 豐富的API，對Streaming/Table/SQL支持良好，支持UDF、流式join、時間窗口等高級用法；

5. 完善的生態體系，實時數倉的構建會涉及多種存儲，Flink在這方面的支持也比較完善。

基於Flink的實時數倉數據流轉過程:

​

實時數倉數據流轉過程

數據在實時數倉中的流轉過程，實際和離線數倉非常相似，只是由Flink替代Hive作為了計算引擎，把存儲由HDFS更換成了Kafka，但是模型的構建思路與流轉過程並沒有發生變化。

​