一文讀懂大數據實時計算

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

一、實時計算

實時計算一般都是針對海量數據進行的，並且要求爲秒級。由於大數據興起之初，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. 數據質量及血緣分析：數據質量分爲平臺監控和數據監控兩個部分，血緣分析則主要是對實時數據依賴關係、實時任務的依賴關係進行分析。

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

實時架構

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

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

1. Lambda 架構

先來看下 Lambda 架構圖：

Lambda 架構圖

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

爲什麼 Lambda 架構要分成兩條線計算？

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

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

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

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

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

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

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

那 Lambda 架構有沒有缺點呢？

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

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

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

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

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

2. Kappa 架構

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

Kappa 架構

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

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

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，但是模型的構建思路與流轉過程並沒有發生變化。

Java 與大數據架構

7 年老碼農，10W 關注者。【Java 與大數據架構】全面分享 Java 編程、Spark、Flink、Kafka、Elasticsearch、數據湖等乾貨。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gJdfQZg9kMNUBMYn5ooa5A

猜你喜歡