一文讀懂大資料實時計算

​

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

一、實時計算

實時計算一般都是針對海量資料進行的，並且要求為秒級。由於大資料興起之初，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，但是模型的構建思路與流轉過程並沒有發生變化。

​