一、背景介紹

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

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

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

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

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

二、挑戰與融合分析引擎的解法?

回到前文提到的挑戰，即以卓越的性能直接訪問明細數據，我們會從融合、內核優化和加速三個方面發力。

1、融合

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

① 多源融合前端 

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

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

② 融合后端?

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

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

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

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

③  WLM（Workload Management）?

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

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

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

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

2、內核優化

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

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

① Impala?

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

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

② Presto

云架構 Presto 在大規模集群下如何保持高效的 Scalabaility Coordinator 單點問題是一個公認的挑戰，這部分優化并非我們獨創，而是業界的一個 feature。

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

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

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

③ Kudu?

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

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

3、加速

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

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

① 緩存?

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

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

② BI Engine?

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

③ 現代的物化視圖?

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

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

三、實踐總結?

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

四、未來演進方向

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

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