5.廖登宏-从openLooKeng看大数据未来的趋势与发展

1 .

2 .从openLooKeng看大数据未 来的趋势与发展 廖登宏 华为高级工程师 

3 .openLooKeng-面向大数据的融合分析引擎 安平 政府 金融 运营商 大企业 警务大数据 政务大数据 金融数据湖 运营商大数据 企业数据湖 数据源 数据集成 数据开发 数据治理 虚拟数仓 管理 数据使能 关系型数据 查询引擎 AI 安全管理 批计算 流计算 融合分析 图计算 搜索 日志数据 机 深 推 器 度 理 计算引擎 Hive Spark Flink openLooKeng GraphBase GeoMesa ElasticSearch 学 习 学 习 引 擎 租户管理 HBase 外部数据 YARN 配置管理 传感器(IoT) 数据管理 数据目录 Catalog 数据安全 Security 性能管理 WEB 入湖 社交媒体 故障管理 HDFS 分布式存储 数据存储 数据存储 TXT | ORC | Parquet | Carbon FS-HDFS | 对象 | 文件 3rd party 鲲鹏服务器 X86服务器 虚拟机 云主机 

4 .统一高效的数据虚拟化引擎，让大数据变简单 统一入口，化繁为简，单一引擎支持多场景 openLooKeng 统一数据访问接口 SQL ODBC JDBC REST 引擎内核 内核增强，高性能查询 融合分析 跨源索引 动态过滤 算子下推 AA 高可用 统一数据源连接框架 Data Source Connector Data Center Connector 跨源关联分析，数据消费零搬移 MySQL Kafka Hive Parquet …… PostgreSQL HBase CarbonData ORC 跨域协同计算，广域网的部署，局域网的体验 数据中心A 数据中心B 数据中心C 

5 .openLooKeng社区已发布版本 2020年6月30日openLooKeng 0.1.0版本在社区发布，提供统一SQL接口，具备跨源/跨域分析能力，支持交互式查询场景，同时构筑了启发式索引、动态过滤、 高可用AA、弹性伸缩、动态UDF等竞争力特性 openLooKeng 1.0.0 openLooKeng 1.2.0 openLooKeng 1.6.0 openLooKeng 1.8.0 社区演进 2020.09 2021.03 2022.03 2022.09 交互式查询持续增强+提升用户 DM优化+通用算子下推框架 企业特性资源隔离+可靠性增强 调度优化+task level retry 体验 +南向生态扩展 跨DC的动态过滤增强、DM优化、通用 Query resource management+Task 融合分析 支持IUD for ORC，支持数据虚拟集市 企业特性资源隔离+可靠性增强 算子下推框架 snapshot based retry 启发式索引增强、TPCDS性能优化、 CBO增强、支持Sorted Source Aggregator，减少内 算子下推、动态过滤增强、执行计划缓 优化算子的资源管理模式，支持不同负载sql的 高性能 Data Management优化、Star-Tree预 存使用、Star-Tree预聚合特性增强、Bloom索引大小优 存 时延处理需求 聚合、CTE Reuse 化 北向兼容性增强、南向提供新的通用算子 北向SQL语法转换工具支持 Memory connector 功能增强、 下推框架、HBase Connector性能优化、 Singledata Connector支持openGauss的分布 南北向生态 HQL/Impala语法 JDBC 数据源支持多分片查询、南向新增数据源：Hudi、 南向新增数据源：openGauss、 式处理能力 南向支持10+数据源 Kylin、GreenPlum、ClickHouse Connector； MongoDB、ElasticSearch 细粒度权限管控、查询重试增强、Admin 资源隔离、可靠性增强(任务级恢复)、支持算子Spill to 同时兼容operator level、task level的 企业级 容器化部署、Try-me、SQL Editor Dashboard Disk、Yarn部署 snapshot，满足不同级别的企业级容错需求 

6 . 大数据引擎现状——五个“Bound” 1 CPU-Bound：CPU 摩尔定律逐渐失效 2 IO-Bound：数据规模持续性爆炸增长 CPU算力的增长远远滞后于数据的增长 ③ 3 Network-Bound: 海量数据在网络上传输 4 JVM-Bound：JVM-Based计算引擎 5 Engine-Bound：不同场景不同引擎重复垂直优化 openLooKeng Spark Hive Flink Local Local Local Local optimization optimization optimization optimization Compute CPU ARM X86 XPU Ascend DPU 

7 .端到端全栈优化，软硬协同，打造下一代大数据基础架构 Compute Engine 5 openLooKeng Spark Hive 1 CPU-Bound • 向量化执行优化 Native Engine 4 • 列式内存格式 向量化算子 Expression Agg/Join SIMD 1 2 IO-Bound • 分布式索引 • 数据重组织 列式内存格式 Type Vector Encoding 3 Network-Bound • 存算分离 • 算子下推 湖仓一体框架 表管理 元数据管理 事务 MVCC 4 JVM-Bound • C++ based Engine • LLVM Codgen 存算协同加速 算子下推 3 Index 2 数据重组织 2 5 Engine-Bound • 统一的运行时框架 Storage Engine • 强数据一致性 HDFS S3 OBS • 减少“烟囱式”优化 ARM X86 GPU DPU 

8 .Native Engine OmniRuntime 加速SQL计算性能提升30+% Spark+ORT 120.00% • openLooKeng集成OmniRuntime实现算子Native计 99.25% 100.00% 算TPC-DS SQL性能平均提升34%，最高提升48.5% 80.00% • Spark集成OmniRuntime实现算子Native计算TPC-DS 60.00% 53.38% 45.61% SQL性能平均提升30%，最高提升99% 40.00% 28.98% 30.31%30.58% 20.03% 19.63% 20.00% 14.09% 1.55% 0.00% 节点数 1个管理节点+3个计算节点 SQL1 SQL2 SQL3 SQL4 SQL5 SQL6 SQL7 SQL8 SQL9 SQL10 AVG -7.06% -20.00% 处理器 Kunpeng 920-5220 openLooKeng+ORT 60.0% 内存大小 384GB（32GB*12） 48.5% 50.0% 43.8% 41.9% 网络 10Ge 40.0% 34.3% 32.0% 30.0% 硬盘 12* 6TB SATA 20.0% 15.6% 15.3% 15.3% 测试环境 10.6% 12.1% 10.0% 0.8% 0.0% 1 2 3 4 5 6 7 8 9 10 total 

9 . OmniData 算子下推实现近数据计算，大幅减少数据网络传输 传统方案 OmniData方案 • 计算在中心DC计算节点进行 • 将过滤算子卸载到边缘侧，计算在数据本地进行 例子 ： 某业务SQL节选 • 数据搬迁量大，导致网络传输瓶颈，计算效率低 • 降低数据搬迁量，消除网络传输瓶颈，提升计算效率 … ( SELECT DC计算节点 DC计算节点 logid AS xxx …… FROM xxx_log_hm WHERE pt_d = ‘20200709’ AND optype=‘11’ 数据无需搬迁 AND substr(downloadTime, 1, 10) = 数据需要搬迁 ‘20200709’ 加载数据量<80万行 加载数据量 >8亿行 ) 执行效率46% … 基于TPC-H测试用例，Spark和openLooKeng算子下推的 计算性能平均提升40% 数据源HDFS/Ceph 2.7 数据源HDFS/Ceph OmniData 2.2 DC存储节点 DC存储节点 1.7 1.2 适用场景：存算分离场景、存算融合大规模集群场景 0.7 sql1 sql4 sql6 sql7 sql10sql11sql12sql14sql15sql17sql18sql19sql20sql21sql22 适用组件：Spark SQL、openLooKeng 原生 OmniData 

10 .openLooKeng小助手 openLooKeng官网