廣州熱線(xiàn)

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

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

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

1.業(yè)務(wù)特點(diǎn)和需求

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

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

在這樣的背景下,我們的OLAP平臺(tái)需要同時(shí)支持實(shí)時(shí)和離線(xiàn)數(shù)據(jù)寫(xiě)入,以支持不同時(shí)效的查詢(xún)需求;需要支持復(fù)雜、多樣的數(shù)據(jù)查詢(xún)邏輯,以滿(mǎn)足各種不同的業(yè)務(wù)場(chǎng)景的數(shù)據(jù)分析需求;需要能夠進(jìn)行快速的在線(xiàn)擴(kuò)展,以支持業(yè)務(wù)快速發(fā)展帶來(lái)的數(shù)據(jù)規(guī)模增長(zhǎng)。

2.對(duì)OLAP引擎的需求

總結(jié)起來(lái),我們對(duì)于OLAP的需求大概包括以下幾點(diǎn):

·數(shù)據(jù)查詢(xún)延遲在秒級(jí)/毫秒級(jí);

·同時(shí)高效支持大寬表和多表join查詢(xún),以支持復(fù)雜查詢(xún)場(chǎng)景;

·需要支持高并發(fā)查詢(xún)場(chǎng)景;

·同時(shí)支持流式數(shù)據(jù)和批式數(shù)據(jù)攝入,支持實(shí)時(shí)/離線(xiàn)數(shù)據(jù)ETL任務(wù);

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

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

·較好的在線(xiàn)擴(kuò)展能力,較低的運(yùn)維管理成本。

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

OLAPOn-line Analytical Processing,聯(lián)機(jī)分析處理是在基于數(shù)據(jù)倉(cāng)庫(kù)多維模型的基礎(chǔ)上實(shí)現(xiàn)的面向分析的各類(lèi)操作的集合,強(qiáng)調(diào)數(shù)據(jù)分析性能和SQL執(zhí)行時(shí)間。

在當(dāng)今,各類(lèi)OLAP數(shù)據(jù)引擎可謂百花齊放,可以分為MOLAPMulti-dimensional OLAP、ROLAPRelational OLAP和HOLAPHybrid OLAP三類(lèi)。

1MOLAP引擎的代表包括:Druid,Kylin等,本質(zhì)是通過(guò)空間和預(yù)計(jì)算換在線(xiàn)查詢(xún)時(shí)間。在數(shù)據(jù)寫(xiě)入時(shí)生成預(yù)聚合數(shù)據(jù),這樣查詢(xún)的時(shí)候命中的就是預(yù)聚合的數(shù)據(jù)而非明細(xì)數(shù)據(jù),從而大幅提高查詢(xún)效率,在一些固定查詢(xún)模式的場(chǎng)景中,這種效率提升可謂非常明顯。但是他的缺點(diǎn)也來(lái)自于這種預(yù)聚合模型,因?yàn)樗鼧O大的限制了數(shù)據(jù)模型的靈活性,比如在數(shù)據(jù)維度變化時(shí)的數(shù)據(jù)重建成本非常高,而且明細(xì)數(shù)據(jù)也丟失了。

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

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

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

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

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

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

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

下面簡(jiǎn)單介紹幾個(gè)典型的應(yīng)用場(chǎng)景:

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

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

2.離線(xiàn)數(shù)據(jù)交互查詢(xún)和BI報(bào)表

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

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

3.準(zhǔn)實(shí)時(shí)用戶(hù)成單和續(xù)報(bào)數(shù)據(jù)

我們?cè)谟唵?續(xù)報(bào)等核心數(shù)據(jù)場(chǎng)景中,T+1的離線(xiàn)數(shù)據(jù)已經(jīng)無(wú)法為業(yè)務(wù)提供最有力的決策支撐,越來(lái)越多需要當(dāng)天數(shù)據(jù)的場(chǎng)景和報(bào)表需求。這里的主要挑戰(zhàn)是:

·跨團(tuán)隊(duì)合作、跨源、跨庫(kù)的數(shù)據(jù)場(chǎng)景。

·數(shù)據(jù)有時(shí)效性要求,查詢(xún)響應(yīng)要快。

·對(duì)線(xiàn)上業(yè)務(wù)沒(méi)有侵入性,屏蔽影響。

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

4.實(shí)時(shí)推廣投放策略

對(duì)于廣告投放類(lèi)的效果數(shù)據(jù),我們會(huì)需要分鐘級(jí)或更高的時(shí)效性要求,因?yàn)閿?shù)據(jù)的變化可能直接影響到投放效果的評(píng)估和投放策略的變化。

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

三、實(shí)踐心得

1.集群監(jiān)控

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

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

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

·BE磁盤(pán)壞盤(pán)

·BE CPU平均使用率過(guò)高

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

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

·大查詢(xún)告警,例如ScanBytes、ScanRows

·超過(guò)2分鐘的慢查詢(xún)告警

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

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

2.打通生態(tài)

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

1Flink Connector

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

2離線(xiàn)數(shù)據(jù)攝入

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

我們主要是使用Stream Load和Broker Load兩種方式,我們?cè)趥}(cāng)庫(kù)ETL調(diào)度框架中對(duì)于兩種Load分別進(jìn)行了封裝,區(qū)別是:

·數(shù)據(jù)量不大/需要加工計(jì)算的,先落地本地磁盤(pán)文件,然后通過(guò)Stream Load導(dǎo)入DorisDB

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

3Presto DorisDB Catalog

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

這里遇到的問(wèn)題是Presto原生的MySQL Catalog無(wú)法讀取DorisDB元數(shù)據(jù),主要原因是information_schema中元數(shù)據(jù)的類(lèi)型和Presto數(shù)據(jù)類(lèi)型需要適配,我們最終通過(guò)重新實(shí)現(xiàn)的Presto DorisDB Catalog來(lái)解決。

4DorisDB審計(jì)平臺(tái)

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

審計(jì)平臺(tái)會(huì)監(jiān)控大查詢(xún)和慢查詢(xún),這些對(duì)集群性能影響較大的查詢(xún),通過(guò)告警機(jī)器人的方式通知到用戶(hù),督促大家去做查詢(xún)的優(yōu)化。

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

之前常見(jiàn)遇到的一個(gè)問(wèn)題是:BE CPU被吃光了/磁盤(pán)IO打滿(mǎn)

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

·某一個(gè)大查詢(xún)scan數(shù)據(jù)量太多、耗時(shí)較長(zhǎng)直接吃掉所有io

·表buckets過(guò)多導(dǎo)致scan所有盤(pán)

·大查詢(xún)頻繁提交等

這類(lèi)問(wèn)題排查起來(lái)較為困難,除了手動(dòng)殺掉查詢(xún),好像沒(méi)什么好的處理辦法。另一方面大量的導(dǎo)入操作compaction是否也會(huì)造成cpu和io的壓力。

目前的解決方案就是通過(guò)審計(jì)日志和BE服務(wù)日志來(lái)監(jiān)控查詢(xún)和寫(xiě)入,對(duì)于有問(wèn)題的請(qǐng)求及時(shí)處理避免對(duì)集群性能影響的進(jìn)一步擴(kuò)大。

我們通過(guò)filebeat采集了fe.audit.log日志,并最終導(dǎo)入到ES中,基于ES做query的分析和監(jiān)控。

目前監(jiān)控主要是:大查詢(xún)和慢查詢(xún),這些對(duì)集群性能影響較大的查詢(xún),通過(guò)告警機(jī)器人的方式通知到用戶(hù),督促大家去做查詢(xún)的優(yōu)化。并實(shí)現(xiàn)了大查詢(xún)/慢查詢(xún)的告警,監(jiān)控和明細(xì)分析。?

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

1.應(yīng)用場(chǎng)景

后續(xù)我們計(jì)劃基于DorisDB做更多的場(chǎng)景實(shí)踐探索:

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

·通用事件分析平臺(tái)支持明細(xì)+聚合

2.運(yùn)維建設(shè)

在組件運(yùn)維層面的工作包括:自動(dòng)化運(yùn)維,建設(shè)回歸測(cè)試框架、自動(dòng)化集群擴(kuò)縮容腳本、自動(dòng)化集群升級(jí)腳本等,降低人工操作成本。

3.平臺(tái)推廣

在數(shù)據(jù)中臺(tái)的平臺(tái)化建設(shè)中也少不了DorisDB的參與,包括:

·技術(shù)分享,最佳實(shí)踐和用戶(hù)培訓(xùn);

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

·用戶(hù)自助BI工具,屏蔽引擎細(xì)節(jié),用戶(hù)簡(jiǎn)單操作的可視化報(bào)表平臺(tái)。?

總結(jié)

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

最后,十分感謝DorisDB鼎石科技團(tuán)隊(duì)專(zhuān)業(yè)的支持服務(wù),希望我們能一起把DorisDB建設(shè)得更好。作者:申陽(yáng)猿輔導(dǎo)數(shù)據(jù)中臺(tái),大數(shù)據(jù)研發(fā)工程師