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

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

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

01

背景介紹

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

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

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

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

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

02

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

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

1. 融合

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

① 多源融合前端

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

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

② 融合后端

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

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

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

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

③ WLM（Workload Management）

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

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

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

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

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

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

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

① Impala

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

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

② Presto

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

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

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

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

③ Kudu

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

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

3. 加速

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

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

① 緩存

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

• 預(yù)計(jì)算（固定圖卡）：通過“增量緩存”只刷最新天數(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）：通過對(duì)歷史 SQL 性能數(shù)據(jù)分析，緩存熱表（如大左表）。

② BI Engine

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

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

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

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

03

實(shí)踐總結(jié)

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

04

未來演進(jìn)方向

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

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