Doris企业架构选型总结：存算分离与一体化的对比与应用场景分析

Apache Doris概述

Apache Doris 是一款基于 MPP 架构的高性能、实时的分析型数据库，以高效、简单、统一的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。基于此，Apache Doris 能够较好的满足报表分析、即席查询、统一数仓构建、湖仓一体等使用场景，用户可以在此之上构建大屏看板、用户行为分析、AB 实验平台、日志检索分析、用户画像分析、订单分析等应用。

如下图所示，数据源经过各种数据集成和加工处理后，通常会入库到实时数据仓库 Apache Doris 和离线湖仓（Hive, Iceberg, Hudi 中），Apache Doris 被广泛应用在以下场景中。

• 报表分析

• 实时看板（Dashboards）

• 面向企业内部分析师和管理者的报表

• 面向用户或者客户的高并发报表分析（Customer Facing Analytics）。比如面向网站主的站点分析、面向广告主的广告报表，并发通常要求成千上万的 QPS，查询延时要求毫秒级响应。著名的电商公司京东在广告报表中使用 Apache Doris，每天写入 100 亿行数据，查询并发 QPS 上万，99 分位的查询延时 150ms。

• 即席查询（Ad-hoc Query）：面向分析师的自助分析，查询模式不固定，要求较高的吞吐。小米公司基于 Apache Doris 构建了增长分析平台（Growing Analytics，GA），利用用户行为数据对业务进行增长分析，平均查询延时 10s，95 分位的查询延时 30s 以内，每天的 SQL 查询量为数万条。

• 湖仓一体（Data Lakehouse）：通过外表的方式联邦分析位于 Hive、Iceberg、Hudi 等离线湖仓中的数据，在避免数据拷贝的前提下，查询性能大幅提升。

• 日志检索分析：在 Apache Doris 2.0 版本中，支持了倒排索引和全文检索，能够很好的满足日志检索分析的场景，并且依赖其高效的查询引擎和存储引擎，相比传统的日志检索分析的方案可以有 10 倍性价比的优势。

• 统一数仓构建：一个平台满足统一的数据仓库建设需求，简化繁琐的大数据软件栈。海底捞基于 Apache Doris 构建的统一数仓，替换了原来由 Spark、Hive、Kudu、Hbase、Phoenix 组成的旧架构，架构大大简化。

存算分离 vs 存算一体

Doris 的整体架构由两类进程组成：Frontend (FE) 和 Backend (BE)。其中 FE 主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作；BE 主要负责数据存储、查询计划的执行。而不论是存算一体还是存算分离都是基于这两类进程进行构建。

存算分离架构分析

从 3.0.0 版本开始，Doris 支持计算存储解耦模式，允许用户通过多个计算集群对业务负载进行物理隔离，实现读写分离。该模式通过利用成熟的对象存储或 HDFS 大幅降低存储成本，并缓解磁盘均衡、多个 BE 节点离线导致数据丢失等运维复杂性。（SelectDB Cloud版本很早就有了云原生存算分离架构）

Doris 存算分离的整体架构为三层结构：元数据层、计算层、数据存储层。

元数据层：提供系统的元数据服务，如数据库表、Schema、Rowset元数据、事务等。

• FE 主要存放库表元数据，Job 以及权限等 MySQL 协议依赖的信息；

• Meta Service 是 Doris 存算分离元数据服务，主要负责处理导入事务，Tablet Meta，Rowset Meta 以及集群资源管理。这是一个可以横向扩展的无状态服务，它依赖了一个高性能分布式事务 KV（即 FoundationDB）来存储元数据。

计算层：负责执行查询计划并通过计算集群提供负载隔离。计算节点完全无状态，本地数据作为远程存储的缓存，以加速查询。

• Cache上会缓存一部分 Tablet 元数据和数据以提高查询性能

数据存储层：数据持久化到共享存储，目前支持S3、OSS、COS、GCS、Azure Blob、MinIO、BOS、HDFS。

• 共享存储主要存放数据文件，包括 Segment 文件、反向索引的索引文件等。

存算一体架构分析

存算一体化架构是Doris自诞生以来的核心架构，也是未来一直会存在的架构。存算分离是趋势，但是存算一体仍有一席之地！

FE：主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。

BE: 主要负责数据存储、查询计划的执行。

在存算一体架构下，BE 节点上存储与计算紧密耦合，数据主要存储在 BE 节点上，多 BE 节点采用 MPP 分布式计算架构。其中，FE和BE都是可以横向扩展的，单集群可以支持到数百台机器，数十 PB 的存储容量。

如何根据业务需求选择架构

大家一直说，存算分离是未来发展的必然趋势，那我们先分析存算分离架构到底解决了什么问题。

存算分离的特点如下：

• 资源独立扩展：存储和计算资源可以根据业务需求分别进行扩展和优化，不必再同时增加存储和计算资源。

• 资源弹性管理：计算资源可以根据负载情况灵活调度和管理，存储资源则可以独立进行优化和管理。

• 降低存储成本：采用共享存储或云存储，能够显著降低存储的成本，并提高存储资源的利用率。

• 计算资源的高效利用：计算资源不再被存储需求所束缚，可以针对不同的计算任务进行高效利用和调度。

• 高可用性和数据安全性：存储和计算的分离提高了系统的高可用性和容灾能力，数据可以集中管理和备份，提高数据的安全性。

• 资源隔离能力：存算分离体系中可以将不同的计算资源按组别划分，不同的计算资源组之间可以做到互相之间完全的物理隔离。

这些特点自然带来的就是成本的极大节约（对象存储的成本更低，而且不需要考虑多副本），资源根据业务需求弹性伸缩，按需分配（最大化的提高了资源利用率），数据的高可用和资源隔离（对象存储可通过纠删码或者多副本来实现数据可靠性，同时不同的资源能够按组划分）。

这些似乎看起来很完美的解决企业面临的重大问题。但是他这些架构特点也会带来一些弊端。

• 网络延迟问题：由于计算和存储分离在不同节点或不同数据中心，数据在计算节点与存储之间的传输会引入网络延迟，即使你可以通过预热一部分数据来提升查询效率，但是如果缓存数据没有命中，这就需要从远端对象存储拉取数据，这个效率可想而知。

• 流量激增问题：纵然存算分离的弹性扩缩容是为了解决不同时间段，业务低谷或者峰谷的问题，但是在应对非预期流量暴增的情况下，计算资源是无法迅速响应的。

• 数据一致性和同步问题：由于数据存储在共享存储系统中，而且由于资源隔离的问题，不同的计算组的所做的计算任务是不同的，那么数据一致性和同步需要额外的机制来保障，这就考虑像传统TP库一样来加锁了，随之而来的就是系统的设计和实现难度的增加。

• 架构复杂度增加：存算分离架构引入了更多的组件，增加了系统的复杂性和运维的难度。从上面Doris 的架构图我们就可以看出来。

很明显，存算分离架构并不是万能的。他在解决这些问题的时候，自然也带来了一些其他的问题。那既然存算分离有利有弊，我们该如何合理选择架构呢？

这里主要考虑的问题存算一体能否解决上面的问题，或者规避上面的问题，又或者是在不同的问题之间做权衡。

• 资源独立扩展：Doris自从1.2.1版就引入计算节点（Compute Node）功能。计算节点作为一种特殊类型的 BE 节点，没有数据存储能力，只负责数据计算。因此，可以将计算节点看做是无状态的 BE 节点，可以方便的进行节点的增加和删除。

• 资源弹性管理：这块只能是综合考虑了，唯一能做到弹性的就是计算节点的弹性管理，存储节点的上下线都是比较耗时的。

• 降低存储成本：这在很多OLAP的数据库都是可以通过冷热分层来解决的，Doris也是如此。

• 计算资源的高效利用：类似资源弹性管理。

• 高可用性和数据安全性：这块可以通过多副本来解决，当然了，也会带来一定的存储成本的增加。

• 资源隔离能力：Resource Group 和 WorkLoad Group 对于资源隔离来说也是一种不错的解决方案。

这样来看，几乎大部分存算分离的场景在存算一体的架构中，都能有较为合理的方式来解决。那针对这些问题，该如何选择架构呢？

这不仅取决于你的业务，更取决于你公司的实际资源情况。中小公司没有太大的必要搞存算分离，收益不明显，甚至会带来更多的运维问题。而对于一些大的云厂商（本身就有非常大的资源可供分配）、或者大型企业（整个企业业务众多，资源用量大，有专门的运维团队，降本增效效果明显）是完全可以考虑存算分离的架构的。

请谨记：没有绝对好的架构，只有更适合业务的架构！

涤生大数据往期精彩推荐