一文讀懂大資料實時計算

​

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

一、實時計算

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

本文來自微信公衆号：五分鐘學大資料，轉載請在公衆号背景擷取作者微信進行授權