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小时)。