流批一体生产应用！Bigo 实时计算平台建设实践
本文由 Bigo 計算平臺負責(zé)人徐帥分享，主要介紹 Bigo 實時計算平臺建設(shè)實踐的介紹。內(nèi)容包括：
一、Bigo 實時計算平臺的發(fā)展歷程
今天主要跟大家分享 Bigo 實時計算平臺的建設(shè)歷程，我們在建設(shè)過程中解決的一些問題，以及所做的一些優(yōu)化和改進。首先進入第一個部分，Bigo 實時計算平臺的發(fā)展歷程。
先簡單介紹一下 Bigo 的業(yè)務(wù)。它主要有三大 APP，分別是 Live， Likee 和 Imo。其中，Live 為全球用戶提供直播服務(wù)。Likee 是短視頻的創(chuàng)作與分享的 App，跟快手和抖音都非常相似。Imo 是一個全球免費的通訊工具。這幾個主要的產(chǎn)品都是跟用戶相關(guān)的，所以我們的業(yè)務(wù)要圍繞著如何提高用戶的轉(zhuǎn)化率和留存率。而實時計算平臺作為基礎(chǔ)的平臺，主要是為以上業(yè)務(wù)服務(wù)的，Bigo 平臺的建設(shè)也要圍繞上述業(yè)務(wù)場景做一些端到端的解決方案。
Bigo 實時計算的發(fā)展歷程大概分為三個階段。
- 在 2018 年之前，實時作業(yè)還非常少，我們使用 Spark Streaming 來做一些實時的業(yè)務(wù)場景。
- 從 18 年到 19 年，隨著 Flink 的興起，大家普遍認為 Flink 是最好的實時計算引擎，我們開始使用 Flink，離散發(fā)展。各個業(yè)務(wù)線自己搭一個 Flink 來簡單使用。
- 從 2019 年開始，我們把所有使用 Flink 的業(yè)務(wù)統(tǒng)一到 Bigo 實時計算平臺上。通過兩年的建設(shè)，目前所有實時計算的場景都運行在 Bigo 平臺上。
如下圖所示，這是 Bigo 實時計算平臺的現(xiàn)狀。在 Data Source 端，我們的數(shù)據(jù)都是用戶的行為日志，主要來自于 APP 和客戶端。還有一部分用戶的信息存在 MySQL 中。
這些信息都會經(jīng)過消息隊列，最終采集到我們的平臺里。消息隊列主要用的是 Kafka，現(xiàn)在也在逐漸的采用 Pulsar。而 MySQL 的日志主要是通過 BDP 進入實時計算平臺。在實時計算平臺這塊，底層也是基于比較常用的 Hadoop 生態(tài)圈來做動態(tài)資源的管理。在上面的引擎層，已經(jīng)統(tǒng)一到 Flink，我們在上面做一些自己的開發(fā)與優(yōu)化。在這種一站式的開發(fā)、運維與監(jiān)控的平臺上，我們內(nèi)部做了一個 BigoFlow 的管理平臺。用戶可以在 BigoFlow 上開發(fā)、調(diào)試和監(jiān)控。最終在數(shù)據(jù)存儲上，我們也是對接了 Hive、ClickHouse、HBase 等等。
二、Bigo 實時計算平臺的特色與改進
接下來我們看一下 Bigo 計算平臺的特色，以及我們做的改進。作為一個發(fā)展中的公司，我們平臺建設(shè)的重點還是盡可能的讓業(yè)務(wù)人員易于使用。從而促進業(yè)務(wù)的發(fā)展，擴大規(guī)模。我們希望建設(shè)一個一站式的開發(fā)、運維、監(jiān)控平臺。
首先，在 BigoFlow 上面，用戶可以非常方便的開發(fā)。我們在開發(fā)這一塊的特色與改進包括：
另外，在運維這一塊，我們也做了許多改進：
最后是監(jiān)控這一塊，我們的特色有：
我們元數(shù)據(jù)的存儲主要有三個地方。分別是 Kafka、Hive 和 ClickHouse。目前我們能夠把所有的存儲系統(tǒng)的元數(shù)據(jù)全面打通。這會極大的方便用戶，同時降低使用成本。
- Kafka 的元數(shù)據(jù)打通之后，就可以一次導(dǎo)入，無限使用，無需 DDL。
- Flink 與 Hive 也做到了完全打通，用戶在使用 Hive 表的時候，無需 DDL，直接使用即可。
- ClickHouse 也類似，可自動追蹤到 Kafka 的 topic。
其實，我們今天提供的不僅僅是一個平臺，還包括在通用場景提供了端到端的解決方案。在 ETL 場景，我們的解決方案包括：
在監(jiān)控這一塊，我們的特色有：
第三個場景是 ABTest 場景，傳統(tǒng)的 ABTest 都是通過離線的方式，隔一天之后才能產(chǎn)出結(jié)果。那么我們今天將 ABTest 轉(zhuǎn)為實時的方式去輸出，通過流批一體的方式大大提高了 ABTest 的效率。
對 Flink 的改進主要體現(xiàn)在這幾個方面：
- 第一，在 connector 層面，我們自定義了很多的 connector，對接了公司用到的所有系統(tǒng)。
- 第二，在數(shù)據(jù)格式化層面，我們對 Json，Protobuf，Baina 三種格式做了非常完整的支持。用戶無需自己做解析，直接使用就可以。
- 第三，公司所有的數(shù)據(jù)都直接落到 Hive 里面，在 Hive 的使用上是領(lǐng)先于社區(qū)的。包括流式的讀取，EventTime 支持，維表分區(qū)過濾，Parquet 復(fù)雜類型支持，等等。
- 第四，在 State 層面我們也做了一些優(yōu)化。包括 SSD 支持，以及 RocksDB 優(yōu)化。
三、Bigo 典型的業(yè)務(wù)場景
傳統(tǒng)的打點入庫，都是通過 Kafka 到 Flume，然后進入到 Hive，最后到 ClickHouse。當(dāng)然 ClickHouse 里面大部分是從 Hive 導(dǎo)進去的，還有一部分是通過 Kafka 直接寫進去的。
這個鏈路是一個非常老的鏈路，它存在以下問題：
- 第一，不穩(wěn)定，flume 一旦有異常，經(jīng)常會出現(xiàn)數(shù)據(jù)丟失和重復(fù)。
- 第二，擴展能力差。面對突然到來的流量高峰，很難去擴展。
- 第三，業(yè)務(wù)邏輯不易調(diào)整。
所以我們在建設(shè) Flink 之后，做了非常多的工作。把原先 Flume 到 Hive 的流程替換掉，今天所有的 ETL 都是通過 Kafka，再經(jīng)過 Flink，所有的打點都會進入到 Hive 離線數(shù)倉，作為歷史的保存，使數(shù)據(jù)不丟失。同時，因為很多作業(yè)需要實時的分析，我們在另外一個鏈路，從 Flink 直接進入 ClickHouse 實時數(shù)倉來分析。
在這個過程中，我們做了一些核心改造，分為三大塊。首先，在用戶接入這一塊，我們的改造包括：
另外，在 Flink 自身這一塊，我們的改造有：
最后，在數(shù)據(jù) Sink 這一塊，我們做了非常多的定制化的開發(fā)，不僅支持 Hive，也對接了 ClickHouse。
四、Flink 為業(yè)務(wù)帶來的效率提升
下面主要介紹 ABTest 場景下，我們做的一些改造。比如說，數(shù)據(jù)全部落到 Hive 之后，就開始啟動離線的計算，可能經(jīng)過無數(shù)個工作流之后，最終產(chǎn)出了一張大寬表。表上可能有很多個維度，記錄了分組實驗的結(jié)果。數(shù)據(jù)分析師拿到結(jié)果之后，去分析哪些實驗比較好。
雖然這個結(jié)構(gòu)很簡單，但是流程太長，出結(jié)果晚，并且不易增加維度。主要問題其實在 Spark 這塊，這個作業(yè)有無數(shù)個工作流去執(zhí)行，一個工作流要等到另外一個執(zhí)行完才能去調(diào)度。而且離線資源沒有非常好的保證。我們之前最大的問題是 ABTest 上一天的結(jié)果要等到下一天的下午才能輸出，數(shù)據(jù)分析師經(jīng)常反饋上午沒法干活，只能下午快下班的時候才能開始分析。
所以我們就開始利用 Flink 實時計算能力去解決時效性的問題。不同于 Spark 任務(wù)要等上一個結(jié)果才能輸出，Flink 直接從 Kafka 消費。基本上可以在上午出結(jié)果。但是當(dāng)時因為它最終產(chǎn)出的結(jié)果維度非常多，可能有幾百個維度，這個時候 State 就非常大，經(jīng)常會遇到 OOM。
因此我們在第一步的改造過程中取了一個折中，沒有直接利用 Flink 在一個作業(yè)里面把所有的維度 join 起來，而是把它拆分成了幾個作業(yè)。每個作業(yè)計算一部分維度，然后把這些結(jié)果先利用 HBase 做了一個 join，再把 join 的結(jié)果導(dǎo)入到 ClickHouse 里面。
在改造的過程中，我們發(fā)現(xiàn)了一個問題。可能作業(yè)需要經(jīng)常的調(diào)整邏輯，調(diào)完后要去看結(jié)果對不對，那么這需要 1 天的時間窗口。如果直接讀歷史數(shù)據(jù)，Kafka 就要保存很久的數(shù)據(jù)，讀歷史數(shù)據(jù)的時候，要到磁盤上去讀，對 Kafka 的壓力就非常大。如果不讀歷史數(shù)據(jù)，因為只有零點才能觸發(fā)，那么今天改了邏輯，要等到一天之后才能夠去看結(jié)果，會導(dǎo)致調(diào)試迭代非常慢。
前面提到我們的所有數(shù)據(jù)在 Hive 里面，當(dāng)時還是 1.9 的版本，我們就支持了從 Hive 里面流式的去讀取數(shù)據(jù)。因為這些數(shù)據(jù)都是用 EventTime 去觸發(fā)，我們在 Hive 上支持了用 EventTime 去觸發(fā)。為了流批統(tǒng)一，這里沒有用 Spark，因為如果用 Spark 去做作業(yè)驗證，需要維護兩套邏輯。
我們在 Flink 上面用流批一體的方式去做離線的補數(shù)據(jù)，或者離線的作業(yè)驗證。而實時的這條用于日常作業(yè)的產(chǎn)生。
剛才說了這其實是一個折中的方案，因為對 HBase 有依賴，也沒有充分發(fā)揮 Flink 的能力。所以我們進行了第二輪的改造，徹底去除對 HBase 的依賴。
經(jīng)過第二輪迭代之后，我們今天在 Flink 上已經(jīng)能夠扛住大表的天級別的窗口交易。這個流批統(tǒng)一的方案已經(jīng)上線了，我們直接通過 Flink 去計算完整個大寬表，在每天的窗口觸發(fā)之后，將結(jié)果直接寫到 ClickHouse 里面，基本上凌晨就可以產(chǎn)出結(jié)果。
在整個過程中間，我們對 Flink 的優(yōu)化包括：
優(yōu)化之后，我們的小時級任務(wù)再也不延遲了，天級別完成時間由下午提早到上班前，大大加速了迭代效率。
五、總結(jié)與展望
總結(jié)一下實時計算在 Bigo 的現(xiàn)狀。首先，非常貼近業(yè)務(wù)。其次，跟公司里用到的所有生態(tài)無縫對接，基本上讓用戶不需要做任何的開發(fā)。另外，實時數(shù)倉已現(xiàn)雛形。最后，我們的場景跟大廠相比還不夠豐富。一些比較典型的實時場景，由于業(yè)務(wù)需求沒有那么高，很多業(yè)務(wù)還沒有真正的切換到實時場景上來。
我們的發(fā)展規(guī)劃有兩大塊。
- 第一塊是拓展更多的業(yè)務(wù)場景。包括實時機器學(xué)習(xí)，廣告，風(fēng)控和實時報表。在這些領(lǐng)域，要更多的去推廣實時計算的概念，去跟業(yè)務(wù)對接好。
- 另外一塊就是在 Flink 自身上面，我們內(nèi)部有很多場景要做。比如說，支持大 Hive 維表 join，自動化資源配置，CGroup 隔離，等等。以上就是我們在未來要做的一些工作。
原文鏈接：https://developer.aliyun.com/article/782104?
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的流批一体生产应用！Bigo 实时计算平台建设实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flink 如何实时分析 Iceberg
- 下一篇： 通过Kubernetes安全高效管理边缘