Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 32

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

2

Share

王萌萌, 美团

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

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 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

×