基于 Flink 的 OLAP 分析及實(shí)時(shí)數(shù)倉(cāng)實(shí)踐

摘要：本文整理自 BIGO Staff Engineer 鄒云鶴在 Flink Forward Asia 2021 的分享。主要內(nèi)容包括：

1. 業(yè)務(wù)背景
2. 落地實(shí)踐 & 特色改進(jìn)
3. 應(yīng)用場(chǎng)景
4. 未來(lái)規(guī)劃

一、業(yè)務(wù)背景

BIGO 是一家面向海外的以短視頻直播業(yè)務(wù)為主的公司, 目前公司的主要業(yè)務(wù)包括 BigoLive (全球直播服務(wù))，Likee (短視頻創(chuàng)作分享平臺(tái))，IMO (免費(fèi)通信工具) 三部分，在全球范圍內(nèi)擁有 4 億用戶。伴隨著業(yè)務(wù)的發(fā)展，對(duì)數(shù)據(jù)平臺(tái)處理能力的要求也是越來(lái)越高，平臺(tái)所面臨的問(wèn)題也是日益凸顯，接下來(lái)將介紹 BIGO 大數(shù)據(jù)平臺(tái)及其所面臨的問(wèn)題。BIGO 大數(shù)據(jù)平臺(tái)的數(shù)據(jù)流轉(zhuǎn)圖如下所示：

用戶在 APP，Web 頁(yè)面上的行為日志數(shù)據(jù)，以及關(guān)系數(shù)據(jù)庫(kù)的 Binlog 數(shù)據(jù)會(huì)被同步到 BIGO 大數(shù)據(jù)平臺(tái)消息隊(duì)列，以及離線存儲(chǔ)系統(tǒng)中，然后通過(guò)實(shí)時(shí)的，離線的數(shù)據(jù)分析手段進(jìn)行計(jì)算，以應(yīng)用于實(shí)時(shí)推薦、監(jiān)控、即席查詢等使用場(chǎng)景。然而存在以下幾個(gè)問(wèn)題：

• OLAP 分析平臺(tái)入口不統(tǒng)一：Presto/Spark 分析任務(wù)入口并存，用戶不清楚自己的 SQL 查詢適合哪個(gè)引擎執(zhí)行，盲目選擇，體驗(yàn)不好；另外，用戶會(huì)在兩個(gè)入口同時(shí)提交相同查詢，以更快的獲取查詢結(jié)果，導(dǎo)致資源浪費(fèi)；
  
  
• 離線任務(wù)計(jì)算時(shí)延高，結(jié)果產(chǎn)出太慢：典型的如 ABTest 業(yè)務(wù)，經(jīng)常計(jì)算到下午才計(jì)算出結(jié)果；
  
  
• 各個(gè)業(yè)務(wù)方基于自己的業(yè)務(wù)場(chǎng)景獨(dú)立開(kāi)發(fā)應(yīng)用，實(shí)時(shí)任務(wù)煙囪式的開(kāi)發(fā)，缺少數(shù)據(jù)分層，數(shù)據(jù)血緣。

面對(duì)以上的問(wèn)題，BIGO 大數(shù)據(jù)平臺(tái)建設(shè)了 OneSQL OLAP 分析平臺(tái)，以及實(shí)時(shí)數(shù)倉(cāng)。

1. 通過(guò) OneSQL OLAP 分析平臺(tái)，統(tǒng)一 OLAP 查詢?nèi)肟冢瑴p少用戶盲目選擇，提升平臺(tái)的資源利用率；
   
   
2. 通過(guò) Flink 構(gòu)建實(shí)時(shí)數(shù)倉(cāng)任務(wù)，通過(guò) Kafka/Pulsar 進(jìn)行數(shù)據(jù)分層；
   
   
3. 將部分離線計(jì)算慢的任務(wù)遷移到 Flink 流式計(jì)算任務(wù)上，加速計(jì)算結(jié)果的產(chǎn)出；

另外建設(shè)實(shí)時(shí)計(jì)算平臺(tái) Bigoflow 管理這些實(shí)時(shí)計(jì)算任務(wù)，建設(shè)實(shí)時(shí)任務(wù)的血緣關(guān)系。

二、落地實(shí)踐 & 特色改進(jìn)

2.1 OneSQL OLAP 分析平臺(tái)實(shí)踐和優(yōu)化

OneSQL OLAP 分析平臺(tái)是一個(gè)集 Flink、Spark、Presto 于一體的 OLAP 查詢分析引擎。用戶提交的 OLAP 查詢請(qǐng)求通過(guò) OneSQL 后端轉(zhuǎn)發(fā)到不同執(zhí)行引擎的客戶端，然后提交對(duì)應(yīng)的查詢請(qǐng)求到不同的集群上執(zhí)行。其整體架構(gòu)圖如下：

該分析平臺(tái)整體結(jié)構(gòu)從上到下分為入口層、轉(zhuǎn)發(fā)層、執(zhí)行層、資源管理層。為了優(yōu)化用戶體驗(yàn)，減少執(zhí)行失敗的概率，提升各集群的資源利用率，OneSQL OLAP 分析平臺(tái)實(shí)現(xiàn)了以下功能：

• 統(tǒng)一查詢?nèi)肟?/strong>：入口層，用戶通過(guò)統(tǒng)一的 Hue 查詢頁(yè)面入口以 Hive SQL 語(yǔ)法為標(biāo)準(zhǔn)提交查詢；
  
  
• 統(tǒng)一查詢語(yǔ)法：集 Flink、Spark、Presto 等多種查詢引擎于一體，不同查詢引擎通過(guò)適配 Hive SQL 語(yǔ)法來(lái)執(zhí)行用戶的 SQL 查詢?nèi)蝿?wù)；
  
  
• 智能路由：在選擇執(zhí)行引擎的過(guò)程中，會(huì)根據(jù)歷史 SQL 查詢執(zhí)行的情況 (在各引擎上是否執(zhí)行成功，以及執(zhí)行耗時(shí))，各集群的繁忙情況，以及各引擎對(duì)該 SQL 語(yǔ)法的是否兼容，來(lái)選擇合適的引擎提交查詢；
  
  
• 失敗重試：OneSQL 后臺(tái)會(huì)監(jiān)控 SQL 任務(wù)的執(zhí)行情況，如果 SQL 任務(wù)在執(zhí)行過(guò)程中失敗，將選擇其他的引擎執(zhí)行重試提交任務(wù)；

如此一來(lái)，通過(guò) OneSQL OLAP 分析平臺(tái)，BIGO 大數(shù)據(jù)平臺(tái)實(shí)現(xiàn)了 OLAP 分析入口的統(tǒng)一，減少用戶的盲目選擇，同時(shí)充分利用各個(gè)集群的資源，減少資源空閑情況。

■?2.1.1 Flink OLAP 分析系統(tǒng)建設(shè)

在 OneSQL 分析平臺(tái)上，F(xiàn)link 也作為 OLAP 分析引擎的一部分。Flink OLAP 系統(tǒng)分成兩個(gè)組成部分：Flink SQL Gateway 和 Flink Session 集群；SQL Gateway 作為 SQL 提交的入口，查詢 SQL 經(jīng)過(guò) Gateway 提交到 Flink Session 集群上執(zhí)行，同時(shí)獲取 SQL 執(zhí)行查詢的進(jìn)度，以及返回查詢的結(jié)果給客戶端。其執(zhí)行 SQL 查詢的流程如下：

首先用戶提交過(guò)來(lái)的 SQL，在 SQL Gateway 進(jìn)行判斷：是否需要將結(jié)果持久化寫(xiě)入到 Hive 表，如果需要，則會(huì)先通過(guò) HiveCatalog 的接口創(chuàng)建一個(gè) Hive 表，用于持久化查詢?nèi)蝿?wù)的計(jì)算結(jié)果；之后，任務(wù)通過(guò) SQL Gateway 上執(zhí)行 SQL 解析，設(shè)置作業(yè)運(yùn)行的并行度，生成 Pipeline 并提交到 Session 集群上執(zhí)行。

為了保證整個(gè) Flink OLAP 系統(tǒng)的穩(wěn)定性，以及高效的執(zhí)行 SQL 查詢，在這個(gè)系統(tǒng)中，進(jìn)行了以下功能增強(qiáng)：

• 穩(wěn)定性：


• 基于 zookeeper HA 來(lái)保證 Flink Session 集群的可靠性，SQL Gateway 監(jiān)聽(tīng) Zookeeper 節(jié)點(diǎn)，感知 Session 集群；
• 控制查詢掃描 Hive 表的數(shù)據(jù)量，分區(qū)個(gè)數(shù)，以及返回結(jié)果數(shù)據(jù)量，防止 Session 集群的 JobManager，TaskManager 因此出現(xiàn) OOM 情況；
  
  
• 性能：
  
  
• Flink Session 集群預(yù)分配資源，減少作業(yè)提交后申請(qǐng)資源所需的時(shí)間；
• Flink JobManager 異步解析 Split，Split 邊解析任務(wù)邊執(zhí)行，減少由于解析 Split 阻塞任務(wù)執(zhí)行的時(shí)間；
• 控制作業(yè)提交過(guò)程中掃描分區(qū)，以及 Split 最大的個(gè)數(shù)，減少設(shè)置任務(wù)并行所需要的時(shí)間；
  
  
• Hive SQL 兼容：
  
  
• 針對(duì) Flink 對(duì)于 Hive SQL 語(yǔ)法的兼容性進(jìn)行改進(jìn)，目前針對(duì) Hive SQL 的兼容性大致為 80%；
  
  
• 監(jiān)控告警：
  
  
• 監(jiān)控 Flink Session 集群的 JobManager，TaskManager，以及 SQL Gateway 的內(nèi)存，CPU 使用情況，以及任務(wù)的提交情況，一旦出現(xiàn)問(wèn)題，及時(shí)告警和處理；

■?2.1.2 OneSQL OLAP 分析平臺(tái)取得的成果

基于以上實(shí)現(xiàn)的 OneSQL OLAP 分析平臺(tái)，取得了以下幾個(gè)收益：

1. 統(tǒng)一查詢?nèi)肟冢瑴p少用戶的盲目選擇，用戶執(zhí)行出錯(cuò)率下降 85.7%，SQL 執(zhí)行的成功率提升 3%；
   
   
2. SQL 執(zhí)行時(shí)間縮短 10%，充分利用了各個(gè)集群的資源，減少任務(wù)排隊(duì)等待的時(shí)間；
   
   
3. Flink 作為 OLAP 分析引擎的一部分，實(shí)時(shí)計(jì)算集群的資源利用率提升了 15%;??

2.2 實(shí)時(shí)數(shù)倉(cāng)建設(shè)和優(yōu)化

為了提升 BIGO 大數(shù)據(jù)平臺(tái)上某些業(yè)務(wù)指標(biāo)的產(chǎn)出效率，以及更好的管理 Flink 實(shí)時(shí)任務(wù)，BIGO 大數(shù)據(jù)平臺(tái)建設(shè)了實(shí)時(shí)計(jì)算平臺(tái) Bigoflow，并將部分計(jì)算慢的任務(wù)遷移到實(shí)時(shí)計(jì)算平臺(tái)上，通過(guò) Flink 流式計(jì)算的方式來(lái)執(zhí)行，通過(guò)消息隊(duì)列 Kafka/Pulsar 來(lái)進(jìn)行數(shù)據(jù)分層，構(gòu)建實(shí)時(shí)數(shù)倉(cāng)；在 Bigoflow 上針對(duì)實(shí)時(shí)數(shù)倉(cāng)的任務(wù)進(jìn)行平臺(tái)化管理，建立統(tǒng)一的實(shí)時(shí)任務(wù)接入入口，并基于該平臺(tái)管理實(shí)時(shí)任務(wù)的元數(shù)據(jù)，構(gòu)建實(shí)時(shí)任務(wù)的血緣關(guān)系。

■?2.2.1 建設(shè)方案

BIGO 大數(shù)據(jù)平臺(tái)主要基于 Flink + ClickHouse 建設(shè)實(shí)時(shí)數(shù)倉(cāng)，大致方案如下：

按照傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)分層方法，將數(shù)據(jù)劃分成 ODS、DWD、DWS、ADS 等四層數(shù)據(jù)：

• ODS 層：基于用戶的行為日志，業(yè)務(wù)日志等作為原始數(shù)據(jù)，存放于 Kafka/Pulsar 等消息隊(duì)列中；
  
  
• DWD 層：這部分?jǐn)?shù)據(jù)根據(jù)用戶的 UserId 經(jīng)過(guò) Flink 任務(wù)進(jìn)行聚合后，形成不同用戶的行為明細(xì)數(shù)據(jù)，保存到 Kafka/Pulsar 中；
  
  
• DWS 層：用戶行為明細(xì)的 Kafka 流表與用戶 Hive/MySQL 維表進(jìn)行流維表 JOIN，然后將 JOIN 之后產(chǎn)生的多維明細(xì)數(shù)據(jù)輸出到 ClickHouse 表中；
  
  
• ADS 層：針對(duì) ClickHouse 中多維明細(xì)數(shù)據(jù)按照不同維度進(jìn)行匯總，然后應(yīng)用于不同的業(yè)務(wù)中。

按照以上方案建設(shè)實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)的過(guò)程中，遇到了一些問(wèn)題：

• 將離線任務(wù)轉(zhuǎn)為實(shí)時(shí)計(jì)算任務(wù)后，計(jì)算邏輯較為復(fù)雜 （多流 JOIN，去重)，導(dǎo)致作業(yè)狀態(tài)太大，作業(yè)出現(xiàn) OOM (內(nèi)存溢出) 異常或者作業(yè)算子背壓太大；
  
  
• 維表 Join 過(guò)程中，明細(xì)流表與大維表 Join，維表數(shù)據(jù)過(guò)多，加載到內(nèi)存后 OOM，作業(yè)失敗無(wú)法運(yùn)行；
  
  
• Flink 將流維表 Join 產(chǎn)生的多維明細(xì)數(shù)據(jù)寫(xiě)入到 ClickHouse，無(wú)法保證 Exactly-once，一旦作業(yè)出現(xiàn) Failover，就會(huì)導(dǎo)致數(shù)據(jù)重復(fù)寫(xiě)入。

■?2.2.2 問(wèn)題解決 & 優(yōu)化

優(yōu)化作業(yè)執(zhí)行邏輯，減小狀態(tài)

離線的計(jì)算任務(wù)邏輯較為復(fù)雜，涉及多個(gè) Hive 表之間的 Join 以及去重操作，其大致邏輯如下：

當(dāng)將離線的作業(yè)轉(zhuǎn)為 Flink 的流式任務(wù)之后，原先離線 Join 多個(gè) Hive 表的場(chǎng)景就轉(zhuǎn)變?yōu)?Join 多個(gè) Kafka Topic 的場(chǎng)景。由于 Join 的 Kafka topic 的流量較大，且 Join 的窗口時(shí)間較長(zhǎng) (窗口最長(zhǎng)的為 1 天)，當(dāng)作業(yè)運(yùn)行一段時(shí)間內(nèi)，Join 算子上就積累了大量的狀態(tài) (一小時(shí)后狀態(tài)就接近 1T)，面對(duì)如此大的狀態(tài)，F(xiàn)link 作業(yè)采取 Rocksdb State Backend 來(lái)存放狀態(tài)數(shù)據(jù)，但是仍然避免不了 Rocksdb 內(nèi)存使用超過(guò)導(dǎo)致被 YARN kill 的問(wèn)題，或者是 Rocksdb State 上存的狀態(tài)太多，吞吐下降導(dǎo)致作業(yè)嚴(yán)重背壓。

針對(duì)這個(gè)問(wèn)題，我們將這多個(gè) Topic，按照相同的 Schema 進(jìn)行 Unoin all 處理，得到一個(gè)大的數(shù)據(jù)流，然后在這個(gè)大的數(shù)據(jù)流中，再根據(jù)不同事件流的 event_id 進(jìn)行判斷，就能知道這條數(shù)據(jù)來(lái)自哪一個(gè)事件流的 Topic，再進(jìn)行聚合計(jì)算，獲取對(duì)應(yīng)事件流上的計(jì)算指標(biāo)。

這樣一來(lái)，通過(guò) UNION ALL 代替 JOIN，避免了因?yàn)?JOIN 計(jì)算帶來(lái)的大 State 帶來(lái)的影響。

另外，在計(jì)算任務(wù)中還存在有比較多的 count distinct 計(jì)算，類似如下：

selectcount(distinct if(events['a'] = 1, postid, null)) as cnt1,count(distinct if(events['b'] = 1, postid, null))as cnt2……count(distinct if(events['x'] = 1, postid, null))As cntxFrom table_aGroup by uid

這些 count distinct 計(jì)算在同一個(gè) group by 中，并基于相同的 postid 進(jìn)行去重計(jì)算，因而可以讓這些 distinct state 可以共享一組 key 來(lái)進(jìn)行去重計(jì)算，那么就可以通過(guò)一個(gè) MapState 來(lái)存儲(chǔ)這若干個(gè) count distinct 的狀態(tài)，如下：

這些 count distinct 函數(shù)去重的 key 相同，因而可以共享 MapState 中的 key 值，從而優(yōu)化存儲(chǔ)空間；而 MapState 的 Value 是 Byte 數(shù)組，每個(gè) Byte 8 個(gè) bit，每個(gè) bit 為 0 或者 1，第 n 個(gè) bit 對(duì)應(yīng)了 n 個(gè) count distinct 函數(shù)在該 key 上的取值：1 表示該 count disitnct 函數(shù)在對(duì)應(yīng)的 key 上需要進(jìn)行計(jì)數(shù)，0 表示不需要計(jì)數(shù)；當(dāng)計(jì)算聚合結(jié)果的時(shí)候，則將所有 key 第 n 位的數(shù)字相加，即為第 n 個(gè) count distinct 的取值，這樣一來(lái)，就更進(jìn)一步節(jié)約了狀態(tài)的存儲(chǔ)空間。

通過(guò)以上優(yōu)化，成功的將 ABTest 的離線任務(wù)遷移到 Flink 流式計(jì)算任務(wù)上，將作業(yè)的狀態(tài)控制在 100GB 以內(nèi)，讓作業(yè)正常的運(yùn)行起來(lái)。

流維表 JOIN 優(yōu)化

生成多維明細(xì)寬表的過(guò)程中，需要進(jìn)行流維表 JOIN, 使用了 Flink Join Hive 維表的功能：Hive 維表的數(shù)據(jù)會(huì)被加載到任務(wù)的 HashMap 的內(nèi)存數(shù)據(jù)結(jié)構(gòu)中，流表中的數(shù)據(jù)再根據(jù) Join Key 與 HashMap 中的數(shù)據(jù)進(jìn)行 Join。但是面對(duì)上億，十億行的 Hive 大維表，加載到內(nèi)存的數(shù)據(jù)量太大，很容易導(dǎo)致 OOM (內(nèi)存溢出)。針對(duì)以上問(wèn)題，我們將 Hive 大維表按照 Join Key 進(jìn)行 Hash 分片，如下圖：

這樣一來(lái)，Hive 大維表的數(shù)據(jù)經(jīng)過(guò) Hash 函數(shù)計(jì)算后分布到 Flink 作業(yè)的不同并行子任務(wù)的 HashMap 中，每個(gè) HashMap 只存放大維表的一部分?jǐn)?shù)據(jù)，只要作業(yè)的并行度夠大，就能夠?qū)⒋缶S表的數(shù)據(jù)拆分成足夠多份，進(jìn)行分片保存；對(duì)于一些太大的維表，也可以采取 Rocksdb Map State 來(lái)保存分片數(shù)據(jù)。

Kafka 流表中的數(shù)據(jù)，當(dāng)要下發(fā)到不同的 subtask 上進(jìn)行 Join 時(shí)，也通過(guò)相同的 Join Key 按照相同的 Hash 函數(shù)進(jìn)行計(jì)算，從而將數(shù)據(jù)分配到對(duì)應(yīng)的 subtask 進(jìn)行 Join，輸出 Join 后的結(jié)果。

通過(guò)以上優(yōu)化，成功 Join 了一些 Hive 大維表任務(wù)來(lái)執(zhí)行流維表 Join 計(jì)算，最大的維表超過(guò) 10 億行。

ClickHouse Sink 的 Exactly-Once 語(yǔ)義支持

將流維表 Join 生成的多維明細(xì)數(shù)據(jù)輸出到 ClickHouse 表的過(guò)程中，由于社區(qū)的 ClickHouse 不支持事務(wù)，所以沒(méi)辦法保證數(shù)據(jù) sink 到 ClickHouse 過(guò)程中的 Exactly-Once 語(yǔ)義。在此過(guò)程中，一旦出現(xiàn)作業(yè) Failover，數(shù)據(jù)就會(huì)重復(fù)寫(xiě)入到 ClickHouse。

針對(duì)這個(gè)問(wèn)題，BIGO ClickHouse 實(shí)現(xiàn)了一個(gè)二階段提交事務(wù)機(jī)制：當(dāng)需要寫(xiě)入數(shù)據(jù)到 ClickHouse 時(shí)，可以先設(shè)置寫(xiě)入的模式為 temporary，表明現(xiàn)在寫(xiě)入的數(shù)據(jù)是臨時(shí)數(shù)據(jù)；當(dāng)數(shù)據(jù)執(zhí)行插入完成后，返回一個(gè) Insert id，然后根據(jù)該 Insert id 執(zhí)行 Commit 操作，那么臨時(shí)數(shù)據(jù)就轉(zhuǎn)為正式數(shù)據(jù)。

基于 BIGO ClickHouse 的二階段提交事務(wù)機(jī)制，并結(jié)合 Flink 的 checkpoint 機(jī)制，實(shí)現(xiàn)了一個(gè) ClickHouse Connector，保證 ClickHouse Sink 的 Exactly Once 寫(xiě)入語(yǔ)義，如下：

• 在正常寫(xiě)入的情況下，Connector 隨機(jī)選擇 ClickHouse 的某一個(gè) shard 寫(xiě)入，根據(jù)用戶配置寫(xiě)單副本，或者雙副本來(lái)執(zhí)行 insert 操作，并記錄寫(xiě)入后的 insert id；在兩次 checkpoint 之間就會(huì)有多次這種 insert 操作，從而產(chǎn)生多個(gè) insert id，當(dāng) checkpoint 完成時(shí)，再將這些 insert id 批量提交，將臨時(shí)數(shù)據(jù)轉(zhuǎn)為正式數(shù)據(jù)，即完成了兩次 checkpoint 間數(shù)據(jù)的寫(xiě)入；
  
  
• 一旦作業(yè)出現(xiàn) Failover，F(xiàn)link 作業(yè) Failover 重啟完成后，將從最近一次完成的 checkpoint 來(lái)恢復(fù)狀態(tài)，此時(shí) ClickHouse Sink 中的 Operator State 可能會(huì)包含上一次還沒(méi)有來(lái)得及提交完成的 Insert id，針對(duì)這些 insert id 進(jìn)行重試提交；針對(duì)那些數(shù)據(jù)已經(jīng)寫(xiě)入 ClickHouse 中之后，但是 insert id 并沒(méi)有記錄到 Opeator State 中的數(shù)據(jù)，由于是臨時(shí)數(shù)據(jù)，在 ClickHouse 中并不會(huì)被查詢到，一段時(shí)間后，將會(huì)由 ClickHouse 的過(guò)期清理機(jī)制，被清理掉，從而保證了狀態(tài)回滾到上一次 checkpoint 之后，數(shù)據(jù)不會(huì)重復(fù)。

通過(guò)以上機(jī)制，成功保證了數(shù)據(jù)從 Kafka 經(jīng)過(guò) Flink 計(jì)算后寫(xiě)入到 ClickHouse 整個(gè)鏈路中端到端的 Exactly-Once 語(yǔ)義，數(shù)據(jù)不重復(fù)也不丟失。

■?2.2.3 平臺(tái)建設(shè)

為了更好的管理 BIGO 大數(shù)據(jù)平臺(tái)的實(shí)時(shí)計(jì)算任務(wù)，公司內(nèi)部建設(shè)了 BIGO 實(shí)時(shí)計(jì)算平臺(tái) Bigoflow，為用戶提供統(tǒng)一的 Flink實(shí)時(shí)任務(wù)接入，平臺(tái)建設(shè)如下：

• 支持 Flink ?JAR、SQL、Python 等多種類型作業(yè)；支持不同的 Flink 版本，覆蓋公司內(nèi)部大部分實(shí)時(shí)計(jì)算相關(guān)業(yè)務(wù)；
  
  
• 一站式管理：集作業(yè)開(kāi)發(fā)、提交、運(yùn)行、歷史展示、監(jiān)控、告警于一體，便于隨時(shí)查看作業(yè)的運(yùn)行狀態(tài)和發(fā)現(xiàn)問(wèn)題；
  
  
• 血緣關(guān)系：方便查詢每個(gè)作業(yè)的數(shù)據(jù)源、數(shù)據(jù)目的、數(shù)據(jù)計(jì)算的來(lái)龍去脈。

三、應(yīng)用場(chǎng)景

3.1 Onesql OLAP 分析平臺(tái)應(yīng)用場(chǎng)景

Onesql OLAP 分析平臺(tái)在公司內(nèi)部的應(yīng)用場(chǎng)景是：應(yīng)用于 AdHoc 查詢，如下：

用戶通過(guò) Hue 頁(yè)面提交的 SQL，通過(guò) OneSQL 后端轉(zhuǎn)發(fā)給 Flink SQL Gateway，并提交到 Flink Session 集群上執(zhí)行查詢?nèi)蝿?wù)，F(xiàn)link SQL Gateway 獲取查詢?nèi)蝿?wù)的執(zhí)行進(jìn)度返回給 Hue 頁(yè)面，并返回查詢結(jié)果。

3.2 實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用場(chǎng)景

實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用場(chǎng)景目前主要是 ABTest 業(yè)務(wù)，如下：

用戶的原始行為日志數(shù)據(jù)經(jīng)過(guò) Flink 任務(wù)聚合后生成用戶明細(xì)數(shù)據(jù)，然后與維表數(shù)據(jù)進(jìn)行流維表 JOIN，輸出到 ClickHouse 生成多維明細(xì)寬表，按照不同維度匯總后，應(yīng)用于不同的業(yè)務(wù)。通過(guò)改造 ABTest 業(yè)務(wù)，將該業(yè)務(wù)的結(jié)果指標(biāo)的生成時(shí)間提前了 8 個(gè)小時(shí)，同時(shí)減少了使用資源一倍以上。

四、未來(lái)規(guī)劃

為了更好的建設(shè) OneSQL OLAP 分析平臺(tái)以及 BIGO 實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)，實(shí)時(shí)計(jì)算平臺(tái)的規(guī)劃如下：

• 完善 Flink ?OLAP 分析平臺(tái)，完善 Hive SQL 語(yǔ)法支持，以及解決計(jì)算過(guò)程中出現(xiàn)的 JOIN 數(shù)據(jù)傾斜問(wèn)題；
  
  
• 完善實(shí)時(shí)數(shù)倉(cāng)建設(shè)，引入數(shù)據(jù)湖技術(shù)，解決實(shí)時(shí)數(shù)倉(cāng)中任務(wù)數(shù)據(jù)的可重跑回溯范圍小的問(wèn)題；
  
  
• 基于 Flink 打造流批一體的數(shù)據(jù)計(jì)算平臺(tái)。