Apache Doris - 架构

一、架构

 

FE（Frontend） 和 BE（Backend）节点

FE 为Doris 的前端节点。主要负责接收和返回客户端请求、元数据以及集群管理、查询计划生成等工作；

BE 为Doris 的后端节点。主要负责数据存储与管理、查询计划执行等工作；

1. FE 节点分为 follower 和 observer 两类。各个 FE 之间，通过 bdbje（BerkeleyDB Java Edition (opens new window)）进行 leader 选举，数据同步等工作。

2. follower 节点通过选举，其中一个 follower 成为 leader 节点，负责元数据的写入操作。当 leader 节点宕机后，其他 follower 节点会重新选举出一个 leader，保证服务的高可用。

3. observer 节点仅从 leader 节点进行元数据同步，不参与选举。可以横向扩展以提供元数据的读服务的扩展性。

4. BE节点存储数据，用户数据被拆分最小粒度为tablet，每个tablet默认3个副本，分别放在不同ip的机器上（同一机器启动3个BE进程视为一台机器，仅存放一份），保证数据安全及高可用。

二、连接Doris

使用MySQL 的 ODBC/JDBC以及MySQL 的客户端连接Doris，且：

1. Doris 兼容 MySQL 的网络协议 ( MySQL Network Protocol )

2. Doris 兼容 MySQL 语法，使用 MySQL 语法可对 Doris 数据库进行查询

三、元数据管理

Doris 的元数据是全内存的。每个 FE 内存中，都维护一个完整的元数据镜像。

同时，元数据在内存中整体采用树状的层级结构存储，并且通过添加辅助结构，能够快速访问各个层级的元数据信息。

如上图，Doris 的元数据主要存储4类数据：

1. 用户数据信息。包括数据库、表的 Schema、分片信息等。
2. 各类作业信息。如导入作业，Clone 作业、SchemaChange 作业等。
3. 用户及权限信息。
4. 集群及节点信息。

 如图，元数据的数据流具体过程：

1. 只有 leader FE 可以对元数据进行写操作。写操作在修改 leader 的内存后，会序列化为一条log，按照 key-value 的形式写入 bdbje。其中 key 为连续的整型，作为 log id，value 即为序列化后的操作日志。

2. 日志写入 bdbje 后，bdbje 会根据策略（写多数/全写），将日志复制到其他 non-leader 的 FE 节点。non-leader FE 节点通过对日志回放，修改自身的元数据内存镜像，完成与 leader 节点的元数据同步。

3. leader 节点的日志条数达到阈值后（默认 10w 条），会启动 checkpoint 线程。checkpoint 会读取已有的 image 文件，和其之后的日志，重新在内存中回放出一份新的元数据镜像副本。然后将该副本写入到磁盘，形成一个新的 image。之所以是重新生成一份镜像副本，而不是将已有镜像写成 image，主要是考虑写 image 加读锁期间，会阻塞写操作。所以每次 checkpoint 会占用双倍内存空间。

4. image 文件生成后，leader 节点会通知其他 non-leader 节点新的 image 已生成。non-leader 主动通过 http 拉取最新的 image 文件，来更换本地的旧文件。

5. bdbje 中的日志，在 image 做完后，会定期删除旧的日志。

参考文档：

Apache Doris 官网 ：编译 | Apache Doris