1-2 基于歷史查詢的 Impala 集群性能優化實踐.pdf

《1-2 基于歷史查詢的 Impala 集群性能優化實踐.pdf》由會員分享，可在線閱讀，更多相關《1-2 基于歷史查詢的 Impala 集群性能優化實踐.pdf（36頁珍藏版）》請在三個皮匠報告上搜索。

1、基于歷史查詢的IMPALA集群性能優化實踐溫正湖 網易數帆-數倉技術負責人|01高性能數倉建設高性能數倉建設介紹網易大數據及高性能數倉建設方案03HBO優化實踐優化實踐介紹HBO在網易云音樂等業務場景使用實踐02HBO實現方案實現方案介紹管理服務器實現和基于歷史查詢的集群優化04未來發展計劃未來發展計劃介紹未來一段時間Impala和產品化的開發計劃目錄目錄 CONTENT|關于網易數帆 網易數帆源自網易杭州研究院，是網易數字經濟的創新載體和技術孵化器，致力于成為領先的數字化轉型技術與服務提供商，為企業數字化轉型提供技術動力。依托網易集團二十余年互聯網技術積累，網易數帆聚合云計算、大數據、人工智

2、能等新型數字化技術，聚焦提供開放、穩定、安全、高效的數據智能、軟件研發、基礎設施與中間件等基礎軟件，致力于幫助企業客戶成功實現數字化轉型。云原生軟件生產力平臺云原生軟件生產力平臺全鏈路大數據生產力平臺全鏈路大數據生產力平臺多媒體智能開放平臺多媒體智能開放平臺全維度質量效能平臺全維度質量效能平臺網易數帆：網易旗下數字化轉型技術與服務提供商網易數帆：網易旗下數字化轉型技術與服務提供商網易有數網易有數華夏銀行音樂電商教育傳媒辦公郵箱物流農業零售金融教育能源工具產品平臺公共數據建設數據建設方法論制造醫藥記憶科技網易有數-Impala的定位交互式查詢：Impala批處理引擎：Spark+Kyuubi流計

3、算引擎：Flink/Sloth網易有數-Impala主要應用場景高性能數倉建設高性能數倉建設01|業務使用痛點分析|BI報表、Ad-Hoc、自助分析、取數和數據抽取共存時的SLA保障BI報表類業務追求實時性要求高，用戶耐受程度不超過5秒查詢的資源消耗預估不準確，執行計劃不合理，如大表廣播等元數據過舊導致查詢出錯，元數據未緩存導致查詢性能下降HDFS NN波動導致文件句柄打開性能，DN波動導致數據掃描耗時變長隨著業務的發展和新場景的引入，集群的SLA和性能變差，需反復治理高性能數倉-建設原則|收集和持久化impala歷史查詢信息，制作標準化圖表進行可視化展示 多維度分析查詢規律并進行基于歷史查詢

4、的優化HBO（History-based Optimization）更高的性能，更強的功能：版本升級、執行引擎增強、物化視圖、虛擬數倉、數據緩存等 更好的產品化體驗：元數據同步、集群管理自動化、集群信息可視化和可獲得性等高性能數倉-建設原則|為有數BI報告的“數據醫生”功能提供性能診斷數據 有數BI等組件通過SQL注解，反哺Impala進行更智能的查詢分析 將物化視圖能力集成到有數產品上 訂閱和消費大數據血緣的數據產出消息，驅動統計信息計算、物化視圖更新等 訂閱和消費Hive Metastore（HMS）的DDL日志，驅動元數據同步、物化視圖更新等 依托網易大數據NDH（Netease Dat

5、a Hub）進行存儲優化，Z-Order、Page Index等高性能數倉-業務痛點解決方案|引入虛擬數倉虛擬數倉（virtual warehouse）對業務進行物理資源隔離 提供基于zookeeper namespace和基于query option的虛擬數倉路由 通過impalad多group name和coordinator多zk namespace來提高資源利用效率增強本地緩存本地緩存能力 優化DataCache性能和使用范圍：LIRS算法、異步CacheFill、重啟可用等 調優和擴大FileHandleCache來提高文件句柄緩存命中率提供統計信息自動計算統計信息自動計算能力 通過

6、分析歷史查詢summary日志輸出待計算的表到配置可動態更新的白名單 通過數據產出消息、定時和DDL日志驅動統計信息計算高性能數倉-業務痛點解決方案|提升計算能力，使用預計算技術 升級Impala版本，提高性能基線 通過MT-DOP，服務器多節點部署提高計算資源利用效率 通過支持多表物化視圖多表物化視圖和透明改寫技術提升查詢性能支持緩存自動更新和異步加載 通過訂閱HMS的DDL變更日志，高效驅動元數據緩存自動同步元數據緩存自動同步 通過配置動態白名單，對失效的緩存進行異步加載異步加載建立Impala集群標準化報表 統計集群每天的負載指標負載指標，包括查詢量、耗時、資源消耗等 使用可視化報表（有

7、數BI產品）進行直觀展示直觀展示 多維度分析負載指標的隨時間變化趨勢變化趨勢并作出相應決策HBO實現方案實現方案02|HBO信息來源-Impala管理服務器|1.1開啟enable_manager參數的coordinator會向statestore的topic注冊查詢的hostname,query_id2.2manager從statestore的topic上獲取注冊的hostname,query_id3.3,4manager根據hostname向對應的coordinator發送http請求制定query_id的查詢信息并保存到mysql中4.manager提供webui用于展示整個集群的查詢情

8、況5.5manager異步解析profile、SQL注解等查詢信息用于支撐HBO歷史查詢信息解析|新增查詢的排隊耗時、內存實際消耗、內存估算值、掃描的數據量等信息 結構化保存profile、timeline和summary中的信息歷史查詢信息解析|新增查詢的排隊耗時、內存實際消耗、內存估算值、掃描的數據量等信息 結構化保存profile、timeline和summary中的信息歷史查詢信息解析|新增查詢的排隊耗時、內存實際消耗、內存估算值、掃描的數據量等信息 結構化保存profile、timeline和summary中的信息歷史查詢信息解析|新增查詢的排隊耗時、內存實際消耗、內存估算值、掃描的

9、數據量等信息 結構化保存profile、timeline和summary中的信息歷史查詢信息解析|-By YouData(apiName:tableQuery)(userId:9349)(resourceId:c-1-36080-105714-kyqxpkt3)(timestamp:1654587547342)(isEdit:false)(trigger:User)(mvName:calcite_youdata21204_1653641141)(dataModelId:21204)(relatedResourceId:36080)(transId:nDTR74vZjm97Apa5WKzRd2)

10、-By UnciaDB(rewroteByMaterialization:calcite_youdata21204_1653641141,checkTime:3 ms,metadataLoadTime:7 ms,rewriteTime:25 ms)-By UnciaDB(HBOMemOpt:-1691677264,optimizeTime:1 ms,HBOEst:429.53 MB,HBOCoordEst:0.0 B)-By UnciaDB(table clipping optimization:0 ms)YouData為BI注解，UnciaDB為內部注解挖掘歷史查詢規律|按分鐘粒度分析集群查

11、詢次數、性能、內存和IO消耗等 識別集群繁忙和空閑規律，進行資源分時調度 分析隊列的查詢次數、排隊情況和排隊耗時 統計集群的查詢耗時、查詢成功率等指標挖掘歷史查詢規律|按分鐘粒度分析集群的查詢次數、性能、內存和IO消耗等 識別集群繁忙和空閑規律，進行資源分時調度 分析隊列的查詢次數、排隊情況和排隊耗時 統計集群的查詢耗時、查詢成功率等指標挖掘歷史查詢規律|按分鐘粒度分析集群查詢次數、性能、內存和IO消耗等 識別集群繁忙和空閑規律，進行資源分時調度 分析隊列的查詢次數、排隊情況和排隊耗時 統計集群的查詢耗時、查詢成功率等指標挖掘歷史查詢規律|挖掘同類型的SQL，關注次數、耗時和資源消耗 可為SQ

12、L模板創建物化視圖和進行內存預估優化 通過解析SQL獲取掃描次數TopN的熱表及其分區 可作為DataCache緩存和元數據異步加載的白名單HBO優化實踐優化實踐03|基于HBO的本地緩存優化|表元數據緩存 表定義、分區信息、文件列表和統計信息等 遠端：Hive Metastore 本地：Catalogd-CoordinatorHDFS文件緩存 文件句柄、文件塊數據 遠端：HDFS NameNode,DataNode 本地：Impalad FileHandle Cache,DataCache存在的問題存在的問題 元數據過舊導致查詢錯誤 元數據未緩存導致性能變差 Impala DataCache

13、成熟度不夠（3.4版本）：重啟失效，Miss代價大，可觀測性差基于HBO的本地緩存優化|表元數據緩存 支持元數據自動同步（invalidate/refresh）過濾無效表、合并同類DDL、暴露同步進度 通過SQL注解收集指定查詢涉及的表信息 通過動態白名單驅動表元數據異步加載DataCache增強 獨立配置Footer Cache CacheMiss異步Fill Cache元數據持久化 服務器多節點部署場景優化 backport 4.0新特性（LIRS、Metrics等）通過SQL注解收集指定查詢的熱表/分區 通過動態白名單及時更新需要緩存的表/分區在網易云音樂自助取數場景下，使用本地緩存等優

14、化措施后，10秒內查詢占總查詢比例從65%提升到91%，提升超過25%基于HBO的多表物化視圖|預計算是OLAP產品的傳統性能加速手段（MOLAP）BI報表場景：SQL批量下發、對性能要求較高 查詢規律性強、重復率高、T+1類型多1.生命周期管理生命周期管理：純自研，以獨立服務形式部署，元數據存mysql 通過數據產出消息、DDL變更日志和文件變更驅動更新2.SQL透明改寫透明改寫：基于Calcite物化視圖實現，輔以二次開發 SQL-calcite AST-rewrite-back to SQL-impala AST 作為jar包集成到coordinator的FE端，攔截SQL請求 優化SQ

15、L匹配和改寫效率 添加outer join、group by、limit等算子和各種UDF支持基于HBO的多表物化視圖|1.獲取優化對象：通過有數BI的報表歷史查看記錄 通過解析有數BI的SQL注解獲取 不同粒度：慢圖表、慢報告、慢模型2.創建物化視圖：模型物化視圖：基于查詢所涉及數據分區范圍+涉及字段 圖表物化視圖：非分區篩選器或聚合類圖表基于HBO的多表物化視圖|3.命中及效果評估：通過通過coordinator metrics 通過分析通過分析SQL注解注解 通過BI統計報表 通過有數BI數據醫生-By UnciaDB(rewroteByMaterialization:calcite_y

16、oudata21204_1653641141,checkTime:3 ms,metadataLoadTime:7 ms,rewriteTime:25 ms)基于HBO的多表物化視圖|3.命中及效果評估：通過coordinator metrics 通過分析SQL注解 通過通過BI統計報表統計報表 通過有數通過有數BI數據醫生數據醫生基于HBO的內存預估優化|提取SQL模板，分析內存預估值和實際值 選擇偏差大的模板作為優化規則 計算用戶查詢的SQL模板并進行規則匹配 統計信息缺失、粒度不夠細、維度不豐富 預估過大，導致內存實際利用率低 因可用內存不足導致查詢排隊虛擬數倉與資源動態調配|靈活高效的數

17、倉形態靈活高效的數倉形態 虛擬數倉位于同一個Impala集群，共用一份元數據 形態1：基于zookeeper namespace（主流）形態2：基于session的查詢參數（類似snowflake）混合分組和負載均衡混合分組和負載均衡 解決物理資源隔離帶來的資源利用率不高問題 混合分組模式：一個executor屬于多個虛擬數倉 虛擬數倉多入口：coordinator分時多zookeeper地址 基于executor負載的分布式執行計劃未來發展計劃04|未來計劃|已完成自研特性合并 添加hive 2.x版本支持 推進上線中 支持更多SQL語法和算子 提高物化視圖創建的自動化程度 與有數BI產品進一步融合 進一步提升HBO內存估算能力 支持更多場景的查詢透明重試 支持向量化執行模式 支持通過K8S進行Impala集群部署 資源動態調度和負載均衡 集群健康狀態診斷系統非常感謝您的觀看|