開源大數(shù)據(jù)OLAP引擎最佳實踐

大家好，我是夢想家Alex ~ 今天給大家分享一篇很不錯的文章，通過六個部分來介紹開源大數(shù)據(jù)OLAP引擎最佳實踐。



01

開源OLAP綜述

如今的開源數(shù)據(jù)引擎多種多樣，不同種類的引擎滿足了我們不同的需求?，F(xiàn)在ROLAP計算存儲一體的數(shù)據(jù)倉庫主要有三種，即StarRocks(DorisDB)，ClickHouse和Apache Doris。應(yīng)用最廣的數(shù)據(jù)查詢系統(tǒng)主要有Druid，Kylin和HBase。MPP引擎主要有Trino，PrestoDB和Impala。這些引擎在行業(yè)內(nèi)有著廣泛的應(yīng)用。

02

開源數(shù)倉解決方案

接下來，我們講講開源大數(shù)據(jù)以及數(shù)倉的解決方案。上圖是EMR的整體架構(gòu)，在云資源層，主要有ECS。在存儲層的JindoFS提供了以O(shè)SS為基底的Hadoop接口，不但節(jié)約了成本，而且提升了整體的擴展性。數(shù)據(jù)湖格式有效解決了數(shù)據(jù)統(tǒng)一管理的難題。其次在計算引擎方面，它具有批處理，流式計算，機器學習和引擎加速等能力。



目前，大家應(yīng)用最多的離線數(shù)倉體系是Lambda架構(gòu)。該架構(gòu)主要分為兩個部分。
第一部分，在實時方面我們從CDC,ORTP的數(shù)據(jù)源開始，進行行為數(shù)據(jù)分析，然后通過Kafka，F(xiàn)link進行加工。讓數(shù)據(jù)在線系統(tǒng)，可以直接調(diào)用API，提升點查效率。其次，當所有聚合的數(shù)都導入Olap系統(tǒng)時，運營人員可以快速用它，實現(xiàn)自己新的想法，提升工作效率。
第二部分，在離線方面當需要長久保存數(shù)據(jù)時，大家都會使用hive。如果沒有增量數(shù)據(jù)庫格式，大家一般通過insert overwrite，在detail上做一些數(shù)據(jù)集市。除此之外，我們通過離線t+1的方式，實現(xiàn)離線數(shù)倉的實時數(shù)據(jù)訂正。因為實時數(shù)據(jù)一般得出的是近似值，離線數(shù)據(jù)得到的是準確值。

第三部分，實時數(shù)據(jù)湖的解決方案，其數(shù)據(jù)量在PB+級別。我們希望統(tǒng)一離線和實時數(shù)倉，用一套代碼構(gòu)建業(yè)務(wù)。數(shù)據(jù)湖的數(shù)據(jù)存儲在OSS/HDFS，由于我們的部分業(yè)務(wù)有Upsert變更需求，所以我們希望建設(shè)分鐘級到小時級的數(shù)倉。能夠?qū)⒆顭岬臄?shù)據(jù)導入StarRocks/CK，OLAP的查詢時長保證在500毫秒到2秒之間。與此同時，我們利用Presto查詢Hudi/Iceberg/Delta時，其速率能夠保證在5秒至30秒之間。



上圖是比較傳統(tǒng)的實時數(shù)倉方案。當每天增量數(shù)據(jù)達到10TB+，我們希望直接以單軟件構(gòu)建業(yè)務(wù)底座，讓數(shù)據(jù)先存儲在CK/StarRocks，讓冷數(shù)據(jù)轉(zhuǎn)存到OSS。不必再運維Hadoop的龐大體系，極大簡化運維操作，可以媲美全托管。


第二種實時數(shù)倉的解決方案，我們通過micro-batch任務(wù)調(diào)度器去處理DWS，DWD和ODS。其實時性非常強，極大簡化了開發(fā)效率，數(shù)據(jù)的一致性最高。后續(xù)我們將推出存算分離方案，用OSS存儲海量數(shù)據(jù)，用Cache加速熱數(shù)據(jù)。

03

ClickHouse介紹

ClickHouse是面向聯(lián)機分析處理（OLAP）的開源分析引擎。最初由俄羅斯第一搜索引擎Yandex開發(fā)，于2016年開源，開發(fā)語言為C++。由于其優(yōu)良的查詢性能，PB級的數(shù)據(jù)規(guī)模，簡單的架構(gòu)，在國內(nèi)外公司被廣泛采用。
它是列存數(shù)據(jù)庫，具有完備的DBMS功能，備份列式存儲和數(shù)據(jù)壓縮。它的MPP架構(gòu)易于擴展，易于維護。除此之外，它支持向量化的查詢，完善的SQL以及實時的數(shù)據(jù)更新，查詢速度可以達到亞秒級的響應(yīng)。


那么ClickHouse的查詢速度為什么會這么快呢？它類似于LSM tree,所有數(shù)據(jù)都是經(jīng)過有序排列，提前做好聚合計算，再存儲。并且它的數(shù)據(jù)存儲格式自帶索引。
其次，ClickHouse可以基于多個Key創(chuàng)建索引。它的二級索引采用Data skipping index。

ClickHouse的應(yīng)用場景主要有四個方面。

第一，用戶行為分析。ClickHouse將用戶行為分析表制作成一張大的寬表，減少join的形式，實現(xiàn)路徑分析、漏斗分析、路徑轉(zhuǎn)化等功能。除此之外，它還能支撐廣告，營銷和AB實驗。
第二，實時BI報表。ClickHouse可以根據(jù)業(yè)務(wù)需求，實時制作及時產(chǎn)出，查詢靈活的BI報表，包括訂單分析，營銷效果分析，大促活動分析等等。
第三，監(jiān)控。ClickHouse可以將系統(tǒng)和應(yīng)用監(jiān)控指標通過流式計算引擎Flink,Spark streaming清洗處理以后，實時寫入ClickHouse。結(jié)合Grafna進行可視化展示。
第四，用戶畫像。ClickHouse可以對各種用戶特征進行數(shù)據(jù)加工，制作成包含全部用戶的一張或多張用戶特征表，提供靈活的用戶畫像分析，支撐廣告，圈人等業(yè)務(wù)需求等等。

接下來，我們講講EMR ClickHouse架構(gòu)。我們在ClickHouse的基礎(chǔ)上做了一定的增強。首先，我們重構(gòu)了In Memory Part寫入模塊，讓它支持Flink單條寫入，F(xiàn)link Exactly Once事務(wù)寫入以及Sharding Key寫入。成功解決了寫Distributed表的痛點，提升了整體性能。其次，它還支持DiskOSS。實現(xiàn)了冷熱的分層存儲，節(jié)約了成本。最后，我們實現(xiàn)了副本擴容和分片擴容，讓擴容方式變得更靈活。


04

StarRocks介紹

接下來，我們聊一聊StarRocks。StarRocks其向量化的執(zhí)行引擎，實現(xiàn)了亞秒級查詢延時。StarRocks單節(jié)點100M/秒的寫入速度，讓它每秒可處理100億行數(shù)據(jù)。StarRocks的綜合查詢速度比其他產(chǎn)品快10到100倍。數(shù)據(jù)秒級實時更新可見。其次，StarRocks支持數(shù)千用戶同時分析，部分場景每秒可支持1萬以上的QPS，TP99控制在1秒以內(nèi)。最后，StarRocks基于多種數(shù)據(jù)模型，實現(xiàn)了極速分析，縮短業(yè)務(wù)交付時間。提升了數(shù)據(jù)工程師和分析師工作效率。

如上圖所示，StarRocks的架構(gòu)簡潔明了，兼容MySQL協(xié)議，可使用各類MySQL客戶端。并且支持FE、BE的水平擴展，從而實現(xiàn)自動均衡。讓運維和使用都非常方便。

StarRocks的極速引擎，實現(xiàn)了全面向量化執(zhí)行。它可以按列存儲，按列計算。用更少的虛函數(shù)調(diào)用，更少的分支判斷，更好地利用SIMD指令并且對CPU Cache更友好。其次，StarRocks向量化提升的效果明顯。向量化Filter，向量化聚合和向量化Shuffle Join的效果都有幾何倍數(shù)的提升。

StarRocks的極速引擎，具有全新的CBO?；贠rca論文，將表達式重寫、表達式復(fù)用。用公共謂詞提取、謂詞推導。將子查詢改寫，調(diào)整Join順序、讓Join算法自動選擇。成功的將SQL語句轉(zhuǎn)化為一個可執(zhí)行Plan。

StarRocks的極速引擎，具有多種分布式的Join。目前，這種分布式Join是ClickHouse比較缺乏的功能。右圖是更加高效的Join方式，它通過提前完成bucket分類，讓整體運行更加高效。

StarRocks為全場景提供了四種數(shù)據(jù)模型。
第一，明細模型。用于保存和分析原始明細數(shù)據(jù)，數(shù)據(jù)寫入后幾乎無更新。主要用于日志，操作記錄，設(shè)備狀態(tài)采樣等等。
第二，聚合模型。用于保存，分析，匯總數(shù)據(jù)。不需要查詢明細數(shù)據(jù)。數(shù)據(jù)導入后實時完成聚合，數(shù)據(jù)寫入后幾乎無更新。適用于按時間、地域、機構(gòu)匯總的數(shù)據(jù)。
第三，主鍵模型。支持基于主鍵的更新，Delete and insert，大批量導入時保證高性能查詢。用于保存和分析需要更新的數(shù)據(jù)。
第四，更新模型。支持基于主鍵的更新，Merge On Read，更新頻率比主鍵模型更高。用于保存和分析需要更新的數(shù)據(jù)。主鍵模型和更新模型都適用于狀態(tài)會發(fā)生變動的訂單，設(shè)備狀態(tài)等。

StarRocks在全場景中，還實現(xiàn)了高并發(fā)的查詢。StarRocks的分區(qū)機制可以高效過濾，提升查詢性能。StarRocks的分桶機制充分發(fā)揮了集群的性能，成功避免了熱點問題。但StarRocks相對于其他的OLAP引擎和行存的OLTP引擎還有一定的差距。


在LakeHouse場景中，StarRocks的聯(lián)合查詢，不但屏蔽了底層數(shù)據(jù)源的細節(jié)，而且可以對異構(gòu)數(shù)據(jù)據(jù)源數(shù)據(jù)聯(lián)合分析，與增量數(shù)據(jù)湖格式完美結(jié)合。為了提升查詢速度，StarRocks對每種數(shù)據(jù)源，進行針對性優(yōu)化。增強了向量化解析ORC、Parquet格式，字典過濾，延遲物化等能力。

StarRocks除了極致的引擎性能和全場景優(yōu)化的能力，它還實現(xiàn)了彈性伸縮，支持在線擴容，讓運維變得簡單。面對流量增長，用戶不但可以按需伸縮，節(jié)省成本。StarRocks還支持小規(guī)模初始集群的逐步擴容，大大節(jié)省了運維成本。

05

Trino介紹
 如下圖所示，EMR的數(shù)據(jù)湖架構(gòu)以O(shè)SS和HDFS作為數(shù)據(jù)湖的存儲層。在存儲層的基礎(chǔ)上，精心安裝了存儲優(yōu)化器，主要是JindoFS和ALLUXIO系列。在存儲格式方面，EMR的數(shù)據(jù)湖支持Hudi,Iceberg和ORC等格式。在計算層，它支持多種計算，比如Flink,SPARK,Trino和Hive等等。


接下來，我們看看EMR Trino的特性。

首先在穩(wěn)定向方面，EMR Trino支持內(nèi)置Coordinator HA赫爾Worker Label功能。由于EMR Trino集成了EMR彈性伸縮的能力，并且支持Trino on K8s產(chǎn)品形態(tài)，所以它大大節(jié)省了運維成本。在生態(tài)方面，EMR Trino不但支持Iceberg、Hudi、Delta Connector等云上生態(tài)，而且支持優(yōu)化的ClickHouse、Hive等Connector。在性能方面，EMR Trino針對Parquet/Orc等格式，進行優(yōu)化。并且利用JindoFS的緩存層加速數(shù)據(jù)湖查詢。大幅提升了查詢效率。

06

客戶案例

最后，我們一起聊幾個客戶案例。如上圖所示，這是一家在線教育客戶。它每天的數(shù)據(jù)量高達幾十億條，同時還存在訂單數(shù)據(jù)變更，特征人群圈選，機器學習訓練等需求。原有的解決方案，存在數(shù)據(jù)處理不及時，無法應(yīng)對Upsert場景，并且拉鏈表笨拙，耗費資源大。經(jīng)過改造之后，完美支持Upsert場景，Presto可以查詢明細數(shù)據(jù)，CK的寬表數(shù)也可供Ad-hoc查詢，CK的物化視圖供BI系統(tǒng)查詢。

上圖是社交領(lǐng)域客戶的架構(gòu)圖。它每天有5TB的數(shù)據(jù)規(guī)模，需要支持實時大屏，業(yè)務(wù)系統(tǒng)點查和業(yè)務(wù)人員隨機查詢。在改造之前，Hive是分鐘級數(shù)倉，它面臨算不完，查不出，系統(tǒng)運維復(fù)雜的痛點。我們將寬表查詢落入CK和Ad-hoc查詢，將明細表落入StarRocks，實現(xiàn)了復(fù)雜Ad-hoc查詢，報表分析，物化視圖點查能力。讓數(shù)據(jù)倉庫的運維變得簡單高效。

上圖是某電商領(lǐng)域的客戶，它的大量業(yè)務(wù)依賴OLTP系統(tǒng)，在GMV，訂單，物流，客戶分析，推薦系統(tǒng)等方面，都有升級的需求。原先的Hadoop數(shù)倉和離線T+1分析系統(tǒng)的方式，讓整個系統(tǒng)運維復(fù)雜，成本居高不下。我們將OLTP系統(tǒng)逐步過渡到OLAP系統(tǒng)，替代了原有數(shù)倉結(jié)構(gòu)的同時，讓鏈路變得極其簡化，讓Ad-hoc查詢靈活，方便運維人員分析細節(jié)數(shù)據(jù)，對接線上系統(tǒng)點查。簡化系統(tǒng)的同時，提升了運維人員的工作效率，大幅降低了運維成本。

作者：夢想家 Alex


歡迎關(guān)注：大數(shù)據(jù)夢想家