京东广告基于 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 原生的冷热数据分层方案，而是希望探索一种基于分布式文件系统作为冷数据存储的新方案。