一、背景先容
京东广告围绕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团队在京东广告场景中开展紧密互助，共同探索存算分离架构在该场景中的实际应用。
作者 京东零售广告产研部-投放平台部-投放报表组
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
