騰訊燈塔融合引擎的設(shè)計與實踐

本次分享的主題是騰訊燈塔融合引擎的設(shè)計與實踐，主要圍繞以下四個方面進(jìn)行介紹：

• 1. 背景介紹
• 2. 挑戰(zhàn)與融合分析引擎的解法
• 3. 實踐總結(jié)
• 4. 未來演進(jìn)方向

01

背景介紹

騰訊燈塔是一款端到端的全鏈路數(shù)據(jù)產(chǎn)品套件，旨在幫助產(chǎn)品、研發(fā)、運營和數(shù)據(jù)科學(xué)團隊 30 分鐘內(nèi)做出更可信及時的決策，促進(jìn)用戶增長和留存。

2020 年后數(shù)據(jù)量仍然呈爆炸性增長的趨勢，且業(yè)務(wù)變化更加迅速、分析需求更加復(fù)雜，傳統(tǒng)的模式無法投入更多的時間來規(guī)劃數(shù)據(jù)模型。我們面臨一個海量、實時和自定義的三角難題。不同引擎都在致力于去解決這個問題。谷歌等博客中曾提到，也是我們很認(rèn)可的一個觀點是以卓越的性能可直接訪問明細(xì)數(shù)據(jù)（ODS/DWD）成為下一代計算引擎的必然趨勢。

下圖展示了燈塔融合分析引擎的整體技術(shù)架構(gòu)：

左側(cè)對接應(yīng)用系統(tǒng)，包括燈塔自己提供的分析模型、可視化方案和一些 API 請求；右側(cè)為融合分析引擎，包括查詢引擎層、計算層、物化存儲層、存儲層分析策略中心和產(chǎn)品化中心。

• 服務(wù)層，包括查詢、接收以及治理，比如任務(wù)級別的緩存攔截等服務(wù)相關(guān)功能。
• 計算層，不同于其他公司的自研方案，我們是在開源能力之上做增強和整合，來滿足不同場景的需求。
• 物化存儲層，其中包含了我們構(gòu)建現(xiàn)代物化視圖的解決方案，實現(xiàn)了基于 Alluxio 的塊級別緩存池，以及針對 BI 場景基于 Clickhouse 的抽取加速方案。
• 存儲層，對接了多種存儲引擎，包括托管給燈塔的存儲層和非托管的存儲層，即業(yè)務(wù)方自己的數(shù)據(jù)。
• 分析策略中心，位于上述四層之上。主要負(fù)責(zé)業(yè)務(wù)方查詢的工作負(fù)載中的治理和理解執(zhí)行的整體鏈路。從一個任務(wù)開始執(zhí)行，到執(zhí)行計劃的各個階段的計算的資源消耗、存儲的消耗、效率等表征作統(tǒng)一存儲，并基于這些明細(xì)的數(shù)據(jù)抽出來一些衍生的指標(biāo)，以推動任務(wù)優(yōu)化，比如物化模型的構(gòu)建和 SQL 自動優(yōu)化，旨在端到端地解決這些問題。
• 產(chǎn)品化中心，除了燈塔產(chǎn)品套件整體作為產(chǎn)品對外輸出以外，融合分析引擎也可以單獨作為產(chǎn)品對外輸出。

02

挑戰(zhàn)與融合分析引擎的解法

回到前文提到的挑戰(zhàn)，即以卓越的性能直接訪問明細(xì)數(shù)據(jù)，我們會從融合、內(nèi)核優(yōu)化和加速三個方面發(fā)力。

1. 融合

同類產(chǎn)品的思路多為一體化，而本文的思路是取長補短，博采眾長，融合開源社區(qū)的能力實現(xiàn) 1+1>2 的效果。

① 多源融合前端

前端聚焦于提供集中化的 SQL 解析、優(yōu)化和執(zhí)行計劃生成。它更多的承擔(dān)的是對各個底層的理解以做出更優(yōu)邏輯執(zhí)行計劃的角色。

前端是基于 Calcite 的兩段式。第一段為常規(guī)操作，一個 SQL 要經(jīng)過 Parse、Validate、Optimizer、Planner，通過自建的統(tǒng)一元數(shù)據(jù)管理中心來提供了運行時的Catalog和統(tǒng)計信息以輔助生成更優(yōu)的執(zhí)行計劃；第二段為不同引擎的融合，提供統(tǒng)一的對外接口且進(jìn)行一些定制化的增強。

② 融合后端

前端主要解決的是 SQL 解析和執(zhí)行計劃的生成優(yōu)化，融合后端真正解決計算層面融合。

RDBMS面臨算力、內(nèi)存不足，無法提高計算并行度；Clickhouse 數(shù)據(jù)源面臨復(fù)雜查詢效率低等問題。

針對上述問題分別有以下解決方案：

• 通用 MPP 引擎（PrestoImpala）加上高性能 connector。
• 增強版 JDBC Connection，基于Mysql表模型對 Split Providers 進(jìn)行自適應(yīng)的優(yōu)化，將單個 Table Scan 轉(zhuǎn)換為多個 Table Scan 以提升計算效率。
• 針對 Clickhouse 數(shù)據(jù)源會將分布式表運算改為基于本地表運算。
• 對 Projection、Aggregation、Predicate 操作進(jìn)行下推。

③ WLM（Workload Management）

前端和后端解決的是多個引擎如何融合和配合的問題，除此之外是端到端的分析策略中心的實現(xiàn)。裸用開源引擎存在以下問題：

• 引擎 Profile 指標(biāo)無持久化，單點分析粒度太細(xì)，無法對租戶整體進(jìn)行洞察；
• 對運維人員要求高，需要足夠的工作負(fù)載的洞察與優(yōu)化的能力。

本設(shè)計的解決方案是通過自研的WLM（Workload Management），自動化收集不同引擎的 Query Profile 并結(jié)合歷史查詢給出基于專家經(jīng)驗給出優(yōu)化建議，在策略中心基于優(yōu)化建議自動設(shè)置 Query Options、Hints 等優(yōu)化配置。

通過一系列的規(guī)則探查到這個 SQL 會存在大量的 Shuffle，會導(dǎo)致占用了大量的內(nèi)存和網(wǎng)絡(luò)資源。該裝置會注入一些 Query Options 和 Hints，比如把它的 broadcast 換成 shuffle join，對于一些 CPU 優(yōu)化器完成不了的事情基于我們的策略做一個自動優(yōu)化，等 SQL 再進(jìn)來就會有比較好的規(guī)劃。

2. 內(nèi)核優(yōu)化

在商業(yè)場景下經(jīng)常會遇到很消耗資源量的大查詢，如何能夠在運行時識別和隔離大查詢成為一個挑戰(zhàn)。

查詢在運行前是無法斷定其查詢對資源的影響的，比如兩表 JION 后笛卡爾積的導(dǎo)致其輸出有上萬億記錄數(shù)的規(guī)模。于是本引擎在收集監(jiān)控運行時的指標(biāo)參數(shù)，結(jié)合負(fù)載中心的優(yōu)化建議，自動設(shè)置優(yōu)化參數(shù)，以使得查詢更高效的運行；對于無法優(yōu)化且識別對資源使用有嚴(yán)重影響的查詢，會進(jìn)行攔截，及時止損。

① Impala

Impala 面臨的一個挑戰(zhàn)是如何充分利用計算引擎的索引加速。

• 引擎 IO 調(diào)度內(nèi)核優(yōu)化，比如局部性的同文件多 DataRange 排序；通過調(diào)整權(quán)重以實現(xiàn)大查詢 IO 懲罰，因為有些場景更多想保小查詢，將大查詢放到慢車道。
• 存儲特性價值發(fā)揮-索引（Pageindex、Zorder、Hillbert）。要高效查詢原始數(shù)據(jù)，就需要利用好原始數(shù)據(jù)中的索引，比如 Parquet 中的數(shù)據(jù)頁 Page Index，可以結(jié)合原始存儲數(shù)據(jù)中的索引信息，在運行時進(jìn)行數(shù)據(jù)過濾。如果要達(dá)到很高的效率，往往不是算法本身，而是底層的數(shù)據(jù)分布。比如一個謂詞的列都是隨機分布，那么一個值分布在每個數(shù)據(jù)頁，就無法進(jìn)行跳過，我們會通過負(fù)載中心查看歷史查詢?nèi)?yōu)化 Zorder 或者 Hillbert 索引。

② Presto

云架構(gòu) Presto 在大規(guī)模集群下如何保持高效的 Scalabaility Coordinator 單點問題是一個公認(rèn)的挑戰(zhàn)，這部分優(yōu)化并非我們獨創(chuàng)，而是業(yè)界的一個 feature。

第一種方案是 Coordinator HA 方案，但其并沒有從根源解決問題，一旦 Active 節(jié)點失活，過不久 stand by 節(jié)點也會掛掉。

第二種方案是多 Cluster 聯(lián)邦方案，部署多個集群，通過 Presto Gateway 路由不同的集群。但是路由策略管理是一個很大的難點，如果路由策略不當(dāng)會帶來嚴(yán)重的資源碎片化。

第三種方案是 Disaggregated Coordinator 方案，引入了 ResouceManager 聚合分布式資源狀態(tài)，每個 RM 內(nèi)存中維護一份狀態(tài)數(shù)據(jù)，RM 之間通過心跳達(dá)成狀態(tài)數(shù)據(jù)的最終一致。Coordinator 可以正常的 Parse、Validate、Plan，準(zhǔn)入時 RM 統(tǒng)一獲取資源視圖，判斷是執(zhí)行還是等待等狀態(tài)。

③ Kudu

這是一個不常見的問題，在一個運行很久的大集群，有一臺機器要裁撤，由于大集群長時間運行元信息負(fù)債嚴(yán)重，導(dǎo)致 Tablet Server 無法優(yōu)雅下線（需要重啟 master），耗時可能高達(dá)幾小時。

在一次實際生產(chǎn) Case 中，幾十萬 Tablet，占用內(nèi)存 50G 以上，Master 啟動和Leader 切換都非慢。經(jīng)排查，集群一直在加載元數(shù)據(jù)，并發(fā)現(xiàn)以前刪除的表和數(shù)據(jù)集群還在維護。通過源碼級別的增強，Master 內(nèi)存消耗降低 10 倍。

3. 加速

考慮到集群的算力和引擎本身的瓶頸上限，除了融合和內(nèi)核優(yōu)化，我們還需要做各種各樣的加速手段。

除了引擎優(yōu)化，Databrick 商業(yè)版的 OLAP 引擎添加了緩存層和索引層；Snowflake 支持了物化視圖的能力；Google 的 BigQuery 提供了多級緩存，以進(jìn)一步的加速。緩存、計算優(yōu)化、索引與數(shù)據(jù)分布、物化、云化是業(yè)界的主攻方向，本次分享主要介紹三種手段。

① 緩存

實際場景中經(jīng)常會遇到重復(fù)的查詢，我們需要解決如何通過多級緩存機制避免“硬查”集群，加速“SQL 內(nèi)”的數(shù)據(jù)掃描性能。該引擎的緩存設(shè)計借鑒了 Databrick 的內(nèi)核緩存、Snowflake 的數(shù)倉緩存的緩存設(shè)計理念，研發(fā)了預(yù)計算與多級緩存的技術(shù)。

• 預(yù)計算（固定圖卡）：通過“增量緩存”只刷最新天數(shù)據(jù)，避免大量數(shù)據(jù)掃描
• 統(tǒng)一緩存（重復(fù)查詢判+非固定圖卡緩存）：深耕 Calcite 源碼，基于 SQL 常量折疊（變更檢測）、SQL改寫、SQL規(guī)則判斷。
• 內(nèi)核緩存（大 SQL 內(nèi)存緩存）：通過遠(yuǎn)程告訴緩存+SQL磁盤溢寫緩存(Alluxio)，加速大查詢，減輕 HDFS IO 壓力。
• Alluxio（HDFS 熱數(shù)據(jù)緩存->SSD）：通過對歷史 SQL 性能數(shù)據(jù)分析，緩存熱表（如大左表）。

② BI Engine

由于 BI 場景不用其他的查詢分析場景，BI 場景下的看板對出數(shù)的時延要求很高，所以需要 BI 場景進(jìn)行了特殊的優(yōu)化。借鑒以 BigQuery 為例，它是有一塊單獨的內(nèi)存池，它會根據(jù)歷史查詢判斷出熱數(shù)據(jù)并以列式的緩存下來。該引擎除了使用到上述的默認(rèn)策略，還會添加一個 Clickhouse 的緩存層，基于歷史記錄判斷那些數(shù)據(jù)是可加速并透明的將可加速的表移動到 Clickhouse 中作為緩存數(shù)據(jù)。這一整套策略可以讓億級數(shù)據(jù)運行至毫秒級。

③ 現(xiàn)代的物化視圖

如何更高效利用好物化視圖面臨著三個問題：如何達(dá)到用最少成本達(dá)到最高性能；如何低成本維護好物化視圖；查詢時，在不改變查詢語句的前提下如何將查詢路由到不同的物化視圖? 現(xiàn)代物化視圖就是在致力于解決上述三個問題。

• 如何達(dá)到用最少成本達(dá)到最高性能? 一般方案是做一些領(lǐng)域?qū)＜夷Ｐ?。但是對于這樣一個平臺化的產(chǎn)品是無法做到這一點的， 因為業(yè)務(wù)方才是最了解業(yè)務(wù)的。所以該產(chǎn)品可以依賴端到端的負(fù)載中心去歷史查詢記錄來找到最大的公共子查詢來自動的實現(xiàn)物化視圖。同時，還會做一些其他的優(yōu)化，比如添加相應(yīng)的索引或者 Zorderhillbert 排序。
• 如何低成本維護好物化視圖? 增量刷新物化視圖，并通過負(fù)載中心來分析歷史查詢物化視圖是否起到加速的效果，刪除加速效果較差的物化視圖。
• 查詢時，在不改變查詢語句的前提下如何將查詢路由到不同的物化視圖? 通過基于 Calcite 的自動改寫功能，用戶不需要修改原有的 SQL 語句，SQL 會透明地路由到不同的物化視圖。

03

實踐總結(jié)

燈塔融合分析引擎，在 SQL、計算和存儲三個技術(shù)領(lǐng)域，做了很多的技術(shù)創(chuàng)新和沉淀。下圖列出了重要的優(yōu)化點。

04

未來演進(jìn)方向

我們未來將繼續(xù)致力于從融合、內(nèi)核優(yōu)化和加速三個方向，解決“以卓越性能直接訪問數(shù)據(jù)”的問題。

作者 | 馮國敬 騰訊 后臺開發(fā)工程師 ，2013年畢業(yè)于哈爾濱工業(yè)大學(xué)，一直從事大數(shù)據(jù)領(lǐng)域研發(fā)工作，目前在騰訊燈塔負(fù)責(zé)融合分析引擎的研發(fā)。