導讀：本次分享的主題爲實時計算引擎在貝殼的應用與實踐。主要內容包括：
- 背景介紹
- 流式計算平臺
- 實時分析監控平臺-FAST
- 後續規劃
背景介紹
貝殼找房由鏈家網升級而來，是以技術驅動的品質居住服務平臺，聚合和賦能全行業的優質服務者，打造開放的品質居住服務生態，致力於爲兩億家庭提供包括二手房、新房、租賃和裝修全方位居住服務。
貝殼找房大數據架構團隊負責公司大數據存儲平臺、計算平臺、實時數據流平臺的架構、性能優化、研發等，提供高效的大數據 OLAP 引擎、以及大數據工具鏈組件研發，爲公司提供穩定、高效、開放的大數據基礎組件與基礎平臺。
貝殼目前有1000多人的產品技術團隊。從實時數據應用角度，公司內主要應用的實時數據，一個是線上的日誌，大概有兩千多個線上的服務，每個服務又輸出了很多的日誌，日誌數據是流式數據應用最多的。第二部分就是埋點，在 APP，web 端上報的經紀人作業情況和 C 端用戶的行爲，這部分通過前端的埋點技術上報。第三部分就是業務的數據，業務用 kafka 做消息隊列產生的實時數據。
流式計算平臺
1. 流式計算平臺
平臺目前主要建設 Spark Streaming，Flink 兩種在實時計算中比較常見的計算引擎。平臺化的背景就是早期如果公司內有業務想用數據流進行計算，可能需要申請客戶端，自己去搭建一個客戶端，然後向集羣上提交實時作業。這個產生的問題就是如果每個業務方都去自己這樣做成本比較高，每個業務都需要關心自己作業的運維問題，還有監控，實時數據作業的監控建設的水平也是參差不齊。Spark Streaming，Flink 對於業務同學直接開發也有一定的學習成本，很難直接用上大數據的能力做實時計算。
我們計算平臺流數據源主要都是用 Kafka。Kafka 數據中數據分爲幾類，一個是數據流，數據流指的是線上的業務日誌、訪問日誌等，會收集到數據流平臺。Binlog 是線上 MySQL、TIDB 產生的 binlog 作爲實時數據源。Dig 是內部前端埋點項目的代號。
計算平臺底層集羣使用 YARN 做資源調度。再上層就是我們現在主要基於社區版 Flink、擴展了開源 Flink 的 SQL 能力。還有提供一些通用的實時處理模板。流計算的輸出要覆蓋線上業務所有需要的存儲分析引擎，例如 ES、Kafka、Hbase 等等。在這些底層基礎之上，首先要做的就是實時任務的管理管控。包括如何幫助平臺上這些所有 Flink 或者 Spark 任務，進行資源的調優，對實時數據流中的數據的元數據化。另外還有在 Web 端提供的 SQL IDE、任務運行狀態的監控報警。在計算平臺之上業務方做的一些應用：指標分析，實時特徵，安全風控，ETL、實時推薦等等。
2. 目前現狀
目前 YARN 平臺大概有七百多個節點，一千多個實時任務，每天的消息量千億級，高峯單個任務消息量百萬條/s。
3. 爲什麼要選擇 Flink
Flink 提供了 Exactly-Once 一致性語義，並且具有非常完善的多種窗口機制，引入了 Event Time 與 WaterMark，還提供豐富狀態的狀態訪問。Flink SQL 降低了實時計算的使用門檻，並且 Flink 社區非常活躍。
我們希望更多使用 SQL 的方式開發計算任務。SQL 的好處在於我們如果用寫代碼的方式計算需要從新建工程開始、引一些相關的依賴、編碼、打包、提交。把這個事變成 SQL 的方式只需要 SQL 文本。我們用平臺的 SQL 解析引擎去加載每個任務的 SQL 文本，就可以生成一個 SQL 任務。
4. 實時數據接入
最終的數據流平臺是 Kafka 集羣。服務器上的日誌這部分數據是怎麼到達 Kafka 集羣的呢？我們是通過一個私有云平臺。業務方可以在私有云上提供項目名與文件路徑，提交自己的採集申請，由運維人員審覈之後，自動下發配置通過 rsyslog 將實時的日誌上報到 topic 上，最終到數據流平臺。
① 元數據化
對於數據流平臺中的實時數據。我們會有一個初期的處理，對標準的數據格式比如 Json 數據、Tab 分隔，可以預先解析實時數據生成它的 Schema，如果後期進行實時計算用到 SQL，可以根據我們解析的元數據幫助用戶自動的生成 DDL。節省了很多任務開發過程中繁瑣的建表操作。
② 實時雲端控制檯
實時雲端控制檯其實是基於 Kafka 做的實時控制檯消費。通常需要預覽 Kafka 中的數據都是去客戶端輸入命令，在實際數據流的使用過程中，有很多用戶有預覽數據的需求，爲了統一管理客戶端我們把它遷移到了 web 端，可以通過 web 端實時消費 kafka 的數據，還可以做一些類似 grep 的簡單過濾。
5. 數據通道
實時計算的能力其實可以把它總結成一個數據通道的能力。實時計算可能不會完全滿足我們的實時分析的需求，比如通常的需求都是一個多維分析、即席查詢的需求。最終我們的方案是通過 Flink 這個引擎去幫我們做這個數據處理與預計算，最終都會落到一個對應存儲分析引擎。
存儲分析引擎根據業務需求去選擇合適的對應輸出。包括實時 OLAP 引擎 druid.io、搜索與分析引擎 Elastic Search、時序數據庫 M3db 等等。
6. 任務開發
業務方或數據開發如何在平臺上開發任務？有兩部分，一個是通常的寫代碼打成 jar 包提交到平臺上，平臺幫它管理任務的流程。還有就是主要做的 SQL 的編輯環境，包括前邊說到的元數據化在這裏可以體現出來。我們把某個 topic 裏的數據元數據化之後，這個 DDL 語句可以自動生成，包括將 UDF 關聯上任務。
7. 任務管控
對於一個任務流程的管理主要包括上圖的這些能力，我們主要支持 Spark2.3、Flink1.8 與 Flink1.9。新的任務優先用 Flink 解決，平臺同時支持 Flink 的 per job、session 兩種模式。session 模式用於小任務合併以合理利用集羣資源，用戶可以在平臺完成實時任務的所有相關操作。
8. Flink SQL 生產實踐
SQL 擴展：
在 Flink1.9 之前社區版對 SQL 的 DDL 沒有支持，另外實際使用時，對維表關聯、輸入輸出源會有一些定製需求。所以我們基於 Apache Calcite 擴展了 Flink SQL 的能力，定義了 DDL、實現了流與多種數據源維表的關聯、UDF 註冊等需求的研發。
關於維表的關聯，我們使用 TiDB 作爲線上 MySQL 的從庫，通過關聯 TiDB 實現與線上業務數據庫的實時關聯。對於 Hbase 的關聯通過 Async IO 去異步讀取 hbase 的數據，並用 LRU 策略去加載維表數據，並支持了 redis 的實時查詢。
9. Flink 任務監控和調優
Flink 任務在集羣中運行會產生各種指標，包括機器系統指標：Hostname、CPU、Memory、Network、IO，還有任務運行組件指標：JobManager、TaskManager、Job、Task、Operater等相關指標。這些 metrics 默認會在 Flink UI 中展示出來。除此之外 Flink 原生還支持了幾種主流的第三方上報方式：JMXReporter、InfluxdbReporter 等等可以直接配置使用。另外還支持自定義 Report。
在 Flink 的 metrics 基礎上，我們還根據業務場景自定義了數據處理實際延遲時間、數據解析失敗量、外部服務調用耗時等指標。所有的指標通過自定義的 Reporter 上報到 Kafka，再通過一個實時的 ETL，把指標結構化後輸出到 ES 和 Druid 裏，按任務的維度在 Grafana 中分類展示，並提供明細的數據查詢。根據這部分 metrics 數據，我們也會定義一些規則去監控任務的各種異常狀態，做一些定製化的報警。
這個是收集上來一些指標的監控，包括任務的輸入輸出速率，算子，JVM，任務運行時的其它指標。
分析 Flink 任務的延遲，傾斜，或者失敗的原因很多都是依靠這些指標，比如根據 JVM 的 metrics 情況對堆內存做出調整。
10. 應用場景-業務 BI 指標實時分析
上圖是流計算在業務指標實時分析上的應用場景。它是基於業務數據庫 binlog 的實時分析，這些業務 binlog 能夠反映出業務實時變化情況。如上圖是其中客源的部分業務指標，通過流計算對 binlog 中對應業務表的 DML 操作的提取以及分析。可以實時掌握業務 BI 指標的變化趨勢。
實時分析監控平臺-FAST
實時計算除了滿足業務的需求，還有一個非常通用的需求就是監控。我們內部的平臺叫做 FAST 天眼平臺。
1. 實時分析監控平臺架構
這個監控分析平臺主要是分析日誌。日誌的種類包括業務的 log、Nginx 的 access log，還有一些 DB 的日誌、中間件日誌、網絡設備等日誌。這些日誌通常通過 rsyslog 採集到 kafka 裏，通過 Spark Streaming/Flink 實時消費。清洗計算後結構化的數據。會落到日誌的的存儲和分析引擎，在這一步也會用 gobblin 把 kafka 裏的數據離線的備份到 hdfs。一是因爲很多情況下實時不能保證數據的準確性。需要離線校準的時候需要一份 kafka 中的原始數據。二是可以滿足日誌長期存儲後續用於審計。在服務層我們提供了一些基礎服務，包括所有引擎對外提供的 API，查詢，計算，分析，監控報警。依託這些清洗之後的數據，通過這些日誌找出他們之間的關聯關係，可以用來實踐 AIOps。在應用方面，可以看到實時計算與日誌結合具體能幫我們做哪些事。有日誌的檢索，日誌聚類。比如日誌一分鐘報了一萬條 Error，如果 RD 去排查問題不可能看完這一萬條再找到問題，所以需要一些文本聚類。包括日誌相關的分析。
2. 日誌計算
在日誌的解析和計算方面我們提供了可視化的配置頁面。可以通過正則、分隔符、json 的解析提取字段，由用戶去解析自己的日誌。這一部分計算引擎對用戶是屏蔽的，因爲對用戶來說，只要配置規則即可，通過配置生成實時計算任務。對於規範化日誌這些可以自動解析，如果是任意的非結構化日誌就需要自己配置規則，然後用 Spark Streaming 或者是 Flink 去做 ETL，包括聚合，join 這些操作。離線的部分會每個小時把原始數據拉一份到 HDFS 冷備，在 hive 中用這些規則進行離線的 ETL。
3. 數據存儲 - Elasticsearch 存儲集羣架構
實時計算的流程最終把日誌的明細數據存儲到 ES 集羣，最初我們的幾套 ES 集羣存儲是全 nvme SSD 的。隨着接入的服務越來越多，日誌量越來越大。需要一個滿足日誌存儲時間很長但成本不會明顯增加的架構。具體的實現是通過對 ES 節點劃分爲 warm 與 hot 冷熱兩種節點。因爲檢索場景中，一般最近一兩天的日誌是查詢頻率比較高的，所以掛載大容量的 HDD 節點適合存儲歷史數據即查詢頻率較低且沒有實時寫入的索引。在凌晨業務低峯期把冷數據通過標籤轉到只讀的冷數據節點。對於查詢幾個月之前的數據需求，這時需要之前冷備的那份 HDFS 上的數據，通過 hadoop-es 將他加載到 ES，基於 ES 集羣上中的數據。我們也提供了檢索 api 服務、下載服務，比如提供給 QA 通過腳本拉取日誌進行版本比對的 diff 測試。
4. 數據存儲 - Druid.io 集羣架構
實時分析這方面現在用的是主要是 Druid.io。Druid 是一個實時 OLAP 的引擎。實時的將我們實時計算的結果經 Kafka，用 Tranquility 將數據寫入 Druid 的 datasource。但因爲 Druid 一般我們會設置一個時間窗口，如果有上層實時計算任務延遲，數據就可能會丟失，因此需要離線校準來保障數據準確性。一般用 MapReduce 將 hive 中離線結構化的數據重新索引到 Druid 對應的 datasource，覆蓋實時寫入的數據。Druid 在存儲上也分爲熱數據的節點和冷數據的節點，hdfs 作爲 deep store。
5. 異常檢測
監控報警、異常檢測是實時計算的主要應用點，我們自研的報警服務可以檢測多種實時數據來源。覆蓋明細類和指標類的異常檢測，支持明細檢測、指標聚合、同環比、流量抖動等等異常事件。可以根據業務需求靈活配置規則、訂閱報警。Flink CEP 的能力我們也在監控場景引入進來應用在爬蟲檢測。實時檢測到的異常事件會通過各種渠道通知訂閱者：電話、企業微信、短信、郵件、callback 等。
6. 應用案例
這個例子是 FAST 天眼平臺在業務日誌實時監控場景的一個實際案例，左邊是業務方在企業微信裏可以實時收到自己負責的項目線上的錯誤日誌的推送，右邊是實時計算的結果存到時序數據庫中，用戶可以根據自己的業務場景在 Grafana 中配各種 Dashboard。比如實時的流量、接口的瓶頸，包括一些 QPS，異常看板的展示。整個過程可以由平臺用戶自助完成。
這個是我們全網服務穩定性分析能力，圖中是某一個線上域名的分析報告的一部分。數據來源是公司的7層負載均衡的訪問日誌。可以用它來做整個公司下所有服務穩定性的分析。展示正常流量、異常流量、SLA 值、請求路徑響應時間趨勢、QPS 趨勢等。可以由這類數據產生實時 QPS 排名，實時穩定性紅黑榜等應用。通過實時+離線的結合。可以支持任意時間範圍的服務穩定性分析。
後續規劃
- 完善 SQL 解析引擎。持續豐富 SQL 解析能力，建設 SQL 調試能力、提升開發效率，降低流計算的使用門檻。
- 動態的資源管理。目前在資源分配場景，有些任務不需要那麼多資源或者優化代碼可以提升的計算效率，但是用戶會把資源分配的很多。因此需要我們在這個平臺能監測任務的資源實際利用率，進行動態的資源調整，合理利用資源。
- 實時任務問題診斷。希望通過收集和分析實時計算任務中歷史常見的錯誤，後續在任務出現問題或報錯時，平臺能夠給出建議解決方案。
- 智能監控。希望能用實時計算+機器學習，在流量預測、異常檢測、根因分析等 AIOps 場景孵化出更多能力。
作者介紹：
王磊
貝殼 | 大數據工程師
本文來自 DataFun 社區
原文鏈接：