亲爱的社区小伙伴们,我们很高兴地向大家宣布,在近期我们迎来了 Apache Doris 3.0 版本的正式发布,欢迎大家下载使用体验!
从 3.0 系列版本开始,Apache Doris 开始支持存算分离模式,用户可以在集群部署时选择采用存算一体模式或存算分离模式。基于云原生存算分离的架构,用户可以通过多计算集群实现查询负载间的物理隔离以及读写负载隔离,并借助对象存储或 HDFS 等低成本的共享存储系统来大幅降低存储成本。
3.0 版本是 Apache Doris 在湖仓一体演化路线上的重要里程碑版本。在 3.0 版本中 Apache Doris 增加了数据湖写回功能,用户可以在 Apache Doris 中完成多个数据源之间的数据分析、共享、处理、存储操作。结合异步物化视图等能力,Apache Doris 可以作为企业统一的湖仓数据处理引擎,帮助用户更好的管理湖、仓、数据库中的数据。与此同时,3.0 版本引入了 Trino Connector 类型,用户可以快速使用 Trino Connector 来连接或适配更多数据源、并可以利用 Apache Doris 的高性能计算引擎提供比 Trino 更快的数据查询能力。
3.0 版本同样对 ETL 批处理场景进行了增强,对insert into select、delete 和 update 操作提供了显式事务支持;对查询执行过程中的可观测性进行了增强。
在性能方面,3.0 版本的查询优化器在框架能力、基础设施以及规则扩充等方面做了重要增强,针对更复杂更多样的业务场景提供更极致的优化能力,盲测性能更高。实现了自适应的 Runtime Filter 计算方式,能够在运行时根据数据大小准确估算 Runtime Filter,在大数据量和高压力场景下有更好的性能表现。对异步物化视图的构建能力、透明改写能力以及性能均进行了增强,使得物化视图在查询加速、数据建模等场景具有更好的稳定性和易用性。
在 3.0 版本的研发过程中,有超过 170 名贡献者为 Apache Doris 提交了近 5000 个优化与修复。 来自飞轮科技、百度、美团、字节跳动、腾讯、阿里、快手、华为、天翼云等企业的贡献者与社区深度共建,贡献了大量来自真实业务场景下测试 Case 来帮助我们持续打磨、共同改进,在此向所有参与版本研发、测试和需求反馈的贡献者们表示最衷心的感谢。
1. 存算分离全新架构
从 Apache Doris 3.0 版本开始,Apache Doris 开始支持存算分离模式,用户可以在集群部署时选择采用存算一体模式或存算分离模式。
全新存算分离模式对计算与存储进行了解耦,计算节点不再存储主数据,而是引入共享存储层(HDFS 与对象存储)作为统一的数据主存储空间,计算资源和存储资源可以独立扩缩容,为用户带来了多方面价值:
-
负载隔离:多个计算集群共享同一份数据,用户可以使用多计算集群对不同业务或者在离线的负载进行隔离;
-
存储成本大幅降低:全量数据存储到成本更低且极其可靠的共享存储中,热数据仅在本地 Cache,相比存算一体三副本,存储成本最高下降至原先的 1/10;
-
计算资源弹性:数据不保存在计算节点,计算资源可以按照负载需求实现灵活弹性扩缩容,比如单个计算集群的扩缩容或者加减计算集群,弹性带来了资源配置的灵活性以及成本的降低;
-
系统鲁棒性的提升:数据存储到共享存储,Doris 不再有多副本一致性的逻辑,会大幅度简化分布式存储带来的复杂度,从而会提升系统的鲁棒性。
-
数据共享和克隆的灵活性:存算分离架构的灵活性不止在一个 Doris 集群内部,在跨 Doris 集群时也应该体现出灵活性,比如 Doris 集群 A 中的库表可以轻量地在 Doris 集群 B 中完成克隆,即只做元数据级别的复制,不做数据的复制。
1-1. 从存算一体到存算分离
在存算一体模式中,Apache Doris 整体由 Frontend(FE)和 Backend(BE)两类进程组成,其中 FE 节点主要负责用户请求接入、查询解析规划、元数据管理和集群管理等相关工作,BE 节点主要负责数据存储和查询计划的执行,多 BE 节点间采取 MPP 分布式计算架构,通过多副本一致性协议来帮助服务的高可用和数据的高可靠。

新兴云计算基础设施的成熟,无论是公有云、私有云以及基于 K8s 的容器平台,云计算基础设施的革新催生了新的需求,越来越多用户期待 Apache Doris 针对云计算基础设施提供更加深度的适配,以便提供更加灵活强大的弹性能力,因此飞轮科技团队早在 2022 年基于 Apache Doris 设计并实现了云原生存算分离版本(SelectDB Cloud),在经过数百家企业近两年的大规模生产打磨后,将其贡献回 Apache Doris 社区,即当前 3.0 版本的存算分离模式。
在存算分离模式下,Apache Doris 整体架构演化成元数据层、计算层和共享存储层三层:
-
元数据层:新引入 Meta Service 模块来提供系统的元数据服务,例如库表、Schema、Rowset Meta、事务等信息,是一个可以横向扩展的无状态服务。目前 BE 的 Meta 已经全部进入了 Meta Service,FE 的部分 Meta 已进入 Meta Service,其它 Meta 在后续版本中也会全部进入 Meta Service。
-
计算层:负责执行查询规划,计算节点即无状态的 BE 节点,会缓存一部分 Tablet 元数据和数据到本地以提高查询性能。通过多个无状态的 BE 节点可以组成计算资源集合(即多计算集群),多个计算集群共享一份数据和元数据服务,计算集群支持随时弹性加减节点。
-
共享存储层:数据持久化到共享存储层,目前支持 HDFS 以及 S3、OSS、GCS、Azure Blob、COS、BOS、MinIO 等各类云上兼容 S3 协议的对象存储系统。

1-2 设计亮点
全新存算分离架构最大的设计亮点在于将 FE 全内存的元数据模式演变成共享的元数据服务,这一方案的优势在于,元数据服务提供了全局一致的状态视图,任何节点可以直接提交写入,不再需要经过 FE 做 Publish。写入时数据进入共享存储,元数据进入元数据服务,可以有效控制共享存储上的小文件数量,同时单表的实时写入性能和存算一体相差无几,整个系统的写入能力不再受限于单 FE 的处理能力。

基于全局一致的状态视图,在数据 GC 时,我们采用了设计上容易证明正确性和效率更高的正向数据删除。具体而言,将共享存储中的数据纳入到在共享元数据服务提供的全局一致视图中,数据生成时绑定一个事务,元数据删除时也绑定一个事务,以此可以实现删除和写入不能一起成功,视图中记录了哪些数据需要删除,异步删除过程只需要根据事务记录正向删除数据即可,不需要反向 GC。
未来随着 FE 中 Tablet 相关的 Meta 进入共享服务,Doris 集群规模也不再受限于单 FE 内存。基于共享的元数据服务和正向的数据删除技术,在此基础上可以便捷地扩展数据共享、轻量克隆等功能。
1-3 业界同类方案对比
业界还有另一种存算分离架构的设计方案,将数据和 BE 节点的 Meta 存放在共享对象存储或者 HDFS 中,该方案会有如下的问题:
-
无法承载实时写:在写入数据时,数据会根据分区分桶规则映射到 Tablet 中并生成 Segment 文件以及 Rowset Meta。在写入阶段会通过 FE 进行两阶段提交(即 Publish),在 BE 节点接到 Publish 请求后再将 Rowset 设置为可见,Publish 是不允许失败的。如果将 Rowset Meta 保存在共享存储中,实时写入过程中的小文件数据是数据文件的三倍,一次写入数据结束后生成 Rowset Meta、一次 Publish 时更改 Rowset Meta 状态。Publish 是由 FE 节点单点驱动的,不论单个表或整个系统的写入能力都受限于 FE 节点。

在 Apache Doris 3.0 版本正式发版后,我们对该方案实时数据写入性能与 Apache Doris 进行了对比。在此我们在相同计算资源下分别模拟 500 并发任务写入 10000 个 500 行的数据文件和 50 并发任务写入 250 个 20000 行的数据文件,可以看到在 50 并发下 Apache Doris 存算分离和存算一体模式的微批写入性能基本相当,而该方案写入性能与 Apache Doris 差距达到 100 倍

最低0.47元/天 解锁文章
967

被折叠的 条评论
为什么被折叠?



