一、背景介紹

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

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

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

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

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

1、融合

同類產(chǎn)品的思路多為一體化，而本文的思路是取長(zhǎng)補(bǔ)短，博采眾長(zhǎng)，融合開(kāi)源社區(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)過(guò) Parse、Validate、Optimizer、Planner，通過(guò)自建的統(tǒng)一元數(shù)據(jù)管理中心來(lái)提供了運(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)存不足，無(wú)法提高計(jì)算并行度；Clickhouse 數(shù)據(jù)源面臨復(fù)雜查詢效率低等問(wèn)題。

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

• 通用 MPP 引擎（Presto\Impala）加上高性能 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è)引擎如何融合和配合的問(wèn)題，除此之外是端到端的分析策略中心的實(shí)現(xiàn)。裸用開(kāi)源引擎存在以下問(wèn)題：

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

本設(shè)計(jì)的解決方案是通過(guò)自研的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ò)一系列的規(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)來(lái)就會(huì)有比較好的規(guī)劃。

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

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

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

① Impala?

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

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

② Presto

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

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

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

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

③ Kudu?

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

在一次實(shí)際生產(chǎn) Case 中，幾十萬(wàn) Tablet，占用內(nèi)存 50G 以上，Master 啟動(dòng)和Leader 切換都非慢。經(jīng)排查，集群一直在加載元數(shù)據(jù)，并發(fā)現(xiàn)以前刪除的表和數(shù)據(jù)集群還在維護(hù)。通過(guò)源碼級(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í)際場(chǎng)景中經(jīng)常會(huì)遇到重復(fù)的查詢，我們需要解決如何通過(guò)多級(jí)緩存機(jī)制避免“硬查”集群，加速“SQL 內(nèi)”的數(shù)據(jù)掃描性能。該引擎的緩存設(shè)計(jì)借鑒了 Databrick 的內(nèi)核緩存、Snowflake 的數(shù)倉(cāng)緩存的緩存設(shè)計(jì)理念，研發(fā)了預(yù)計(jì)算與多級(jí)緩存的技術(shù)。

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

② BI Engine?

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

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

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

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

三、實(shí)踐總結(jié)?

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

四、未來(lái)演進(jìn)方向

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

今天的分享就到這里，謝謝大家。