Apache Doris 冷热分层技术如何实现存储成本降低 70%？

最新推荐文章于 2025-10-14 09:18:04 发布
原创 最新推荐文章于 2025-10-14 09:18:04 发布 · 1.7k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#大数据 #数据库 #doris #阿里云 #数据分析

文章介绍了ApacheDoris2.0版本引入的冷热数据分层技术，该技术通过将冷数据存储在低成本的对象存储上，降低存储成本，同时保持查询效率。冷热数据分层允许根据访问频率和性能要求将数据分别存储在SSD、HDD和对象存储，通过动态分区和生命周期管理实现数据自动冷却。文章还提供了配置和使用该功能的步骤，以及查询性能测试结果，证明了冷数据分层对查询性能的影响微乎其微。

在数据分析的实际场景中，冷热数据往往面临着不同的查询频次及响应速度要求。例如在电商订单场景中，用户经常访问近 6 个月的订单，时间较久远的订单访问次数非常少；在行为分析场景中，需支持近期流量数据的高频查询且时效性要求高，但为了保证历史数据随时可查，往往要求数据保存周期更为久远；在日志分析场景中，历史数据的访问频次很低，但需长时间备份以保证后续的审计和回溯的工作…往往历史数据的应用价值会随着时间推移而降低，且需要应对的查询需求也会随之锐减。而随着历史数据的不断增多，如果我们将所有数据存储在本地，将造成大量的资源浪费。

为了解决满足以上问题，冷热数据分层技术应运而生，以更好满足企业降本增效的趋势。顾名思义，冷热分层是将 冷 热数据 分别 存储在 成本不同 的存储介质上，例如热数据存储在成本更高的 SSD 盘上、以提高时效数据的查询速度和响应能力，而冷数据则存储在相对低成本的 HDD 盘甚至更为廉价的对象存储上，以降低存储成本。我们还可以根据实际业务需求进行灵活的配置和调整，以满足不同场景的要求。

冷热分层一般适用于以下需求场景：

  • 数据存储周期长：面对历史数据的不断增加，存储成本也随之增加；

  • 冷热数据访问频率及性能要求不同：热数据访问频率高且需要快速响应，而冷数据访问频率低且响应速度要求不高；

  • 数据备份和恢复成本高：备份和恢复大量数据需要消耗大量的时间和资源。

  • …

更高存储效率的冷热分层技术

自 Apache Doris 0.12 版本引入动态分区功能，开始支持对表分区进行生命周期管理，可以设置热数据转冷时间以及存储介质标识，通过后台任务将热数据从 SSD 自动冷却到 HDD，以帮助用户较大程度地降低存储成本。用户可以在建表属性中配置参数 storage_cooldown_time 或者 dynamic_partition.hot_partition_num 来控制数据从 SSD 冷却到 HDD，当分区满足冷却条件时，Doris 会自动执行任务。而 HDD 上的数据是以多副本的方式存储的，并没有做到最大程度的成本节约，因此对于冷数据存储成本仍然有较大的优化空间。

为了帮助用户进一步降低存储成本，社区在已有功能上进行了优化，并在 Apache Doris 2.0 版本中推出了冷热 数据 分层的功能。冷热数据分层功能使 Apache Doris 可以将冷数据下沉到存储成本更加低廉的对象存储中，同时冷数据在对象存储上的保存方式也从多副本变为单副本，存储成本进一步降至原先的三分之一，同时也减少了因存储附加的计算资源成本和网络开销成本。

如下图所示，在 Apache Doris 2.0 版本中支持三级存储，分别是 SSD、HDD 和对象存储。用户可以配置使数据从 SSD 下沉到 HDD，并使用冷热分层功能将数据从 SSD 或者 HDD 下沉到对象存储中。

以公有云价格为例，云磁盘的价格通常是对象存储的 5-10 倍，如果可以将 80% 的冷数据保存到对象存储中，存储成本至少可降低 70%。

我们使用以下公式计算节约的成本，设冷数据比率为 rate，对象存储价格为 OSS，云磁盘价格为 CloudDisk

1 − r a t e ∗ 100 ∗ O S S + ( 1 − r a t e ) ∗ 100 ∗ C l o u d D i s k 100 ∗ C l o u d D i s k 1 - \frac{rate * 100 * OSS + (1 - rate) * 100 * CloudDisk}{100 * CloudDisk} 1−100∗CloudDiskrate∗100∗OSS+

最低0.47元/天 解锁文章
Doris 冷热数据分层
02-07 5172
未来一个很大的使用场景是类似于 ES 日志存储，日志场景下通常会按照日期来切割数据，很多数据是冷数据，查询很少，需要降低这类数据的存储成本。
Doris：冷热分层
m0_37559973的博客
06-16 1581
冷热分层支持所有 Doris 功能，只是把部分数据放到对象存储上，以节省成本，不牺牲功能。
Doris冷热数据分层实现
sunxunyong的博客
07-11 612
3、冷数据Compaction后，合并前的rowset因为还可能被其他Replica使用不能立即删除，但是最终FollowerReplica都使用了最新的合并后的rowset，BE 参数cold_data_compaction_interval_sec可以设置执行冷数据的 Compaction 的时间间隔，默认是 1800，单位：秒，即半个小时。BE参数remove_unused_remote_files_interval_sec可以设置冷数据的垃圾回收的时间间隔，默认是21600，单位：秒，即6个小时。
Doris专题9- 行列混存和冷热数据分层
weixin_44999258的博客
10-07 842
存储方案适用条件核心特性成本效益性能特点存算分离具备部署条件• 数据单副本存对象存储• 本地缓存加速• 存储计算独立扩展存储成本显著降低热数据缓存加速，冷数据直接访问本地分层存算一体模式• SSD→HDD自动迁移• 利用本地存储层级节省高性能存储成本热数据SSD高性能，冷数据HDD低成本远程分层存算一体模式• 冷数据→对象存储/HDFS• 热数据本地存储进一步降低成本热数据本地访问，冷数据远程读取行列混存：优化点查性能，解决宽表IOPS瓶颈远程存储。
Apache Doris 入门教程30：冷热分层机制
sunjian286的专栏
08-16 823
本文简要介绍如何在Apache Doris中，通过冷热分层机制优化性能
Apache Doris 2.0 冷热分离快速体验
锋哥聊DORIS数仓
05-11 2219
用户在满足了自身对于数据使用要求的情况下，自然会开始考虑数据存储成本等方面的问题，对于那些很少访问甚至基本不访问的数据，使用成本更低的存储方式将是一种更好的选择。未来一个很大的使用场景是类似于es日志存储，日志场景下数据会按照日期来切割数据，很多数据是冷数据，查询很少，需要降低这类数据的存储成本。对于热数据，其访问的频率很高，且往往是用户非常关心的数据，其实时性要求一般都很高，并且读写的频率也会更高，这正是DORIS本地存储重点解决的问题。从这个图上我们也可以看到，已经将部分数据迁移到对象存储上了。
Doris——冷热数据分层
weixin_71195617的博客
09-11 1599
Doris冷热数据分层核心策略和参数使用
京东广告基于 Apache Doris 的冷热数据分层实践
京东零售技术的博客
02-20 1201
京东广告围绕Apache Doris建设广告数据存储服务，为广告主提供实时广告效果报表和多维数据分析服务。历经多年发展，积累了海量的广告数据，目前系统总数据容量接近1PB，数据行数达到18万亿行+，日查询请求量8,000万次+，日最高QPS2700+。随着业务的不断增长与迭代，数据量持续激增，存储资源逐渐成为瓶颈。近两年存储资源经历了多次扩容，存储容量增加了近十倍，而日查询请求量仅增长两倍。同时，计算资源的利用率因频繁扩容而相应降低，导致资源浪费。
一文读懂 Doris 冷热分离，优化存储与查询性能
一入大数据深似海?别怕!“数据极客圈”就是你的救生圈，走对圈子跟对人，趣析数据、畅聊趋势，快进圈子!
07-25 1119
摘要：Doris的冷热分离技术通过智能存储策略有效解决大数据存储成本与查询性能的平衡问题。该功能基于存储资源管理，支持S3、AZURE、HDFS等多种存储介质，可根据时间策略自动将冷数据迁移至低成本存储。用户可通过创建存储策略（如设置冷却时间或TTL）实现数据分层，同时支持SSD/HDD分层存储。该技术特别适用于日志分析等时间敏感型业务场景，在保证热数据高效查询的同时显著降低存储成本，实现资源优化配置。
Doris冷热分离与存储查询性能优化指南
weixin_47253479的博客
08-04 1011
本文介绍了数据存储中冷热分离的实现方案与优化策略。主要包括三种实现方式：基于分区的冷热分离配置（可动态修改）、基于TTL的自动冷热迁移，以及存储介质的S3配置。存储优化方面提出了压缩优化、分区分桶优化等措施。查询性能优化建议采用物化视图、索引优化和并行查询等方法。还提供了冷热数据管理、监控调优工具及最佳实践建议，如冷热数据分层存储策略（热数据7-30天SSD存储，冷数据90天以上对象存储）、合理设置分区分桶等。通过合理配置这些策略，可以在降低存储成本的同时保持查询性能。
【 Doris】Apache Doris 冷热数据存储（一）
m0_54252387的博客
07-09 876
1. 前言对于任何一种数据库类软件来说，无论其基于传统数据库模型还是基于分布式结构，作为核心的永远是数据本身。而数据的生命周期，则体现在CRUD操作（创建、查询、更新、删除）上。任何一条数据从其生成的时刻开始，数据价值随着时间的推移而逐渐降低，直至成为无用数据，最终删除。作为使用数据的主体——用户，对于各种数据的需求程度是不同的，人们往往对重要的数据有更高效、稳定的访问需求；而对于不重要的数据则没有这么高的要求，而前者存储的代价往往是远高于后者的。用户在满足了自身对于数据使用要求的情况下，自然会开始考虑
根据数据冷热程度分层存储，让HDFS更高效
ChengYanan的博客
04-28 684
摘要: 随着大数据技术相关技术的发展和普及，越来越多的公司开始使用基于开源Hadoop的平台系统，同时，越来越多的业务和应用也在从传统的技术架构迁移到大数据平台上。在典型的Hadoop大数据平台中，人们使用HDFS作为存储服服务 Hadoop 一、背景 随着大数据技术相关技术的发展和普及，越来越多的公司开始使用基于开源Hadoop的平台系统，同时，越来越多的业务和应用也在从传统的技术架构迁移到大数...
一文吃透！Doris 冷热分层技术全解析
涤生大数据
05-01 1116
在大数据领域，数据量呈指数级增长，企业不仅要应对海量数据的存储难题，还要保障数据查询的高效性。Doris 作为一款备受青睐的高性能分布式分析型数据库，其冷热分层技术为企业提供了兼具高效性与成本效益的解决方案。本文将从原理、优势、实现方式，以及实际案例等多个维度，对 Doris 冷热分层技术进行深入剖析。
Apache Doris 冷热分层技术如何实现存储成本降低 70%？｜新版本特性
jiedaodezhuti的博客
06-17 888
冷热分层是将冷热数据分别存储在成本不同的存储介质上
Apache Doris历史数据归档：冷热分离存储方案
最新发布
gitblog_00399的博客
10-14 887
你是否还在为Apache Doris集群存储成本居高不下而烦恼？随着业务增长，历史数据不断累积，不仅占用大量高性能存储资源，还导致查询性能下降。本文将详细介绍如何利用Apache Doris的冷热分离存储方案，通过合理配置实现历史数据归档，在保证查询性能的同时降低存储成本。读完本文后，你将掌握冷热存储介质配置、数据分区策略制定、自动归档脚本编写的全流程操作。 ## 什么是冷热分离存储 冷热分离...
Doris数据库BE——冷热数据方案
肥叔菌的博客
10-05 1089
其中 ROWSET 代表着数据导入批次，同一个ROWSET 一般代表着一个批次的导入任务，比如一次 stream load，一个 begin/commit 事务等，都对应一个 ROWSET，ROWSET 的这种特性，意味着其具有着事务的特点，即是说，同一个rowset可以作为一个独立的数据单元存在，其中的数据要么全部有效，要么全部无效。当数据需要转冷的时候，为该热数据分片创建一个冷数据的副本分片，然后将数据转储到冷数据指定的外部集群上，当冷数据副本生成完毕后，将热数据分片删除。
在 PostgreSQL 里如何实现数据的冷热数据分层存储和访问控制？
2401_86074221的博客
07-09 1204
在数据库中，冷数据通常是指那些很少被访问、陈旧或者重要性较低的数据，而热数据则是经常被访问、时效性强、对业务至关重要的数据。例如，在一个电商数据库中，近期的订单交易记录可能属于热数据，而一年前的已完成订单记录可能属于冷数据。在 PostgreSQL 中实现数据的冷热分层存储和访问控制是一个复杂但有效的数据库管理策略。通过合理地利用表分区、存储介质选择、索引优化、访问控制机制以及数据迁移策略，可以提高数据库的性能、保障数据的安全，并更好地满足业务需求。
在 PostgreSQL 里如何实现数据的冷热数据分层存储的资源分配？
2401_86074221的博客
07-14 1194
在数据库中，数据的访问频率和重要性是各不相同的。一般来说，经常被访问、对业务至关重要的数据被称为热数据，而那些访问频率较低、相对不重要的数据则被称为冷数据。冷热数据分层存储就是将热数据和冷数据分别存储在不同的存储介质或数据库对象中，以实现资源的优化配置。打个比方，我们可以把数据库比作一个仓库，热数据就像是仓库里的畅销商品，需要放在容易拿到的地方，以便快速满足客户的需求；而冷数据则像是仓库里的积压库存，可以放在不太方便取用的地方，以节省仓库的空间和成本。
【Doris】 技术实现 - 冷热数据存储(二)
m0_54252387的博客
07-26 941
上一篇文章[ApacheDoris技术实现-冷热数据存储(一)]主要讲述了冷热数据存储与存算分离之间的关系，结合数据仓库的历史，分析了存算分离在实时数仓上面的局限性，相比起分布式计算类项目（spark、flink），实时数仓只能做到有限制的存算分离。并根据这一现状，描述了一个冷热数据与存算分离结合的模型。接下来，我会先后讲述该模型的几个主要模块的原理与实现热数据转冷、冷数据读写。本文介绍了DORIS冷热数据转换的基本功能，热数据转冷与冷数据读写。关于冷热数据的实现，还有很多方面可讲。...
Apache doris bitmap使用
06-13
<think>嗯，用户想深入了解ApacheDoris中bitmap的实现原理和使用方法。看来需要结合多个引用资料进行解读。引用[2]提到bitmap用于高效处理高基数数据，比如用户ID去重这类场景。这涉及两个关键点：存储压缩和集合运算性能。RoaringBitmap确实是个重要的技术点。引用[1]和[3]都提到用户行为分析案例，具体实现应是先用全局字典将用户ID映射为整数，然后用这些整数构建bitmap。这样进行交集并集运算就非常高效。引用[4]给出的资源链接很有价值，特别是Kylin的全局字典实现文档，这个在Doris中应该类似。用户若想实际操作，全局字典的创建和更新步骤需要重点说明。需要特别注意压缩机制。RoaringBitmap对稀疏和密集数据采用不同容器存储，32KB的区块划分既能高效压缩又支持快速位运算，这正是查询性能的关键。用户行为分析的演示示例需要设计清楚。UV/留存分析都是典型场景，展示具体的SQL语法和结果解读能帮助理解bitmap的实际价值。存储优化方面要强调低内存占用。100万用户ID压缩后只需数MB，对比Hive方案有数量级优势。使用限制也要提醒。虽然bitmap查询快，但初始化构建全局字典时可能较慢，且大整数溢出问题在实际使用中容易被忽略。全局字典的维护成本容易被低估，需要单独说明。新增用户时触发字典更新的机制要明确，用户可能遇到字典膨胀影响查询性能的情况。相关问题的设计要有递进性，从原理到优化再到源码，给不同需求的用户提供延伸路径。特别是HLL补充方案的选择条件，这在实际架构中很关键。</think> 以下是 Apache Doris 中 Bitmap 的实现原理和使用方法的详细说明，结合引用内容整理而成： ### 一、Bitmap 实现原理 1. **底层数据结构** Doris 采用 **RoaringBitmap**（压缩位图）存储数据，核心结构包括： - 32 位无符号整数作为索引值（对应全局字典映射） - 动态容器划分：根据数据密度自动选择 ArrayContainer（稀疏数据）、BitmapContainer（稠密数据）或 RunContainer（连续数据） - 区块分桶：每 2^16 (65,536) 个值划分为一个区块，实现快速二分查找[^2][^4] 2. **高效压缩机制** ```mermaid graph LR A[原始用户ID] --> B(全局字典编码) B --> C{数据密度} C -->|稀疏| D[ArrayContainer] C -->|稠密| E[BitmapContainer] C -->|连续| F[RunContainer] D & E & F --> G[RoaringBitmap] ``` 实测压缩率：1亿用户ID存储仅需 **12.5MB**（传统方案需 800MB）[^2] 3. **全局字典映射** 实现精确去重的关键步骤： ```sql -- 1. 创建字典表 CREATE TABLE user_dict ( user_id BIGINT, dict_id INT ) UNIQUE KEY(user_id) DISTRIBUTED BY HASH(user_id); -- 2. 生成字典编码（分布式ETL作业） INSERT INTO user_dict SELECT user_id, ROW_NUMBER() OVER() AS dict_id FROM raw_data; ``` ### 二、核心使用场景 #### 场景1：精确去重计数 ```sql -- 创建含 Bitmap 列的聚合表 CREATE TABLE user_actions ( dt DATE, page_id INT, user_bitmap BITMAP BITMAP_UNION ) AGGREGATE KEY(dt, page_id); -- 导入数据（自动聚合Bitmap） INSERT INTO user_actions VALUES ('2023-01-01', 101, TO_BITMAP(123)), ('2023-01-01', 101, TO_BITMAP(456)); -- 查询 UV SELECT dt, page_id, BITMAP_UNION_COUNT(user_bitmap) FROM user_actions GROUP BY dt, page_id; ``` ▶️ 结果： dt | page_id | uv ---|---------|---- 2023-01-01 | 101 | 2 #### 场景2：用户行为分析（留存率计算） ```sql SELECT DAYS_ADD(first_dt, 7) AS retention_date, BITMAP_COUNT(BITMAP_INTERSECT(first_day_users, seventh_day_users)) * 1.0 / BITMAP_COUNT(first_day_users) AS retention_rate FROM ( SELECT dt AS first_dt, BITMAP_UNION(user_bitmap) AS first_day_users, LEAD(BITMAP_UNION(user_bitmap), 7) OVER(ORDER BY dt) AS seventh_day_users FROM user_actions GROUP BY dt ) t; ``` ### 三、性能优化策略 1. **预处理加速** - 在数据导入阶段进行 Bitmap 聚合（`BITMAP_UNION`） - 使用物化视图预计算常用维度组合[^1] 2. **存储优化** - 字典编码采用 `SMALLINT`（最大支持65,535用户）可减少50%存储 - 冷热数据分层：历史数据转存至 S3 并使用 `BITMAP_UNION` 状态合并[^4] 3. **参数调优** ```ini # be.conf 关键参数 bitmap_memory_limit=1073741824 # Bitmap操作内存上限=1GB enable_bitmap_serialize=true # 启用磁盘溢出机制 ``` ### 四、使用限制与解决方案 | 限制 | 解决方案 | |-----------------------|----------------------------| | 基数超20亿导致溢出 | 采用 `BIGINT` 字典 + 分片计算 | | 高频更新导致字典膨胀 | 增量字典+定期合并（`BITMAP_UNION`）| | 超大 Bitmap 内存压力 | 开启 `spill_to_disk` 参数 | > **注**：在用户行为分析中，Bitmap 计算 UV 的查询速度比传统 `COUNT(DISTINCT)` 快 **10-100倍**，尤其在大数据量下优势显著[^3] --- ### 相关问题 1. Bitmap 与 HLL（HyperLogLog）在 Doris 中如何选择？各自适用场景是什么？ 2. 如何处理 Bitmap 计算时的内存溢出问题？有哪些调优手段？ 3. 全局字典在分布式环境下如何保证编码唯一性？ 4. RoaringBitmap 的三种容器转换阈值如何设定？如何验证存储效率？ 5. 如何利用 Bitmap 实现漏斗分析等复杂行为分析？ [^1]: Doris Bitmap 精确去重原理 [^2]: Bitmap 在 Doris 中的应用场景分析 [^3]: 用户行为分析实战案例 [^4]: RoaringBitmap 压缩算法源码解析
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

SelectDB技术团队

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值