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

我們引入了性能強悍的新一代MPP數(shù)據(jù)庫：DorisDB，來構(gòu)建OLAP平臺�；�于DorisDB，我們統(tǒng)一了實時數(shù)據(jù)分析和離線數(shù)據(jù)分析。當(dāng)前DorisDB有3個集群，每天百萬級有效查詢請求，p99延遲1s，用于廣告投放渠道轉(zhuǎn)化、用戶成單和續(xù)報、直播質(zhì)量監(jiān)控等多個數(shù)據(jù)場景，支持各業(yè)務(wù)線進行更加快速靈活的查詢和分析，全面提升數(shù)據(jù)分析能力。

一、平臺選型的業(yè)務(wù)背景

1．業(yè)務(wù)特點和需求

猿輔導(dǎo)作為互聯(lián)網(wǎng)教育行業(yè)賽道中的領(lǐng)先品牌，每日有海量數(shù)據(jù)生成，為實現(xiàn)科技助力教育，十分重視數(shù)據(jù)在公司發(fā)展中發(fā)揮的作用，需要不斷解決在數(shù)據(jù)建設(shè)上遇到的諸多挑戰(zhàn)。

在互聯(lián)網(wǎng)教育數(shù)據(jù)體系中，不僅僅要關(guān)注用戶活躍、訂單收入，也很看重渠道推廣轉(zhuǎn)換率和用戶續(xù)報率。這些指標(biāo)存在不同的維度和不同的計算口徑，以及多樣化的業(yè)務(wù)系統(tǒng)接入模式，給我們OneService的底層設(shè)計帶來了挑戰(zhàn)。另一方面，數(shù)據(jù)時效性需求逐漸增強，離線T＋1的數(shù)據(jù)已經(jīng)越來越無法滿足驅(qū)動業(yè)務(wù)的需求，數(shù)據(jù)逐步實時化也成為不可逆轉(zhuǎn)的行業(yè)發(fā)展趨勢。

在這樣的背景下，我們的OLAP平臺需要同時支持實時和離線數(shù)據(jù)寫入，以支持不同時效的查詢需求；需要支持復(fù)雜、多樣的數(shù)據(jù)查詢邏輯，以滿足各種不同的業(yè)務(wù)場景的數(shù)據(jù)分析需求；需要能夠進行快速的在線擴展，以支持業(yè)務(wù)快速發(fā)展帶來的數(shù)據(jù)規(guī)模增長。

2．對OLAP引擎的需求

總結(jié)起來，我們對于OLAP的需求大概包括以下幾點：

·數(shù)據(jù)查詢延遲在秒級／毫秒級；

·同時高效支持大寬表和多表join查詢，以支持復(fù)雜查詢場景；

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

·同時支持流式數(shù)據(jù)和批式數(shù)據(jù)攝入，支持實時／離線數(shù)據(jù)ETL任務(wù)；

·支持標(biāo)準(zhǔn)化SQL，大幅度降低用戶使用成本；

·具有高效的精準(zhǔn)去重能力；

·較好的在線擴展能力，較低的運維管理成本。

3．技術(shù)選型和優(yōu)劣勢對比

OLAP（On－line Analytical Processing，聯(lián)機分析處理）是在基于數(shù)據(jù)倉庫多維模型的基礎(chǔ)上實現(xiàn)的面向分析的各類操作的集合，強調(diào)數(shù)據(jù)分析性能和SQL執(zhí)行時間。

在當(dāng)今，各類OLAP數(shù)據(jù)引擎可謂百花齊放，可以分為MOLAP（Multi－dimensional OLAP）、ROLAP（Relational OLAP）和HOLAP（Hybrid OLAP）三類。

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

（2）ROLAP引擎的代表包括：Presto，Impala，GreenPlum，Clickhouse等，和MOLAP的區(qū)別在于，ROLAP在收到查詢請求時，會先把query解析成查詢計劃，執(zhí)行查詢算子，在原始數(shù)據(jù)基礎(chǔ)上進行諸如sum、groupby等各種各類計算，查詢靈活，可擴展性好，往往使用MPP架構(gòu)通過擴大并發(fā)來提升計算效率。這種模型的引擎優(yōu)點是靈活性好，但是對于一個大查詢／復(fù)雜查詢它的性能是不穩(wěn)定的，同時可能造成冗余的重復(fù)計算，消耗更多資源。

（3）HOLAP引擎是MOLAP和ROLAP的融合體，對于聚合數(shù)據(jù)的查詢請求，使用類似于MOLAP的預(yù)計算數(shù)據(jù)模型。對于明細數(shù)據(jù)和沒有預(yù)聚合的數(shù)據(jù)場景下使用ROLAP的計算方式，比拼資源和算力，這樣即使沒有明確的場景要求下，也可以實現(xiàn)最優(yōu)化的查詢性能，適應(yīng)性更好。這方面做的比較好的系統(tǒng)主要有DorisDB。

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

DorisDB作為一個MPP架構(gòu)的HOLAP引擎，保證了數(shù)據(jù)模型的靈活性和查詢性能，Rollup和物化視圖功能使用了MOLAP引擎的預(yù)計算思想，在一些場景上通過空間換時間的方式極大地提高數(shù)據(jù)查詢效率。最終我們選擇DorisDB，一方面是因為DorisDB查詢性能強悍，同時兼容MySQL協(xié)議極大降低了用戶的使用門檻；另一方面它可以在高并發(fā)和高吞吐的不同場景下都表現(xiàn)出較好的適用性，和數(shù)據(jù)中臺流批一體的OneService發(fā)展思路不謀而合。

二、應(yīng)用場景

我們基于DorisDB構(gòu)建了實時和離線統(tǒng)一的OLAP平臺，交互查詢和BI報表應(yīng)用在數(shù)據(jù)中臺的應(yīng)用層發(fā)揮了巨大作用，為各個業(yè)務(wù)線的主管／產(chǎn)品運營同學(xué)的運營策略、廣告投放策略等提供了可靠支持。

基于DorisDB，我們構(gòu)建的全新數(shù)據(jù)架構(gòu)如下：

下面簡單介紹幾個典型的應(yīng)用場景：

1．實時直播質(zhì)量監(jiān)控

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

2．離線數(shù)據(jù)交互查詢和BI報表

在數(shù)據(jù)架構(gòu)升級前，離線T＋1數(shù)據(jù)最終落地到MySQL上進行交互式查詢和BI報表展示，查詢的Query多是單表查詢，維度組合較為靈活。但是隨著業(yè)務(wù)增長和數(shù)據(jù)規(guī)模擴大，MySQL的查詢性能逐漸遇到瓶頸，無法支持一些多維度數(shù)據(jù)的查詢場景，同時運維成本也越來越重。

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

3．準(zhǔn)實時用戶成單和續(xù)報數(shù)據(jù)

我們在訂單／續(xù)報等核心數(shù)據(jù)場景中，T＋1的離線數(shù)據(jù)已經(jīng)無法為業(yè)務(wù)提供最有力的決策支撐，越來越多需要當(dāng)天數(shù)據(jù)的場景和報表需求。這里的主要挑戰(zhàn)是：

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

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

·對線上業(yè)務(wù)沒有侵入性，屏蔽影響。

我們的解決方法是，導(dǎo)入Hive歷史存量數(shù)據(jù)＋訂閱binlog增量數(shù)據(jù)通過flinkSQL實時灌進DorisDB中，同時針對不用的業(yè)務(wù)需求場景做表結(jié)構(gòu)設(shè)計和查詢優(yōu)化。

4．實時推廣投放策略

對于廣告投放類的效果數(shù)據(jù)，我們會需要分鐘級或更高的時效性要求，因為數(shù)據(jù)的變化可能直接影響到投放效果的評估和投放策略的變化。

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

三、實踐心得

1．集群監(jiān)控

目前我們關(guān)注的核心集群監(jiān)控指標(biāo)包括：

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

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

·BE磁盤壞盤

·BE CPU平均使用率過高

·FE Master的內(nèi)存水位過高

基于Query級別的監(jiān)控主要有：

·大查詢告警，例如ScanBytes、ScanRows

·超過2分鐘的慢查詢告警

·用戶連接數(shù)過多

·用“select 1”查詢探活整體服務(wù)的可用性

2．打通生態(tài)

在早期使用時，DorisDB當(dāng)時和其他大數(shù)據(jù)開源生態(tài)的適配能力還有不足，因此我們做了一些改造性工作。

（1）Flink Connector

我們目前實時的攝入任務(wù)大部分都是通過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導(dǎo)入DorisDB

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

（3）Presto DorisDB Catalog

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

這里遇到的問題是Presto原生的MySQL Catalog無法讀取DorisDB元數(shù)據(jù)，主要原因是information＿schema中元數(shù)據(jù)的類型和Presto數(shù)據(jù)類型需要適配，我們最終通過重新實現(xiàn)的Presto DorisDB Catalog來解決。

（4）DorisDB審計平臺

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

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

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

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

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

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

·表buckets過多導(dǎo)致scan所有盤

·大查詢頻繁提交等

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

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

我們通過filebeat采集了fe．a(chǎn)udit．log日志，并最終導(dǎo)入到ES中，基于ES做query的分析和監(jiān)控。

目前監(jiān)控主要是：大查詢和慢查詢，這些對集群性能影響較大的查詢，通過告警機器人的方式通知到用戶，督促大家去做查詢的優(yōu)化。并實現(xiàn)了大查詢／慢查詢的告警，監(jiān)控和明細分析。

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

1．應(yīng)用場景

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

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

·通用事件分析平臺（支持明細＋聚合）

2．運維建設(shè)

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

3．平臺推廣

在數(shù)據(jù)中臺的平臺化建設(shè)中也少不了DorisDB的參與，包括：

·技術(shù)分享，最佳實踐和用戶培訓(xùn)；

·統(tǒng)一元數(shù)據(jù)平臺，打通不同引擎的DDL、權(quán)限／租戶管理等功能；

·用戶自助BI工具，屏蔽引擎細節(jié)，用戶簡單操作的可視化報表平臺。

總結(jié)

通過引入DorisDB計算引擎，我們實現(xiàn)了流式數(shù)據(jù)、批式數(shù)據(jù)融合的一站式數(shù)據(jù)存儲和查詢引擎，對外提供語義一致和易用的數(shù)據(jù)服務(wù)�？梢哉fDorisDB為猿輔導(dǎo)數(shù)據(jù)中臺的標(biāo)準(zhǔn)化數(shù)據(jù)集（OneData）和統(tǒng)一數(shù)據(jù)平臺服務(wù)（OneService）能力奠定了一個穩(wěn)固的基礎(chǔ)，支持各業(yè)務(wù)線進行更加快速靈活的查詢和分析，全面提升數(shù)據(jù)分析能力，也為未來的數(shù)據(jù)平臺化建設(shè)提供了更多可能性。

最后，十分感謝DorisDB鼎石科技團隊專業(yè)的支持服務(wù)，希望我們能一起把DorisDB建設(shè)得更好。