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

　　我們引入了性能強悍的新一代MPP數據庫：DorisDB，來構建OLAP平臺。基于DorisDB，我們統一了實時數據分析和離線數據分析。當前DorisDB有3個集群，每天百萬級有效查詢請求，p99延遲1s，用于廣告投放渠道轉化、用戶成單和續報、直播質量監控等多個數據場景，支持各業務線進行更加快速靈活的查詢和分析，全面提升數據分析能力。

　　一、平臺選型的業務背景

　　1.業務特點和需求

　　猿輔導作為互聯網教育行業賽道中的領先品牌，每日有海量數據生成，為實現科技助力教育，十分重視數據在公司發展中發揮的作用，需要不斷解決在數據建設上遇到的諸多挑戰。

　　在互聯網教育數據體系中，不僅僅要關注用戶活躍、訂單收入，也很看重渠道推廣轉換率和用戶續報率。這些指標存在不同的維度和不同的計算口徑，以及多樣化的業務系統接入模式，給我們OneService的底層設計帶來了挑戰。另一方面，數據時效性需求逐漸增強，離線T+1的數據已經越來越無法滿足驅動業務的需求，數據逐步實時化也成為不可逆轉的行業發展趨勢。

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

　　2.對OLAP引擎的需求

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

　　·數據查詢延遲在秒級/毫秒級;

　　·同時高效支持大寬表和多表join查詢，以支持復雜查詢場景;

　　·需要支持高并發查詢場景;

　　·同時支持流式數據和批式數據攝入，支持實時/離線數據ETL任務;

　　·支持標準化SQL，大幅度降低用戶使用成本;

　　·具有高效的精準去重能力;

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

　　3.技術選型和優劣勢對比

　　OLAP(On-line Analytical Processing，聯機分析處理)是在基于數據倉庫多維模型的基礎上實現的面向分析的各類操作的集合，強調數據分析性能和SQL執行時間。

　　在當今，各類OLAP數據引擎可謂百花齊放，可以分為MOLAP(Multi-dimensional OLAP)、ROLAP(Relational OLAP)和HOLAP(Hybrid OLAP)三類。

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

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

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

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

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

　　二、應用場景

　　我們基于DorisDB構建了實時和離線統一的OLAP平臺，交互查詢和BI報表應用在數據中臺的應用層發揮了巨大作用，為各個業務線的主管/產品運營同學的運營策略、廣告投放策略等提供了可靠支持。

　　基于DorisDB，我們構建的全新數據架構如下：

　　下面簡單介紹幾個典型的應用場景：

　　1.實時直播質量監控

　　我們使用DorisDB在直播質量分析相關系統中提供支持。這部分是直播引擎的研發同事十分關心的一些指標，直接關系到直播上課中的服務質量，一般是分鐘級/亞分鐘級的時效性要求。場景包括：網絡質量、宏觀丟包率、高峰時段可用率、音視頻可用率等。

　　2.離線數據交互查詢和BI報表

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

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

　　3.準實時用戶成單和續報數據

　　我們在訂單/續報等核心數據場景中，T+1的離線數據已經無法為業務提供最有力的決策支撐，越來越多需要當天數據的場景和報表需求。這里的主要挑戰是：

　　·跨團隊合作、跨源、跨庫的數據場景。

　　·數據有時效性要求，查詢響應要快。

　　·對線上業務沒有侵入性，屏蔽影響。

　　我們的解決方法是，導入Hive歷史存量數據+訂閱binlog增量數據通過flinkSQL實時灌進DorisDB中，同時針對不用的業務需求場景做表結構設計和查詢優化。

　　4.實時推廣投放策略

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

　　我們同樣用flinkSQL訂閱業務DB的binlog，最終落地到DorisDB，作為BI報表和業務系統的統一數據產出口徑。

　　三、實踐心得

　　1.集群監控

　　目前我們關注的核心集群監控指標包括：

　　·FE節點失聯

　　·BE節點失聯

　　·BE磁盤壞盤

　　·BE CPU平均使用率過高

　　·FE Master的內存水位過高

　　基于Query級別的監控主要有：

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

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

　　·用戶連接數過多

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

　　2.打通生態

　　在早期使用時，DorisDB當時和其他大數據開源生態的適配能力還有不足，因此我們做了一些改造性工作。

　　(1)Flink Connector

　　我們目前實時的攝入任務大部分都是通過Flink來實現。我們基于Stream Load實現了flink connector，線上使用性能良好，數據批次的時效性一般控制在分鐘/半分鐘級別。

　　(2)離線數據攝入

　　對于離線數據的攝入，基本是T+1的時效，在凌晨調度中完成。

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

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

　　·數據量較大的，先寫入Hive臨時表，然后Broker Load導入DorisDB

　　(3)Presto DorisDB Catalog

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

　　這里遇到的問題是Presto原生的MySQL Catalog無法讀取DorisDB元數據，主要原因是information_schema中元數據的類型和Presto數據類型需要適配，我們最終通過重新實現的Presto DorisDB Catalog來解決。

　　(4)DorisDB審計平臺

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

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

　　3.基于審計日志數據治理

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

　　不同的case都可能導致這個現象：

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

　　·表buckets過多導致scan所有盤

　　·大查詢頻繁提交等

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

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

　　我們通過filebeat采集了fe.audit.log日志，并最終導入到ES中，基于ES做query的分析和監控。

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

　　四、未來展望和規劃

　　1.應用場景

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

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

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

　　2.運維建設

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

　　3.平臺推廣

　　在數據中臺的平臺化建設中也少不了DorisDB的參與，包括：

　　·技術分享，最佳實踐和用戶培訓;

　　·統一元數據平臺，打通不同引擎的DDL、權限/租戶管理等功能;

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

　　總結

　　通過引入DorisDB計算引擎，我們實現了流式數據、批式數據融合的一站式數據存儲和查詢引擎，對外提供語義一致和易用的數據服務。可以說DorisDB為猿輔導數據中臺的標準化數據集(OneData)和統一數據平臺服務(OneService)能力奠定了一個穩固的基礎，支持各業務線進行更加快速靈活的查詢和分析，全面提升數據分析能力，也為未來的數據平臺化建設提供了更多可能性。

　　最后，十分感謝DorisDB鼎石科技團隊專業的支持服務，希望我們能一起把DorisDB建設得更好。(作者：申陽 猿輔導數據中臺，大數據研發工程師)