快手万亿级别 Kafka 集群应用实践与技术演进之路 赵健博

QCon大会

2019/05/14 发布于 技术 分类

QCon  QCon2019 

文字内容
1. 快手万亿级别Kafka集群应用实践与技术演进之路 赵健博 大数据架构团队负责人
2. 自我介绍
3. 自我介绍 快手科技大数据架构团队负责人 10年大数据架构研发与应用经验 存储、计算、调度、AI架构以及周边子系统
4. 目录 业务背景 技术演进 未来规划
5. 目录 业务背景 场景 集群 规模 技术演进 未来规划
6. 业务场景 集群 场景 在线集群 在线服务消息中间件 集群 集群 场景 LOG集群 1.日志收集与传输的本地缓存 2.面向重要的实时消费与数据处理 场景 离线集群 1.日志的最终汇聚点,数 据dump到Hadoop集群。 离线建仓与处理 2. 面向次重要的实时消费 与数据处理
7. 业务场景 集群 场景 在线集群 在线服务消息中间件 LOG集群 1.日志收集与传输的本 地缓存 离线集群 2.面向重要的实时消费 与数据处理 1.日志的最终汇聚点, 数据dump到Hadoop 集群 2. 面向次重要的实时消 费与数据处理 集群拆分:服务质量保障
8. 规模 2000 30+ 12000 20万 机器数 集群数 Topic Topic Partition 4万亿+ 1亿 4P/20P 1T/4T 日处理 消息数 日消息 峰值 总流量 带宽峰 值(bps)
9. 目录 业务背景 技术演进 演进时间线 技术改进剖析 未来规划
10. 技术演进时间线 多集群建设 可用性改造 资源管理平台建设 Cache改造 …… 2017.7 2017.12 2018.4 2018.8 2019 2017.10 2018.2 2018.6 2018.11 平滑扩容 Mirror集群化建设 资源隔离 消费智能限速 支持业务快发展 保障业务稳定 可维护性提升,提高效率 精细化打磨:稳定性、流控、性能\容量优化
11. 技术演进时间线 多集群建设 可用性改造 资源管理平台建设 Cache改造 …… 2017.7 2017.12 2018.4 2018.8 2019 2017.10 2018.2 2018.6 2018.11 平滑扩容 Mirror集群化建设 资源隔离 消费智能限速
12. 平滑扩容 1 2 3
13. 平滑扩容  原有扩容流程问题:  数据迁移从Partition最初的offset开始,触发读 盘,物理资源大量消耗 => produce延迟增高且 抖动;扩容不平滑 为什么一定要从partition最初offset开始迁移数据呢?
14. 平滑扩容  解决思路:  从最新offset开始迁移  同步一定时间,保障所有consumer都已经 跟上 https://issues.apache.org/jira/browse/KAFKA-8328
15. 技术演进时间线 多集群建设 可用性改造 资源管理平台建设 Cache改造 …… 2017.7 2017.12 2018.4 2018.8 2019 2017.10 2018.2 2018.6 2018.11 平滑扩容 Mirror集群化建设 资源隔离 消费智能限速
16. Mirror集群化  MirrorMaker主要问题: 1. 静态管理,运维成本高,易出错  mirror的topic(1000+)  mirror的机器列表 2. 变更操作导致正在运行的数据Mirror 整体断流  增减topic  增减机器
17. Mirror集群化 KReplicator是基于UReplicator的改进版本 UReplicator: https://github.com/uber/uReplicator
18. Mirror集群化  Controller:  动态管理topic、worker节点的增减  Topic partition的分配策略(变更时支持局部 partition的迁移)  检测worker异常,并重新分配  KReplicator worker:  支持动态增加或者减少topic partition  执行mirror任务(一个worker支持多个源到多个 目标集群的传输)  执行dump到HDFS的任务  ZooKeeper:  协调controller与worker的交互 KReplicator是基于UReplicator的改进版本 UReplicator: https://github.com/uber/uReplicator Mirror服务集群化管理:减低运维,避免出错,支持快速调整,应对突增流量
19. 技术演进时间线 多集群建设 可用性改造 资源管理平台建设 Cache改造 …… 2017.7 2017.12 2018.4 2018.8 2019 2017.10 2018.2 2018.6 2018.11 平滑扩容 Mirror集群化建设 资源隔离 消费智能限速
20. 资源隔离  问题1. 不同业务线topic缺少物理隔 离,会相互影响
21. 资源隔离  问题1.不同业务线topic缺少物理隔 离,会相互影响  解决思路:  Broker级别物理隔离  创建Topic  迁移TP  宕机恢复流程
22. 资源隔离  问题1.不同业务线topic缺少物理隔 离,会相互影响  解决思路:  Broker级别物理隔离  创建Topic  迁移TP  宕机恢复流程  问题2. Kafka Rpc队列缺少隔离,一 旦某个topic处理慢,会导致所有请求 hang住
23. 资源隔离  问题1.不同业务线topic缺少物理隔 离,会相互影响  解决思路:  Broker级别物理隔离  创建Topic  迁移TP  宕机恢复流程  问题2. Kafka Rpc队列缺少隔离,一 旦某个topic处理慢,会导致所有请求 hang住  解决思路:  多RPC队列,进行隔离
24. 技术演进时间线 多集群建设 可用性改造 资源管理平台建设 Cache改造 …… 2017.7 2017.12 2018.4 2018.8 2019 2017.10 2018.2 2018.6 2018.11 平滑扩容 Mirror集群化建设 资源隔离 消费智能限速
25. Cache改造  Kafka高性能依赖page cache,但page cache不可控,主要问题: 1. Consumer的lag读会对page cache产生污染
26. Cache改造  Kafka高性能依赖page cache,但page cache不可控,主要问题: 1. Consumer的lag读会对page cache产生污染 2. Follower也会占用page cache的空间,从而产生污染  Kafka服务自己维护数据cache: 1. 严格按照时间顺序cache 2. 控制follower的数据不进入cache
27. Cache改造
28. Cache改造
29. Cache改造  环境:  5个Broker;一个topic(150Partiton+3副本)  压力:  Mirror数据到topic上;  150个consumer,总体lag 450w读数据  结论:  Cache版本可以缓存更多数据在内存中  Cache版本的性能会更好
30. Cache改造 写入操作同步写内存,异步刷磁盘,延迟更稳定!
31. 技术演进时间线 多集群建设 可用性改造 资源管理平台建设 Cache改造 …… 2017.7 2017.12 2018.4 2018.8 2019 2017.10 2018.2 2018.6 2018.11 平滑扩容 Mirror集群化建设 资源隔离 消费智能限速
32. 消费智能限速  问题:如何解决comsumer lag后读盘导致 producer写入受阻问题?  思路:当磁盘繁忙,针对lag的consumer进行 限速控制
33. 消费智能限速 限速开始 稳定 限速开始 稳定
34. 目录 业务背景 技术演进 演进时间线 技术改进剖析(平滑扩容、mirror集群化、可用性、性能) 未来规划
35. 未来规划  跨IDC统一大集群建设  Controller性能改进  事物能力支持  坏磁盘节点的检测与规避