Doris - 核心原理、特点、以及架构详解
作者：hangge | 2024-11-14 08:31
1，什么是 Doris？
（1）Doris 是一个现代化的 MPP 分析型数据库产品，“亚秒”级响应，可以有效地支持实时数据分析。
（2）Doris 的分布式架构非常简洁，易于运维，并且可以支持 PB 级别以上的超大数据集。
（3）Doris 可以满足多种数据分析需求。例如：固定的历史报表、实时数据分析、交互式数据分析、探索式数据分析等。它可以使数据分析工作更加简单高效。
（4）Doris 的典型应用场景和 ClickHouse 类似，目前在企业中常见的也是构建实时数据仓库。
2，Doris 采用的技术
（1）Doris 主要整合了 Google Mesa（数据模型）、Apache Impala（MPP 查询引擎）和 ApacheORCFile（存储格式、编码和压缩）的技术。
- Google Mesa：可以满足我们许多存储需求的需求，但是 Google Mesa 本身不提供 SQL 查询引擎。
- Apache Impala：是一个非常好的 MPP SQL 查询引擎，但是缺少完美的分布式存储引擎。
- Apache ORCFile：存储层对存储数据的管理通过 storage_root_path 路径进行配置，路径可以是多个。存储目录下一层按照分桶进行组织，分桶目录下存放具体的 tablet，按照 tablet_id 命名子目录。
3，Doris、DorisDB 和 StarRocks 的关系
- Doris 是百度自主研发的一款 MPP 分析型数据库产品，最初名为 PALO，由于和国外的产品同名，所以改名为 Doris，于 2018 年贡献给 Apache 社区。Doris 使用的是 Apache License 2.0 协议。
- 2020 年 2 月，百度 Doris 团队中的一些成员离职创业，做出了商业化闭源产品 DorisDB。
- 2021 年 9 月 DorisDB 被改名为 StarRocks，并且开源。StarRocks 使用的是 Elastic License2.0 协议。
提示：采用 Elastic License 2.0 协议还是 Apache License 2.0 协议对于普通企业用户没有什么影响，对云服务厂商会有一定影响。
4，Doris 的核心特性
- 现代化 MPP 架构：MPP 表示支持大规模并行处理。
- “秒”级查询返回延时：查询性能比较高。
- 支持标准 SQL，兼容 MySQL 协议：Doris 是支持增删改查功能和完整事务的，并且也支持较好的多表 JOIN 操作策略和灵活的表达式查询。
- 向量化执行器：和 ClickHouse 中的“向量引擎”是一个意思，都是为了高效地使用 CPU。
- 高效的聚合表技术：在数据聚合方面有自己的特色。
- 新型预聚合技术 Rollup：Rollup 属于多维分析中的概念，表示将数据按照某种粒度进行聚合。Rollup 可以被理解为表的一个物化索引结构，Rollup 可以调整列的顺序以增加前缀索引的命中率，也可以减少列以增加数据的聚合度。在基础明细表之上，可以基于常用的聚合维度创建多个 Rollup，当后期在基础明细表中使用相同聚合维度进行查询时，会自动命中之前创建的 Rollup，直接查询预聚合后的数据，提高查询效率。通过这种技术可以同时支持明细查询和预聚合查询。
- 高性能、高可用、高可靠：Doris 集群是非常稳定的，并且性能也高。
- 极简运维，弹性伸缩：ClickHouse 集群的运维复杂度遭到运维人员的不满，而 Doris 在这方面做得比较好，运维比较简单，集群扩容也比较方便。
5，Doris 存在的缺点
- 大数据生态圈兼容度一般：Doris 可以被认为是传统的数据库，不属于大数据生态圈中的技术，所以和大数据生态圈技术的兼容度一般。
- 不兼容 Hive SQL：由于 Doris 支持标准 SQL，所以不支持 Hive SQL 的一些特性。从 Hive 切换到 Doris 有一定的成本。
- 目前社区和生态圈成熟度一般：Doris 目前属于快速发展阶段，整体成熟度一般。
6，架构分析
（1）Doris 的架构很简洁，只有 FE（Frontend）和 BE（Backend）这两种角色，如下图所示：
（2）FE 和 BE 这两种角色不依赖外部组件，方便部署和运维。
- FE 主要负责查询的编译、分发和元数据管理。
- BE 主要负责查询的执行和物理数据的存储。
附：对比 Druid、ClickHouse 和 Doris
Druid、ClickHouse 和 Doris 都适合应用于实时 OLAP 数据分析领域，不过它们各有特色，在技术选型时需要结合具体业务需求进行考虑。这 3 个实时 OLAP 引擎的对比如下。
- Druid：主要针对时间序列数据提供低延时的数据写入及快速交互式 SQL 查询，适合被应用在海量实时数据的交互式分析场景中。其可以基于时间维度对实时产生的明细数据自动实时聚合，提高查询效率。它有一个比较明显的缺点——对 SQL 支持有限。在 Druid 0.18 版本之前它是不支持 JOIN 操作的，从 0.18 版本开始它有限支持 JOIN 操作，目前主要支持 INNER JOIN、LEFT JOIN 和 CROSS JOIN。
- ClickHouse：可以提供海量实时数据的快速写入，以及基于 SQL 的快速实时查询，适合应用在海量实时数据的交互式分析场景中。其支持非标准 SQL，有限支持 JOIN 操作，目前在实时数据仓库领域应用得比较广泛。
- Doris：可以通过 SQL 实现实时数据分析，适合应用在海量实时数据的交互式分析场景中。其对 SQL 支持比较好，支持 JOIN 操作。Doris 和 ClickHouse 是比较类似的，但是 Doris 目前的成熟度暂时还不如 ClickHouse。
说明：
- 查询性能：这 3 个组件的查询性能都比较高。
- 高并发：Druid 和 Doris 可以支持高并发，ClickHouse 的并发能力有限。
- 实时数据摄入：因为都属于实时 OLAP 引擎，所以它们都支持实时数据摄入。
- 实时数据更新：Druid 是不支持实时更新的，只能通过后台批处理任务实现覆盖更新。ClickHouse 支持实时更新，只是功能比较弱。Doris 可以正常支持实时更新。
- 支持 JOIN 操作：在基于 SQL 实现统计分析时，是否支持 JOIN 操作是一个比较重要的指标。Druid 和 ClickHouse 都支持 JOIN 操作，但是支持度有限。Doris 可以正常支持 JOIN 操作。
- SQL 支持程度：Druid 对 SQL 的支持度是有限的，ClickHouse 支持非标准 SQL，Doris 支持标准 SQL（相对较好）。
- 成熟程度：Druid 和 ClickHouse 的成熟程度比较高，Doris 目前正处于快速发展阶段。
- 运维复杂度：ClickHouse 运维比较复杂，Druid 运维难度中等，Doris 运维最简单。
全部评论（0）