一、業(yè)務(wù)背景
BIGO全球音視頻業(yè)務(wù)對數(shù)據(jù)的實時能力要求越來越高,數(shù)據(jù)分析師希望多維度實時看到新增用戶、活躍用戶等業(yè)務(wù)數(shù)據(jù)以便盡快掌握市場動向,機器學(xué)習(xí)工程師希望實時拿到用戶的瀏覽、點擊等數(shù)據(jù)然后通過在線學(xué)習(xí)將用戶偏好快速加入到模型中,以便給用戶推送當(dāng)前最感興趣的內(nèi)容,APP開發(fā)工程師希望能夠?qū)崟r監(jiān)控APP打開的成功率、崩潰率。這些實時數(shù)據(jù)的能力都要依靠實時計算平臺來提供。從業(yè)界來看,實時化的趨勢正在加速,本文將介紹BIGO基于flink的實時計算平臺的建設(shè)經(jīng)驗和成果。
二、平臺介紹
BIGO實時計算的發(fā)展大概分為兩個階段,在2018年之前,實時場景還比較少,實時的作業(yè)數(shù)量也不多,當(dāng)時主要采用Spark Streaming來支持。從2018年開始,在綜合考慮了Flink相對于Spark Streaming的優(yōu)勢之后,BIGO技術(shù)決定將實時計算平臺切換到基于flink的技術(shù)路線上來。經(jīng)過近兩年的發(fā)展,BIGO實時計算平臺日趨完善,基本支持了公司內(nèi)主流的實時計算場景,下圖是BIGO實時計算平臺的架構(gòu)圖:
實時計算的數(shù)據(jù)來源可分為兩大類,一類是用戶在APP或者瀏覽器里的瀏覽、點擊等行為日志,通過kafka收集進入實時計算;另一類是用戶的行為產(chǎn)生的關(guān)系型數(shù)據(jù)庫里記錄的改變,這些改動產(chǎn)生的biglog被BDP抽取進入實時計算。
從圖中可以看出,BIGO實時計算平臺底層基于yarn來做集群資源管理,借助于Yarn的分布式調(diào)度能力,實現(xiàn)大規(guī)模集群下的調(diào)度。實時平臺的計算引擎在開源Flink的基礎(chǔ)上,為適配BIGO的場景進行了特殊的定制及開發(fā)。實時平臺的上層是BIGO自研的一站式開發(fā)平臺BigoFlow,在這里,用戶可以方便的進行作業(yè)的開發(fā)、調(diào)試以及監(jiān)控運維。BigoFlow提供了完善的SQL開發(fā)能力、自動化監(jiān)控配置能力以及日志自動收集、查詢能力,讓用戶僅需要一條SQL,就可以完成一個業(yè)務(wù)作業(yè)。它具有以下功能:
1. 提供了強大的SQL編輯器,可以進行語法檢查及自動提示。
2. 可以對接公司所有的數(shù)據(jù)源及數(shù)據(jù)存儲,省去了業(yè)務(wù)方自定義的工作。
3. 日志自動收集到ES里,用戶可以方便的檢索和查詢,可以快速的定位錯誤。
4. 作業(yè)關(guān)鍵指標(biāo)自動對接到公司的監(jiān)控告警平臺,用戶不用再自己配置。
5. 收集所有作業(yè)的資源使用情況,自動進行分析,幫助識別、治理不合理作業(yè)。
實時計算出來的結(jié)果根據(jù)業(yè)務(wù)的需求,會存放到不同的存儲中。ETL類作業(yè)的結(jié)果通常會入庫到hive中,需要進行adhoc查詢的數(shù)據(jù)通常會放到clickhouse里面。監(jiān)控告警等類型的作業(yè)可以直接把結(jié)果輸出到告警平臺的Prometheus數(shù)據(jù)庫里,供告警平臺直接使用。
三、業(yè)務(wù)應(yīng)用
隨著實時計算平臺的發(fā)展,越來越多的場景都搬到了BigoFlow平臺上,實時計算也給這些場景帶了很多好處,下面BIGO技術(shù)以幾個典型場景為例來說明實時計算為它們帶來的能力或者性能的增強。
數(shù)據(jù)ETL
數(shù)據(jù)的抽取、轉(zhuǎn)換是一個典型的實時場景,用戶在APP、瀏覽器里的行為日志是實時不間斷產(chǎn)生的,要實時的去采集并經(jīng)過抽取轉(zhuǎn)換,最后入到數(shù)據(jù)庫里。BIGO之前的ETL場景數(shù)據(jù)路徑通常是Kafka->flume->Hive。經(jīng)過flume入庫的路徑存在著一下幾方面的問題:
1. Flume的容錯能力差,遇到已成可能會導(dǎo)致丟數(shù)據(jù)或者數(shù)據(jù)重復(fù)。
2. Flume的動態(tài)擴展能力差,流量突然到來時候很難立刻擴展。
3. 一旦數(shù)據(jù)字段或者格式發(fā)生變化,flume比較難于靈活調(diào)整。
而Flink提供了基于state的強大的容錯能力,可以端到端exactly once,并發(fā)度可以靈活的調(diào)整,Flink SQL可以靈活的去調(diào)整邏輯。因此,絕大部分的ETL場景目前都已經(jīng)遷移到了Flink架構(gòu)上。
實時統(tǒng)計
作為一家有多個APP產(chǎn)品的公司,BIGO需要有大量的統(tǒng)計指標(biāo)來反應(yīng)產(chǎn)品的日活、營收等指標(biāo)。傳統(tǒng)這些指標(biāo)一般都是通過離線Spark作業(yè)來每天或者每小時計算一次。離線計算很難保證數(shù)據(jù)的產(chǎn)生的及時性。經(jīng)常會出現(xiàn)重要指標(biāo)延遲產(chǎn)生的問題。因此我們慢慢的將重要指標(biāo)通過實時計算來產(chǎn)生,極大的保證了數(shù)據(jù)產(chǎn)生的及時性。最顯著的是之前一個重要指標(biāo)經(jīng)常延遲導(dǎo)致它的下游在下午才能產(chǎn)出,給數(shù)據(jù)分析師帶來了很多困擾,改造為實時鏈路后,最終指標(biāo)在早上7點就能產(chǎn)出,數(shù)據(jù)分析師上班就可以使用了。
機器學(xué)習(xí)
隨著信息的爆炸發(fā)展,用戶的興趣轉(zhuǎn)移的越來越快,這就要求機器學(xué)習(xí)能夠盡快根據(jù)用戶當(dāng)時的行為推薦他感興趣的視頻。傳統(tǒng)機器學(xué)習(xí)基于批處理的方式,通常要到最快小時級別才能更新模型。今天基于實時計算的樣本訓(xùn)練可以不間斷的將樣本訓(xùn)練成實時模型并應(yīng)用于線上,真正做到了在線學(xué)習(xí),將根據(jù)用戶行為產(chǎn)生的推薦做到分鐘級別更新。目前,機器學(xué)習(xí)的作業(yè)已經(jīng)占到了實時計算集群的50%以上。
實時監(jiān)控
實時監(jiān)控也是一個很重要的實時場景,app的開發(fā)者需要實時監(jiān)控app打開的成功率等指標(biāo),如果出現(xiàn)異常,就要及時告警通知出來。之前的做法通常是原始數(shù)據(jù)存放于Hive或者ClickHouse,在基于Grafana的監(jiān)控平臺配置規(guī)則,每個一定時間用Presto或者ClickHouse去查詢一下,根據(jù)計算出來結(jié)果進行判斷是否需要告警。這種方式存在幾個問題:
1. Presto或者ClickHouse本身雖然是OLAP的引擎,性能很好,但并不保證集群的高可用及實時性。而監(jiān)控對實時性和高可用要求比較高。
2. 這種方式的每次計算指標(biāo)都要把當(dāng)天的全部數(shù)據(jù)計算一遍,存在著極大的計算浪費。
而通過實時計算的監(jiān)控方案可以實時計算出來指標(biāo),直接輸出到Grafana的數(shù)據(jù)庫里,不僅保證了實時性,更是可以將計算的數(shù)據(jù)量減少上千倍。
四、BIGO實時平臺特色
BIGO實時計算平臺在發(fā)展過程中,逐步根據(jù)BIGO內(nèi)部業(yè)務(wù)的使用特點,形成了自己的特色和優(yōu)勢。主要體現(xiàn)在以下幾個方面:
元數(shù)據(jù)打通
一個常見的情況是數(shù)據(jù)的產(chǎn)生者和使用者不是同一批人。打點的同事將數(shù)據(jù)上報到kafka或者hive里,數(shù)據(jù)分析師要用這些數(shù)據(jù)去計算。他們不知道kafka的具體信息,只知道要使用的hive表名。為了減少用戶使用實時計算的麻煩,BigoFlow將元數(shù)據(jù)和Kafka、hive、ClickHouse等存儲都進行了打通,用戶可以在作業(yè)里直接使用hive、ClickHouse的表,不需要寫DDL,BigoFlow自動去解析,根據(jù)元數(shù)據(jù)的信息自動轉(zhuǎn)換成Flink里的DDL語句,極大的減少了用戶的開發(fā)工作。這得益于BIGO計算平臺的統(tǒng)一規(guī)劃,是很多離線、實時系統(tǒng)分開的公司所做不到的。
端到端的產(chǎn)品化方案
BigoFlow不僅僅是實時計算的平臺,為了方便用戶使用或者遷移,也會根據(jù)業(yè)務(wù)場景,提供端到端的整個解決方案。像前面介紹的監(jiān)控場景,用戶有很多監(jiān)控業(yè)務(wù)需要遷移,為了盡量減少的工作,BigoFlow專門提供了監(jiān)控場景的解決方案,用戶只需要將計算監(jiān)控指標(biāo)的sql遷移到flink sql,其他包括Flink作業(yè)的DDL,數(shù)據(jù)sink到監(jiān)控平臺等工作完全不用做,都由BigoFlow自動實現(xiàn),用戶原先配置的規(guī)則也都不用變。這使得用戶可以用最少的工作量完成遷移。
另外前面也提到了,BigoFlow自動將用戶作業(yè)的關(guān)鍵指標(biāo)添加了告警,這基本滿足了絕大多數(shù)用戶的需求,讓他們專心于業(yè)務(wù)邏輯,而不用操心其他事情。用戶的日志也會自動收集到ES里,方便用戶查看。ES里有沉淀了一些總結(jié)出來的調(diào)查問題的搜索query,用戶可以根據(jù)現(xiàn)象直接點擊查詢。
強大的hive能力
由于BIGO內(nèi)的絕大部分數(shù)據(jù)都是存在Hive里的,實時作業(yè)也經(jīng)常需要將結(jié)果寫入hive,不少場景也需要能夠從hive里讀數(shù)據(jù)。所以BigoFlow跟hive的集成一直走在業(yè)界的前列。在社區(qū)1.11之前,BIGO技術(shù)就自己實現(xiàn)了向hive寫數(shù)據(jù),并可以動態(tài)更新meta的能力。1.11還未正式發(fā)布,我們就在1.11的基礎(chǔ)上,自研開發(fā)了流式讀取hive表支持EventTime、支持動態(tài)過濾分區(qū)、支持txt格式壓縮等功能,這些功能都領(lǐng)先于開源社區(qū)。
這是我們在ABTest上通過Flink實現(xiàn)的一個批流統(tǒng)一的場景。正常情況下,flink消費kafka的實時數(shù)據(jù),實時計算結(jié)果存入到hive。但作業(yè)經(jīng)常會遇到業(yè)務(wù)邏輯調(diào)整,需要重新追數(shù)據(jù)進行對數(shù)。由于數(shù)據(jù)量很大,如果追數(shù)據(jù)還從kafka消費,就會對kafka帶來很大的壓力,影響線上的穩(wěn)定。由于數(shù)據(jù)在hive里也存了一份,我們追數(shù)據(jù)的時候,選擇從hive里讀取,這樣用同一份代碼,可以走離線和在線兩條路,最大限度減少了追數(shù)據(jù)對在線的影響。
自動化ETL作業(yè)生成
Flink目前承接了大部分的ETL場景。ETL作業(yè)的邏輯一般比較簡單,但作業(yè)眾多,而且用戶上報的數(shù)據(jù)格式會經(jīng)常變化,或者字段進行了增減。為了減少用戶開發(fā)、維護ETL作業(yè)的成本,我們開發(fā)ETL作業(yè)自動生成的功能,用戶只需要提供上報數(shù)據(jù)的topic和格式,就可以自動生成ETL作業(yè),將結(jié)果寫入到hive中。上報數(shù)據(jù)格式或者字段發(fā)生了變化之后,也可以自動將作業(yè)進行更新。目前支持json、pb等多種數(shù)據(jù)格式。
五、展望
隨著BIGO業(yè)務(wù)的快速發(fā)展,BigoFlow實時計算平臺也在不斷的壯大和完善,但也還有很多需要改進以及提高的地方,BIGO技術(shù)未來將會在平臺完善和業(yè)務(wù)支持兩個方面重點建設(shè):
平臺完善:重點提升平臺的產(chǎn)品化水平。主要包括幾個方面:開發(fā)自動化資源配置、自動調(diào)優(yōu)等功能,可以根據(jù)作業(yè)的實時數(shù)據(jù)量,自動配置作業(yè)需要的資源,在流量高峰進行自動擴展,在流量低谷自動縮容;支持表血緣關(guān)系展示,方便用戶分析作業(yè)之間依賴關(guān)系;支持異地多集群,flink上面支持了眾多關(guān)鍵業(yè)務(wù),需要極高的SLA保證,我們會通過異地多機房來保證關(guān)鍵業(yè)務(wù)的可靠性。探索流批統(tǒng)一、數(shù)據(jù)湖等場景。
支持更多業(yè)務(wù)場景:開拓更多機器學(xué)習(xí)、實時數(shù)倉的場景,進一步推廣Flink SQL的使用。
六、團隊簡介
BIGO大數(shù)據(jù)團隊專注于在PB級別數(shù)據(jù)上實現(xiàn)快速迭代,用大數(shù)據(jù)分析技術(shù)賦能上層業(yè)務(wù)。具體負責(zé)面向公司所有業(yè)務(wù)建設(shè)EB級別的分布式文件存儲、日均萬億消息隊列和50PB規(guī)模的大數(shù)據(jù)計算,包括批、流、MPP等多種計算架構(gòu),涵蓋從數(shù)據(jù)定義、通道、存儲與計算、數(shù)據(jù)倉庫和BI等全鏈路技術(shù)棧。團隊技術(shù)氛圍濃厚,有眾多開源軟件的開發(fā)者,期待優(yōu)秀的人才加入我們!
稿件來源來自于BIGO技術(shù)自媒體