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