Apache Doris 实时查询分析

李航宇SelectDB数据库内核研发、Apache Doris Commiter DataFunSummit#2023 架构演变 Apache Doris有哪些高并发优化手段 包括Apache Doris整体架构及存储引擎介绍 高并发点查实现原理与优化 未来规划 Apache Doris存储架构介绍 DataFunSummit#2023 架构图 层级关系 存储and索引 列式存储 Apache Doris高并发核心技术 分区分桶 •Apache Doris采用两级分区，第一级是Partition，通常可以将时间作为分区键。第二级为Bucket，通过Hash将数据打散至各个节点中，以此提升读取并行度并进一步提高读取吞吐。通过合理地划分区分桶，可以提高查询性能，以下列查询语句为例： •select*from user_table where id = 5122 and create_time= '2022-01-01' •用户以create_time作为分区键、ID作为分桶键，并设置了10个Bucket，经过分区分桶裁剪后可快速过滤非必要的分区数据，最终只需读取极少数据，比如1个分区的1个Bucket即可快速定位到查询结果，最大限度减少了数据的扫描量、降低了单个查询的延时。 索引过滤机制 SELECT*from table wherekey = 1 andindex_column =‘abc’andxyx = 10 •按条件裁剪segment •前缀稀疏索引加速前缀匹配•倒排索引加速字符串匹配•bloom过滤等值查询 •表达式过滤(向量化)•延迟物化 物化视图 1.空间换时间 2.预聚合 3.前缀匹配 物化视图 /对于聚合操作，直接读物化视图预聚合的列 create materialized view store_amt as select store_id, sum(sale_amt) from sales_records group bystore_id; SELECT store_id, sum(sale_amt) FROM sales_records GROUP BY store_id; //对于查询，k3满足物化视图前缀列条件，走物化视图加速查询CREATE MATERIALIZED VIEW mv_1 as SELECT k3, k2, k1 FROM tableA ORDER BY k3;select k1, k2, k3 from table A where k3=3; 其他 •包括多种Cache •TopN optimization •limit下推•key filter•延迟物化 •PageCache•SQL Cache•PartitionCache •.... •RuntimeFilter•根据小表数据过滤大表 Doris高并发点查优化 DataFunSummit#2023 优化背景以及思路 Apache Doris已经在单节点上实现了支持数千次每秒的查询（Queries Per Second, QPS）。然而，在对超高并发性能要求的数据服务场景中（例如，数万次每秒的QPS），仍然存在一些瓶颈。以下是所面临的挑战： 1.列式存储引擎对于读取行级数据不友好，在宽表模型中会导致随机读I/O大幅增加。 2.OLAP数据库的执行引擎和查询优化器对于某些简单查询（例如点查询）过于繁重，需要进行短路径规划来处理此类查询。 3.SQL请求访问、查询计划解析和生成由FE模块使用Java处理，当在高并发场景中解析和生成大量查询执行计划时，会导致高CPU开销。 4.利用高效的PrimaryIndex以及bloomfilter加速点查 为了解决这些挑战，Apache Doris从以下三个设计要点实施了一系列优化： 1.减少SQL内存I/O开销2.提高点查询执行效率3.降低SQL解析开销 行存vs列存 引入新的编码方式，将一行紧凑的编码到一块空间，较少读取整行数据的IO放大 短路径规划 MPP查询为跑大数据量查询性能优化极致、但是对于单点查询过于复杂，路径冗余 短路径规划 id是主键 利用RowsetTree快速定位segment 线段树二分查找快速定位rowset & segment 区间为主键编码后的[lower_bound, upper_bound), 叶子节点是对应rowset/segment-id 主键索引& bloom filter FE性能瓶颈 一条SQL语句的执行需要经过三个步骤：首先通过SQL Parser解析语句，生成抽象语法树(AST)，随后通过Query Optimizer生成可执行计划（Plan），最终通过执行该计划得到计算结果 由于FE是Java编写，性能难以优化到极致，考虑到类似的查询pattern足够简单，很多数据结构是可以复用的。这里我们用Mysql的ServerSide PreparedStatement(SSP)来解决该问题。 PreparedStatement Prepared Statement的工作原理是通过在Session内存HashMap中缓存预先计算好的SQL和表达式，在后续查询时直接复用缓存对象即可 PreparedStatement Cache 多级cache：Page级别Cache，类似Rocksdb BlockCache，极大减少磁盘IORow级别Cache，缓存原始行存，减少codec都是LRU缓存 Cache •Meta Cache•缓存Schema、Expression、thrift、proto等结构 YCSB Benchmark Yahoo! Cloud Serving Benchmark（YCSB）用于专门评测NoSQL系统 •数据规模：一共1亿条数据，平均每行在1K左右，测试前进行了预热。•表结构为YCSB提供，10个字段，都是varchar(100),第一个字段做主键，随机生成 YCSB Benchmark 展望 展望 1.更加智能的cache2.优化存储空间3.更智能的调优4.支持更丰富的查询语法5.支持物化视图，提供二级索引 如何加入Apache Doris社区 订阅开发者邮件组 订阅社区开发者邮件dev@doris.apache.org并参与社区的邮件讨论中 双周开发者会议(线上会议) 通过会议链接参与到社区开发者双周会：https://meeting.tencent.com/dm/6iQBgkIhn5LO DorisImprovementProposals(DSIP)通过DSIP查阅社区核心功能设计方案及相关进展：https://cwiki.apache.org/confluence/display/DORIS/Doris+Improvement+Proposals 欢迎关注： 欢迎关注SelectDB微信公众号获取最新活动资讯、技术解析、社区动态公司邮箱：support@selectdb.comSelectDB官网：www.selectdb.com 欢迎关注Apache Doris GitHub &官网 ApacheDorisGitHub：https://github.com/apache/dorisApacheDoris官网：https://doris.apache.org/ 感谢观看