Druid在滴滴的应用实践 刘博宇@滴滴出行
2020-03-01 698浏览
- 1.8 Druid在滴滴的应用实践 1 0 2 与平台化建设 C C T D 刘博宇
- 2.目录 8 1 01 Druid特性简介 02 Druid在滴滴的应用 C C T D 03 04 0 2 Druid平台化建设 展望
- 3.Druid特性介绍-Druid是什么？ 8 1 Druid是针对时间序列数据提供低延时的数据写入以及快速交互 式查询的分布式OLAP数据库。 T D C C 0 2
- 4.Druid特性介绍-时序数据库 TSDB(Time-series database) • 时间序列数据 • 低延时写入 • 快速聚合查询 0 2 8 1 C C 典型的TSDB：InfluxDB、Graphite、OpenTSDB T D • 写入即可查 – 内存增量索引 • 下采样，RDD – 预聚合 • Schema less – 需要预先定义schema
- 5.Druid特性介绍-OLAP数据库 OLAP数据库 - 上卷、切块、切片、下钻等操作 • 数据检索引擎 – ES • 预计算 + kv存储 - Kylin • SQL on Hadoop – Presto、SparkSQL T D C C 0 2 8 1
- 6.Druid特性介绍-OLAP数据库 数据检索引擎 – ES ① 结构化数据与非结构化数据，明细查询与聚合能力 ② 存储空间开销大 C C Druid 结构化数据 & 预聚合 T D ① 结构化数据 较弱的明细查询能力 ② 存储空间更小 ③ 针对数据的写入与聚合进行优化 8 1 0 2 ③ 数据的写入与聚合开销大
- 7.Druid特性介绍-OLAP数据库 预计算 + kv存储 - Kylin KV存储通过预计算来实现聚合，key涵盖了查询参数，值就是查询结果 8 1 ① 查询速度极快 ② 损失了查询的灵活性，复杂的场景下，预计算过程可能十分耗时 ③ 只有前缀拼配一种索引方式，大数据量下复杂过滤条件性能下降 ④ 缺少聚合下推的能力 0 2 T D C C Druid 列式存储 & Bitmap索引 ① 查询速度不如KV存储 ② 内存增量索引，增量预聚合，写入即可查 ③ 任意维度列组合过滤、聚合，查询灵活 ④ Scatter & Gather模式，支持一定的聚合下推
- 8.Druid特性介绍-OLAP数据库 SQL on Hadoop ① SQL支持强大 8 1 ② 无冗余数据，不需要预处理 0 2 ③ 分钟级响应 ④ QPS低 Druid T D C C ① SQL支持有限 ② 必须预先定义维度指标 ③ 亚秒级响应 ④ 高并发
- 9.Druid在滴滴的应用-使用概况 规模 • 多个集群数百台机器 • 千亿级日原始数据写入量 • TB级日落盘数据量 • 数百实时数据源，千级实时写入任务 • 近千万级日查询量 承接业务 • T D C C 0 2 监控、实时报表、大屏展示等业务 8 1
- 10.Druid在滴滴的应用-应用案例 业务实时监控 承接公司所有核心业务的指标监控与告警 T D C C 0 2 8 1
- 11.Druid在滴滴的应用-应用案例 实时报表类应用 运营数据分析、客户端网络性能分析、客服应答实时统计等等 T D C C 0 2 8 1
- 12.Druid在滴滴的应用-应用案例 大屏展示类应用 客服服务状态大屏 T D C C 0 2 8 1
- 13.Druid平台化建设 背景 • 业务数据主要来源，日志、binlog • 公司统一数据通道Kafka • 业务监控指标多样，逻辑复杂多变 • Druid接入配置较复杂，工单接入方式成本高 • 数据进入Druid之前通常需要流计算处理 • 数据链路较长，上下游关系需要梳理 • Druid服务需要提供数据可视化能力 T D C C 0 2 8 1
- 14.Druid平台化建设 实时计算平台 提供流计算，Druid数据储存，指标查询，数据可视化一站式服务。 T D C C 0 2 8 1
- 15.Druid平台化建设 基本工作流 T D C C 0 2 8 1
- 16.Druid平台化建设 Druid数据源用户自助接入 T D C C 0 2 8 1
- 17.Druid平台化建设 Druid查询Web化配置，100%SQL T D C C 0 2 8 1
- 18.Druid平台化建设-稳定性 挑战 1. 核心业务与非核心业务共享资源，存在风险。 8 1 2. 用户提交任务配置、查询不合理，造成异常状况，甚至影响集群稳定性。 0 2 3. 随着业务的快速发展，Druid依赖组件热迁移到独立部署环境。 T D C C
- 19.Druid平台化建设-稳定性 针对不同重要程度的业务共享资源的问题 1. Druid集群异地双活，核心数据源集群级双活 8 1 2. 统一网关建设 ① 对用户屏蔽多集群细节 0 2 ② 根据用户身份进行查询路由，实现查询资源隔离 C C 3. 业务分级： ① 核心业务集群级双活； T D ② 对查询资源需求较高的大业务分配独立查询资源组 ③ 其他使用默认资源池
- 20.Druid平台化建设-稳定性 异地双活、业务分级、资源隔离 T D C C 0 2 8 1
- 21.Druid平台化建设-稳定性 针对用户配置与查询不合理造成的异常 1. 引擎层面bad case防范（earlyMessageRejectPeriod的case） 8 1 2. 封装druid原生API，提供更合理的默认配置项 3. 完善指标监控体系与异常定位手段，确保能捕捉到异常查询 日志与指标收集 C C 0 2 结合Druid的聚合查询能力与ES的明细查询能力进行问题定位 T D
- 22.Druid平台化建设-稳定性 第三方依赖热迁移 Zookeeper迁移：扩容-集群分裂-缩容的迁移方案 zk1 zk2 zk3 2. zk1 zk2 zk3 zk4 zk1 zk2 zk3 zk4 3. C C T D zk5 zk5 zk6 zk6 5. zk7 8 1 0 2 4. 1. zk1 zk2 zk3 zk1 zk2 zk3 zk1 zk2 zk3 zk4 zk4 zk7 zk5 zk6 zk5 zk6 zk7 zk5 zk6 zk7 6. zk7 zk4
- 23.Druid平台化建设-稳定性 第三方依赖热迁移 MySQL迁移：开发实时任务状态冻结API（针对Kafka-indexing-service），保证元数 8 1 据的不变性，随后进行迁移 T D C C 0 2
- 24.Druid平台化建设-稳定性 第三方依赖热迁移 HDFS迁移：保证历史节点可以读取两个HDFS集群，混动升级MM，改变增量数据写入 8 1 地址；批量修改元数据，改变存量数据的加载地址。 T D C C 0 2
- 25.Druid平台化建设-性能优化 实时数据接入方式对比 Standalone Realtime Node 8 1 • 数据消费任务为单机模式，任务失败后无法恢复 • 使用Kafka高阶API，多任务消费数据时，难以保证副本任务消费相同的数据 Tranquility + indexing-service C C 0 2 • 任务失败后无法恢复，如果所有副本任务都失败，那么还是会丢失数据 • 数据迟到容忍窗口与任务时长挂钩，无法做到容忍较长时间的数据迟到 T D Kafka-indexing-service • 实时任务数据消费依赖Overlord服务，所以Overlord单机性能将会成为集群规模的瓶颈 • 由于Segment与Kafka topic的partition关联，容易造成元数据过度膨胀，引发性能问题
- 26.Druid平台化建设-性能优化 问题背景： 主要Kafka-indexing-service作为数据写入方式，具有高可用、接入便捷的优势，但 8 1 是高度依赖Overlord节点服务。 Overlord节点高峰期的性能瓶颈导致： ① Druid消费能力下降 0 2 ② 实时任务调度不及时，实时任务状态判断错误 ① Mysql查询性能问题 C C T D 经过定位，瓶颈有以下原因 ② 元数据JSON化存储，反序列化耗时 ③ ZK watch回调单线程模型事件处理排队
- 27.Druid平台化建设-性能优化 针对Mysql查询瓶颈 ① Druid元数据存储索引优化 8 1 ② 元数据合并精简，Segment定时Merge，合理设置数据生命周期 ③ 数据库连接池DBCP2参数修改 针对反序列化与Watch回调问题 0 2 C C 对Druid进行多Overlord改造，引入namespace概念，增加Overlord水平扩展能力 namespace:n1T D task task MM1 namespace:n2task task MM2 task MM3
- 28.展望 • Druid数据消费能力依赖kafka topic的partition，引入Flink等流计算引擎， 提升单partition消费能力，解耦对topic partition的依赖。 • 8 1 Overlord大量服务需要涉及对Mysql的直接操作，单机性能瓶颈仍存在，后 续将会对高并发服务进行内存化改造。 0 2 • Coordinator任务处理单线程模型需要优化。 • On-yarn，提升资源利用率，简化运维。 T D C C
- 29.T D C C 0 2 8 1
- 30.
