- 快召唤伙伴们来围观吧
- 微博 QQ QQ空间 贴吧
- 视频嵌入链接 文档嵌入链接
- 复制
- 微信扫一扫分享
- 已成功复制到剪贴板
openLooKeng交互式查询场景性能优化
随着大数据技术的应用和发展,数据种类越来越多,数据分布越来越广,查询场景也越来越复杂,这使得大数据使用更加困难。为了改善大数据的易用性,华为发起数据虚拟化引擎openLooKeng开源项目。在此次演讲中,我们将介绍华为开源数据虚拟化引擎openLooKeng,以及针对交互式查询场景所采用的关键技术。
展开查看详情
1 .openLooKeng交互式查询场景性能优化 李铮 openLooKeng committer
2 .目录 01 openLooKeng介绍 02 openLooKeng交互式场景关键技术 03 TPC-DS场景中的挑战 04 客户实际场景中的挑战
3 .目录 01 openLooKeng介绍 02 openLooKeng交互式场景关键技术 03 TPC-DS场景中的挑战 04 客户实际场景中的挑战
4 . openLooKeng:统一高效的数据虚拟化融合分析引擎,让大数据变简单 统一入口,化繁为简,单一引擎支持 多场景 openLooKeng 统一数据访问接口 SQL ODBC JDBC REST 引擎内核 内核增强,高性能查询 融合分析 跨源索引 动态过滤 算子下推 AA 高可用 数据源连接框架 Data Source Connector Data Center Connector 跨源关联分析,数据消费零搬移 跨域协同计算,广域网的部署,局 域网的体验 数据中心A 数据中心B 数据中心C 4
5 . openLooKeng架构 openLooKeng cluster1 openLooKeng cluster2 Discovery Coordinator … Coordinator Discovery Coordinator server server 分布式处理系统,MPP架构 跨域 跨DC Worker Worker Worker Worker Worker Worker 高可用性,无单点故障 Data Center Connector 向量化列式处理引擎 Data Source Data Source Connector Connector MySQL Hive Elasticsearch MySQL Hive 基于内存的流水线处理 5
6 .目录 01 openLooKeng介绍 02 openLooKeng交互式场景关键技术 03 TPC-DS场景中的挑战 04 客户实际场景中的挑战
7 .交互式查询特点 随机性 数据量适中 用户SQL不可预测,具有很强的随机性 数据存在data warehouse中 并发支持 交互式 所需结果集小 一般需要提供50-100并发支持 查询 通常所需结果集较小,使用limit或者取消 端到端时间敏感 跨源跨域 秒级/分钟级返回,查询涉及资源不敏感 需要跨DC或者跨源支持 7
8 .交互式查询特点 随机性 数据量适中 用户SQL不可预测,具有很强的随机性 数据存在data warehouse中 并发支持 交互式 所需结果集小 一般需要提供50-100并发支持 查询 通常所需结果集较小,使用limit或者取消 端到端时间敏感 跨源跨域 秒级/分钟级返回,查询涉及资源不敏感 需要跨DC或者跨源支持 8
9 . openLooKeng交互式场景关键技术 Client Coordinator 数据源侧,更适应openLooKeng Coordinator ➢ 分桶/分区 Metadata Cache ➢ 小文件合并 • Dynamic filter planning Data Metadata API • Semi join optimization rule ➢ 查询字段排序 Location API • Predicate pushdown 引擎层,增强交互式查询能力 • Index optimizer - 缓存加速: Parser/analyzer planner scheduler • Create index ➢ 执行计划缓存 Execution plan cache • Create cache ➢ 元数据缓存 Java • Affinity Scheduler • Serialization Worker ➢ 增量列式缓存 • Deserialization Worker - 优化器: Worker Processor Processor ➢ 谓词下推 ➢ 动态过滤 • Dynamic filter • Dynamic filter ➢ RBO&CBO • Predicate filter • Predicate filter Data Stream API Data Stream API - 自适应调度器 Data cache Data cache 额外层,加速交互式查询 ➢ Heuristic index layer (bitmap/bloomfilter/min-max) Index layer ➢ Data cache layer DataSource ➢ 序列化&反序列化 9
10 .目录 01 openLooKeng介绍 02 openLooKeng交互式场景关键技术 03 TPC-DS场景中的挑战 04 客户实际场景中的挑战
11 . TPC-DS场景分析 TPC-DS是TPC标准组织推出的一个广泛使用的行业标准决策支持基准,用于评估数据处理引擎的性能 TPCDS数据模型 ➢ 包含7张事实表和17张维度表 ➢ 事实表数据量极大,而维度表相对较小 事实表Billion级 ➢ 查询很少有谓词直接应用到事实表 随机性 ➢ 事实表查询条件通过维度表相连接得到 数据量适中 并发支持 带来的挑战 维度表Kilo至Millon级 ➢ 传统谓词下推等优化很难应用 所需结果集 端到端时间 小 敏感 ➢ Join数据量巨大导致执行时间过长 跨源跨域 Catalog Sales表ER图 场景维度分析 11
12 . Dynamic Filtering 依靠join条件以及build侧表读出的数据,运行时生成动态过滤条件(dynamic filters),应用到probe侧 表的table scan阶段,从而减少参与join操作的数据量,有效地减少IO读取与网络传输 客户端 语法语义分析 Coordinator DynamicFilter Dynamic Filtering 执行计划生成 动态过滤查询优化规则 Service ➢ 添加DynamicFIlterSource算子,搜集 执行计划调度 ③ Merge build侧数据 Worker ➢ 依赖分布式缓存进行DF的处理 Worker Join ➢ 适用于inner join & right join ② Get ➢ 适用于join选择率较高的场景 分布式缓存 DynamicFilter ④Apply ProbeTableScan Source DynamicFilter ①Build BuildTableScan 数据源 12
13 . Dynamic Filtering /user/hive/warehouse/tpcds_bin_partitioned_orc_1000.db/store_sales /ss_sold_date_sk=2452638/000997_0 Coordinator split Data split ORC File 1 Get dynamic filters Location API split DynamicFilter Service split scheduler ORC File 2 split … split … split split split split ORC File n split Worker Worker 分布式缓存 分区裁剪 partition pruning Processor Processor ➢ Join条件应用在分区列上,有效地减少读取的 文件和分区的数量,扫描仅读取与分区过滤器 Data Stream API Data Stream API 匹配的目录,从而减少了磁盘I/O与网络传输 13
14 . Dynamic Filtering 客户端 语法语义分析 Coordinator 行过滤 row filtering DynamicFilter 执行计划生成 动态过滤查询优化规则 Service ➢ Join条件应用在非分区列上,通过应用动态过 执行计划调度 滤条件对数据进行行过滤,减少Join的数据量 ③ Merge Worker Join ② Get 分布式缓存 DynamicFilter ④Apply ProbeTableScan Source ①Build BuildTableScan Filtered page Page Filtered Page DynamicFilter Column 1 Column 1 Page Column 2 Column 2 OrcPageSource Column 3 Column 3 … … Column 8 Column 8 数据源 14
15 . 性能测试 500 450 400 350 运行时间(s) 300 250 200 150 100 50 0 q11 q12 q13 q15 q16 q17 q19 q20 q21 q25 q26 q28 q29 q30 q31 q32 q33 q34 q37 q40 q41 q42 q43 q46 q47 q48 q49 q50 q51 q52 q53 q54 q55 q56 q57 q58 q59 q60 q61 q62 q63 q64 q65 q66 q68 q69 q71 q72 q73 q74 q75 q76 q78 q79 q81 q82 q83 q84 q85 q88 q89 q91 q92 q93 q94 q95 q96 q97 q98 q99 q1 q2 q3 q39a q4 q7 q39b DF-ON DF-OFF 总用时(s) 测试背景: 结论及后续优化 数据集:2TB TPCDS 节点:11计算节点 内存:376GB DF-OFF 2193.939 ➢ 结论 Cpu:2*Gold 6140 CPU @ 2.30GHz ➢ TPC-DS测试用例总用时openLooKeng开启 OS:RedHat 7.3 *openLooKeng基于master分支 动态过滤,执行时间减少38.9% ➢ 后续优化 DF-ON 1340.225 ➢ Predicate pushdown优化 ➢ Dynamic filtering等待及应用优化 15 0 500 1000 1500 2000 2500
16 .目录 01 openLooKeng介绍 02 openLooKeng交互式场景关键技术 03 TPC-DS场景中的挑战 04 客户实际场景中的挑战
17 . XX客户场景 应用 应用 数据源 openLooKeng ETL ETL 数据源 ANSI SQL统一接口 生产系统 HIVE 创建索引 生产系统 高性能MPP分析引擎 专题库 HDFS 业务痛点 openLooKeng优势与挑战 ➢ 数据重复存储,拉高建设成本 ➢ 优势 • 组件间数据流转效率低,Hive分析结果生成导入专题库,表多、数据量大 • 基于一份数据,数据无需再导出实现时空库点查询和批量分析 ➢ 数据索引膨胀,额外存储成本 ➢ 劣势 • 无索引无法满足并发与性能需求 • 查询性能如何满足用户高并发需求 • 创建索引后性能满足,但数据膨胀20倍 17
18 . XX客户场景 客户需求 表名 数据量 Sql 产品 性能 ➢ 100并发可以支撑30天数据查询 XX 800GB,30天 单表点查 openLooKeng 8s-10s ➢ 响应时间满足用户APP使用要求(1-2s) 随机性 场景分析 openLooKeng性能分析 数据量适中 并发支持 ➢ 单表数据量很大,只有天分区,测试数据 ➢ 性能瓶颈在于table scan阶段 包含30天 ➢ 分区只有天分区,无法做到有效过滤 ➢ 谓词包含OR以及AND • 针对场景增加二级分区 所需结果集 端到端时间 ➢ 单表点查询,无join ➢ HDFS orc存在小文件问题 小 敏感 • 需要合并小文件提升HDFS读性能 跨源跨域 ➢ 通过openLooKeng H-index可以有效提升 • 创建bloomfilter以及bitmap索引 场景维度分析 18
19 . Heuristic index架构 Client Coordinator Coordinator Metadata API Data Location API Heuristic index • Index optimizer HIndex-稀疏索引 ➢ 提供统一的索引框架 Parser/analyzer planner scheduler ➢ 支持多种索引结构 • Create index ➢ 稀疏索引:Bloomfilter、Min-Max • Affinity Scheduler Worker Worker ➢ 稠密索引:Bitmap ➢ 任务调度阶段: Worker Processor Processor ➢ 裁剪Split,减少调度到Worker的任务数 ➢ 支持基于索引的亲和性调度 • Index filtering • Index filtering Data Stream API Data Stream API ➢ 数据读取阶段: ➢ 减少加载到计算侧内存的数据量 HIndex-稠密索引 Index layer DataSource 19
20 . Heuristic index- 稀疏索引 Bloom filter索引,确定每个split是否包含要搜索的值,并只对可能包含该值的split进行读操作 split Index: Table:test_base File 1 split Column:j1 split split split Select * from test_base File 2 split where j1 = ‘070299439’ split … split split split File n split split H-index-bloom filter ➢ 可以快速判断一个集合中有无某个值(只支持等于符号) ➢ 需要预先通过create index进行索引创建 ➢ 通过在coordinator侧过滤,减少不必要的split生成与处理 20
21 . Heuristic index - 稠密索引 Bitmap索引,通过为谓词列保留外部位图索引,可以过滤掉与谓词不匹配的行 Stripe Batch Page Column 1 Stream Reader Index Data Column 2 Stream Reader Row Data OrcPageSource Column 3 Stream Reader Stripe Footer … … Column 8 Stream Reader 1 1 0 0 1 1 0 1 0 0 Select * from table 0 N where app_id = 123 H-index-bitmap Bitmap ➢ 列式存储,记录了一列的值,字典,以及 bitmap,适用于与操作,使用字典快速查询 ➢ 需要预先通过create index进行索引创建 21
22 . XX客户场景 sql 数据范围 并发数 最快响应 总时长 查询失败 结论及后续优化 10 146ms 206ms 0 ➢ 结论 20 158ms 364ms 0 ➢ 100并发20天查询性能满足需求 1天 50 186ms 1.2s 0 ➢ 50并发30天查询性能满足用户需求 100 145ms 2.4s 0 ➢ 100并发30天查询性能存在一定差距 10 191ms 309ms 0 ➢ 后续优化 20 338ms 583ms 0 ➢ 索引OR支持及测试 sql 10天 50 1.1s 2.7s 0 ➢ Predicate pushdown优化 100 2.4s 5.6s 0 ➢ 聚合场景的StarTree Index 10 430ms 517ms 0 20 930ms 1.1s 0 30天 50 1.9s 2.9s 0 100 4.4s 9.7s 0 22
23 . 总结 • openLooKeng愿景是让大数据更简单 • 统一SQL入口,数据免搬迁 • 高性能的交互式查询能力 • 多源异构数据源融合分析 • 跨域跨DC融合分析 • 交互式查询随机性及时延敏感性为openLooKeng引擎提出了巨大挑战 • openLooKeng从如下三个方面进行交互式查询优化: • 让数据源更好的适配引擎(分区/小文件合并) • 引擎自身优化(动态过滤/RBO/CBO/谓词下推/缓存) • 添加额外层加速(Heuristic index layer/Cache layer/序列化/反序列化) • Future work • 谓词下推增强 • 动态过滤增强 • StarTree Index 23
24 . Try-Me Show https://tryme.openlookeng.io/ 廖登宏 openLooKeng user group
25 .Demo测试语句 Cache SELECT count(*) FROM store_sales WHERE store_sales.ss_sold_date_sk BETWEEN 2451484 AND 2451513 Index select count(*) from store_sales where ss_item_sk=123; 动态过滤 set session enable_dynamic_filtering = true; set session join_distribution_type = 'BROADCAST'; SELECT count(*) FROM hive.tpcds.catalog_sales t2 join hive.tpcds.date_dim as t1 on t2. cs_sold_date_sk= t1. d_date_sk AND t1.d_year = 2001; 跨DC SELECT count(*) FROM dc1.tpcds.sf1.call_center as t1, hive.tpcds.catalog_sales t2 WHERE t1. cc_call_center_sk = t2. cs_call_center_sk ; VDM CREATE VIEW vdm1.schema1.view1 AS (SELECT * FROM tpcds.sf1.call_center); CREATE VIEW vdm1.schema1.view2 AS (SELECT * FROM dc1.tpcds.sf1.call_center as t1, hive.tpcds.catalog_sales t2 WHERE t1. cc_call_center_sk = t2. cs_call_center_sk); SELECT count(*) FROM vdm1.schema1.view1 as v1, vdm1.schema1.view2 as v2 WHERE v1.cc_call_center_id = v2.cc_call_center_id;
26 .Thank you
27 .openLooKeng, Big Data Simplified openLooKeng微信公众号 openLooKeng微信小助手
28 .openLooKeng交互式查询场景性能优化 李铮 openLooKeng committer
29 .Backup