Apache Doris 基础 -- 数据表设计（分层存储）

chinusyan

于 2024-06-11 17:40:46 发布

阅读量967

点赞数 22

分类专栏： BigData 文章标签： Apache Doris

本文链接：https://blog.csdn.net/chinus_yan/article/details/139528133

版权

BigData 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

1、应用场景

未来一个重要的用例是类似于ES日志存储，其中日志场景中的数据是根据日期分割的。许多数据都是查询不频繁的冷数据，因此需要降低此类数据的存储成本。考虑到节约成本:

来自不同厂商的常规云磁盘的定价比对象存储更昂贵。
Doris 集群实际在线使用时，常规云盘利用率不能达到100%。
云磁盘不按需计费，对象存储按需计费。
使用普通云磁盘实现高可用性需要多个副本和副本迁移，以防止出现故障。相比之下，将数据存储在对象存储中可以消除这些问题，因为它是共享的。

2、解决方案

在分区级别设置冻结时间，表示多久这个 Partition 会被 Freeze，并定义冻结后数据的远程存储位置。在BE(后端)守护线程中，会定期检查表的冻结状态。如果满足冻结条件，则上传数据到兼容S3协议和HDFS的对象存储。

冷热分层支持所有Doris功能，并且只将一些数据移动到对象存储中，以节省成本而不牺牲功能。因此，它具有以下特点:

冷数据存储在对象存储上，用户无需担心数据的一致性和安全性。
灵活的冻结策略，其中冷远程存储属性可以应用于表和分区级别。
用户可以查询数据，而不用担心数据的分布。如果数据不是本地的，它将从对象存储中提取，并在BE(后端)本地缓存。
副本克隆优化。如果存储的数据在对象存储上，克隆副本时不需要在本地获取存储的数据。
远程对象空间回收。当表或分区被删除或冷热分级过程中出现特殊情况导致空间浪费时，回收线程会定期回收空间，从而节省存储资源。
缓存优化，在BE中本地缓存访问的冷数据，以实现类似于非冷-热分层的查询性能。
BE线程池优化，区分来自本地和对象存储的数据源，以防止读取对象的延迟影响查询性能。

3、存储策略的使用

存储策略是使用冷热分层特性的入口点。用户只需要在表创建期间或使用Doris时将存储策略与表或分区关联起来。

在创建S3资源时，将执行远程S3连接验证，以确保资源的正确创建。

下面是创建S3资源的示例:

CREATE RESOURCE "remote_s3"
PROPERTIES
(
    "type" = "s3",
    "s3.endpoint" = "bj.s3.com",
    "s3.region" = "bj",
    "s3.bucket" = "test-bucket",
    "s3.root.path" = "path/to/root",
    "s3.access_key" = "bbb",
    "s3.secret_key" = "aaaa",
    "s3.connection.maximum" = "50",
    "s3.connection.request.timeout" = "3000",
    "s3.connection.timeout" = "1000"
);

CREATE STORAGE POLICY test_policy
PROPERTIES(
    "storage_resource" = "remote_s3",
    "cooldown_ttl" = "1d"
);

CREATE TABLE IF NOT EXISTS create_table_use_created_policy 
(
    k1 BIGINT,
    k2 LARGEINT,
    v1 VARCHAR(2048)
)
UNIQUE KEY(k1)
DISTRIBUTED BY HASH (k1) BUCKETS 3
PROPERTIES(
    "storage_policy" = "test_policy"
);

下面是一个创建HDFS资源的示例:

CREATE RESOURCE "remote_hdfs" PROPERTIES (
        "type"="hdfs",
        "fs.defaultFS"="fs_host:default_fs_port",
        "hadoop.username"="hive",
        "hadoop.password"="hive",
        "dfs.nameservices" = "my_ha",
        "dfs.ha.namenodes.my_ha" = "my_namenode1, my_namenode2",
        "dfs.namenode.rpc-address.my_ha.my_namenode1" = "nn1_host:rpc_port",
        "dfs.namenode.rpc-address.my_ha.my_namenode2" = "nn2_host:rpc_port",
        "dfs.client.failover.proxy.provider" = "org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider"
    );

CREATE STORAGE POLICY test_policy PROPERTIES (
    "storage_resource" = "remote_hdfs",
    "cooldown_ttl" = "300"
)

CREATE TABLE IF NOT EXISTS create_table_use_created_policy (
    k1 BIGINT,
    k2 LARGEINTv1 VARCHAR(2048)
)
UNIQUE KEY(k1)
DISTRIBUTED BY HASH (k1) BUCKETS 3
PROPERTIES(
    "storage_policy" = "test_policy"
);

使用以下命令将存储策略与现有表关联:

ALTER TABLE create_table_not_have_policy SET ("storage_policy" = "test_policy");

使用实例将存储策略与已有分区关联。

ALTER TABLE create_table_partition MODIFY PARTITION (*) SET ("storage_policy" = "test_policy");

如果在表创建过程中为整个表和某些分区指定了不同的存储策略，那么分区的存储策略集将被忽略，表的所有分区将使用表的存储策略。如果希望某个特定分区具有不同于其他分区的存储策略，可以使用上面提到的方法修改该特定分区的关联。
要了解更多细节，请参考Docs目录中的以下文档:RESOURCE, POLICY, CREATE TABLE, ALTER TABLE，其中提供了详细的解释。

3.1 限制

一个表或分区只能与一个存储策略相关联。一旦关联，如果不首先删除它们之间的关联，则不能删除存储策略。
存储策略关联的对象信息不支持修改数据存储路径，如bucket、endpoint、root_path等信息。
存储策略支持创建、修改和删除。在删除存储策略之前，请确保没有表引用该存储策略。
存储策略支持创建、修改和删除。在删除存储策略之前，请确保没有表引用该存储策略。
当启用Merge-on-Write特性时，Unique模型不支持设置存储策略。

4、已占用的冷数据对象大小

方法1:可以使用show proc '/backends'命令查看每个后端上传对象的大小。查找RemoteUsedCapacity字段。请注意，这种方法可能会有一些延迟。

方法2:可以使用show tablet from tableName命令查看表中每个tablet的大小，由RemoteDataSize字段表示。

5、冷数据缓存

如前所述，对冷数据引入缓存是为了优化查询性能和节省对象存储资源。当冷数据在冷却后首次被访问时，Doris将冷却后的数据重新加载到后端(BE)的本地磁盘上。冷数据缓存具有以下特点:

缓存存储在BE的磁盘上，不占用内存空间。
缓存可以限制大小，并使用LRU (Least Recently Used)进行数据清除。
冷数据缓存的实现与联合查询catalog的缓存相同。请参考Filecache的文档了解更多细节。

6、冷数据的压缩

冷数据进入的时间是从数据行集文件写入本地磁盘的那一刻算起，再加上冷却持续时间。由于数据不是一次性写入和冷却的，因此Doris对冷数据执行压缩，以避免对象存储中的小文件问题。然而，冷数据压缩的频率和资源优先级不是很高。建议在冷却前对本地热数据进行压缩处理。您可以调整以下BE参数:

BE参数cold_data_compaction_thread_num设置冷数据压缩的并发性。默认值为2。
BE参数cold_data_compaction_interval_sec设置数据冷压缩的时间间隔。缺省值是1800秒(30分钟)。

7、冷数据的模式更改

冷数据支持以下模式更改类型:

添加或删除列
修改列类型
调整列序
添加或修改索引

8、冷数据的垃圾回收

冷数据的垃圾数据是指没有被任何副本使用的数据。以下情况可能会在对象存储上产生垃圾数据:

上传 rowset 失败但是有部分 segment 上传成功。
在FE重新选择CooldownReplica之后，旧的和新的CooldownReplica的行集版本不匹配。FollowerReplicas同步新CooldownReplica的CooldownMeta，旧CooldownReplica中版本不一致的rowset 成为垃圾数据。
在冷数据压缩之后，合并前的行集（rowsets）不能立即删除，因为它们可能仍被其他副本使用。但是，最终，所有FollowerReplicas都使用最新合并的行集，合并之前的行集成为垃圾数据。

此外，对象上的垃圾数据不会立即清理。BE参数remove_unused_remote_files_interval_sec设置冷数据垃圾收集的时间间隔。缺省值是21600秒(6小时)。