開源大數據 OLAP 引擎最佳實踐
導讀： 本篇內容將通過如下六部分來介紹開源大數據 OLAP 引擎最佳實踐。
一、開源 OLAP 綜述
二、開源數倉解決方案
三、ClickHouse 介紹
四、StarRocks 介紹
五、Trino 介紹
六、客戶案例
01 開源 OLAP 綜述
如今的開源數據引擎多種多樣，不同種類的引擎滿足了我們不同的需求。現在 ROLAP 計算存儲一體的數據倉庫主要有三種，即 StarRocks(DorisDB)，ClickHouse 和 Apache Doris。應用最廣的數據查詢系統主要有 Druid，Kylin 和 HBase。MPP 引擎主要有 Trino，PrestoDB 和 Impala。這些引擎在行業內有着廣泛的應用。
圖：EMR 的整體架構
02 開源數倉解決方案
接下來，我們講講開源大數據以及數倉的解決方案。上圖是 EMR 的整體架構，在雲資源層，主要有 ECS。在存儲層的 JindoFS 提供了以 OSS 爲基底的 Hadoop 接口，不但節約了成本，而且提升了整體的擴展性。數據湖格式有效解決了數據統一管理的難題。其次在計算引擎方面，它具有批處理，流式計算，機器學習和引擎加速等能力。
目前，大家應用最多的離線數倉體系是 Lambda 架構。該架構主要分爲兩個部分。
第一部分，在實時方面我們從 CDC,ORTP 的數據源開始，進行行爲數據分析，然後通過 Kafka，Flink 進行加工。讓數據在線系統，可以直接調用 API，提升點查效率。其次，當所有聚合的數都導入 Olap 系統時，運營人員可以快速用它，實現自己新的想法，提升工作效率。
第二部分，在離線方面當需要長久保存數據時，大家都會使用 hive。如果沒有增量數據庫格式，大家一般通過 insert overwrite，在 detail 上做一些數據集市。除此之外，我們通過離線 t+1 的方式，實現離線數倉的實時數據訂正。因爲實時數據一般得出的是近似值，離線數據得到的是準確值。
第三部分，實時數據湖的解決方案，其數據量在 PB + 級別。我們希望統一離線和實時數倉，用一套代碼構建業務。數據湖的數據存儲在 OSS/HDFS，由於我們的部分業務有 Upsert 變更需求，所以我們希望建設分鐘級到小時級的數倉。能夠將最熱的數據導入 StarRocks/CK，OLAP 的查詢時長保證在 500 毫秒到 2 秒之間。與此同時，我們利用 Presto 查詢 Hudi/Iceberg/Delta 時，其速率能夠保證在 5 秒至 30 秒之間。
上圖是比較傳統的實時數倉方案。當每天增量數據達到 10TB+，我們希望直接以單軟件構建業務底座，讓數據先存儲在 CK/StarRocks，讓冷數據轉存到 OSS。不必再運維 Hadoop 的龐大體系，極大簡化運維操作，可以媲美全託管。
第二種實時數倉的解決方案，我們通過 micro-batch 任務調度器去處理 DWS，DWD 和 ODS。其實時性非常強，極大簡化了開發效率，數據的一致性最高。後續我們將推出存算分離方案，用 OSS 存儲海量數據，用 Cache 加速熱數據。
03 ClickHouse 介紹
ClickHouse 是面向聯機分析處理（OLAP）的開源分析引擎。最初由俄羅斯第一搜索引擎 Yandex 開發，於 2016 年開源，開發語言爲 C++。由於其優良的查詢性能，PB 級的數據規模，簡單的架構，在國內外公司被廣泛採用。
它是列存數據庫，具有完備的 DBMS 功能，備份列式存儲和數據壓縮。它的 MPP 架構易於擴展，易於維護。除此之外，它支持向量化的查詢，完善的 SQL 以及實時的數據更新，查詢速度可以達到亞秒級的響應。
那麼 ClickHouse 的查詢速度爲什麼會這麼快呢？它類似於 LSM tree, 所有數據都是經過有序排列，提前做好聚合計算，再存儲。並且它的數據存儲格式自帶索引。
其次，ClickHouse 可以基於多個 Key 創建索引。它的二級索引採用 Data skipping index。
ClickHouse 的應用場景主要有四個方面。
第一，用戶行爲分析。ClickHouse 將用戶行爲分析表製作成一張大的寬表，減少 join 的形式，實現路徑分析、漏斗分析、路徑轉化等功能。除此之外，它還能支撐廣告，營銷和 AB 實驗。
第二，實時 BI 報表。ClickHouse 可以根據業務需求，實時製作及時產出，查詢靈活的 BI 報表，包括訂單分析，營銷效果分析，大促活動分析等等。
第三，監控。ClickHouse 可以將系統和應用監控指標通過流式計算引擎 Flink,Spark streaming 清洗處理以後，實時寫入 ClickHouse。結合 Grafna 進行可視化展示。
第四，用戶畫像。ClickHouse 可以對各種用戶特徵進行數據加工，製作成包含全部用戶的一張或多張用戶特徵表，提供靈活的用戶畫像分析，支撐廣告，圈人等業務需求等等。
接下來，我們講講 EMR ClickHouse 架構。我們在 ClickHouse 的基礎上做了一定的增強。首先，我們重構了 In Memory Part 寫入模塊，讓它支持 Flink 單條寫入，Flink Exactly Once 事務寫入以及 Sharding Key 寫入。成功解決了寫 Distributed 表的痛點，提升了整體性能。其次，它還支持 DiskOSS。實現了冷熱的分層存儲，節約了成本。最後，我們實現了副本擴容和分片擴容，讓擴容方式變得更靈活。
04 StarRocks 介紹
接下來，我們聊一聊 StarRocks。StarRocks 其向量化的執行引擎，實現了亞秒級查詢延時。StarRocks 單節點 100M / 秒的寫入速度，讓它每秒可處理 100 億行數據。StarRocks 的綜合查詢速度比其他產品快 10 到 100 倍。數據秒級實時更新可見。其次，StarRocks 支持數千用戶同時分析，部分場景每秒可支持 1 萬以上的 QPS，TP99 控制在 1 秒以內。最後，StarRocks 基於多種數據模型，實現了極速分析，縮短業務交付時間。提升了數據工程師和分析師工作效率。
如上圖所示，StarRocks 的架構簡潔明瞭，兼容 MySQL 協議，可使用各類 MySQL 客戶端。並且支持 FE、BE 的水平擴展，從而實現自動均衡。讓運維和使用都非常方便。
StarRocks 的極速引擎，實現了全面向量化執行。它可以按列存儲，按列計算。用更少的虛函數調用，更少的分支判斷，更好地利用 SIMD 指令並且對 CPU Cache 更友好。其次，StarRocks 向量化提升的效果明顯。向量化 Filter，向量化聚合和向量化 Shuffle Join 的效果都有幾何倍數的提升。
StarRocks 的極速引擎，具有全新的 CBO。基於 Orca 論文，將表達式重寫、表達式複用。用公共謂詞提取、謂詞推導。將子查詢改寫，調整 Join 順序、讓 Join 算法自動選擇。成功的將 SQL 語句轉化爲一個可執行 Plan。
StarRocks 的極速引擎，具有多種分佈式的 Join。目前，這種分佈式 Join 是 ClickHouse 比較缺乏的功能。右圖是更加高效的 Join 方式，它通過提前完成 bucket 分類，讓整體運行更加高效。
StarRocks 爲全場景提供了四種數據模型。
第一，明細模型。用於保存和分析原始明細數據，數據寫入後幾乎無更新。主要用於日誌，操作記錄，設備狀態採樣等等。
第二，聚合模型。用於保存，分析，彙總數據。不需要查詢明細數據。數據導入後實時完成聚合，數據寫入後幾乎無更新。適用於按時間、地域、機構彙總的數據。
第三，主鍵模型。支持基於主鍵的更新，Delete and insert，大批量導入時保證高性能查詢。用於保存和分析需要更新的數據。
第四，更新模型。支持基於主鍵的更新，Merge On Read，更新頻率比主鍵模型更高。用於保存和分析需要更新的數據。主鍵模型和更新模型都適用於狀態會發生變動的訂單，設備狀態等。
StarRocks 在全場景中，還實現了高併發的查詢。StarRocks 的分區機制可以高效過濾，提升查詢性能。StarRocks 的分桶機制充分發揮了集羣的性能，成功避免了熱點問題。但 StarRocks 相對於其他的 OLAP 引擎和行存的 OLTP 引擎還有一定的差距。
在 LakeHouse 場景中，StarRocks 的聯合查詢，不但屏蔽了底層數據源的細節，而且可以對異構數據據源數據聯合分析，與增量數據湖格式完美結合。爲了提升查詢速度，StarRocks 對每種數據源，進行鍼對性優化。增強了向量化解析 ORC、Parquet 格式，字典過濾，延遲物化等能力。
StarRocks 除了極致的引擎性能和全場景優化的能力，它還實現了彈性伸縮，支持在線擴容，讓運維變得簡單。面對流量增長，用戶不但可以按需伸縮，節省成本。StarRocks 還支持小規模初始集羣的逐步擴容，大大節省了運維成本。
05 Tino 介紹
如上圖所示，EMR 的數據湖架構以 OSS 和 HDFS 作爲數據湖的存儲層。在存儲層的基礎上，精心安裝了存儲優化器，主要是 JindoFS 和 ALLUXIO 系列。在存儲格式方面，EMR 的數據湖支持 Hudi,Iceberg 和 ORC 等格式。在計算層，它支持多種計算，比如 Flink,SPARK,Trino 和 Hive 等等。
接下來，我們看看 EMR Trino 的特性。首先在穩定向方面，EMR Trino 支持內置 Coordinator HA 赫爾 Worker Label 功能。由於 EMR Trino 集成了 EMR 彈性伸縮的能力，並且支持 Trino on K8s 產品形態，所以它大大節省了運維成本。在生態方面，EMR Trino 不但支持 Iceberg、Hudi、Delta Connector 等雲上生態，而且支持優化的 ClickHouse、Hive 等 Connector。在性能方面，EMR Trino 針對 Parquet/Orc 等格式，進行優化。並且利用 JindoFS 的緩存層加速數據湖查詢。大幅提升了查詢效率。
06 客戶案例
最後，我們一起聊幾個客戶案例。如上所示，這是一家在線教育客戶。它每天的數據量高達幾十億條，同時還存在訂單數據變更，特徵人羣圈選，機器學習訓練等需求。原有的解決方案，存在數據處理不及時，無法應對 Upsert 場景，並且拉鍊表笨拙，耗費資源大。經過改造之後，完美支持 Upsert 場景，Presto 可以查詢明細數據，CK 的寬表數也可供 Ad-hoc 查詢，CK 的物化視圖供 BI 系統查詢。
上圖是社交領域客戶的架構圖。它每天有 5TB 的數據規模，需要支持實時大屏，業務系統點查和業務人員隨機查詢。在改造之前，Hive 是分鐘級數倉，它面臨算不完，查不出，系統運維複雜的痛點。我們將寬表查詢落入 CK 和 Ad-hoc 查詢，將明細表落入 StarRocks，實現了複雜 Ad-hoc 查詢，報表分析，物化視圖點查能力。讓數據倉庫的運維變得簡單高效。
上圖是某電商領域的客戶，它的大量業務依賴 OLTP 系統，在 GMV，訂單，物流，客戶分析，推薦系統等方面，都有升級的需求。原先的 Hadoop 數倉和離線 T+1 分析系統的方式，讓整個系統運維複雜，成本居高不下。我們將 OLTP 系統逐步過渡到 OLAP 系統，替代了原有數倉結構的同時，讓鏈路變得極其簡化，讓 Ad-hoc 查詢靈活，方便運維人員分析細節數據，對接線上系統點查。簡化系統的同時，提升了運維人員的工作效率，大幅降低了運維成本。
來源：阿里巴巴大數據計算
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CQO4KyqzkWTjlNscMqGo8g