摘要:Apache Flink 是一個分布式大資料處理引擎,可對有限資料流和無限資料流進行有狀态計算。本文由貝殼找房的資深工程師劉力雲将帶來Apache Flink技術在貝殼找房業務中的應用,通過企業開發的實時計算平台案例的分享幫助使用者了解Apache Flink的技術特性與應用場景。
業務規模及演進
下圖為貝殼找房的業務場景示意圖。最上層為貝殼找房公司最為主體的四大業務:二手房交易、新房交易、租賃業務及裝修業務。四大業務營運将産生圖示中間部分的四大資料即樓盤字典、交易資料、使用者行為日志與後端服務日志。圖示最下部分代表公司實時資料采集、實時資料計算的業務子產品,本文中的案例将重點介紹資料實時計算部分的設計、實作及應用内容。

發展曆程
在2018年初,随着公司埋點治理規範的推進,我們建設了DP實時資料總線,統一承接各種埋點資料流的标準化處理,并對外提供清洗後的實時資料。随着維護的實時任務增加,面臨着實時資料流穩定性以及任務管理方面的挑戰,于是貝殼大資料部着手研發了Hermes實時計算平台,提供統一的實時任務管理平台。
在2018年10月,我們推出了SQL V1編輯器來友善使用者開發實時計算任務。SQL V1基于Spark Structured Streaming技術,使用者可以使用SQL完成需求的開發,同時以界面拖拽的形式呈現給使用者,使使用者的操作更加便捷。在2019年5月,經過調研對比,我們引入了Flink技術棧,研發的SQL V2編輯器正式上線,SQL V2全面支援Flink SQL的各種文法并設計了大量的自定義函數,相容hive UDF以及使用者常用函數。目前我們已經在公司内進行實時數倉業務場景的探索應用。
應用規模
下圖所示為目前實時計算在貝殼找房企業中的應用規模。目前平台支援30餘個業務項目,流計算任務數達到400個,随着數倉的不斷擴充,實時流計算的任務數将不斷上升。每日處理的消息條數達到了800億級别,效率十分可觀。
支援的項目
從下圖所示實時計算在企業中的支援項目可以看出,目前實時計算平台支援從風控、租賃到政策搜尋再到新房交易等一系列業務項目,從各個次元支援起了企業營運産生出資料實時計算業務需求。
任務增長趨勢
最開始平台上線時支援的任務增長較為緩慢,在2019年6月初,平台更新到Flink并全面支援SQL開發後,任務數量開始大規模的增長,在2019年11月份實時數倉建成後,平台所支援的任務數量有了十分明顯的增長趨勢。
平台資料統計
下圖所示為平台每日資料統計。目前平台每日可以處理1000億條資料,一般資料任務的處理延遲在40毫秒左右。
Hermes實時計算平台介紹
平台概覽
Hermes平台目前支援着公司實時任務的開發、編輯、部署、啟停等管理功能及豐富的監控報警等服務。平台支援Java、Scala、Python等多種語言開發的實時任務,支援自定義任務、模闆任務及場景任務三大任務類型,同時做到了各個項目的資源隔離,每個項目均有項目的專有隊列,防止與其他項目在資源上發生競争。平台同時為資源需求較小的項目提供了公共隊列,通過公共隊列對該種項目進行支援的方式,更為友善的實作任務的開發。
Hermes架構
下圖所示為Hermes平台的整體架構,架構分為4個層次,圖中最下層深藍條目代表架構中的計算引擎,目前計算引擎支援Flink與Spark Streaming技術,并通過消息隊列、離線存儲等技術輔助完成資料實時的存儲。在引擎層方面,架構采用StreamSQL、DataStream、StreamCEP等技術搭建,其中StreamCEP技術很好的支援了經紀人平台業務實時監控報警的需求。功能元件層方面包括了任務執行個體的管理、項目管理及資料源管理等。平台目前可以在同一任務中的不同任務快照間進行互相切換,當發現上線任務有問題時,可以回退到之前的快照。
SQL V1編輯器
下圖所示為SQL V1編輯器示意圖。該編輯器對于大部分資料清洗及資料處理的業務場景可以實作簡潔高效的編輯處理。使用者在編輯器左側可以定義編輯資料源、操作符及目标源等資料資訊。中央面闆上呈現的資料為SQL V1支援編輯的操作類型,選中面闆中央的過濾器,即可在編輯器右側添加相關的過濾條件,實作資料的相關過濾。在目标源層面,編輯器目前支援Kafka、Druid等多種目标源,大大提升了編輯器的相容性。
SQL V2編輯器
下圖所示為SQL V2編輯器示意圖。目前SQL V2是基于Flink SQL技術較為完善的編輯器,左側為使用者進行代碼編輯的部分,使用者在此處可以編輯大量SQL語句以此助力不同業務場景。左下欄目中的資料為使用者選中資料源自動生成的DDL,通過DDL編輯器将操作資料的樣式更清晰的展示給使用者。SQL V2支援了三大類型的資料表,分别是source表、sink表及維表,以此友善使用者的開發。編輯器右下角可以呈現SQL文法的檢測情況,以此提示使用者在編輯時出現的文法錯誤。
SQL V2架構
SQL V2工具整體架構如下圖所示。前端SQL編輯器子產品包括文法語義的檢查、執行計劃的檢視、自動DDL的生成及任務調試的功能。使用者通過任務調試功能可以檢視任務執行結果。背景将引擎送出到Yarn叢集上執行,引擎通過任務id回調背景接口擷取需要執行的SQL,對SQL做文法校驗和文法解析,若出現維表關聯則會額外對SQL做一層轉換。
SQL引擎整體架構
下圖所示為SQL引擎的整體架構。整體架構分為三個層次,最底層為Flink Table API。在Flink層之上企業設計了代碼的封裝,以factory的形式友善最上層的方法調用。最上層的core層負責整個系統的SQL解析。
維表關聯
在SQL解析過程中,最為複雜的是維表的表格關聯,下圖為維表關聯系統架構圖。資料從資料源導入後,系統使用Async I/O技術通路後端,系統後端使用Data Accessor接口通路後端的存儲。系統後端存儲支援HBase與Redis存儲技術,同時後端會将資料緩存于LRU Cache子產品中。維表關聯後的資料支援多種大資料工具的存儲,進而大大增加了系統的相容性。
豐富的内置函數
系統同時為使用者提供了豐富的内置函數,包括時間函數、集合函數、Json處理函數及字元串函數。豐富的内置函數可以友善使用者的開發,省去使用者自己去開發的時間。
實時數倉整體架構
下圖所示為實時數倉的整體架構,同時也是SQL V2系統落地的應用場景。各個層級間産生的資料被儲存在了Kafka Topic中,同時資料也将被同步到hive中備份。業務方可以查詢實時備份資料進行資料驗證及分析等操作。目前數倉的實時計算部分可以計算當天或過往幾天的資料,實時計算平台正在與其他元件合作,開發實時與離線聯合的分析查詢,以此擴充實時數倉的使用範圍。
實時數倉資料統計
下圖所示為企業實時數倉的資料統計。從2019年8月,SQL V2正式上線營運,至2019年10月平台開始支援實時數倉開發,系統的資料量開始加速增長。目前,實時數倉已經有100餘個任務,資料吞吐量也達到了21億條/天的資料級别,資料規模較為可觀。
實時數倉案例
下圖列舉出實時數倉平台已經實作提供資料支援的應用案例。
1. 交易平台
交易平台實時大屏實時展示大區内的交易狀況。在交易平台的建設中,開發團隊通過資料回環将還未關聯的資料傳回儲存子產品進行重新關聯,并通過檢驗該資料的生命周期判斷是否關聯成功,團隊通過此種方式使得資料維表與事實表資料最終一緻。
2. 經紀人行程量
經紀人行程量可以動态的展示目前經紀人對客戶的維護情況,使企業可以掌握經紀人實時的工作狀态。
3. 實時使用者畫像
實時使用者畫像可以實時地向企業呈現來自各個系統使用者的資料資訊,通過組合各個平台上使用者的行為資訊,提供全面、精準的使用者畫像。企業的算法政策部門将根據使用者的實時畫像進行相關資訊、内容的推薦。
監控報警
下圖為平台的監控報警頁面截圖。監控系統會實時監控平台任務的處理延時、source寫入量及sink寫出量三大名額。系統中同時可以設定平台資料的無心跳時間,當超出設定時限後,系統将會進行報警。
監控報警架構
下圖為監控報警架構圖。監控系統通過自定義的Listener對Spark進行監控,Listener引入SDK收集Spark任務的資訊及運作中的日志資料。使用者在此處需要進行手動SDK的導入。在Flink應用子產品中,系統設計支援了自定義Report資料的擷取,并通過自動加載的方式直接載入Flink中進行資料的分析與計算,同時通過任務啟動是注入java探針的方式擷取任務的相關資訊。所有的監控資訊将被統一送到Kafka Topic中,經Hermes平台分析處理,觸發相應的延時報警及心跳報警。
未來發展與規劃
整體架構
實時計算平台的整體架構如下圖所示。在架構中間部分,平台包含了實時事件中心、事件處理平台等系統來更好的處理未來企業中的業務場景需求,以通用服務平台的方式為更多的業務方提供統一的業務支撐。在引擎方面,未來會深入研究Flink的狀态管理、端到端的精确一次等技術,提高資料處理的準确性和一緻性。
未來發展
未來将會建設平台的資源動态配置設定能力,根據任務的曆史運作情況自動配置設定資源。使用者可以在事件處理平台上定義各種事件,實時的對事件進行分析,并産生相關的資料報表。使用者通過實時規則引擎用以完成各種業務規則的配置,事件命中規則後觸發相關的業務操作。使用者資料平台彙集各個産品、各個端的使用者資料,提供使用者行為的實時查詢、分析,更加高效的支援營銷、推薦等業務場景。實時數倉建設方面會進行KAPPA模式的探索,推進流批一體化建設,提升曆史資料的處理和查詢能力。