wap网站用什么服务器,做网站简单还是写程序,云梦网络 网站模板,福田蒙派克空调滤芯安装位置图一、背景介绍
京东广告围绕Apache Doris建设广告数据存储服务#xff0c;为广告主提供实时广告效果报表和多维数据分析服务。历经多年发展#xff0c;积累了海量的广告数据#xff0c;目前系统总数据容量接近1PB#xff0c;数据行数达到18万亿行#xff0c;日查询请求量8…一、背景介绍
京东广告围绕Apache Doris建设广告数据存储服务为广告主提供实时广告效果报表和多维数据分析服务。历经多年发展积累了海量的广告数据目前系统总数据容量接近1PB数据行数达到18万亿行日查询请求量8,000万次日最高QPS2700。 随着业务的不断增长与迭代数据量持续激增存储资源逐渐成为瓶颈。近两年存储资源经历了多次扩容存储容量增加了近十倍而日查询请求量仅增长两倍。同时计算资源的利用率因频繁扩容而相应降低导致资源浪费。通过对查询请求的分析我们发现日常查询中有99%集中在近一年的数据上数据使用呈现出明显的冷热现象。基于此希望借助Apache Doris探索一种满足线上服务要求的冷热数据分层解决方案在数据不断膨胀的情况下降低数据的存储和使用成本。
二、冷热分层方案介绍
截至当前我们的数据冷热分层实践已历经两种方案分别是Doris冷数据入湖和Doris冷热数据分层。Doris冷数据入湖方案通过SDCSpark-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-ConnectorSDC将Doris中的冷数据迁移至数据湖如Iceberg。查询时需根据业务时间对查询进行冷热区分将冷数据查询冷查询与热数据查询热查询分别路由至不同的查询引擎。冷数据查询通过查询改写将查询重定向至数据湖对应的外部表热数据查询则无需改写直接查询Doris中的OLAP表。 数据入湖方案的优势在于冷数据的查询与下载能够与线上Doris系统实现解耦从而确保线上操作的稳定性不受影响。这种解耦设计确保了冷数据的处理和查询不会干扰线上Doris系统的正常运行。通过将冷数据与线上系统分离可以确保线上系统在处理实时数据时保持高效和稳定。这对于需要高可用性和低延迟的在线广告报表业务而言尤为重要。
数据入湖方案的主要劣势包括以下几点首先需借助ETL工具实现数据从Doris到数据湖的迁移。ETL工具能够自动化数据迁移过程但这也意味着需要额外的资源和时间来配置及运行这些工具。其次为了获取完整的数据集必须对Doris中的热数据和数据湖中的冷数据进行UNION操作。这意味着在进行数据分析或查询时需要同时访问两个不同的数据存储系统这不仅增加了系统的复杂性还可能影响查询性能。例如如果一个分析需要同时查询热数据和冷数据那么查询时间可能会显著增加因为系统需要从两个不同的地方获取数据。最后数据入湖后Schema变更操作需得到相应数据湖的支持。这意味着如果需要对数据结构进行修改例如添加或删除字段必须确保数据湖能够支持这些变更。这可能需要额外的技术支持和维护工作。 冷热分层V2Apache 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阶段我们发现在报表小查询场景平均tp9920ms中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类型(如类似Date2024-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_ttl10s实现历史数据立刻冷却至ChubaoFS。对全量热数据则统一设置了cooldown_ttl2years实现线上热数据随着两年时间窗口推进自动冷却。整个历史数据的恢复和冷却全过程做到对线上业务透明准确高效地实现全量历史数据恢复和冷却。同时在冷却数据过程中发现冷热数据策略设置异常问题进行了修复参考prhttps://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团队在京东广告场景中开展紧密合作共同探索存算分离架构在该场景中的实际应用。 作者 京东零售广告产研部-投放平台部-投放报表组
