Successfully reported this slideshow.

美团数据平台之Kafka应用实践和优化

2

Share

1 of 32
1 of 32

美团数据平台之Kafka应用实践和优化

2

Share

王萌萌, 美团

作为美团大数据平台的基础设施之一,Kafka支撑了美团内部众多业务线在数据采集、实时数仓、实时事件处理等方面的应用。本次分享主要介绍Kafka在美团的应用情况,以及我们在性能、稳定性、平台化管理方面的一些实践与优化经验。

https://www.meetup.com/Beijing-Kafka-Meetup/events/281812695/

王萌萌, 美团

作为美团大数据平台的基础设施之一,Kafka支撑了美团内部众多业务线在数据采集、实时数仓、实时事件处理等方面的应用。本次分享主要介绍Kafka在美团的应用情况,以及我们在性能、稳定性、平台化管理方面的一些实践与优化经验。

https://www.meetup.com/Beijing-Kafka-Meetup/events/281812695/

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

美团数据平台之Kafka应用实践和优化

  1. 1. 美团数据平台之Kafka应用实践和优化 美团数据平台中心 王萌萌 美团数据平台中心-数据集成团队负责人
  2. 2. 个人简介 王萌萌,美团大数据平台数据集成方向负责人, 2015年加入美团,主要负责为美团大数据生产分 析提供数据采集、集成、分发服务。在海量数据 采集、异构数据源数据同步、消息队列等方面有 较多的实践经验。
  3. 3. 大纲 • 背景介绍 • 实践1:读写延时优化 • 实践2:元数据服务稳定性提升 • 实践3:平台化管理 • 后续规划
  4. 4. 背景介绍-Kafka在美团大数据体系的应用 • 业务定位: Ø 数据采集管道 Ø 实时数据分发 • 典型服务场景: Ø 离线计算的缓存层 Ø 实时数仓 Ø 实时事件处理
  5. 5. • 集群规模: Ø 物理集群:30+ Ø 逻辑集群:100+ Ø 单集群最大broker数: 1800+ • Topic规模: Ø topic总数:10w+ Ø 单集群最大partition数:10w+ • 数据规模: Ø 峰值吞吐:700TB/s,3亿+ msg/s Ø 天级消息量:23w亿+ 背景介绍-服务规模
  6. 6. • SSD缓存架构 • 均衡策略 • 请求队列拆分 • sticky分区策略 实践1-读写延时优化
  7. 7. • 业务背景:延迟消费&实时消费场景并存 • 线上问题: PageCache容量不足引起磁盘读,不 仅速度变慢,而且会污染PageCache,影响其他 读写请求 累计百分比 请求时间分布 读写延时优化-SSD缓存架构
  8. 8. • 权衡成本与性能,引入SSD作为PageCache和HDD间的缓存层 • 热数据读SSD,冷数据读HDD 读写延时优化-SSD缓存架构
  9. 9. • 效果(延迟读较严重的集群): Ø TP99 写入时间从40ms+降至5ms Ø TP99 读取时间从300ms+降至180ms+ Ø HDD磁盘读取占比从19.5%降至1% 读写延时优化-SSD缓存架构
  10. 10. • 背景: Ø 机型异构,磁盘容量各异 Ø 业务多样,流量差异大 • 问题: Ø 磁盘利用率不均衡,偶发打满 Ø broker处理能力不均衡,热点频发 • 解法: Ø 事前:空闲磁盘优先的副本分配算法 Ø 事后:流量、磁盘容量多维度均衡 读写延时优化-均衡策略
  11. 11. • RoundRobin分配算法未考虑磁盘使用情况 • 改进:副本分配时采用空闲磁盘优先(IDF)策略。IDF基于箱子模型实现,每块磁盘被划分 为若干块大小相等的箱子(30GB),每个分区占用1~n个箱子 均衡策略-空闲磁盘优先的副本分配算法
  12. 12. • 迁移算法: Ø 整体策略:使用率高的磁盘迁移至使用率低的磁盘 Ø 细节策略: ü 考虑多磁盘规格,不同容量磁盘权重不同 Ø 限制条件: ü 保证replica分布在不同的broker上 ü 保证partition在不同磁盘上的数量均匀 ü 保证TOR容灾 ü 尽量保证partition/leader数均衡 均衡策略-磁盘均衡
  13. 13. 均衡策略-磁盘均衡效果
  14. 14. • 挑战:迁移效率 vs 读写稳定性 • 优化方案: Ø 提升迁移效率: ü 流水线加速,长尾分区不影响整体迁移速度 Ø 提升迁移稳定性: ü 低峰期迁移 ü 迁移并发控制、迁移限速 ü fetcher隔离 数据迁移优化
  15. 15. • 按批次(逻辑集群)提交迁移计划,串行执行 =>满足限流条件下,流水线向zk补充提交reassign 数据迁移优化-流水线加速
  16. 16. • 背景:follower实时读和延迟读共享一个fetcher线程, 延迟读影响实时读 Ø 延迟读的请求量远大于实时读,导致实时读请求积压 Ø 延迟读触发读磁盘,显著拖慢fetcher的拉取效率 • 改进: Ø 所有ISR的follower共享fetcher Ø 所有非ISR的follower共享fetcher 数据迁移优化-fetcher隔离
  17. 17. • 评价指标:同集群内leader写入速率的方 差尽可能小 • 细节设计: Ø reassign和prefer提交流水线化 Ø region粒度的管理能力 Ø 关键参数配置化: ü 执行时间 ü leader切换并发 ü reassign并发 均衡策略-流量均衡
  18. 18. • 核心组件处理链路分析: Ø Processor Ø RequestHandler 读写延时优化-请求队列拆分&sticky分区策略
  19. 19. • Processor瓶颈分析: Ø 对线上的慢节点,io-ratio和io-wait-ratio均很低->瓶颈在process 读写延时优化-请求队列拆分&sticky分区策略
  20. 20. • Processor的瓶颈: 高QPS的produce请求-> processor处理性能下降-> responseQueueTime升高, responseTime升高 ->totalTime升高 读写延时优化-请求队列拆分&sticky分区策略
  21. 21. • RequestHandler分析: Ø 多线程阻塞模型,多个RequestHandler共同消费 RequestQueue Ø 可能的瓶颈点:mmap触发磁盘读写,降低 RequestQueue消费速度,反压引起Processor阻 塞 读写延时优化-请求队列拆分&sticky分区策略
  22. 22. • 线上真实情况: Ø 高produce QPS造成 requestQueue拥堵(80%+) • 指标体现:network handler idle percent <= 0.2 && request handler idle percent >0.2 Ø requestHandler处理慢,反压到processor(10%+) • 指标体现:request handler idle percent <= 0.2 读写延时优化-请求队列拆分&sticky分区策略
  23. 23. • 解法: Ø 读写请求队列拆分,避免写影响读 Ø 客户端sticky方式发送,降低QPS • 业务背景: Ø 超过一半的写请求来自日志收集,客户端可控 读写延时优化-请求队列拆分&sticky分区策略
  24. 24. • 效果: Ø 客户端sticky策略:QPS降低为原来的1/20,吞吐&延时变化不大 Ø 读写队列拆分: ü 集群1(高QPS):读延迟下降80%,QPS增加40% ü 集群2(非高QPS):读写QPS/延迟无显著变化, ProcessorIdlePercent提升, QueueTime耗 时降低70% 读写延时优化-请求队列拆分&sticky分区策略
  25. 25. • 背景: Ø 集群规模过大,节点变更(掉线、升级等)频繁,元数据广播压力大(broker数*partition数) Ø FullGC频繁,主备controller切换,影响客户端消费 • 针对不同场景分别处理: Ø broker状态变更:broker startup/failure,此时的广播不必须 Ø controllor failover:需要全量广播,分批进行 实践2:元数据服务稳定性提升-广播优化
  26. 26. • 背景:依赖zk做节点探活,当zk故障恢复后controller产生误判,进行不必要的meta更新,误 判分区不可用,从而影响客户端消费 元数据服务稳定性提升-SafeMode
  27. 27. • SafeMode:对掉线节点数量进行判断,超过阈值即进入SafeMode状态 元数据服务稳定性提升- SafeMode
  28. 28. • 核心指标监控 Ø 服务端指标:基础环境指标(IO/Mem/CPU)、分阶段请求延迟、入出流量 Ø 客户端视角的指标:请求延迟分布、元数据接口成功率 Ø partition/broker/集群多维度聚合统计 实践3-平台化管理
  29. 29. • 核心指标监控 • 自动化运维:机器管理、扩容升级、数据迁移、数据均衡 实践3-平台化管理
  30. 30. • 能力扩展: Ø 事务能力 • 稳定性: Ø 硬件故障容错 Ø QoS能力 • 扩展性: Ø 存算分离 Ø 弹性架构 后续规划
  31. 31. Q&A
  32. 32. 邮箱:jinlai_ch@qq.com

×