一、背景介紹

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

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

下圖展示了燈塔融合分析引擎的整體技術架構：

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

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

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

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

1、融合

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

① 多源融合前端 

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

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

② 融合后端?

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

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

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

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

③  WLM（Workload Management）?

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

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

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

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

2、內核優(yōu)化

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

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

① Impala?

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

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

② Presto

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

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

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

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

③ Kudu?

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

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

3、加速

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

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

① 緩存?

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

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

② BI Engine?

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

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

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

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

三、實踐總結?

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

四、未來演進方向

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

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