摘要：本文由?bilibili?大數(shù)據(jù)實(shí)時(shí)平臺(tái)負(fù)責(zé)人鄭志升分享，基于對(duì) bilibili 實(shí)時(shí)計(jì)算的痛點(diǎn)分析，詳細(xì)介紹了 bilibili Saber 實(shí)時(shí)計(jì)算平臺(tái)架構(gòu)與實(shí)踐。本次分享主要圍繞以下四個(gè)方面：

?

一、實(shí)時(shí)計(jì)算的痛點(diǎn)

二、Saber?的平臺(tái)演進(jìn)

三、結(jié)合?AI?的案例實(shí)踐

四、未來的發(fā)展與思考

?

?

一、實(shí)時(shí)計(jì)算的痛點(diǎn)

?

1.痛點(diǎn)

?

各個(gè)業(yè)務(wù)部門進(jìn)行業(yè)務(wù)研發(fā)時(shí)都有實(shí)時(shí)計(jì)算的需求。早期，在沒有平臺(tái)體系做支撐時(shí)開發(fā)工作難度較大，由于不同業(yè)務(wù)部門的語言種類和體系不同，導(dǎo)致管理和維護(hù)非常困難。其次，bilibili 有很多關(guān)于用戶增長、渠道投放的分析等 BI 分析任務(wù)。而且還需要對(duì)實(shí)時(shí)數(shù)倉的實(shí)時(shí)數(shù)據(jù)進(jìn)行清洗。此外，bilibili 作為一個(gè)內(nèi)容導(dǎo)向的視頻網(wǎng)站，AI 推薦場景下的實(shí)時(shí)計(jì)算需求也比較強(qiáng)烈。

?

2.痛點(diǎn)共性

?

• 開發(fā)門檻高：基于底層實(shí)時(shí)引擎做開發(fā)，需要關(guān)注的東西較多。包括環(huán)境配置、語言基礎(chǔ)，而編碼過程中還需要考慮數(shù)據(jù)的可靠性、代碼的質(zhì)量等。其次，市場實(shí)時(shí)引擎種類多樣，用戶選擇有一定困難。

?

?

• 運(yùn)維成本高：運(yùn)維成本主要體現(xiàn)在兩方面。首先是作業(yè)穩(wěn)定性差。早期團(tuán)隊(duì)有 Spark 集群、YARN 集群，導(dǎo)致作業(yè)穩(wěn)定性差，容錯(cuò)等方面難以管理。其次，缺乏統(tǒng)一的監(jiān)控告警體系，業(yè)務(wù)團(tuán)隊(duì)需要重復(fù)工作，如計(jì)算延時(shí)、斷流、波動(dòng)、故障切換等。

?

?

• AI 實(shí)時(shí)工程難：bilibili 客戶端首頁推薦頁面依靠 AI 體系的支撐，早期在 AI 機(jī)器學(xué)習(xí)方面遇到非常多問題。機(jī)器學(xué)習(xí)是一套算法與工程交叉的體系。工程注重的是效率與代碼復(fù)用，而算法更注重特征提取以及模型產(chǎn)出。實(shí)際上 AI 團(tuán)隊(duì)要承擔(dān)很多工程的工作，在一定程度上十分約束實(shí)驗(yàn)的展開。另外，AI 團(tuán)隊(duì)語言體系和框架體系差異較大，所以工程是基建體系，需要提高基建才能加快 AI 的流程，降低算法人員的工程投入。

?

?

3.基于 Apache?Flink 的流式計(jì)算平臺(tái)

?

為解決上述問題，bilibili 希望根據(jù)以下三點(diǎn)要求構(gòu)建基于 Apache Flink 的流式計(jì)算平臺(tái)。

?

• 第一點(diǎn)，需要提供 SQL 化編程。bilibili 對(duì) SQL 進(jìn)行了擴(kuò)展，稱為 BSQL。BSQL 擴(kuò)展了 Flink 底層 SQL 的上層，即 SQL 語法層。

• 第二點(diǎn)，DAG 拖拽編程,一方面用戶可以通過畫板來構(gòu)建自己的 Pipeline，另一方面用戶也可以使用原生 Jar 方式進(jìn)行編碼。

• 第三點(diǎn)，作業(yè)的一體化托管運(yùn)維。

?

?

涵蓋場景：bilibili 流式計(jì)算平臺(tái)主要涵蓋四個(gè)方面的場景。

?

• AI 工程方向，解決了廣告、搜索、推薦的流式 Joiner 和維表 Joiner；

• 實(shí)時(shí)計(jì)算的特征支持，支持 Player 以及 CDN 的質(zhì)量監(jiān)控。包括直播、PCU、卡頓率、CDN 質(zhì)量等；

• 用戶增長，即如何借助實(shí)時(shí)計(jì)算進(jìn)行渠道分析、調(diào)整渠道投放效果；

• 實(shí)時(shí) ETL，包括 Boss 實(shí)時(shí)播報(bào)、實(shí)時(shí)大屏、看板等。

??

?

二、Saber?的平臺(tái)演進(jìn)

?

1.平臺(tái)架構(gòu)

?

實(shí)時(shí)平臺(tái)由實(shí)時(shí)傳輸和實(shí)時(shí)計(jì)算兩部分組成，平臺(tái)底層統(tǒng)一管理元數(shù)據(jù)、血緣、權(quán)限以及作業(yè)運(yùn)維等。實(shí)時(shí)傳輸主要負(fù)責(zé)將數(shù)據(jù)傳入到大數(shù)據(jù)體系中。實(shí)時(shí)計(jì)算基于 BSQL 提供各種應(yīng)用場景支持。

?

如下圖所示，實(shí)時(shí)傳輸有 APP 日志、數(shù)據(jù)庫 Binlog、服務(wù)端日志或系統(tǒng)日志。bilibili 內(nèi)部的 Lancer 系統(tǒng)解決數(shù)據(jù)落地到 Kafka 或 HDFS。計(jì)算體系主要圍繞 Saber 構(gòu)建一套 BSQL，底層基于 YARN 進(jìn)行調(diào)度管理。

?

上層核心基于 Flink 構(gòu)建運(yùn)行池。再向上一層滿足多種維表場景，包括 MySQL、Redis、HBase。狀態(tài)（State）部分在 RocksDB 基礎(chǔ)上，還擴(kuò)展了 MapDB、Redis。Flink 需要 IO 密集是很麻煩的問題，因?yàn)?Flink 的資源調(diào)度體系內(nèi)有內(nèi)存和 CPU，但 IO 單位未做統(tǒng)一管理。當(dāng)某一個(gè)作業(yè)對(duì) IO 有強(qiáng)烈的需求時(shí)，需要分配很多以 CPU 或內(nèi)存為單位的資源，且未必能夠很好的滿足 IO 的擴(kuò)展。所以本質(zhì)上 bilibili 現(xiàn)階段是將 IO 密集的資源的 State 轉(zhuǎn)移到 Redis 上做緩解。數(shù)據(jù)經(jīng)過 BSQL 計(jì)算完成之后傳輸?shù)綄?shí)時(shí)數(shù)倉，如 Kafka、HBase、ES 或 MySQL、TiDB。最終到 AI 或 BI、報(bào)表以及日志中心。

?

?

2.?開發(fā)架構(gòu)設(shè)計(jì)

?

（1）開發(fā)架構(gòu)圖：如下圖左側(cè)所示。最上層是 Saber-Streamer，主要進(jìn)行作業(yè)提交以及 API 管理。下一層是 BSQL 層，主要進(jìn)行 SQL 的擴(kuò)展和解析，包括自定義算子和個(gè)性算子。再下層是運(yùn)行時(shí)態(tài)，下面是引擎層。運(yùn)行時(shí)態(tài)主要管理引擎層作業(yè)的上下層。bilibili 早期使用的引擎是 Spark Streaming，后期擴(kuò)展了 Flink，在開發(fā)架構(gòu)中預(yù)留了一部分引擎層的擴(kuò)展。最下層是狀態(tài)存儲(chǔ)層，右側(cè)為指標(biāo)監(jiān)控模塊。

?

（2）平臺(tái)設(shè)計(jì)準(zhǔn)則：Saber 平臺(tái)系統(tǒng)設(shè)計(jì)時(shí)團(tuán)隊(duì)關(guān)注其邊界以及規(guī)范和準(zhǔn)則，有以下四個(gè)關(guān)鍵點(diǎn)。第一是對(duì) Streaming workflows 進(jìn)行抽象。第二是數(shù)據(jù)規(guī)范性，保證 schema 完整。第三是通用的 BSQL 解析層。第四是工程效率。

??

?

• Streaming workflows：下圖為流計(jì)算模型抽象。大數(shù)據(jù)計(jì)算引擎的本質(zhì)是數(shù)據(jù)輸入經(jīng)過一個(gè) function 得到輸出，所以 function 本質(zhì)是一個(gè)能夠做 DAG 轉(zhuǎn)換的 Transform。Saber 平臺(tái)期望的流計(jì)算抽象形態(tài)是提供相應(yīng)的 Source，計(jì)算過程中是一個(gè) Transform 的 DAG，最后有一個(gè) Sink 的輸出。

?

在上述抽象過程中規(guī)范語義化標(biāo)準(zhǔn)。即最后輸入、輸出給定規(guī)范標(biāo)準(zhǔn)，底層通過 Json 表達(dá)方式提交作業(yè)。在沒有界面的情況下，也可以直接通過 Json 方式拉起作業(yè)。

?

?

• 讓數(shù)據(jù)說話：數(shù)據(jù)抽象化。計(jì)算過程中的數(shù)據(jù)源于數(shù)據(jù)集成的上報(bào)。數(shù)據(jù)集成的上報(bào)有一套統(tǒng)一的平臺(tái)入口。用戶首先需要在平臺(tái)上構(gòu)建一個(gè)輸入的數(shù)據(jù)源。用戶選擇了一個(gè)對(duì)應(yīng)的數(shù)據(jù)源，平臺(tái)可以將其分發(fā)到 Kafka、 HBase、 Hive 等，并且在分發(fā)過程中要求用戶定義 Schema。所以在數(shù)據(jù)集成過程中，可以輕松地管理輸入語言的 Schema。計(jì)算過程中，用戶選擇 Input Source，比如選擇一個(gè) HBase 的表或 Kafka 的表，此時(shí) Schema 已是強(qiáng)約束的。用戶通過平臺(tái)提供的 BSQL 或者 DAG 的方式進(jìn)行結(jié)果表或者指標(biāo)的輸出。

?

?

• BSQL 通用設(shè)計(jì)：BSQL 是遵照 Streaming workflows 設(shè)計(jì)的思想,核心工作圍繞 Source、Transform 以及 Sink。Transform 主要依托 Flink SQL，所以 BSQL 更多是在 Source 和 Sink 上進(jìn)行分裝，支持 DDL 的分裝。此處 DDL 參照阿里云對(duì)外資料進(jìn)行了擴(kuò)展。另外，BSQL 針對(duì)計(jì)算過程進(jìn)行了優(yōu)化，如針對(duì)算子計(jì)算的數(shù)據(jù)傾斜問題采取分桶 + hash 策略進(jìn)行打掃。針對(duì) distinct 類 count，非精準(zhǔn)計(jì)算采用 Redis 的 HyperLogLog。

?

?

• BSQL 解析模型：BSQL 解析模型拓?fù)湔归_如下圖。當(dāng)用戶提交了一個(gè) SQL，目標(biāo)是將 SQL 轉(zhuǎn)化成樹。之后可以獲取 SqlNode 節(jié)點(diǎn)。SqlNode 節(jié)點(diǎn)中有很多元數(shù)據(jù)信息。在 SqlNode 樹的情況下實(shí)現(xiàn) Table 解析器，將不同的 SqlNode 節(jié)點(diǎn)轉(zhuǎn)化成 Flink 相應(yīng)的 Streamer 進(jìn)行映射。

?

?

• BSQL 執(zhí)行流程：用戶提交 SQL，BSQL 首先進(jìn)行驗(yàn)證并構(gòu)建 SQL 樹。驗(yàn)證與構(gòu)建主要是提取表名、字段信息，從元數(shù)據(jù)庫中提取 schema 驗(yàn)證 SQL 的規(guī)范性、完整性和合法性。驗(yàn)證完成后，將輸入表和結(jié)果表注冊(cè)到 Flink 的運(yùn)行時(shí)態(tài)，其中還包括 UDF 和 watermark 信息的完善。另外，平臺(tái)對(duì) SQL 有一些擴(kuò)展。第三塊是擴(kuò)展的核心工作，將 SQL 樹中擴(kuò)展的子樹轉(zhuǎn)換為新的節(jié)點(diǎn)，然后將 SQL 的 DAG 提交到 Flink 上運(yùn)行。

??

?

• 效果展示-DAG：如下圖所示，DAG 產(chǎn)品展示，包括并行度的設(shè)計(jì)、日志、監(jiān)控指標(biāo)告警輸出。

?

?

• 效果展示-BSQL：用戶根據(jù)選擇的表的輸入源的 schema 編寫相應(yīng)的 SQL。最后選擇相應(yīng) UDF 就可以提交到相應(yīng)集群。

?

?

• 效果展示-作業(yè)調(diào)試：如下圖所示為平臺(tái)支持的作業(yè)調(diào)試。如果只有 SQL 開發(fā)卻沒有作業(yè)調(diào)試環(huán)節(jié)，是令用戶痛苦的。故平臺(tái)支持通過文件上傳的方式以及線上采樣的方式進(jìn)行作業(yè)調(diào)試 SQL。

?

?

• 效果展示-作業(yè)運(yùn)維：平臺(tái)提供給用戶一些監(jiān)控指標(biāo)、用戶可自定義擴(kuò)展的指標(biāo)以及 bilibili 實(shí)現(xiàn)的一些特殊 SQL 的自定義指標(biāo)。下圖所示為部分隊(duì)列的運(yùn)行情況。

?

?

三、結(jié)合 AI 的案例實(shí)踐

?

1.AI - 機(jī)器學(xué)習(xí)現(xiàn)狀

?

AI 體系中有 Offline 和 Online 過程。Online（線上訓(xùn)練）根據(jù)流量做 A/B 實(shí)驗(yàn)，根據(jù)不同實(shí)驗(yàn)的效果做推薦。同時(shí)每個(gè)實(shí)驗(yàn)需要有相應(yīng)的模型 push 到線上。AI 的痛點(diǎn)集中在 Offline（離線訓(xùn)練）。Offline 則通過流式方式進(jìn)行訓(xùn)練。下圖是 Offline 流式訓(xùn)練早期情況。用戶需要構(gòu)建流和流的實(shí)時(shí) join，從而產(chǎn)出實(shí)時(shí) label 流。而流和維表及特征信息的 join 來產(chǎn)出實(shí)時(shí) instance 流，但早期相關(guān)的工程服務(wù)存在著單點(diǎn)問題，服務(wù)質(zhì)量、穩(wěn)定性帶來的維護(hù)成本也很高，致使 AI 在早期 Pipeline 的構(gòu)建下投入非常大。

?

?

2.弊端與痛點(diǎn)

?

• 數(shù)據(jù)時(shí)效性：數(shù)據(jù)時(shí)效性無法得到保證。很多數(shù)據(jù)是通過離線方式進(jìn)行計(jì)算，但很多特征的時(shí)效性要求非常高。

• 工程質(zhì)量：單點(diǎn)工程不利于服務(wù)擴(kuò)展以及穩(wěn)定性保障。

• 工程效率：每一個(gè)實(shí)驗(yàn)都有較高門檻，需要做 Label 生產(chǎn)，Features 計(jì)算以及 Instance 拼接。在不同業(yè)務(wù)線，不同場景的推薦背后，算法同學(xué)做工程工作。他們掌握的語言不同，導(dǎo)致工程上語言非常亂。另外，流、批不一致，模型的訓(xùn)練在實(shí)時(shí)環(huán)境與離線批次環(huán)境的工程差異很大，其背后的邏輯相似，導(dǎo)致人員投入翻倍增長。

?

3.模型訓(xùn)練的工程化

?

構(gòu)建一套基于 Saber-BSQL、Flink 引擎的數(shù)據(jù)計(jì)算 Pipeline，極大簡化 Instance 流的構(gòu)建。其核心需要解決以下三個(gè)問題：Streaming Join Streaming（流式 SJoin），Streaming Join Table（維表 DJoin），Real-time Feature（實(shí)時(shí)特征）。

?

?

• SJoin-工程背景：流量規(guī)模大，如 bilibili 首頁推薦的流量，AI 的展現(xiàn)點(diǎn)擊 Join，來自全站的點(diǎn)擊量和展現(xiàn)。此外，不僅有雙流 Join，還有三流及以上的 Join，如廣告展現(xiàn)流、點(diǎn)擊流、搜索查詢流等。第三，不同 Join 對(duì) ETL 的清洗不同。如果不能通過 SQL 的方式進(jìn)行表達(dá)，則需要為用戶提供通用的擴(kuò)展，解決不同業(yè)務(wù)對(duì) Join 之前的定制化 ETL 清洗。第四，非典型 A Left Join B On Time-based Window 模型。主流 A 在窗口時(shí)間內(nèi) Join 成功后，需要等待窗口時(shí)間結(jié)束再吐出數(shù)據(jù)，延長了主流 A 在窗口的停留時(shí)間。此場景較為關(guān)鍵，bilibili 內(nèi)部不僅廣告、AI、搜索，包括直播都需要類似的場景。因?yàn)?AI 機(jī)器學(xué)習(xí)需要正負(fù)樣本均勻以保證訓(xùn)練效果，所以第四點(diǎn)問題屬于強(qiáng)需求。

?

• SJoin-工程規(guī)模：基于線上實(shí)時(shí)推薦 Joiner。原始 feed 流與 click 流，QPS 高峰分別在 15w 和 2w，Join 輸出 QPS 高峰達(dá)到 10w，字節(jié)量高峰為 200 M/s。keyState 狀態(tài)查詢量維持在高峰值 60w，包括 read、write、exist 等狀態(tài)。一小時(shí) window 下，Timer 的 key 量 15w * 3600 = 54 億條，RocksDBState 量達(dá)到 200M * 3600 = 700G。實(shí)際過程中，采用原生 Flink 在該規(guī)模下會(huì)遇到較多的性能問題，如在早期 Flink 1.3.* 版本，其穩(wěn)定性會(huì)較差。

?

• SJoin-技術(shù)痛點(diǎn)：下圖是 Flink 使用 WindowOperator 時(shí)的內(nèi)部拓?fù)鋱D。用戶打開窗口，每一條記錄都是一個(gè) Window 窗口。第一個(gè)問題是窗口分配量巨大，QPS 與窗口分配量基本持恒。第二個(gè)問題是 Timer Service 每一個(gè)記錄都打開了一個(gè)窗口，在早期原生 Flink 中是一個(gè)內(nèi)存隊(duì)列，內(nèi)存隊(duì)列部分也存在許多問題。底層隊(duì)列早期是單線程機(jī)制，數(shù)據(jù) Cache 在內(nèi)存中，存在許多問題。

?

簡單總結(jié)其技術(shù)痛點(diǎn)，首先，Timer 性能較差，且內(nèi)存消耗大。第二，Value RocksDB State 在 compact 時(shí)會(huì)導(dǎo)致流量抖動(dòng)。類似 HBase，多 level 的 compact 會(huì)造成性能抖動(dòng)和寫放大。第三，重啟流量過大時(shí)，由于 Timer 早期只有內(nèi)存隊(duì)列，Window 和 Keystate 恢復(fù)周期不可控。從磁盤加載大量數(shù)據(jù)耗時(shí)長，服務(wù) recovery 時(shí)間久。

??

?

• SJoin-優(yōu)化思路：首先是 Timer 優(yōu)化升級(jí)。早期社區(qū)沒有更好的解決方案時(shí)，bilibili 嘗試自研 PersistentTimerManager，后期升級(jí) Flink，采用基于 RocksDB 的 Timer。第二，啟用 Redis 作為 ValueState，提高 State 穩(wěn)定性。第三，擴(kuò)展 SQL 語法，以支持非典型 A Left Join B On Time-based Window 場景下的 SQL 語義。

?

• SJoin 優(yōu)化-自研 Timer：實(shí)現(xiàn)將內(nèi)存數(shù)據(jù)達(dá)到 Max 之后溢寫到磁盤。底層用 MapDB 做磁盤溢寫。磁盤溢寫原理是 LSM 模型，同樣存在數(shù)據(jù)抖動(dòng)問題。由于窗口是 1 小時(shí)，相當(dāng)于數(shù)據(jù)以 1 小時(shí)為單位進(jìn)行 State 管理。如下圖右側(cè)所示，當(dāng) 0 點(diǎn)到 1 點(diǎn)的 1 小時(shí)，由于記錄在 1 小時(shí)后才會(huì)吐出，數(shù)據(jù)進(jìn)來只有寫的動(dòng)作。在 1 點(diǎn)到 2 點(diǎn)，數(shù)據(jù)會(huì)寫入到新的 State，0 點(diǎn)到 1 點(diǎn)的 State 已經(jīng)到達(dá)窗口時(shí)間，進(jìn)行數(shù)據(jù)吐出。自研 Timer 很好地解決了數(shù)據(jù)的讀寫問題和抖動(dòng)問題。但是由于自研 Timer 缺乏 CheckPoint 機(jī)制，如果節(jié)點(diǎn)上的磁盤出現(xiàn)故障，會(huì)導(dǎo)致 State 數(shù)據(jù)丟失。

?

?

• SJoin 優(yōu)化-RocksDBTimer：升級(jí) Flink 版本，引入基于 RocksDB 的 Timer。升級(jí)后架構(gòu)如下圖所示。數(shù)據(jù)從 Kafka 獲取 Topic-Feed 和 Topic-Click，首先對(duì)其進(jìn)行一層清洗，然后進(jìn)入自定義的 Joiner Operator 算子。算子做兩件事，將主流數(shù)據(jù)吐到 Redis 中，由 Redis 做 State，同時(shí)將需要開窗口的 Key 存儲(chǔ)注冊(cè)到 Timer Service 中。接下來利用 Timer Service 原生的 CheckPoint 開啟增量 CheckPoint 過程。當(dāng) OnTimer 到達(dá)時(shí)間后，就可以吐出數(shù)據(jù)。非常此方案契合 SJoin 在高吞吐作業(yè)下的要求。

?

?

• SJoin 優(yōu)化-引入 KVStore：Flink 原生 State 無法滿足要求，在對(duì) Value、IO 要求高時(shí)抖動(dòng)嚴(yán)重，RocksDBState 實(shí)際使用中會(huì)出現(xiàn)抖動(dòng)問題。對(duì)此，bilibili 嘗試過多種改進(jìn)方案。開 1 小時(shí)窗口，數(shù)據(jù)量約 700G，雙流 1 小時(shí)窗口總流量達(dá)到 TB 級(jí)別。采用分布式 KVStore 存儲(chǔ)，后續(xù)進(jìn)行壓縮后數(shù)據(jù)量約 700G。

?

?

• SJoin 優(yōu)化-擴(kuò)展 SQL 語法：擴(kuò)展 SQL 的功能訴求是展現(xiàn)流等待 1 小時(shí)窗口，當(dāng)點(diǎn)擊流到達(dá)時(shí)，不立即吐出 Join 完成的數(shù)據(jù)，而等待窗口結(jié)束后再吐出。故擴(kuò)展了 SQL 語法，雖然目前未達(dá)到通用，但是能滿足諸多部門的 AI 需求。語法支持 Select * from A left（global）$time window and $time delay join B on A.xx=B.xx where A.xx=xx。給用戶帶來了很大收益。

?

?

進(jìn)行 SQL 語義擴(kuò)展主要有兩個(gè)關(guān)鍵點(diǎn)。SQL 語義的定義頂層通過 Calcite 擴(kuò)展 JoinType。首先將 SQL 展開成 SQL 樹。SQL 樹的一個(gè)節(jié)點(diǎn)為 left（global）$time window and $time delay join。抽取出該子樹，自定義邏輯轉(zhuǎn)換規(guī)則。在此定義了 StreamingJoinRute，將該子樹轉(zhuǎn)換為新的節(jié)點(diǎn)。通過 Flink 提供的異步 IO 能力，將異步子樹轉(zhuǎn)換為 Streaming Table，并將其注冊(cè)到 Flink 環(huán)境中。通過以上過程支持 SQL 表達(dá)。

?

?

• DJoin-工程背景：bilibili 對(duì)于維表數(shù)據(jù)要求不同。比如一些維表數(shù)據(jù)很大，以 T 為單位，此時(shí)如果用 Redis 存儲(chǔ)會(huì)造成浪費(fèi)。而有一些維表數(shù)據(jù)很小，如實(shí)時(shí)特征。同時(shí)，維表數(shù)據(jù)更新粒度不同，可以按天更新、按小時(shí)更新、按分鐘更新等。

  ?

  另外，維表性能要求很高。因?yàn)?AI 場景會(huì)進(jìn)行很多實(shí)驗(yàn)，例如某一個(gè)特征比較好，就會(huì)開很多模型、調(diào)整不同參數(shù)進(jìn)行實(shí)驗(yàn)。單作業(yè)下實(shí)驗(yàn)組越多，QPS 越高，RT 要求越高。不同維表存儲(chǔ)介質(zhì)有差異，對(duì)穩(wěn)定性有顯著影響。調(diào)研中有兩種場景。當(dāng)量比較小，可以使用 Redis 存儲(chǔ)，穩(wěn)定性較好。當(dāng)量很大，使用 Redis 成本高，但 HBase CP 架構(gòu)無法保證穩(wěn)定性。

?

?

• DJoin-工程優(yōu)化：需要針對(duì)維表 Join 的 SQL 進(jìn)行語法支持。包括 Cache 優(yōu)化，當(dāng)用戶寫多條 SQL 的維表 Join 時(shí)，需要提取多條 SQL 維表的 Key，并通過請(qǐng)求合并查詢維表，以提高 IO，以及流量均衡優(yōu)化等。第二，KV 存儲(chǔ)分場景支持，比如 JDBC、KV。KV 場景中，對(duì)百 G 級(jí)別使用 Redis 實(shí)時(shí)更新實(shí)時(shí)查詢。T 級(jí)別使用 HBase 多集群，比如通過兩套 HBase，Failover+LoadBalance 模式保證 99 線 RT 小于 20ms，以提高穩(wěn)定性。

?

?

• DJoin-語法擴(kuò)展：DJoin 語法擴(kuò)展與 SJoin 語法擴(kuò)展類似，對(duì) SQL 樹子樹進(jìn)行轉(zhuǎn)化，通過 AsyncIO 進(jìn)行擴(kuò)展，實(shí)現(xiàn)維表。

?

?

• DJoin-HBase 高可用：維表數(shù)據(jù)達(dá)到T級(jí)別時(shí)使用 HBase 進(jìn)行數(shù)據(jù)存儲(chǔ)。HBase 高可用性采用雙 HBase 集群，Failover AB 模式。這時(shí)需要考慮兩個(gè)問題。第一是數(shù)據(jù)更新機(jī)制。數(shù)據(jù)更新可以是按小時(shí)或按天，采用 HFile BulkLoad 模式，串行+ Interval 間隔導(dǎo)入，導(dǎo)入后同步數(shù)據(jù)預(yù)熱，以此保證兩套HBase 集群的穩(wěn)定性。第二是數(shù)據(jù)查詢機(jī)制。引入 Hystrix 實(shí)現(xiàn)服務(wù)熔斷、降級(jí)回退策略。當(dāng) A 集群可用性下降時(shí)，根據(jù) AB 的 RT 質(zhì)量，動(dòng)態(tài)切換一定數(shù)據(jù)到B集群，以保證數(shù)據(jù)流量均衡。

  ?

  下圖為 HBase 雙集群架構(gòu)。右側(cè)是離線，以天為單位，通過調(diào)度框架拉起一個(gè) DAG 進(jìn)行計(jì)算。DAG 的輸出經(jīng)過兩層串行的 HBase 的 Sink，串行可以保證數(shù)據(jù)先寫完 A 再寫 B。運(yùn)行時(shí)態(tài)中通過 Flink、AsyncIO 方式，通過兩層 HystrixClient。第一層 HystrixClient 主要對(duì)第二層 HystrixClient HBase 的 RT 通信質(zhì)量進(jìn)行收集，根據(jù) RT 通信質(zhì)量將流量動(dòng)態(tài)分發(fā)到兩套 HBase 集群中。在 A 集群穩(wěn)定性很好時(shí)，流量都在 A 集群跑。當(dāng) A 集群出現(xiàn)抖動(dòng)，會(huì)根據(jù)失敗率動(dòng)態(tài)切換一定配比流量到 B 集群。

?

?

4.模型訓(xùn)練的實(shí)時(shí) Pipeline

?

整個(gè)體系解決了 AI 模型訓(xùn)練預(yù)生成數(shù)據(jù)給模型的 Pipeline。展現(xiàn)和點(diǎn)擊通過 BSQL 方案實(shí)現(xiàn) Joiner。實(shí)時(shí)特征數(shù)據(jù)通過 BSQL 進(jìn)行計(jì)算，離線數(shù)據(jù)通過離線調(diào)度解決。維表的 Join 會(huì)通過 BSQL 構(gòu)成 Pipeline，從而給機(jī)器學(xué)習(xí)團(tuán)隊(duì) Instances 流，訓(xùn)練模型，產(chǎn)出模型。

?

?

四、未來的發(fā)展與思考

?

1.Saber-基礎(chǔ)功能完善

?

越來越多人使用平臺(tái)時(shí)，基礎(chǔ)運(yùn)維是最為關(guān)鍵的。Saber 平臺(tái)將會(huì)完善 SQL IDE 開發(fā)，如提供更豐富的版本管理、上下線、任務(wù)調(diào)試、資源管理、基礎(chǔ)操作等。同時(shí)將豐富化作業(yè)運(yùn)維。包括 SLA、上線審批、優(yōu)先級(jí)、各類系統(tǒng)監(jiān)控指標(biāo)、用戶自定義指標(biāo)告警、作業(yè) OP 操作等。

?

2.Saber-應(yīng)用能力提升

?

Saber 應(yīng)用能力將會(huì)向 AI 方向不斷演進(jìn)。例如模型訓(xùn)練的工程化方面，將引入實(shí)驗(yàn)維度概念，通過實(shí)驗(yàn)拉起 SQL Pipeline。同時(shí)將為做模型訓(xùn)練的同學(xué)統(tǒng)一流、批 SQL 復(fù)用。并且進(jìn)行模型實(shí)驗(yàn)效果、評(píng)估、預(yù)警等。實(shí)時(shí)特征的工程化方面，將會(huì)支持多特征復(fù)合計(jì)算，涵蓋特征計(jì)算、存儲(chǔ)、查詢等多個(gè)場景。

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的bilibili Saber 实时计算平台架构与实践【Apache Flink 替换 Spark Stream的架构与实践】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。