《Impala中的性能优化.pdf》由会员分享,可在线阅读,更多相关《Impala中的性能优化.pdf(38页珍藏版)》请在三个皮匠报告上搜索。
1、DataFunSummit2023Impala在数据湖中的性能优化黄权隆-Cloudera-Staff Software EngineerImpala与数据湖Iceberg相关优化Codegen优化未来展望DataFunSummit2023Impala与数据湖数据湖概览 SQL查询引擎,面向交互式查询场景 数据/元数据都在外部存储上,无状态 MPP架构,内存计算,C+内核 Open Storage HDFS、Ozone、Kudu、S3、ADLS、HBase等 Open File Format Parquet、ORC、Avro、Text等 Open Table Format Iceberg、Hu
2、di、Hive ACID等 企业级的Security集成 授权、鉴权、血缘、审计、脱敏等都有集成 如Kerberos、LDAP、JWT、SSL、Ranger、Atlas集成等 企业级应用广泛 1400 个客户,97000 台机器 单集群规模 500 节点Impala简介 Coordinator处理查询请求,可有多个 Parse,Analyze,Plan,Optimize 元数据缓存 准入控制/并发控制,调度 Executor 分布式执行Impala架构Query CompilerQuery CoordinatorLocal Metadata CacheQuery ExecutorHive Me
3、tastoreStorage Master NodesStateStoreFE(Java)BE(C+)HDFS/OzoneKuduS3/ADLS/GCPHBaseImpala CoordinatorImpala ExecutorsMetadata&Control ExecutionStorageRangerQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery ExecutorQuery
4、ExecutorQuery ExecutorCatalog ServerCached Table Metadata外部系统元数据/调度/集群管控执行层 所有查询都能查看,包括正在运行或失败的查询,以及DDL/DML等Impala WebUI Queries页面 图形化的query plan,开源版本即可拥有Impala WebUI Query Plan可视化Impala WebUI Query Timeline 4.3.0:计划中 4.2.0:2022-12-08 4.1.0:2022-06-01 4.0.0:2021-07-12 3.4.0:2020-04-24 3.3.0:2019-08-
5、22 3.2.0:2019-03-28(CDH6.3 版本)3.1.0:2018-12-06 3.0.1:2018-10-24 3.0.0:2018-05-07 2.12.0:2018-04-24(CDH5.16 版本)2.11.0:2017-12-28Impala 发布历史Benckmark测试建议使用新版本 对数据的假设/管控有限 数据源、数据导入方式、文件格式、表格式多样 存算分离,支持开放存储 数据湖/湖仓优化 vs.传统数仓优化 数据预排序 需要数据生产者支持 若保证有序,简单的min()/max()查询可只读首/末行,可实现直接merge-join等优化 不保证有序,只能基于文件m
6、in-max索引做谓词下推,数据有序时,min-max索引更有效 字典编码、索引等 文件级别可以有字典编码,但难以维护全局字典 难以自定义文件格式 数据位置不可控,难以做colocated优化等 数据湖查询引擎的挑战 开放性(Openness)数据湖查询引擎可做的优化 为支持开放性、存算分离等,不能对数据做过多假设,但仍有许多优化点可做:查询计划层 谓词推导/下推、常量传播、Join顺序、子查询改写等 结合执行层:Pre-aggregation、Runtime Filter、Broadcast vs Partitioned(Shuffle)执行层 JIT Codegen、向量化、SIMD、Pr
7、efetch、并行优化、延迟物化、内存计算、自适应执行等 内存管理、Spill to disk IO层 本地短路读、列存优化、压缩、编码(Encoding)、异步IO 缓存 元数据、File handle、数据文件、中间数据、物化视图(需要自主管控)工程实现优化DataFunSummit2023Impala在Iceberg上的优化 用文件保存元数据 如何分区 每个分区有哪些数据文件等 不再需要file-listing 表结构/分区定义/修改 更灵活 方便实现snapshot、回滚等功能 使用外部系统来保证事务 如HDFS上的rename HMS上的元数据变更等Iceberg Open Tabl
8、e Format 支持HadoopTables、HadoopCatalog 和 HiveCatalog 读写IcebergV1表 读IcebergV2表(仅支持position delete)snapshot操作:show、expire、rollback 查询历史版本(time travel)partition变更 Impala on Iceberg功能集https:/impala.apache.org/docs/build/html/topics/impala_iceberg.html merge-on-read 两种delete files Position delete files 记录
9、文件 URIs+行号 Equality delete files 记录已删除行的某些列的值 实际应用不多 Iceberg library可返回哪些 delete file对应哪些 data fileIceberg V2Data filesDelete filesImpala 读 Iceberg V2 的实现LEFTANTIHASH JOINSCAN NODE(DATA ROWS)SCAN NODE(DELETED ROWS)data.INPUT_FILE_NAME=del.file_path ANDdata.FILE_POSITION=del.pos 可选方案 Iceberg Java Rea
10、der IcebergScanner(C+)Anti Join Anti Join 使用已有Join实现,支持BROADCAST 或 PARTITIONED 与Hive ACID支持方案类似 增加虚拟列 INPUT_FILE_NAME,FILE_POSITION Join条件:data.INPUT_FILE_NAME=del.file_path ANDdata.FILE_POSITION=del.posImpala on Iceberg V2 读实现优化LEFTANTIHASH JOINSCAN NODE(DATA ROWS)SCAN NODE(DELETED ROWS)SCAN NODE(N
11、O DELETES)UNION ALL 区分data files,没有对应delete files的可以直接读取,绕过AntiJoin 使用 Union all 连接结果Impala on Iceberg V2 读实现优化(开发中)IcebergSpecificAntiJoinScanNode(Data rows)ScanNode(Deleted rows)Anti HashJoin 需要为每行计算hash值 替换为Iceberg特定的operator 使用特定的 lookup table:File sorted positions 只索引在prode side要读的data file对应的d
12、elete file 每个row batch仅需一次lookup,然后类似merge join处理 delete positions 注:row batch里各行天然按position排序count(*)优化 使用snapshot的统计信息优化简单的count(*)SELECT count(*)FROM ice_tbl SELECT 1000 SELECT count(*),min(a),max(b)FROM ice_tbl SELECT 1000,min(a),max(b)FROM ice_tbl 仅对v1和没有delete file的v2表有效count(*)优化 Iceberg V2 I
13、ceberg V2表包含 delete file,是否能简单减去delete file行数?Delete file可能有内容重复(并发修改导致)rewriteFiles(partial compaction)可能导致delete file指向的某些文件失效Delete File(2)A(100)B(100)C(100)BC(199)Snapshot 1Snapshot 2compaction忽略已删除的行 查询计划优化LEFTANTIHASH JOINSCAN NODE(DATA ROWS)SCAN NODE(DELETED ROWS)SCAN NODE(NO DELETES)UNION AL
14、LAGGREGATEcount(*)LEFTANTIHASH JOINSCAN NODE(DATA ROWS)SCAN NODE(DELETED ROWS)ConstantAGGREGATEcount(*)count(*)优化 Iceberg V2Manifest 文件的读取不同条件的TableScan在planFiles()时都需要读Manifest文件TPCDS-Q9读取store_sales表15次,需要查看Manifest文件15次在云上Manifest文件的读取成为QueryPlanning的瓶颈缓存Manifest文件 Impala已有的元数据缓存 表结构定义 文件信息,如path
15、、大小、权限信息等 Block location(HDFS)两种缓存优化方案 缓存无谓词的 planFiles()结果集,ScanNode planning时不再调用Iceberg API,在缓存的结果集上根据谓词过滤文件 在Iceberg library内部缓存manifest文件,加速planFiles()等API的执行 对上层引擎透明,所有使用Iceberg Java Library的引擎都受益 注:Iceberg的设计里Manifest文件不会被修改,只有新增和删除使用 Caffeine 缓存 ManifestFileIO 1FileIO 2FileIO NContentCache 1
16、ContentCache 2ContentCache NFile Location 1File Location 2File Location NContentCache for Manifest filesManifest File 1Manifest File 2Manifest File NIceberg Core Library(iceberg#4518)Iceberg 1.1.0开始支持Manifest 缓存优化效果DataFunSummit2023Codegen相关优化Impala中的Codegen 基于LLVM 目标:为每个查询编译出最优的执行程序 利用运行时信息优化执行代码 裁
17、减分支,如排序是升序/降序、NULL First/Last等 使用常量下标、指针,如排序列下标 替换虚函数调用,如 GetValue()-GetBigIntValue()现状:主要优化Operator、表达式内部代码Codegen例子Codegen加速比Codegen导致的延迟 向量化引擎相比Codegen引擎在小数据集上有天然优势“As Martin Kersten pointed out in a workshop discussion,end-to-end MonetDB could easily outperform HyPer on small data sets due to th
18、e high compilation time.Even for TPC-H SF1 the query compilation time was often higher than the query execution time.”MonetDB:向量化引擎代表HyPer:查询编译引擎代表Impala在TPC-H查询上的codegen编译时间为 200 900msAsync Codegen 在异步线程中执行Codegen 查询先用解释型代码执行 Codegen完成后,把函数指针改成codegen后的函数 小查询可能在Codegen线程完成前就已完成Async Codegen 效果 TPC-
19、H(SF=1)性能对比:是否开启Async Codegen,是否关闭CodegenCodegen Cache 优化有fragment相同的查询select count(*)from lineitemwhere l_orderkey 1000;select count(*)from lineitemwhere l_orderkey 5000;Final-AggExchangePre-AggScan lineiteml_orderkey 1000F01F00Final-AggExchangePre-AggScan lineiteml_orderkey 5000F01F00F01代码相同命中cach
20、eF00代码不同cache missCodegen Cache 测试 TPC-H(SF=1)性能对比:是否命中Codegen Cache,是否关闭CodegenCodegen cache也能缓解小查询上codegen带来的性能回退未来展望Iceberg相关 优化IcebergV2表读性能 支持IcebergV2表上的DELETE和UPDATE操作 支持用SELECT查询Iceberg元数据(IMPALA-10947)Codegen相关 在更多地方使用Codegen Adaptive Query Compilation Codegen Cache内存优化 Codegen 可见性(Observability)欢迎交流!#:China_Impala!$Impala%&()*+,-Impala./邮件列表(英文交流):userimpala.apache.orgdevimpala.apache.orgDataFunSummit2023感谢观看