Apache Doris 2.0-beta 盲测性能 10 倍提升，更统一的多场景极速分析体验！

亲爱的社区小伙伴们，我们很高兴地向大家宣布，Apache Doris 2.0-beta 版本已于 2023 年 7 月 3 日正式发布！在 2.0-beta 版本中有超过 255 位贡献者为 Apache Doris 提交了超过 3500 个优化与修复，欢迎大家下载使用！

下载链接：https://doris.apache.org/download

GitHub 源码：https://github.com/apache/doris/tree/branch-2.0

在今年年初举办的 Doris Summit 年度峰会上，我们曾发布了 Apache Doris 的 2023 年 Roadmap 并提出了新的愿景：

我们希望用户可以基于 Apache Doris 构建多种不同场景的数据分析服务、同时支撑在线与离线的业务负载、高吞吐的交互式分析与高并发的点查询；通过一套架构实现湖和仓的统一、在数据湖和多种异构存储之上提供无缝且极速的分析服务；也可通过对日志/文本等半结构化乃至非结构化的多模数据进行统一管理和分析、来满足更多样化数据分析的需求。

这是我们希望 Apache Doris 能够带给用户的价值，不再让用户在多套系统之间权衡，仅通过一个系统解决绝大部分问题，降低复杂技术栈带来的开发、运维和使用成本，最大化提升生产力。

面对海量数据的实时分析难题，这一愿景的实现无疑需要克服许多困难，尤其是在应对实际业务场景的真实诉求中更是遭遇了许多挑战：

• 如何保证上游数据实时高频写入的同时保证用户的查询稳定；
• 如何在上游数据更新及表结构变更的同时保证在线服务的连续性；
• 如何实现结构化与半结构化数据的统一存储与高效分析；
• 如何同时应对点查询、报表分析、即席查询、ETL/ELT 等不同的查询负载且保证负载间相互隔离？
• 如何保证复杂 SQL 语句执行的高效性、大查询的稳定性以及执行过程的可观测性？
• 如何更便捷地集成与访问数据湖以及各种异构数据源？
• 如何在大幅降低数据存储和计算资源成本的同时兼顾高性能查询？
• ……

秉持着“将易用性留给用户、将复杂性留给自己”的原则，为了克服以上一系列挑战，从理论基础到工程实现、从理想业务场景到极端异常 Case、从内部测试通过到大规模生产可用，我们耗费了更多的时间与精力在功能的开发、验证、持续迭代与精益求精上。值得庆祝的是，在经过近半年的开发、测试与稳定性调优后，Apache Doris 终于迎来了 2.0-beta 版本的正式发布！而这一版本的成功发布也使得我们的愿景离现实更进一步！

盲测性能 10 倍以上提升！

全新的查询优化器

高性能是 Apache Doris 不断追求的目标。过去一年在 Clickbench、TPC-H 等公开测试数据集上的优异表现，已经证明了其在执行层以及算子优化方面做到了业界领先，但从 Benchmark 到真实业务场景之间还存在一定距离：

• Benchmark 更多是真实业务场景的抽象、提炼与简化，而现实场景往往可能面临更复杂的查询语句，这是测试所无法覆盖的；
• Benchmark 查询语句可枚举、可针对性进行调优，而真实业务场景的调优极度依赖工程师的心智成本、调优效率往往较为低下且过于消耗工程师人力；

基于此，我们着手研发了现代架构的全新查询优化器，并在 Apache Doris 2.0-beta 版本全面启用。全新查询优化器采取了更先进的 Cascades 框架、使用了更丰富的统计信息、实现了更智能化的自适应调优，在绝大多数场景无需任何调优和 SQL 改写即可实现极致的查询性能，同时对复杂 SQL 支持得更加完备、可完整支持 TPC-DS 全部 99 个 SQL。

我们对全新查询优化器的执行性能进行了盲测，仅以 TPC-H 22 个 SQL 为例 ，全新优化器在未进行任何手工调优和 SQL 改写的情况下 查询耗时，盲测性能提升了超过 10 倍！而在数十个 2.0 版本用户的真实业务场景中，绝大多数原始 SQL 执行效率得以极大提升，真正解决了人工调优的痛点！

参考文档：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/nereids

如何开启：SET enable_nereids_planner=true 在 Apache Doris 2.0-beta 版本中全新查询优化器已经默认开启，通过调用 Analyze 命令收集统计信息。

自适应的 Pipeline 执行引擎

过去 Apache Doris 的执行引擎是基于传统的火山模型构建，为了更好利用多机多核的并发能力，过去我们需要手动设置执行并发度（例如将 parallel_fragment_exec_instance_num 这一参数从默认值 1 手工设置为 8 或者 16），在存在大量查询任务时存在一系列问题：

• 大查询、小查询需要设置不同的instance 并发度，系统不能做到自适应调整；
• Instance 算子占用线程阻塞执行，大量查询任务将导致执行线程池被占满、无法响应后续请求，甚至出现逻辑死锁；
• Instance 线程间的调度依赖于系统调度机制，线程进行反复切换将产生额外的性能开销；
• 在不同分析负载并存时，Instance 线程间可能出现 CPU 资源争抢的情况，可能导致大小查询、不同租户之间相互受影响；

针对以上问题，Apache Doris 2.0 引入了 Pipeline 执行模型作为查询执行引擎。在 Pipeline 执行引擎中，查询的执行是由数据来驱动控制流变化的， 各个查询执行过程之中的阻塞算子被拆分成不同 Pipeline，各个 Pipeline 能否获取执行线程调度执行取决于前置数据是否就绪，因此实现了以下效果：

• Pipeline 执行模型通过阻塞逻辑将执行计划拆解成 Pipeline Task，将 Pipeline Task 分时调度到线程池中，实现了阻塞操作的异步化，解决了 Instance 长期占用单一线程的问题。
• 可以采用不同的调度策略，实现 CPU 资源在大小查询间、不同租户间的分配，从而更加灵活地管理系统资源。
• Pipeline 执行模型还采用了数据池化技术，将单个数据分桶中的数据进行池化，从而解除分桶数对 Instance 数量的限制，提高 Apache Doris 对多核系统的利用能力，同时避免了线程频繁创建和销毁的问题。

通过 Pipeline 执行引擎，Apache Doris 在混合负载场景中的查询性能和稳定性都得以进一步提升。

参考文档：