猿輔導公司的數(shù)據(jù)中臺部門為猿輔導、斑馬、猿編程、小猿搜題、猿題庫、南瓜科學等各個業(yè)務線的產(chǎn)品、運營、研發(fā)提供標準化的數(shù)據(jù)集(OneData)和統(tǒng)一數(shù)據(jù)服務(OneService)。OLAP平臺作為數(shù)據(jù)中臺的核心部分，為各業(yè)務線提供統(tǒng)一標準化、可再利用、可靠的數(shù)據(jù)服務，支持各業(yè)務線人員快速靈活的查詢和分析，是連接前臺和后臺的橋梁。

引進性能強的下一代MPP數(shù)據(jù)庫:DorisDB，構建OLAP平臺。基于DorisDB，統(tǒng)一了實時數(shù)據(jù)分析和離線數(shù)據(jù)分析。目前，DorisDB有三個集群，每天百萬級有效查詢請求，p99延遲1s，用于廣告投放渠道轉(zhuǎn)換、用戶訂單和更新、直播質(zhì)量監(jiān)測等多個數(shù)據(jù)場景，支持各業(yè)務線更快、更靈活的查詢和分析

一、平臺選擇的業(yè)務背景

1.業(yè)務特點和需求

猴子指導作為網(wǎng)絡教育行業(yè)課程的領先品牌，每天生成大量的數(shù)據(jù)，為了實現(xiàn)科技輔助教育，重視數(shù)據(jù)在公司發(fā)展中發(fā)揮的作用

在網(wǎng)絡教育數(shù)據(jù)系統(tǒng)中，不僅要重視用戶的活躍、訂單收入，還要重視渠道的轉(zhuǎn)換率和用戶的持續(xù)率。這些指標有不同的維度和不同的計算口徑和多樣化的業(yè)務系統(tǒng)訪問模式，給OneService的基礎設計帶來了挑戰(zhàn)。另一方面，數(shù)據(jù)的時效性需求逐漸增強，離線top1的數(shù)據(jù)越來越不能滿足驅(qū)動業(yè)務的需求，數(shù)據(jù)的實時化也成為不可逆轉(zhuǎn)的行業(yè)發(fā)展趨勢。

在這樣的背景下，我們的OLAP平臺需要支持實時和離線數(shù)據(jù)的填寫，支持不同時效的查詢需求，支持復雜多樣的數(shù)據(jù)查詢邏輯，滿足各種業(yè)務場景的數(shù)據(jù)分析需求

2.對OLAP發(fā)動機的需求

總結起來，我們對OLAP的需求大致包括以下幾點:

數(shù)據(jù)查詢延遲到秒級/毫秒級的

同時有效地支持寬度表和多表join查詢，支持復雜的查詢場景

需要支持高并發(fā)查詢場景

同時支持流動數(shù)據(jù)和批準數(shù)據(jù)的攝入，支持實時/離線數(shù)據(jù)ETL任務

支持標準化SQ化，大大降低用戶的使用成本。

3.技術選型與優(yōu)缺點對比

OLAP是基于數(shù)據(jù)倉庫多維模型實現(xiàn)的各種操作集合，強調(diào)數(shù)據(jù)分析性能和SQL執(zhí)行時間。

今天，各種OLAP數(shù)據(jù)引擎可以說是百花齊放，分為MOLAPMulti-dimensionalOLAP)、ROLAPRelationaloLAP)和HOLAP(HybridoLAP)三種。

(1)MOLAP引擎的代表是Druid、Kylin等，本質(zhì)上是通過空間和預算更換在線查詢時間。在數(shù)據(jù)寫入時生成預聚合數(shù)據(jù)，這樣查詢的時候命中的就是預聚合的數(shù)據(jù)而非明細數(shù)據(jù)，從而大幅提高查詢效率，在一些固定查詢模式的場景中，這種效率提升可謂非常明顯。但是他的缺點也來自于這種預聚合模型，因為它極大的限制了數(shù)據(jù)模型的靈活性，比如在數(shù)據(jù)維度變化時的數(shù)據(jù)重建成本非常高，而且明細數(shù)據(jù)也丟失了。

(2)ROLAP發(fā)動機的代表Presto、Impala、GreenPlum、Clickhouse等，與MOLAP的不同之處在于，ROLAP在收到查詢請求時，首先將query分析為查詢計劃，執(zhí)行查詢算子，根據(jù)原始數(shù)據(jù)進行sum、groupby等各種計算該模型的發(fā)動機優(yōu)點是靈活性好，但大查詢/復雜查詢性能不穩(wěn)定，同時可能引起冗馀的重復計算，消耗更多資源。

(3)HOLAP引擎是MOLAP和ROLAP的融合體，對于聚合數(shù)據(jù)的查詢要求，使用與MOLAP相似的預算數(shù)據(jù)模型。在明細數(shù)據(jù)和未預收集的數(shù)據(jù)場景中使用ROLAP的計算方式，比較資源和計算能力，即使沒有明確的場景要求，也能實現(xiàn)最佳化的查詢性能，適應性更好。在這方面制作的比較好的系統(tǒng)主要有DorisDB。

在團隊的小伙伴們一系列調(diào)研和論證之后，首先排除了無法提供低延遲查詢性能的引擎，比如Presto等，其次我們同時需要兼顧復雜業(yè)務場景支持能力，易用性和生產(chǎn)運維成本最低化，因此在這些維度上對比了Druid、ClickHouse、Kylin和DorisDB。

DorisDB作為MPP架構的HOLAP引擎，保證了數(shù)據(jù)模型的靈活性和查詢性能，Rollup和物化視圖功能使用了MOLAP引擎的預算思想，在一些場景中通過空間交換時間的方式大大提高了數(shù)據(jù)查詢效率。最終選擇DorisDB是因為DorisDB的查詢性能很強，與MySQL協(xié)議的兼容性大幅度降低了用戶的使用閾值，另一方面，在高并發(fā)和高吞吐量的不同場表現(xiàn)出良好的適用性，與數(shù)據(jù)中臺流一體化的OneService的發(fā)展構想不一致。

二、應用場景

我們根據(jù)DorisDB搭建了實時和線下統(tǒng)一的OLAP平臺，互動查詢和BI報表應用在數(shù)據(jù)中臺的應用層發(fā)揮了巨大作用，為各業(yè)務線主管/產(chǎn)品運營同學的運營戰(zhàn)略、廣告投放戰(zhàn)略等提供了可靠的支持。

基于DorisDB，我們構建的新數(shù)據(jù)結構如下:

以下簡要介紹一些典型的應用場景:

1.實時直播質(zhì)量監(jiān)測

我們使用DorisDB在直播質(zhì)量分析相關系統(tǒng)中提供支持。這部分是直播引擎開發(fā)同事關心的指標，直接關系到直播課的服務質(zhì)量，一般是分級/亞分級的時效性要求。場景包括網(wǎng)絡質(zhì)量、宏觀丟失率、高峰時段使用率、音頻視頻使用率等。

2.線下數(shù)據(jù)互動查詢和BI報表

在數(shù)據(jù)架構升級前，線下top1數(shù)據(jù)最終落地到MySQL進行互動查詢和BI報表展示，查詢的Query多為單表查詢，維度組合靈活。但隨著業(yè)務增長和數(shù)據(jù)規(guī)模的擴大，MySQL的查詢性能逐漸成為瓶頸，不能支持多維數(shù)據(jù)的查詢場景，同時運輸成本也越來越重。

在結構升級過程中，引進了DorisDB計算引擎作為BI數(shù)據(jù)的落地層。由于DorisDB兼容MySQL協(xié)議，數(shù)據(jù)應用層可以直接通過JDBC連接，因此在搬移過程中幾乎沒有成本，數(shù)據(jù)攝入和查詢效率從數(shù)倍提高到數(shù)百倍，為各業(yè)務線主管/產(chǎn)品運營同學提供了可靠的決策支持。

3.準實時用戶訂單和更新數(shù)據(jù)

我們在訂單/更新等核心數(shù)據(jù)場景中，TT1的離線數(shù)據(jù)不能為業(yè)務提供最有力的決策支持，需要當天的數(shù)據(jù)場景和報告需求這里的主要挑戰(zhàn)是

跨隊合作、跨源、跨庫數(shù)據(jù)場景。

數(shù)據(jù)有時效性要求，查詢響應快。

對在線業(yè)務沒有侵入性，屏蔽影響。

我們的解決辦法是引進Hive歷史庫存數(shù)據(jù)，通過flinkSQL實時輸入DorisDB，優(yōu)化不使用的業(yè)務需求場景的表結構設計和查詢。

4.實時推進投入戰(zhàn)略

廣告投入類的效果數(shù)據(jù)需要分級或更高的時效性要求。因為數(shù)據(jù)的變化可能會直接影響投入效果的評價和投入戰(zhàn)略的變化。

我們同樣用flinkSQL訂閱業(yè)務DB的binlog，最終落地到DorisDB，作為BI報表和業(yè)務系統(tǒng)的統(tǒng)一數(shù)據(jù)產(chǎn)出口徑。

三、實踐經(jīng)驗

集體監(jiān)視

目前我們關注的核心集體監(jiān)視指標是

FE節(jié)點失去聯(lián)系

BE節(jié)點失去聯(lián)系

BE磁盤壞盤

BE的CPU平均使用率過高

FE電腦存儲水平過高

BE節(jié)點失去聯(lián)系

BE磁盤壞盤

BE的CPU平均使用率過高

FE電腦存儲水平過高

基于QE電腦存儲水平的監(jiān)視水平的監(jiān)視主要是

(1)FlinkConnector

我們現(xiàn)在的實時攝取任務大部分都是通過Flink實現(xiàn)的。我們基于Stream Load實現(xiàn)了flink connector，線上使用性能良好，數(shù)據(jù)批次的時效性一般控制在分鐘/半分鐘級別。

(2<愛尬聊_頭條百科>)離線數(shù)據(jù)攝入

對于離線數(shù)據(jù)的攝入，基本是T 1的時效，在凌晨調(diào)度中完成。

我們主要是使用Stream Load和Broker Load兩種方式，我們在倉庫ETL調(diào)度框架中對于兩種Load分別進行了封裝，區(qū)別是：

數(shù)據(jù)量不大/需要加工計算的，先落地本地磁盤文件，然后通過Stream Load導入DorisDB

數(shù)據(jù)量較大的，先寫入Hive臨時表，然后Broker Load導入DorisDB

(3)Presto DorisDB Catalog

我們使用Presto查詢DorisDB的時候主要是針對于一些需要跨源查詢的場景，比如DorisDB中的實時同步數(shù)據(jù)與Hive中的歷史數(shù)據(jù)通過一定條件join并最終產(chǎn)出小時級的數(shù)據(jù)報表。

這里遇到的問題是Presto原生的MySQLCatalog不能讀DorisDB元數(shù)據(jù)，主要原因是information_schema中元數(shù)據(jù)的類型和Presto數(shù)據(jù)的類型需要適應，我們最終通過重新實現(xiàn)的Presto推薦DorisDBCatalog來解決。

(4)DorisDB審計平臺

另外我們也打造了DorisDB DDL工單審計平臺，幫助用戶能夠更好的建立正確的表結構。

審計平臺會監(jiān)控大查詢和慢查詢，這些對集群性能影響較大的查詢，通過告警機器人的方式通知到用戶，督促大家去做查詢的優(yōu)化。

3.基于審計日志數(shù)據(jù)治理

之前常見遇到的一個問題是：BE CPU被吃光了/磁盤IO打滿

不同的case都可能導致這個現(xiàn)象：

某一個大查詢scan數(shù)據(jù)量太多、耗時較長直接吃掉所有io

表buckets過多導致scan所有盤

大查詢頻繁提交等

這類問題排查起來較為困難，除了手動殺掉查詢，好像沒什么好的處理辦法。另一方面大量的導入操作(compaction)是否也會造成cpu和io的壓力。

目前的解決方案就是通過審計日志和BE服務日志來監(jiān)控查詢和寫入，對于有問題的請求及時處理避免對集群性能影響的進一步擴大。

我們通過filebeat收集fe.audit.log日志，最終導入ES，根據(jù)ES進行query的分析和監(jiān)視。

現(xiàn)在的監(jiān)視主要是大的查詢和慢的查詢，這些對集團性能有很大影響的查詢，通過警告機器人通知用戶，促進了查詢的最佳化。并實現(xiàn)了大查詢/慢查詢的告警，監(jiān)控和明細分析。

四、未來展望和規(guī)劃

1.應用場景

后續(xù)我們計劃基于DorisDB做更多的場景實踐探索：

基于Bitmap的多維分析/BI自助工具

通用事件分析平臺(支持明細 聚合)

2.運維建設

在組件運維層面的工作包括：自動化運維，建設回歸測試框架、自動化集群擴縮容腳本、自動化集群升級腳本等，降低人工操作成本。

3.平臺的普及

在數(shù)據(jù)中臺的平臺化建設中，DorisDB的參與也是必不可少的。

技術共享、最佳實踐和用戶培訓

統(tǒng)一元數(shù)據(jù)平臺，通過不同發(fā)動機的DDL、權限/租戶管理等功能

用戶自助BI工具，屏蔽發(fā)動機細節(jié)，用戶簡單操作的可視化報告平臺。

通過引入DorisDB計算引擎，我們實現(xiàn)了流量數(shù)據(jù)、批量數(shù)據(jù)融合的一站式數(shù)據(jù)存儲和查詢引擎，提供語義一致、易于使用的數(shù)據(jù)服務。DorisDB為猿輔導數(shù)據(jù)中臺的標準化數(shù)據(jù)集和統(tǒng)一數(shù)據(jù)平臺服務能力奠定了堅實的基礎，支持各業(yè)務線更快、更靈活的查詢和分析，全面提高數(shù)據(jù)分析能力，為未來數(shù)據(jù)平臺化建設提供了更多可能性。

最后，感謝DorisDB鼎石科技團隊的專業(yè)支持服務，希望能一起更好地建設DorisDB。(作者:申陽猿指導數(shù)據(jù)中臺，大數(shù)據(jù)開發(fā)工程師)