貝殼基於 Flink 的實時計算演進之路

簡介：貝殼找房在實時計算之路上的平臺建設以及實時數倉應用。

摘要：貝殼找房大數據平臺實時計算負責人劉力雲帶來的分享內容是貝殼找房的實時計算演進之路，內容以下：

1. 發展歷程
2. 平臺建設
3. 實時數倉及其應用場景
4. 事件驅動場景
5. 將來規劃

GitHub 地址
https://github.com/apache/flink
歡迎你們給 Flink 點贊送 star~

1、發展歷程

首先是平臺的發展歷程。最先是由於業務方在實時計算方面有比較多的業務場景，包括業務方自研的實時任務，須要自行開發、部署及維護，咱們的大數據部門也會承接客戶大數據的實時開發需求。

這些看起來都是一些煙囪式的開發架構（即每一個業務線之間由不一樣的開發團隊獨立建設，技術棧不一樣，互不聯繫），缺少統一的任務管控，也很難保留開發過程當中積累的技術沉澱。所以，咱們在 18 年時上線了基於 Spark Streaming 的實時計算平臺，統一部署管理實時計算任務。以後咱們又在此基礎上提供了任務開發功能 - 標準化的 SQL 語言（SQL 1.0），以提升數據開發效率。

隨着咱們承接的任務愈來愈多，咱們也發現了 Spark Streaming 的一些使用問題，主要是其 Checkpoint 是同步的，有時會形成比較大的延遲。此外，Kafka 消費的 Offset 數據存在 Checkpoint，很難作到任務細粒度的監控，好比消費狀態的獲取，因而咱們開始轉向 Flink。

19 年，咱們的平臺開始支持 Flink 任務，而且很快提供了基於 Flink 1.8 的 SQL 2.0 功能，包括 DDL 定義和維表關聯。接下來，在 SQL 2.0 的基礎上，咱們開始了實時數倉的建設。

今年初，在收集了業務方的需求場景後，咱們認爲在實時事件處理方面需求明確，並且目前的實現也存在較多的弊端，所以咱們開始着手事件處理平臺的開發。今年發佈的 Flink 1.11 在 SQL 方面有很大的提高，咱們在其基礎上正在開發一套統一的 SQL（3.0）。

目前平臺支持的部門涵蓋了貝殼絕大部分的業務方，支持各類場景，包括人店相關的房源、客源、經紀人、風控以及運營等。

目前平臺支持的項目有 30 多個。在 SQL2.0 後，平臺上的任務數有明顯增加，達到 800 多個。因爲貝殼全部的流量數據、用戶行爲分析、以及數倉的建設都是經過平臺來構建的，因此數據量很大，天天處理的消息達 2500 億條，單任務的消息吞吐量峯值達 3 百萬。

這是咱們平臺任務的增加狀況，能夠明顯看到 19 年 10 月 SQL 2.0 上線且支持實時數倉開發後，任務增加勢頭顯著。

2、平臺建設

平臺的功能概覽包括四個方面：

• 支持任務託管的基本能力，包括任務的編輯發佈、版本管理、監控報警等；
• 支持多種語言的實時任務，包括對貝殼算法相關的 Python 實時任務的良好支持；
• 根據業務場景不一樣，支持多種業務類型，如自定義任務、模板任務及場景任務（SQL 任務），內部通用配置化任務，如分流合併操做。目前 SQL 任務在平臺佔比較高，咱們的目標是 80%；
• 支持公共隊列（針對較數據量小的需求），對於數據量大的需求，要有穩定的資源保證，咱們能夠提供專有隊列，運行更爲可靠。

平臺的總體架構與其它公司的差很少。底層是計算和存儲層，計算支持 Flink 和 Spark，主要包括消息隊列和各類 OLAP 存儲，同時也支持 MySQL，Hive 也能夠作到實時落地，維表支持 Redis，HBase 存儲。ClickHouse 是目前主要的實時 OLAP 存儲，因爲 Doris 支持 update，同時對關聯查詢的支持也比較好，咱們也在嘗試 Doris 存儲。

引擎層主要封裝的是 SQL 引擎、DataStream 的通用性操做。在事件處理方面，對 Flink 的 CEP，包括對其它普通規則也作了較好的封裝。

開發管理層提供了各類任務的開發、監控和資源管理。

平臺之上，也是提供了對 ETL、BI、推薦、監控、風控等各類業務場景的支持。

這是平臺任務生命週期的管理。能夠看到，在啓動後會新建實例，從集羣拿到運行狀態後會判斷是否正常運行。「是」則轉成運行中狀態。在運行過程當中會對任務作延遲和心跳的監控；若是說任務發生了異常，而且在配置中設置了延遲或心跳時長的閾值，則會嘗試進行重啓。用戶能夠在啓動任務時設置重啓次數，當超過該值時，則認爲重啓失敗，將發送告警給任務負責人。

這是平臺監控報警的架構。咱們在 Spark 引入了 sdk 依賴，在用戶開發任務時用代碼顯示添加就能夠監聽系統關心的指標。Flink 任務支持自定義 Reporter 的 metrics 的獲取。咱們還支持 java agent 的依賴注入，經過依賴注入咱們能夠獲取實時任務的制定信息。在 Hermes 平臺，咱們能夠拿到這些監控信息，來支持延時報警、心跳報警、及數據血緣基礎上的流量分析，後續的有狀態任務恢復也依賴這些監控指標。監控日誌落入存儲（InfluxDB）以後能夠進行可視化處理，方便的查看歷史運行狀態。

這是平臺監控查看頁面，分別顯示了數據讀入、寫出、及延時的狀況。

3、實時數倉

咱們的實時數倉目前具有如下幾方面能力：首先是完善的元數據管理，包括鏈接管理和表管理；數倉開發人員共同構建了數據分層架構，包括 4 個分層：

• 在實時側，分層越少越好，不然中間環節越多，出問題的機率越大；
• 在 SQL 層面，支持標準的SQL語法，維表關聯，提供圖形化的SQL開發環境。另外還支持豐富的內置函數，並逐步完善支持用戶自定義函數（UDF）的開發；
• 數據血緣方面，平臺支持圖形化展現和完善的鏈路分析，並且能實時看到數據流的運行狀況並對異常進行標示；
• 最後是多源支持，對公司內部用到的各類存儲作到了較好的支持。

這是簡易的實時數倉架構圖，整體來講是屬於 Lambda 架構，包括實時流和離線流，以及離線流對實時流數據覆蓋的修復。從用戶行爲日誌、後端服務器日誌及業務數據庫採集來的消息流，匯入並經過 ODS（Opertional Data Source）層再到 DW（Data Warehouse）層，咱們支持 ODS 和 DW 層對維度進行擴充，關聯維表。

目前 DWD（Data Warehouse Detail）層的數據直接送入 ClickHouse，ClickHouse 如今是咱們 OLAP 引擎的一個主力存儲。從 DWD 到 ClickHouse 的存儲只知足了部分業務場景，還存在一些問題。好比咱們須要作數據彙總，那麼咱們如今 DWS（Data Warehouse Service）層在這方面還稍微欠缺。目前明細數據進入了 ClickHouse，咱們首先對那些應該彙總的數據存了明細，這樣會致使存儲量比較大，查詢效率較低。後續咱們會考慮引入 Doris，由於它能夠在實時計算側作實時聚合，依託 Doris 對 Update 的支持，就能夠完善 DWS 功能。

這裏展現的是咱們的 SQL 編輯器。能夠看到左邊是正在編輯的 SQL，咱們支持 Flink 執行計劃的查看、任務調試。右側一列能夠定義源表、維表、輸出表。能夠在自定義的數據源基礎上定義流表，並自動生產 DDL。同時，對於某些自動生成 DDL 難以支持的場景，用戶能夠在左邊的編輯區域自行編寫 DDL。

任務調式分爲手動和自動兩種方式。手動方式需準備樣例數據，拷貝到開發界面；自動方式則會從 SQL 任務的上游獲取樣例數據。元數據信息（kafka、HBase、ClickHouse 等）是動態得到的，元信息和樣例共同生成的 DebugSQL 去調用 SQL 引擎的公共服務。SQL 引擎獲得樣例數據後，好比，若是有關聯維表的操做，則會關聯線上維表，在 SQL 引擎中執行調試，將結果送給 UI 端進行展現。

這是一個完整的調試界面，能夠看到左側是自動獲取的樣例數據，右側是下游的輸出。

根據元數據的定義及上報的指標等監控數據，咱們能夠生成一個實時數據血緣鏈路。圖中的箭頭展現了數據流轉的健康情況，將來會對血緣鏈路上的數據監控作得更細緻。數據血緣知足了 4 個方面的需求：溯源分析、問題排查、數據差別分析、提高用戶體驗。在血緣鏈路上還能夠進行比較複雜的異常預警，例如，數據源字段的變動對下游的影響。

這是咱們 SQL2.0 引擎的大體架構，經過 Antlr4 擴展標準 SQL 的語法，從而支持 Flink 的各類源，維表和下游存儲表的定義。經過 SqljobParser 內置的 SqlStmtParser 生成 SqlContext，在邏輯計劃（Logical Plan）中作解析。若是遇到維表，則通過一系列維表關聯的流程。上圖中下半部分是底層 API 架構。

這是平臺 DDL 樣例。對於源表（Source），支持 Kafka，將來在新版本的 Flink 之上將能夠支持更多種源。對於維表（Dim），支持 HBase、Redis、MySQL。數據存儲表（Sink）支持圖中所列五種。表格下面的是 DDL 定義的語法規則，右邊是一些表定義的樣例，分別是 Kafka 源表、維表和輸出表（輸出到控制檯）。

再看咱們的維表關聯，從 SQL 引擎結構能夠看出，輸入的 SQL 進行解析，當有維表關聯時（包含 join 字段），咱們會從語法層面作轉換。咱們在表的層面定義了流和維關聯以後的表的形態，左下角是其生成過程。關聯維表、流維轉換、用異步 IO 獲取數據等過程不在這裏細說。

隨着 Flink 社區新版本的發佈，在 SQL 方面的支持愈來愈強，咱們目前正在作基於 Flink1.11 的新版 SQL 引擎，也會將以前的 SQL 引擎統一。由於 Flink1.11 支持DDL，因此這部分咱們不會再作，而是直接使用其新特性：

• 解析模塊（Parse Model）將用戶原始的 SQL 解析成內部的執行計劃，徹底依賴於 Flink SQL。Connector Model 完成目前 Flink 還沒有支持的 Connector 開發。
• Format Model 實現數據源字段的序列化和反序列化。
• 執行模塊（Execute Model）基於 Flink1.11 SQL API 執行解析後的執行計劃。
• UDF 模塊是專門處理 UDF 的解析，如參數調用的合法驗證、權限驗證、細緻的數據權限限制。
• SDK Model 是對外提供的標準化服務，如 SQL 文本開發的驗證，debug 功能等。

![image.png](https://ucc.alicdn.com/pic/developer-ecology/9542a09e686042e19564d3839194d526.png

這是實時數倉的一個落地場景：交易的實時大屏，也是咱們第一個落地的典型業務場景。咱們支持各類交易實時指標，用戶能夠經過實時查詢 ClickHouse 獲得交易數據的各類圖表展現。

客戶實時熱力圖是咱們正在跟業務方溝通的一個需求場景，能實時獲取用戶線上的行爲，使經紀人對客戶行爲有一個比較全面的實時掌控，促進客戶維護的轉化率。另外一方面，也使客戶更方便地瞭解房源熱度狀態，促使用戶作出購買決策。

4、事件驅動

先了解一下事件驅動型和數據分析型的區別：

• 事件驅動是根據事件流中的事件實時觸發外部計算和外部狀態的更新，主要關注實時事件觸發的外部變化，重在單獨事件以及外部動做的觸發。
• 數據分析型主要是從原始數據中提取有價值的信息，重在分析。

在咱們跟業務方的溝經過程中，咱們發現不少場景中他們但願實時獲取用戶的行爲。比較典型的是風控場景，根據用戶線上的行爲模式判斷其是否觸發風控規則。此外，咱們的實時運營，根據用戶線上行爲給用戶進行積分的增長及信息推送。搜索推薦也是咱們很是關心的，即用戶在搜索以前的實時行爲。綜合這些，咱們提取出三方面問題：

• 一是用戶行爲事件缺少統一的抽象和管理，開發效率低，週期長，各部門存在重複建設；
• 二是規則邏輯與業務系統是耦合的，難以實現靈活的變化，對於複雜的規則或場景，業務方缺少相關的技能和知識儲備，如對 CEP 的支持；
• 第三是缺少統一的下游動做觸發的配置。

基於以上三個痛點，咱們構建了事件處理平臺，抽象成三個模塊，事件管理，規則引擎和動做觸發。

這是事件處理平臺所支持的業務場景。

這是事件處理平臺的架構，整體來講就是管理模塊，引擎和動做觸發。在中間這裏咱們提供了一個適配層，能夠跟第三方系統進行集成。

這是咱們事件處理的操做流程，首先是建立數據源，與實時計算平臺相似，主要支持 Kafka，在 Kafka 消息流上定義咱們的數據格式。

在數據源基礎上建立事件流，事件流包含了同類事件，咱們實現了一些算子，能夠在數據源的基礎上作一些操做。從右側能夠看到，在多個數據源上進行了一些過濾、加解密的操做，最終經過 union 算子彙總成一個統一格式的同類事件的事件流，方便後續使用。

在事件流的基礎上能夠定義單個的事件，以後能夠建立事件組，以對接咱們的業務含義，即明確具體的業務是作什麼的，如用戶的點擊、瀏覽、分享、關注等事件。建立事件組有兩種方式：

• 一是本地方式，便可以根據事件的各個字段和維度設定條件；
• 二是遠程方式，這與咱們的埋點系統（用戶行爲日誌）直接連通，能夠直接獲得用戶事件的定義。

任務配置過程分幾個部分，這是 log 監控的任務樣例。上圖展現的是事件處理的規則設置部分。這是一個 CEP 事件，能夠定義事件窗口，獲取具體事件，在此之上定義 CEP 的模式，還能夠定義事件的輸出，例如須要輸出哪些字段。

這是觸發動做調用，支持消息發送，服務調用及落地 Kafka。截圖展現的是消息發送的樣例。

5、將來規劃

這是咱們實時計算的總體架構，下部是 Hermes 實時計算平臺，主要包括任務管控、SQL 引擎、CEP 引擎等各類能力。Data Pipeline、實時數倉及事件處理平臺的任務都是經過此平臺進行管控。將來咱們計劃作的是用戶數據平臺，如各業務方對用戶的線上行爲的歷史查詢，以及在全平臺用戶數據的綜合分析。

對將來的規劃主要有以上幾個方向，包括狀態的管理及恢復、動態的資源分配（動態的配置、動態的資源調整）。爲了保持任務的穩定性，咱們在也計劃在高可用性方面作一些調研。在流批一體方面，會借用數據湖的能力，提供對歷史和實時數據的混合查詢的支持。

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。