货拉拉大数据 Doris 稳定性保障实践

杨秋吉-货拉拉-OLAP负责人梁健聪-货拉拉-大数据工程师 DataFunSummit#2023 目录CONTENT 背景与挑战稳定性流程规范 总结与规划 背景与挑战 DataFunSummit#2023 货拉拉介绍 货拉拉-大数据 货拉拉-大数据 Doris业务介绍 稳定性挑战 开源软件基本能力和生产需求之间的差距大 业务对Doris服务稳定性要求高 1. Doris内核能力完善，但外围平台能力不足，例如监控告警、运维管控2. Doris内核演进速度快，相应的Issue也较多 1. Doris已接入多个核心业务已成为大数据核心基础组件 稳定性保障目标 核心链路数据准确率：全年>=99.45%（2次/年） 少出事 核心链路问题（主动发现）时间<=5min 快发现 P0核心链路恢复时间<=5min；P1级（埋点相关指标，容忍度相对高）链路恢复时间<=10min 快恢复 02 稳定性能力保障 DataFunSummit#2023 稳定性案例 5、业务变更问题在问题发生后才发现新增字段变更 2、导数问题 3、数据质量问题 1、查询问题 Doris-1.1.3 Sparkload的unique模型数据查询结果不准确 稳定性案例 场景:云台查询Doris间歇性报错(Thread pool is at capacity) 案例一查询性能问题 原因:用户提交大量查询以及一些大查询，导致fragment的rpc处理线程池满 解法办法：1、加大查询缓存容量，增加缓存命中率（query_cache_max_size_mb） 2、查询超时由5min调整至3min3、增强大查询拦截能力 稳定性案例 场景:准实时场景下5分钟调度任务因多个任务执行超时，导致报表数据更新延迟并跌0 原因:新增的其他任务存在严重乱序，集群整体写入吞吐变慢，影响了准实时场景 解法办法：1、Doris任务及导入参数优化number_tablet_writer_threads (16 -> 32) 2、加强Doris变更规范管控与审批流程3、业务多租户隔离(进行中) 稳定性案例 场景:业务使用sparkload导入Unique模型表，查询结果不稳定 原因: Unique模型表使用Sparkload导数时存在异常 解法办法：1、将Unique模型改为Duplicate模型重建表 2、将Unique模型使用注意事项加入准入规范及最佳实践进行宣讲 稳定性案例 场景:凌晨时间段broker load任务和insert任务重合时间段，BE内存出现OOM被kill导致任务报错 原因:升级1.2版本后的bitmap向量化读没有进行谓词下推，导致内存上涨 解法办法：1、业务对SQL谓词下推的优化，如and和or的条件合并2、后续集群HA方案（因1.2无法直接回退1.1） 稳定性案例 场景:业务侧自行对Doris表进行新增字段,表数据未更新且在无法查询 原因:触发Doris版本1.0的bug，导致部分segment损坏，无法修复 解决办法:1、沉淀通过Sparkload快速恢复数据预案 2、宣导用户使用规范、任务上线规范、发布变更规范 建设思路 发现能力 目标 快发现：核心链路问题（主动发现）时间<=5min Doris监控告警系统 以Zabbix作为大数据基础架构组核心监控系统底座，对Doris服务进行监控和告警。 发现能力 1、表级监控：监控表容量、状态2、任务监控：监控导数任务状态 3、组件监控：服务指标(查询、导数)、进程、机器指标 发现能力 容量规划 容量梳理 容量监控 容量预警 1.高危/严重告警事件2.关注业务需求3.高峰期、拉货节保障4.监控容量异动 1.业务需求2.数据量3.硬件资源4.集群规模 1.机器指标2.服务内部指标3.导数及查询指标4.表级监控指标 容量规划-容量梳理 一、业务需求 三、硬件资源 1、了解业务当前需求，如实时或者离线、数据写入速度、时延、分区情况、查询要求、存储要求、是否有特殊feature支持，且需要业务完成大数据OLAP接入评审 1、参考官网硬件数据2、高性能HA模式，3台FE(云盘)+4台BE(本地SSD)2、中性能HA模式，3台FE(云盘)+ 4台>=BE(云盘)3、常规高可用配置FE的配置1:4，如4C16GBE的配置1:4，如32C128G 二、数据量 四、集群规模1、参考业务需求、数据量情况来确认最终的集群规模 1、BE独享节点-本地盘业务总数据量=当前存量+未来增量的数据量数据量预留比例=40%数据副本= 3所需磁盘总大小=(业务总数据量/(1 -数据量预留比例))*数据副本2、FE独享节点-云盘一般提供300GB 容量规划-容量监控 高可用能力 1.离线/准实时导数链路:Spark load/Broker load/Select insertinto任务，通过离线调度任务平台进行调度，支持异常自动重试或者电话告警2.实时导数链路：Flink类型任务，通过自研实时任务平台进行调度，支持异常自动重试或者电话告警 1.FE：三台FE高可用部署2.BE：数据三副本，四台及以上BE，避免一台宕机导致数据不可写3.LB：使用负载均衡绑定三台FE，实现连接数均衡及读写高可用 自动化能力 背景：初期在构建大数据Doris集群时，我们以标准SOP指引下通过脚本手动操作为主，人为误操作或遗漏的可能，稳定性相对较差。 进展：通过大数据自动化平台构建Doris自动化能力，底座基于Netflix Conductor、Ansible开发，已集成Doris部署、Doris扩容、Doris升级等工作流编排能力。 收益： 1、提升Doris组件服务稳定性2、提升运维人效 其他保障能力 一、查询拦截能力 1、设置用户级别拦截规则，根据实际数据量级、查询规模制定拦截规则2、可快速对异常query进行手动kill，防止对集群整体产生更大影响 二、故障快恢复能力 1、分区数据的快速恢复能力2、tablet状态恢复能力 三、业务隔离 1、根据业务重要程度、数据类型属于实时或离线进行集群隔离、多租户。 四、用户权限管控 1、通过使用Doris自带的RBAC(Role-BasedAccess Control)能力，对用户/角色赋予相关权限 03 稳定性流程规范 DataFunSummit#2023 稳定性流程规范 一、Doris业务准入规范 二、Doris使用规范 三、Doris业务变更规范 Doris业务准入规范 需求评估 1、快速理解业务需求，判断Doris是否最适合业务场景 准入评审 1、参加大数据部门的需求准入评审2、评估业务价值、投入产出比ROI Doris变更规范 一、发布窗口 三、审核 1、方向负责人、组负责人审核2、遵循Doris使用规范3、不变更就必然产生稳定性风险或无法故障恢复情况下可提前变更，事后补充 1、业务低峰期，非节假日前一天2、离线12-16点，实时20-24点3、非变更窗口需走紧急变更流程 二、发布内容、发布通知 四、验收 1、服务稳定性验收2、服务功能性验收3、异常快速回滚 1、发布背景、执行操作需描述清楚2、通知业务方、执行方、次日Oncall 04总结与规划 总结 三、保障能力 一、保障目标 1、发现能力2、容量规划3、高可用能力4、自动化能力5、拦截、隔离、恢复、权限管控能力 1、数据准确性/可靠性2、业务链路稳定性 二、案例分析 1、数据查询2、导数性能3、数据质量4、版本升级5、业务变更 四、流程规范 1、Doris业务准入规范2、Doris使用规范3、Doris变更规范 思考 稳定性的建设是持续的、成体系化的，而非靠运气 稳定性的目标实现需要业务方支持，而非靠单点突破 规划 稳 定 多集群HA、多租户隔离、冷热存储 易 用 OLAP能力平台化，提升易用能力 高 效 紧跟Doris社区，尝试更多的应用场景：高并发点查/文本搜索代替ES/联邦查询 感谢观看