簡(jiǎn)介：本文由 Bigo 計(jì)算平臺(tái)負(fù)責(zé)人徐帥分享，主要介紹 Bigo 實(shí)時(shí)計(jì)算平臺(tái)建設(shè)實(shí)踐的介紹

本文由 Bigo 計(jì)算平臺(tái)負(fù)責(zé)人徐帥分享，主要介紹 Bigo 實(shí)時(shí)計(jì)算平臺(tái)建設(shè)實(shí)踐的介紹。內(nèi)容包括：

Bigo 實(shí)時(shí)計(jì)算平臺(tái)的發(fā)展歷程

特色與改進(jìn)

業(yè)務(wù)場(chǎng)景

效率提升

總結(jié)展望

一、Bigo 實(shí)時(shí)計(jì)算平臺(tái)的發(fā)展歷程

今天主要跟大家分享 Bigo 實(shí)時(shí)計(jì)算平臺(tái)的建設(shè)歷程，我們?cè)诮ㄔO(shè)過程中解決的一些問題，以及所做的一些優(yōu)化和改進(jìn)。首先進(jìn)入第一個(gè)部分，Bigo 實(shí)時(shí)計(jì)算平臺(tái)的發(fā)展歷程。

先簡(jiǎn)單介紹一下 Bigo 的業(yè)務(wù)。它主要有三大 APP，分別是 Live， Likee 和 Imo。其中，Live 為全球用戶提供直播服務(wù)。Likee 是短視頻的創(chuàng)作與分享的 App，跟快手和抖音都非常相似。Imo 是一個(gè)全球免費(fèi)的通訊工具。這幾個(gè)主要的產(chǎn)品都是跟用戶相關(guān)的，所以我們的業(yè)務(wù)要圍繞著如何提高用戶的轉(zhuǎn)化率和留存率。而實(shí)時(shí)計(jì)算平臺(tái)作為基礎(chǔ)的平臺(tái)，主要是為以上業(yè)務(wù)服務(wù)的，Bigo 平臺(tái)的建設(shè)也要圍繞上述業(yè)務(wù)場(chǎng)景做一些端到端的解決方案。

Bigo 實(shí)時(shí)計(jì)算的發(fā)展歷程大概分為三個(gè)階段。

• 在 2018 年之前，實(shí)時(shí)作業(yè)還非常少，我們使用 Spark Streaming 來做一些實(shí)時(shí)的業(yè)務(wù)場(chǎng)景。
• 從 18 年到 19 年，隨著 Flink 的興起，大家普遍認(rèn)為 Flink 是最好的實(shí)時(shí)計(jì)算引擎，我們開始使用 Flink，離散發(fā)展。各個(gè)業(yè)務(wù)線自己搭一個(gè) Flink 來簡(jiǎn)單使用。
• 從 2019 年開始，我們把所有使用 Flink 的業(yè)務(wù)統(tǒng)一到 Bigo 實(shí)時(shí)計(jì)算平臺(tái)上。通過兩年的建設(shè)，目前所有實(shí)時(shí)計(jì)算的場(chǎng)景都運(yùn)行在 Bigo 平臺(tái)上。

如下圖所示，這是 Bigo 實(shí)時(shí)計(jì)算平臺(tái)的現(xiàn)狀。在 Data Source 端，我們的數(shù)據(jù)都是用戶的行為日志，主要來自于 APP 和客戶端。還有一部分用戶的信息存在 MySQL 中。

這些信息都會(huì)經(jīng)過消息隊(duì)列，最終采集到我們的平臺(tái)里。消息隊(duì)列主要用的是 Kafka，現(xiàn)在也在逐漸的采用 Pulsar。而 MySQL 的日志主要是通過 BDP 進(jìn)入實(shí)時(shí)計(jì)算平臺(tái)。在實(shí)時(shí)計(jì)算平臺(tái)這塊，底層也是基于比較常用的 Hadoop 生態(tài)圈來做動(dòng)態(tài)資源的管理。在上面的引擎層，已經(jīng)統(tǒng)一到 Flink，我們?cè)谏厦孀鲆恍┳约旱拈_發(fā)與優(yōu)化。在這種一站式的開發(fā)、運(yùn)維與監(jiān)控的平臺(tái)上，我們內(nèi)部做了一個(gè) BigoFlow 的管理平臺(tái)。用戶可以在 BigoFlow 上開發(fā)、調(diào)試和監(jiān)控。最終在數(shù)據(jù)存儲(chǔ)上，我們也是對(duì)接了 Hive、ClickHouse、HBase 等等。

二、Bigo 實(shí)時(shí)計(jì)算平臺(tái)的特色與改進(jìn)

接下來我們看一下 Bigo 計(jì)算平臺(tái)的特色，以及我們做的改進(jìn)。作為一個(gè)發(fā)展中的公司，我們平臺(tái)建設(shè)的重點(diǎn)還是盡可能的讓業(yè)務(wù)人員易于使用。從而促進(jìn)業(yè)務(wù)的發(fā)展，擴(kuò)大規(guī)模。我們希望建設(shè)一個(gè)一站式的開發(fā)、運(yùn)維、監(jiān)控平臺(tái)。

首先，在 BigoFlow 上面，用戶可以非常方便的開發(fā)。我們?cè)陂_發(fā)這一塊的特色與改進(jìn)包括：

功能強(qiáng)大的 SQL 編輯器。

圖形化拓?fù)湔{(diào)整、配置。

一鍵多集群部署。

版本統(tǒng)一管理，盡可能收斂。

另外，在運(yùn)維這一塊，我們也做了許多改進(jìn)：

完善的 savepoint 管理機(jī)制。

日志自動(dòng)收集到 ES，內(nèi)置常 用錯(cuò)誤排查規(guī)則。

保存了任務(wù)歷史，方便進(jìn)行對(duì)比和問題追蹤。

最后是監(jiān)控這一塊，我們的特色有：

監(jiān)控自動(dòng)添加，用戶基本無需手動(dòng)配置。

自動(dòng)化分析資源使用，為用戶推薦合理資源配置。

我們?cè)獢?shù)據(jù)的存儲(chǔ)主要有三個(gè)地方。分別是 Kafka、Hive 和 ClickHouse。目前我們能夠把所有的存儲(chǔ)系統(tǒng)的元數(shù)據(jù)全面打通。這會(huì)極大的方便用戶，同時(shí)降低使用成本。

• Kafka 的元數(shù)據(jù)打通之后，就可以一次導(dǎo)入，無限使用，無需 DDL。
• Flink 與 Hive 也做到了完全打通，用戶在使用 Hive 表的時(shí)候，無需 DDL，直接使用即可。
• ClickHouse 也類似，可自動(dòng)追蹤到 Kafka 的 topic。

其實(shí)，我們今天提供的不僅僅是一個(gè)平臺(tái)，還包括在通用場(chǎng)景提供了端到端的解決方案。在 ETL 場(chǎng)景，我們的解決方案包括：

通用打點(diǎn)完全自動(dòng)化接入。

用戶無需開發(fā)任何代碼。

數(shù)據(jù)進(jìn)入 hive。

自動(dòng)更新 meta。

在監(jiān)控這一塊，我們的特色有：

數(shù)據(jù)源自動(dòng)切換。

監(jiān)控規(guī)則不變。

結(jié)果自動(dòng)存入 prometheus。

第三個(gè)場(chǎng)景是 ABTest 場(chǎng)景，傳統(tǒng)的 ABTest 都是通過離線的方式，隔一天之后才能產(chǎn)出結(jié)果。那么我們今天將 ABTest 轉(zhuǎn)為實(shí)時(shí)的方式去輸出，通過流批一體的方式大大提高了 ABTest 的效率。

對(duì) Flink 的改進(jìn)主要體現(xiàn)在這幾個(gè)方面：

• 第一，在 connector 層面，我們自定義了很多的 connector，對(duì)接了公司用到的所有系統(tǒng)。
• 第二，在數(shù)據(jù)格式化層面，我們對(duì) Json，Protobuf，Baina 三種格式做了非常完整的支持。用戶無需自己做解析，直接使用就可以。
• 第三，公司所有的數(shù)據(jù)都直接落到 Hive 里面，在 Hive 的使用上是領(lǐng)先于社區(qū)的。包括流式的讀取，EventTime 支持，維表分區(qū)過濾，Parquet 復(fù)雜類型支持，等等。
• 第四，在 State 層面我們也做了一些優(yōu)化。包括 SSD 支持，以及 RocksDB 優(yōu)化。

三、Bigo 典型的業(yè)務(wù)場(chǎng)景

傳統(tǒng)的打點(diǎn)入庫(kù)，都是通過 Kafka 到 Flume，然后進(jìn)入到 Hive，最后到 ClickHouse。當(dāng)然 ClickHouse 里面大部分是從 Hive 導(dǎo)進(jìn)去的，還有一部分是通過 Kafka 直接寫進(jìn)去的。

這個(gè)鏈路是一個(gè)非常老的鏈路，它存在以下問題：

• 第一，不穩(wěn)定，flume 一旦有異常，經(jīng)常會(huì)出現(xiàn)數(shù)據(jù)丟失和重復(fù)。
• 第二，擴(kuò)展能力差。面對(duì)突然到來的流量高峰，很難去擴(kuò)展。
• 第三，業(yè)務(wù)邏輯不易調(diào)整。

所以我們?cè)诮ㄔO(shè) Flink 之后，做了非常多的工作。把原先 Flume 到 Hive 的流程替換掉，今天所有的 ETL 都是通過 Kafka，再經(jīng)過 Flink，所有的打點(diǎn)都會(huì)進(jìn)入到 Hive 離線數(shù)倉(cāng)，作為歷史的保存，使數(shù)據(jù)不丟失。同時(shí)，因?yàn)楹芏嘧鳂I(yè)需要實(shí)時(shí)的分析，我們?cè)诹硗庖粋€(gè)鏈路，從 Flink 直接進(jìn)入 ClickHouse 實(shí)時(shí)數(shù)倉(cāng)來分析。

在這個(gè)過程中，我們做了一些核心改造，分為三大塊。首先，在用戶接入這一塊，我們的改造包括：

盡可能簡(jiǎn)單。

通用打點(diǎn)全自動(dòng)。

元信息打通，無需 DDL。

另外，在 Flink 自身這一塊，我們的改造有：

Parquet 寫優(yōu)化。

并發(fā)度調(diào)整。

通過 SSD 盤，支持大狀態(tài)的作業(yè)。

RocksDB 優(yōu)化，更好控制內(nèi)存。

最后，在數(shù)據(jù) Sink 這一塊，我們做了非常多的定制化的開發(fā)，不僅支持 Hive，也對(duì)接了 ClickHouse。

四、Flink 為業(yè)務(wù)帶來的效率提升

下面主要介紹 ABTest 場(chǎng)景下，我們做的一些改造。比如說，數(shù)據(jù)全部落到 Hive 之后，就開始啟動(dòng)離線的計(jì)算，可能經(jīng)過無數(shù)個(gè)工作流之后，最終產(chǎn)出了一張大寬表。表上可能有很多個(gè)維度，記錄了分組實(shí)驗(yàn)的結(jié)果。數(shù)據(jù)分析師拿到結(jié)果之后，去分析哪些實(shí)驗(yàn)比較好。

雖然這個(gè)結(jié)構(gòu)很簡(jiǎn)單，但是流程太長(zhǎng)，出結(jié)果晚，并且不易增加維度。主要問題其實(shí)在 Spark 這塊，這個(gè)作業(yè)有無數(shù)個(gè)工作流去執(zhí)行，一個(gè)工作流要等到另外一個(gè)執(zhí)行完才能去調(diào)度。而且離線資源沒有非常好的保證。我們之前最大的問題是 ABTest 上一天的結(jié)果要等到下一天的下午才能輸出，數(shù)據(jù)分析師經(jīng)常反饋上午沒法干活，只能下午快下班的時(shí)候才能開始分析。

所以我們就開始利用 Flink 實(shí)時(shí)計(jì)算能力去解決時(shí)效性的問題。不同于 Spark 任務(wù)要等上一個(gè)結(jié)果才能輸出，Flink 直接從 Kafka 消費(fèi)。基本上可以在上午出結(jié)果。但是當(dāng)時(shí)因?yàn)樗罱K產(chǎn)出的結(jié)果維度非常多，可能有幾百個(gè)維度，這個(gè)時(shí)候 State 就非常大，經(jīng)常會(huì)遇到 OOM。

因此我們?cè)诘谝徊降母脑爝^程中取了一個(gè)折中，沒有直接利用 Flink 在一個(gè)作業(yè)里面把所有的維度 join 起來，而是把它拆分成了幾個(gè)作業(yè)。每個(gè)作業(yè)計(jì)算一部分維度，然后把這些結(jié)果先利用 HBase 做了一個(gè) join，再把 join 的結(jié)果導(dǎo)入到 ClickHouse 里面。

在改造的過程中，我們發(fā)現(xiàn)了一個(gè)問題。可能作業(yè)需要經(jīng)常的調(diào)整邏輯，調(diào)完后要去看結(jié)果對(duì)不對(duì)，那么這需要 1 天的時(shí)間窗口。如果直接讀歷史數(shù)據(jù)，Kafka 就要保存很久的數(shù)據(jù)，讀歷史數(shù)據(jù)的時(shí)候，要到磁盤上去讀，對(duì) Kafka 的壓力就非常大。如果不讀歷史數(shù)據(jù)，因?yàn)橹挥辛泓c(diǎn)才能觸發(fā)，那么今天改了邏輯，要等到一天之后才能夠去看結(jié)果，會(huì)導(dǎo)致調(diào)試迭代非常慢。

前面提到我們的所有數(shù)據(jù)在 Hive 里面，當(dāng)時(shí)還是 1.9 的版本，我們就支持了從 Hive 里面流式的去讀取數(shù)據(jù)。因?yàn)檫@些數(shù)據(jù)都是用 EventTime 去觸發(fā)，我們?cè)?Hive 上支持了用 EventTime 去觸發(fā)。為了流批統(tǒng)一，這里沒有用 Spark，因?yàn)槿绻?Spark 去做作業(yè)驗(yàn)證，需要維護(hù)兩套邏輯。

我們?cè)?Flink 上面用流批一體的方式去做離線的補(bǔ)數(shù)據(jù)，或者離線的作業(yè)驗(yàn)證。而實(shí)時(shí)的這條用于日常作業(yè)的產(chǎn)生。

剛才說了這其實(shí)是一個(gè)折中的方案，因?yàn)閷?duì) HBase 有依賴，也沒有充分發(fā)揮 Flink 的能力。所以我們進(jìn)行了第二輪的改造，徹底去除對(duì) HBase 的依賴。

經(jīng)過第二輪迭代之后，我們今天在 Flink 上已經(jīng)能夠扛住大表的天級(jí)別的窗口交易。這個(gè)流批統(tǒng)一的方案已經(jīng)上線了，我們直接通過 Flink 去計(jì)算完整個(gè)大寬表，在每天的窗口觸發(fā)之后，將結(jié)果直接寫到 ClickHouse 里面，基本上凌晨就可以產(chǎn)出結(jié)果。

在整個(gè)過程中間，我們對(duì) Flink 的優(yōu)化包括：

State 支持 SSD 盤。

流式讀取 Hive，支持 EventTime。

Hive 維表 join，支持 partition 分區(qū) load。

完善的 ClickHouse Sinker。

優(yōu)化之后，我們的小時(shí)級(jí)任務(wù)再也不延遲了，天級(jí)別完成時(shí)間由下午提早到上班前，大大加速了迭代效率。

五、總結(jié)與展望

總結(jié)一下實(shí)時(shí)計(jì)算在 Bigo 的現(xiàn)狀。首先，非常貼近業(yè)務(wù)。其次，跟公司里用到的所有生態(tài)無縫對(duì)接，基本上讓用戶不需要做任何的開發(fā)。另外，實(shí)時(shí)數(shù)倉(cāng)已現(xiàn)雛形。最后，我們的場(chǎng)景跟大廠相比還不夠豐富。一些比較典型的實(shí)時(shí)場(chǎng)景，由于業(yè)務(wù)需求沒有那么高，很多業(yè)務(wù)還沒有真正的切換到實(shí)時(shí)場(chǎng)景上來。

我們的發(fā)展規(guī)劃有兩大塊。

• 第一塊是拓展更多的業(yè)務(wù)場(chǎng)景。包括實(shí)時(shí)機(jī)器學(xué)習(xí)，廣告，風(fēng)控和實(shí)時(shí)報(bào)表。在這些領(lǐng)域，要更多的去推廣實(shí)時(shí)計(jì)算的概念，去跟業(yè)務(wù)對(duì)接好。
• 另外一塊就是在 Flink 自身上面，我們內(nèi)部有很多場(chǎng)景要做。比如說，支持大 Hive 維表 join，自動(dòng)化資源配置，CGroup 隔離，等等。以上就是我們?cè)谖磥硪龅囊恍┕ぷ鳌?/li>

原文鏈接：https://developer.aliyun.com/article/782104?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的流批一体生产应用！Bigo 实时计算平台建设实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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