元数据支持存储计算分离

在存储计算架构中，数据可能存储在本地、远端，或同时存储在本地和远端。当数据存储在远端时，本地存储将作为一个全量Cache存在。在这种架构，现有的以下流程需求进行重新设计：

• Backend 的元数据管理
• 建表或创建分区时数据分片的分布管理
• 数据副本的修改，数据分片的修复和均衡
• 数据导入控制
• StorageMedium 分级存储
• Backend 节点的上下线操作
• 和现有元数据的兼容方案

本文档针对以上问题进行说明。

目标

基于新的设计，我们希望 Doris 获得以下新的特性：

• 支持全部数据存储在远端存储

当全部数据都塞远端存储后，本地节点可以非常灵活的添加或删除，而无需进行数据的重分布等操作。

• 支持数据副本的存储位置

通过将数据的副本存储在不同的节点，可以将对同一个表的在线、离线业务进行物理隔离。

• 支持多机房部署

支持将一个 Doris 集群同时在多个机房机型部署。

概念解释

在存储计算分离中，我们将引入几个新的概念。

Resource

资源。可以为 Doris 提供某种服务的实体。比如 Backend 是一种资源，Broker 也是一种资源。资源需要先通过命令加入到 Doris 集群中才能被使用。

Resource Tag

资源标签。一个资源可以被赋予一个或多个标签。标签可以让用户自定义的描述一个资源，如资源的功能、属性等等。

每一个标签都归属一个类型。对标签进行分类，可以某些场景下，通过类型来晒选出合适标签，而无需指定标签的名称。本期 Doris 提供两个内置的类型：

• type：包含表示资源类型的标签。
• function：包含表示资源功能的标签。
• location：包含表示物理的位置的标签，如机房、机架等
• custom：包含用户自定义的标签。

标签的表示方法为："tag.type" = "tag1.tag2"。其中 tag 是关键词。如：

"tag.location" = "zone1,rack1",
"tag.type" = "store,computation"

内置资源和标签

Doris 会内置一些资源和他们的标签。

内置标签

• type

• frontend：FE

• backend：BE

• broker：Broker

• remote_storage：RemoteStorage

• function

• store：表示拥有数据存储功能

• computation：表示拥有计算功能

• location

• default：默认的位置标签

内置资源

• Frontend

FE 节点。和先用 FE 功能保持一致（请求接入、元数据管理、查询计划生成等）。默认拥有标签：

"tag.type" = "frontend"

• Backend

BE 节点。当前 BE 节点提供存储和计算属性。后续可能会加入仅存储、仅计算、仅导入等属性。默认拥有标签：

"tag.type" = "backend",
"tag.function" = "store, computation",
"tag.location" = "default_cluster"

• Broker

Broker 节点。和现有功能保持一致（为远端存储提供文件系统读写接口）。默认拥有标签：

"tag.type" = "broker"

• RemoteStorage

远端储存。用于在计算存储分离架构下，提供远端存储属性。默认拥有标签：

"tag.type" = "remote_storage",
"tag.function" = "store"

资源管理

资源可以被添加或删除。资源可以添加、删除或修改资源标签。

添加资源

对 Doris 中已有的资源（FE、BE、BROKER），为保证兼容性，我们沿用现有的操作命令。同时，新增增加 Remote Storage 的命令。

ALTER SYSTEM ADD FOLLOWER xxx;
ALTER SYSTEM ADD BACKEND xxx;
ALTER SYSTEM ADD BROKER xxx;
ALTER SYSTEM ADD REMOTE STORAGE xxx;

上述为默认的资源添加语句。在添加语句中，也支持自定义资源标签。举例如下：

ALTER SYSTEM ADD BACKNED "host:ip"
PROPERTIES(
    "tag.function" = "store, computation",
    "tag.location" = "rack1, asia"
);

ALTER SYSTEM ADD REMOTE STORAGE WITH BROKER broker_name
PROPERTIES(
    "path" = "/path/"
    "username" = "user",
    "password" = "pass",
    "tag.function" = "store",
    "tag.location" = "rack1, asia"
);

删除资源

资源可以被删除，对于现有资源，删除方式和现在保持一致。

ALTER SYSTEM DROP BACKEND xxx;
ALTER SYSTEM DROP FOLLOWER xxx;
ALTER SYSTEM DROP BROKER xxx;
ALTER SYSTEM DROP REMOTE STORAGE xxx;

修改资源

资源可以被修改，如增加或删除资源属性、修改资源组等。示例如下：

ALTER SYSTEM MODIFY BACKEND "host:ip"
PROPERTIES (
    "tag.xxx" = "xxx"
)

对 store 属性的修改可能会导致数据迁移，需要配合副本修复流程一起修改。

资源选择

统一通过标签来选择资源。比如选择 tag 为 asia 和 rack1 Backend，则可以通过以下标签组合来选择：

{
    "tag.type" = "backend"
    "tag.location" = "asia,rack1"
}

资源使用

资源创建并正常加入集群后，才能被使用。这里主要介绍有改动的一些操作的使用方式。

创建表和分区

创建表和分区时，可以指定资源组。Doris 会在资源组中寻找拥有 Store 属性的资源，进行数据分片副本的分布。同时我们示例如下：

CREATE TABLE tbl1 (k1 int) DISTRIBUTED BY HASH(k1) BUCKETS 4
PROPERTIES (
    "backend.tag.location" = "rack1:2",
    "backend.tag.location" = "rack2:1",
    "remote_storage.tag.location" = "zone1"
);

其中 backend.tag 指定了副本在本地存储中的分布，必选。如上表示在标签为 rack1 的 Backend 中部署2副本，在标签为 rack2 中 Backend 中部署1副本。remote_storage.tag 表示使用的远端存储的标签，可选。

ALTER TABLE tbl2 ADD PARTITION p2 VALUES LESS THAN("200")  
(
    "backend.tag.location" = "rack1:2",
    "backend.tag.location" = "rack2:1",
    "remote_storage.tag.location" = "zone1"

LocalMode 和 RemoteMode

必须为一个表或分区指定至少一个 backend.tag。每个 Backend 存放至少1个副本。

remote_storage.tag 至多一个。如果不指定，则相当于一个LocalMode表。如果指定，则这是一个RemoteMode的表。

通过在建表时设置 backend.tag 和 remote_storage.tag，确定了一个表是 LocalMode 还是 RemoteMode。这个属性后续不可修改。但是可以修改 backend.tag 和 remote_storage.tag。比如为不同的分区指定不同的 Tag 等。

为保持兼容，当用户指定 "replication_num" = "3" 时，等同于：

"backend.tag.location" = "default_cluster:3"

如果指定 backend.tag 属性，replication_num 将失效。

修改副本和数据分片管理

ALTER TABLE MODIFY PARTITION p1 SET ("backend.tag.xxx" : "xxx");

对于 LocalMode 或 RemoteMode 的表，都可以通过这个方式更换本地副本的 backend.tag，以及每个 backend.tag 中副本的数量。副本检查模块会检查并开始迁移副本。RemoteMode 的副本会直接从远端存储下载数据。

remote_storage.tag 暂不支持修改。

对于LocalMode的表。数据分片的管理方式和现在相同，区别在于需要按照 tag 粒度进行数据分片的修复和均衡。

对于RemoteMode的表。数据分片在本地的管理方式和 LocalMode 相同。但 RemoteMode 允许用户删除所有 backend.tag（类似关闭集群），此时集群将处于冻结状态（TODO：当需要删除所有 backend.tag 时，需要将表先进入一个“冻结“状态，用于同步还没有同步到 remote_storage.tag 的数据）。

导入控制

对于LocalMode的表，导入和之前流程一样。
对于RemoteMode的表。我们会在建表时，指定一个本地副本作为 PrimaryReplica。导入请求会尽量发给 PrimaryReplica，由 PrimaryReplica 完成导入并通知其他副本同步数据。如果 PrimaryReplica 不可用（比如节点宕机，PrimaryReplica多次导入失败等），也可以将导入发给其他节点。

FE 根据一定得策略来判断是否需要更换 PrimaryReplica。当 PrimaryReplica 在一段时间内不可用后，会切换一个新的副本作为 PrimaryReplica。尽量不切换 PrimaryReplica，防止频繁切换导致的冷数据问题。

Storage Medium 分级存储

本期我们先不支持 RemoteMode 表的分级存储功能。在存储计算分离框架下，这个功能可能被其他方案取代（比如新的缓存策略）

查询

用户可以在查询某个表时，通过 hint 的方式，来指定使用满足某些标签的资源进行查询

SELECT * FROM TBALE /*+ tag:tag1,tag2,... */

权限控制

可以通过 SET PROPERTY 语句将一个或多个资源标签赋予某个用户，则该用户可以查询其有权限访问的表的在这些标签所属资源上的副本。当一个用户没有任何标签时，即使有表的 SELECT 权限，也无法执行查询。为保证兼容，默认所有用户拥有 backend 标签的权限。

对于 LocalMode 的表，当修改了表的 backend.tag 后，可能因为新的 Storage 中数据还没有 ready 而无法查询。因此我们建议先增加新的 tag，再删除旧的 tag。RemoteMode 不存在这个问题，查询会直接从远端存储拉取数据，不过第一次查询会较慢。

Cluster

我们希望新的设计能够取代之前的多 cluster 功能。所以要对多 cluster 进行一些兼容性改建。当前多 cluster 主要有以下功能和命令：

• CREATE CLUSTER

创建一个 cluster 对象。不再使用，替换为单独为 BE 添加标签

• DROP CLUSTER

把cluster包含的 backend 设为 free。不再使用，替换为单独删除 BE 的标签。

• ADD FREE BACKNED

增加一个没有标签的 BE。继续保留。

• ADD BACKEND TO CLUSTER

将 Backend 增加到一个 cluster 中。保留，但建议替换为为 BE 增加标签的语句。

• ALTER CLUSTER

cluster 中的节点扩缩容，或者decommission 某个 BE。不再支持，替换为为Backend 增加会删除标签。

• LINK Database

不再支持，当用户想查询某个db时，直接授权db读权限，并授权对应标签即可。

• MIGRATION Database

不再支持。替换为修改表的副本的标签。

• Enter cluster

支持，但该命令不再产生任何实际改动。（原先会设置 context 中的 cluster name）。即使enter 一个错误的 cluster，系统也不会报错。

同时，我们需要对集群内已存在的 cluster 相关的元信息进行变换已兼容新的框架：

• Backend

属于某一 cluster 的 backend，将被添加标签 "tag.location" = "cluster_name"。对于 FREE 的backend，无标签。

• Database

属于某一 cluster 的 database。会将database下所有表的副本的标签设置为 cluster_name。

• User

属于某一 cluster 的 user。变更为给user这个 cluster name 标签的权限。

使用场景

这里介绍一下在 tag 系统框架下的一下典型使用场景

多机房部署

一个 Doris 集群可以将 BE 部署在不同的机房以保证数据的可靠性。我们可以通过 tag.location 区分不同机房的 BE。用户在建表时，可以指定将副本存储在不同 tag.location 的 BE 上。或者仅说明是否要进行多机房部署，Doris 会自动根据不同的 tag.location 来分配副本。

在多机房部署场景下，查询会自动选择同一个机房内的副本进行查询。如果机房不可用，Doris 可以自动切换到另一个可用机房。

独立资源、共享数据

当数据支持存储在远端存储系统中后，用户可以方便的单独启动一组 BE 资源并分配 tag。然后将希望使用的表或分区的副本扩展到这些 BE 上。这种方式可以用户分离一些业务场景，比如 QA 环境，DEV 环境等，可以共享一套数据，但是使用独立的计算资源。