京东广告基于 Apache Doris 的冷热数据分层实践

一、背景介绍

京东广告围绕Apache Doris建设广告数据存储服务，为广告主提供实时广告效果报表和多维数据分析服务。历经多年发展，积累了海量的广告数据，目前系统总数据容量接近1PB，数据行数达到18万亿行+，日查询请求量8,000万次+，日最高QPS2700+。 随着业务的不断增长与迭代，数据量持续激增，存储资源逐渐成为瓶颈。近两年存储资源经历了多次扩容，存储容量增加了近十倍，而日查询请求量仅增长两倍。同时，计算资源的利用率因频繁扩容而相应降低，导致资源浪费。通过对查询请求的分析，我们发现日常查询中有99%集中在近一年的数据上，数据使用呈现出明显的冷热现象。基于此，希望借助Apache Doris探索一种满足线上服务要求的冷热数据分层解决方案，在数据不断膨胀的情况下，降低数据的存储和使用成本。

二、冷热分层方案介绍

截至当前，我们的数据冷热分层实践已历经两种方案，分别是Doris冷数据入湖和Doris冷热数据分层。Doris冷数据入湖方案通过SDC（Spark-Doris-Connector）将Doris中的冷数据转入湖中，入湖后的冷数据可通过Doris外表进行查询。Doris冷热数据分层方案则通过在Doris中设置数据的TTL时间，由Doris根据数据的TTL时间自动判断冷热数据，并将冷数据移至相对廉价的存储介质。冷数据入湖方案借鉴了腾讯游戏的相关经验（https://cloud.tencent.com/developer/article/2251030），并在Apache Doris 1.2版本中进行了实践；而Doris冷热数据分层方案则是最近上线的新一代冷热数据分层方案。以下将结合我们过往的实践经验，简要介绍这两种方案。

冷热分层V1：数据湖方案

在数据湖方案中，需将Doris的数据依据业务时间进行冷热划分。在类似场景中，业务时间即为Doris表的分区时间。为实现Doris数据入湖，需借助Spark-Doris-Connector（SDC）将Doris中的冷数据迁移至数据湖（如Iceberg）。查询时，需根据业务时间对查询进行冷热区分，将冷数据查询（冷查询）与热数据查询（热查询）分别路由至不同的查询引擎。冷数据查询通过查询改写，将查询重定向至数据湖对应的外部表；热数据查询则无需改写，直接查询Doris中的OLAP表。





数据入湖方案的优势在于，冷数据的查询与下载能够与线上Doris系统实现解耦，从而确保线上操作的稳定性不受影响。这种解耦设计确保了冷数据的处理和查询不会干扰线上Doris系统的正常运行。通过将冷数据与线上系统分离，可以确保线上系统在处理实时数据时保持高效和稳定。这对于需要高可用性和低延迟的在线广告报表业务而言尤为重要。

数据入湖方案的主要劣势包括以下几点：首先，需借助ETL工具实现数据从Doris到数据湖的迁移。ETL工具能够自动化数据迁移过程，但这也意味着需要额外的资源和时间来配置及运行这些工具。其次，为了获取完整的数据集，必须对Doris中的热数据和数据湖中的冷数据进行UNION操作。这意味着在进行数据分析或查询时，需要同时访问两个不同的数据存储系统，这不仅增加了系统的复杂性，还可能影响查询性能。例如，如果一个分析需要同时查询热数据和冷数据，那么查询时间可能会显著增加，因为系统需要从两个不同的地方获取数据。最后，数据入湖后，Schema变更操作需得到相应数据湖的支持。这意味着如果需要对数据结构进行修改，例如添加或删除字段，必须确保数据湖能够支持这些变更。这可能需要额外的技术支持和维护工作。



冷热分层V2：Apache Doris冷热数据分层方案

Apache Doris 1.2 的冷热数据分层方案基于本地磁盘，热数据存储于 SSD，而冷数据则转移至性能较低的 HDD，以此实现数据分层。然而，此方案存在以下缺点：首先，该方案更适合物理机部署，而不适用于容器或 Kubernetes (K8S) 部署。当前，大多数公司已转向基于容器或 K8S 的部署方式，物理机部署已较为罕见。其次，需要预先估算冷数据的存储空间，然而，冷数据量会随时间逐渐增加，难以准确预估其容量。因此，我们并未在 Doris 1.2 中采用 Doris 原生的冷热数据分层方案，而是希望探索一种基于分布式文件系统作为冷数据存储的新方案。





Apache Doris 2.0 的冷热数据分层功能支持将冷数据存储于如 OSS 和 HDFS 等分布式存储系统中。用户可通过配置相应的存储策略来指定数据的冷热分层规则，进而通过为表或分区设定存储策略，实现冷数据自动迁移至外部存储系统。基于分布式存储的 Doris 冷热数据分层方案具有简洁性，避免了数据湖方案的复杂性。然而，该方案的缺点在于冷热数据统一在一个集群中进行管理和使用，高优先级的热查询可能会受到冷查询的影响，因此需要对冷数据查询进行适当的限流。以下将介绍我们在从 Doris 1.2 的数据湖方案升级至 Doris 2.0 基于分布式存储的冷热数据分层过程中遇到的一些问题及其解决方案。

三、问题解决

3.1 Apache Doris2.0性能优化&问题修复

为了实现基于分布式存储的冷热数据分层，需将Doris集群由1.2版本升级至2.0版本。尽管我们在前期已与社区共同完成了大量Doris开发工作，但在具体实施冷热数据分层过程中，仍遇到了若干问题。以下是几个典型问题。

查询性能下降问题

在性能Diff阶段，我们发现，在报表小查询场景（平均tp99<20ms）中，Doris 2.0相较于我们之前的Doris 1.2版本，性能下降约50%左右。经过分析，我们发现Doris 2.0的FE默认启用了新的优化器，而该优化器在SQL Rewrite阶段使用了更多的规则进行重写，从而导致了性能下降。通过进一步的压测、分析以及与社区的交流，我们得出结论：除非在Doris 2.0中对新优化器进行更深层次的优化，否则很难使性能达到Doris 1.2的水平。因此，在我们的应用场景中，我们关闭了Doris 2.0的新优化器功能。在使用旧优化器的情况下，我们还是遇到了以下性能问题：

分桶裁剪失效

当查询命中表的Rollup后，底层数据扫描量明显增多，查询耗时较1.2明显升高。查看执行计划，发现执行计划扫描了对应分区下面的所有分桶数据，分桶裁剪没有生效。修复PR:[Fix](MV) query not hit partition in original planner by GoGoWen · Pull Request #38565 · apache/doris · GitHub







前缀索引失效

当从1.2升级到2.0时，升级前于1.2时创建的Date类型的字段在查询时如果将它和DateTime类型(如类似Date>="2024-10-01 00:00:00")进行比较，FE会对Date类型进行自动类型提升(类似CAST(Date as datetime) >= Datetime("2024-10-01 00:00:00"))。 提升后的谓词在BE处理的时候和底层数据存储的实际类型(Date("2024"))不能进行比较，导致对应前缀索引失效，引起查询性能大幅下降。这种情况我们通过在FE端进行类型对齐进行了修复https://github.com/apache/doris/pull/39446。 修复后索引生效，性能得到大幅提升。







FE CPU使用率高问题

在对Doris2.0进行压力测试时，观察到FE节点的CPU使用率相较于Doris1.2显著上升，在相同的QPS请求下，Doris2.0的CPU使用率几乎翻倍。资源消耗明显增加。在测试过程中，我们对FE节点进行了火焰图分析，识别出性能消耗较高的函数；同时，我们与社区成员进行了充分的沟通，最终确定了多个资源消耗点，并实施了相应的优化措施。





时间比较效率优化

广告报表场景下时间比较操作是几乎每个查询在分区裁剪时都会用到，而Doris2.0对时间的比较需要先转化为字符串再进行比较，这种比较没有直接使用数据结构自身的成员变量进行比较效率高，这里我们通过PR:https://github.com/apache/doris/pull/31970对分区裁剪时的时间比较操作进行了优化，优化后CPU使用率整体降低25%左右。

物化视图字段列重写优化

在表有Rollup而没有物化视图时，Doris FE对查询的执行计划还是会使用只需作用于物化视图的改写规则进行优化改写，这些无效的改写不仅造成CPU利用率提升还会影响查询延时。 PR: https://github.com/apache/doris/pull/40000对这种情况进行优化，在无物化视图情况下避免无意义的执行计划改写。

此外，我们还通过使用for循环代替流操作、关键路径减少日志输出等进行了CPU使用率优化，最总Doris 2.0 FE CPU消耗最终达到1.2版本等同水平。

BE 内存使用率高

在对 Doris 2.0 版本的集群使用过程中，发现BE内存使用率会极缓慢持续升高，长期使用的情况下，Doris BE 阶段存在 OOM 风险。排查该现象和 SegmentCache的配置有关：

Doris2.0使用了SegmentCache，用于对底层数据文件对象缓存。但2.0对于SegmentCache的内存使用计算存在问题且默认阈值设置过大，导致一直触发不到SegmentCache使用阈值；随着segment文件数量的增加，SegmentCache使用量会越来越大。结合日常内存使用量的评估及压测验证，我们重新调整了合理的SegmentCache使用阈值；在保证Cache命中率基本不变的情况下降BE常驻内存使用率从 60%以上降低到25%一下，有效避免了 BE 节点 OOM的风险。



经过一系列优化后，2.0版本查询性能参数(TP99耗时、FECPU消耗、BE CPU消耗)有了较大优化，基本和1.2版本对齐。





3.2 冷数据 Schema Change(SC)优化

Schema Change(SC) 是Apache Doris等实时数仓日常使用当中的高频操作，其中，Add Key Column 的操作是广告数据报表中使用较多的场景，实践中发现冷数据添加 Key 列的SC操作存在如下问题：

1.Schema Change 退化：冷数据的Add Key Column 操作会退化成Direct Schema Change(DSC)；DSC操作比较重，需要对全量数据进行重新读取和写入。在实际使用过程中对于含大量冷数据的表进行 Add Key Column 操作需要重新对远端海量数据进行读写，增大系统IO负载的同时，SC 任务耗时也很长。实践中一张冷数据量20T左右的表，整个SC耗时在7天以上，对于需要紧急上线的业务体感极差。

2.数据冗余：冷数据Schema Change(SC)时，Tablet 的每个副本都会独立进行 SC 操作，导致原来冷数据单副本存储在SC后变成多副本，冷数据存储资源浪费严重。

为了优化和修复上述冷数据 Schema Change 遇到的问题，我们对冷数据的 Schema Change 进行了如下优化：

实现冷数据 Linked Schema Change

针对冷数据 Add Key Column类型的SC 退化成 Direct Schema Change 导致 SC 任务执行缓慢的问题，我们对冷数据Add Key Column类型SC的流程进行深度优化，利用远端存储系统(ChubaoFS)的CopyObject接口，实现在远端直接进行数据复制，避免数据文件从远端拉取到Apache Doris，经数据重写后再存储到远端存储系统的巨大IO开销。该优化减少了两次网络传输和一次数据转换的开销，这样能够极大加速Add Key Column场景下冷数据Schema Change的执行速度。经测算优化后SC执行速度提升40倍， 相关PR已合并社区2.0分支：[branch-2.0](schema change) opt cooldown data schema change by DarvenDuan · Pull Request #40963 · apache/doris · GitHub。







实现冷数据单副本SC

Apache Doris 2.0中冷数据在进行Schema Change时，同一份数据的多个副本之间相互独立进行(SC)。如此, Schema Change完成后造成冷数据将在远端存储存在多份，造成存储资源浪费的同时也降低SC任务执行效率。为了解决这个问题，参考Raft协议对冷数据多副本SC场景进行了优化。即SC只在选举出来的Leader副本上执行，非Leader副本只生成元数据。





我们已成功解决了SC后数据副本冗余的问题。然而，仍存在一个潜在风险：FE会定期检查BE上的tablet SC操作是否正常。我们允许不超过半数的tablet副本SC失败，即使BE上的Leader副本SC失败，整个SC任务仍可能成功。因此，若Leader副本在复制数据时失败，可能会导致数据丢失。为避免这种情况，我们在FE对Schema Change任务的健康度判断时，特别考虑了冷数据的“Linked Schema Change”。只有当tablet的Leader副本成功时，SC才会被视为成功。这样可以确保数据的完整性和一致性。



实现冷数据的Light Schema Change

对于存量表中可以直接使用Light Schema Change的表，我们希望更进一步支持一种冷数据Light Schema Change；如果走Light Schema Change，则只需要修改FE 元数据信息，不需要进行BE端任务创建及数据文件处理；处理时间会达到毫秒级。







当前Light Schema Change只支持Value列字段的添加，不支持Key列字段添加。但对于不涉及分区、分桶、前缀索引的普通Key列；可以按照Light Schema Change的逻辑进行处理。这里对这一功能进行了升级。主要改动在FE阶段Light Schema Change判断阶段，支持对Key列添加的逻辑。以满足较普通的添加Key列操作。

3.3 其他问题解决

随着整体数据量持续增长，在引入冷热数据分层方案之前，为缓解线上存储资源紧缺的现状，我们将 Doris 历史数据通过 backup 的方式结转到外部存储，维持 Doris 集群安全的存储水位。完成Doris2.0版本升级后，再将结转的历史数据重新恢复至 Doris 集群。为了便捷高效地操作历史数据，我们实现了一套统一的结转和恢复工具，工具解决了如下三个问题：

1.历史数据总量大，底表数量多，如何准确高效地结转这些数据？

2.历史数据持续结转，线上表schema持续变更，如何将这部分 schema 不一致的数据重新恢复？

3.如何实现统一的冷热数据分层和热数据自动冷却？

为解决第一个数据结转的问题，我们实现了一个历史数据自动结转工具data migrator。支持将线上集群所有DB任意时间段内的数据异步并行结转至外部离线存储。

Doris2.0完成升级后启动建设冷热数据分层，首先需要将结转至外部存储的历史数据恢复至线上环境。此时遇到的最大问题是线上表结构已发生多次变更，导致多次结转的历史数据备份snapshot文件所对应的schema结构与线上表不一致。为了解决schema不一致的问题，我们设计开发了一套自动化数据恢复工具narwal_cli，如下图中Data Restore Process过程所示，narwal_cli工具支持自动对齐历史结转数据和Doris 集群中数据的的schema，并定向恢复至线上环境。





在实施恢复过程中，还遇到Flink2Doris实时写入任务失败的情况，具体信息如下：LOAD_RUN_FAIL; msg:errCode = 2, detailMessage = Table xxxxx is in restore process. Can not load into it经排查，问题原因是Doris表在restore过程中伴随实时数据写入，写入会对表当前的meta info进行check，但状态检测粒度较粗，仅检测tableState而未进一步检测partitionState，造成状态误判，进而影响了写入任务。问题定位后迅速完成修复和发版上线，详细信息可参考pr：[enhancement](Load)allow load data to the other partitions when some partitions are restoring by Johnnyssc · Pull Request #39595 · apache/doris · GitHub。以上问题解决后，在线上环境快速准确地恢复了所有历史数据，且工具兼顾易用性，做到随时启停、断点续传。

在我们的应用场景中，我们对历史恢复的数据和线上的数据分别设置了不同的冷热分层策略：我们将历史数据的storage_policy设置为cooldown_ttl=10s，实现历史数据立刻冷却至ChubaoFS。对全量热数据则统一设置了cooldown_ttl=2years，实现线上热数据随着两年时间窗口推进自动冷却。整个历史数据的恢复和冷却全过程，做到对线上业务透明，准确高效地实现全量历史数据恢复和冷却。同时，在冷却数据过程中发现冷热数据策略设置异常问题，进行了修复，参考pr：https://github.com/apache/doris/pull/35270。实现统一的冷热分层和自动冷却后，后续存储数据量继续保持增长，也无需再扩容线上存储资源，仅需扩容较低成本的外部离线存储即可，实现计算资源利用率提升的同时，存储经济成本大幅降低。

除了以上优化，我们还在为 Apache Doris 在读写性能提升、问题修复、功能完善等方面积极贡献，已为社区 2.0 版本提交并合并 30+ PR。

四、小结

通过对数据进行冷热分层，我们的存储成本降低了约87%。对比Doris 1.2的冷数据入湖方案与Doris 2.0的冷数据分层方案，后者在并发查询能力上提升了超过10倍，查询延迟显著减少。此外，冷热数据分层方案简化了存储和查询的维护工作，降低了整体复杂性和成本。冷热分层架构的成功实施，离不开Apache Doris社区和中台OLAP团队的鼎力支持，特此向所有Apache Doris社区和中台OLAP团队的成员表示衷心的感谢。展望未来，我们期待继续与Apache Doris社区和中台OLAP团队在京东广告场景中开展紧密合作，共同探索存算分离架构在该场景中的实际应用。



作者 京东零售广告产研部-投放平台部-投放报表组