Doris凭什么这么强？

Original 涤生-阳哥涤生大数据

2024-12-05

要说在OLAP领域的数据库，就不得不提起源于百度palo的Apache 顶流项目Doris。但是按照一贯的思维，各种强势的大数据时代的OLAP产品，比如Kylin、ClickHouse、Elasticsearch、Snowflake、BigQuery、Greenplum、Impala等等，都不是由国内人员主导或者主要参与贡献的，所以Doris在这一方面可谓是独树一帜，但他同作为大数据时代浪潮下的OLAP数据库，它凭什么能够在强者如云的数据库领域，争得一席之地并成为了Apache的顶流项目？

1.强大的处理引擎

先看性能测试结果，Doris 在 ClickHouse的测试榜单上可谓是争尽风头。

那么问题来了，Doris凭什么这么强？

存储方面：

Doris 采用列式存储，按列进行数据的编码压缩和读取，能够实现极高的压缩比，同时这种设计使得Doris在处理分析查询时能够更快地定位到需要的数据列，减少了不必要的数据读取和计算，从而更加有效利用 IO 和 CPU 资源，极大的提升查询效率。

丰富的索引结构，索引是提升查询性能的一大利器，索引技术可以通过减少不必要的扫描和计算来帮助快速定位到数据，丰富的索引结构使得Doris能够应对更多的查询场景，更好的提升Doris的查询性能。

多样的存储模型，这块在Doris里面是非常重要的点，这是因为不同的查询场景对应的存储模型是完全不一致，而Doris本身也对这些模型进行了针对性的优化，从而大幅提升正确模型下的查询性能。

查询方面：

Doris 采用MPP 模型，节点间和节点内都并行执行，也支持多个大表的分布式 Shuffle Join，从而能够更好应对复杂查询。

向量化查询引擎，这使得所有的内存结构能够按照列式布局，能够达到大幅减少虚函数调用、提升 Cache 命中率，高效利用 SIMD 指令的效果。在宽表聚合场景下性能是非向量化引擎的 5-10 倍。

自适应查询执行（Adaptive Query Execution）技术，可以根据 Runtime Statistics 来动态调整执行计划，比如通过 Runtime Filter 技术能够在运行时生成 Filter 推到 Probe 侧，并且能够将 Filter 自动穿透到 Probe 侧最底层的 Scan 节点，从而大幅减少 Probe 的数据量，加速 Join 性能。
Doris的优化器是采用 CBO 和 RBO 结合的优化策略，RBO 支持常量折叠、子查询改写、谓词下推等，CBO 支持 Join Reorder。（强烈推荐2.1的新优化器，嘎嘎猛）。

2.极低的运维成本

运维是所有大数据领域里面最逃不掉的东西，尤其是对于使用开源的产品的小伙伴来说，更是不可回避的问题（有钱买商业化服务的另说）。

相对比很多OLAP各种各样的组件的组合，Doris倒是显得很独树一帜！他只有Frontend（FE）和Backend（BE）两类进程，架构极其简单！（存算分离架构多了一个Meta Service，但相对来说也是很简单的）。

架构简单，带来最大的好处就是运维极简，因为你要处理的组件少了很多，各种组件之间的兼容性问题就是没了。你唯一需要处理的就是FE和BE这两类进程了，而这两类进程又能通过一致性协议来保证服务的高可用和数据的高可靠，这样来看这个方面，又少了不少烦恼。

在扩缩容方面来说，Doris只需要简单的命令即可实现，无需人工干预，FE能够实现快速上下线，而BE也能够实现数据的自动reblance。

而对于BE来说，Doris能够自动管理数据副本的分布、修复（定期自动进行 bad tablet 的修复）和均衡（新增/下线磁盘、节点都可以自动均衡），用户无需过多关心（唯一需要担心的就是一定要保证3副本，这是高可用的前提）。

3.强大的适配能力

单纯看数据库的能力是没有任何意义的，尤其是在OLAP领域，上下游的适配能力是能够极大的影响数据库的发展的。而Doris的快速发展，正是得益于它对于MySql的高度兼容性。

Doris 采用 MySQL 协议，高度兼容 MySQL 语法，支持标准 SQL，这就使得所有支持 MySQL 协议的上下游工具，都能极大的兼容性支持Doris。一方面对于Doris社区的发展来说，这就很大程度上减少了Doris与上下游各种工具的适配开发工作，另一方面，对于社区用户来说，学习以及使用上基本是与MySql一致的，那就极大的降低了学习和使用成本。

而且得益于社区的对Doris的不断完善，目前Doris对于上下游数据的流转已经变得非常方便了。