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

1、快手万亿级别Kafka集群应用实践与技术演进之路大数据架构团队负责人目录业务背景技术演进未来规划目录业务背景场景集群规模技术演进未来规划业务场景集群场景在线集群在线服务消息中间件集群场景LOG集群 1.日志收集与传输的本地缓存2.面向重要的实时消费与数据处理集群场景离线集群1.日志的最终汇聚点，数据dump到Hadoop集群。离线建仓与处理2.面向次重要的实时消费与数据处理业务场景集群场景在线集群在线服务消息中间件LOG集群1.日志收集与传输的本地缓存2.面向重要的实时消费与数据处理离线集群1.日志的最终汇聚点，数据dump到Hadoop集群2.面向次重要的实时消费与数据处理集群拆分：服务质量

2、保障规模日处理消息数4万亿+日消息峰值1亿总流量4P/20P带宽峰值(bps)1T/4T集群数30+Topic12000TopicPartition20万机器数2000目录业务背景技术演进演进时间线技术改进剖析未来规划技术演进时间线2017.72017.7多集群建设2017.122017.12可用性改造2018.42018.4资源管理平台建设2018.82018.8Cache改造201920192017.102017.10平滑扩容2018.22018.2Mirror集群化建设2018.62018.6资源隔离2018.112018.11消费智能限速支持业务快发展保障业务稳定可维护性提升，提高效率

3、精细化打磨：稳定性、流控、性能容量优化技术演进时间线2017.72017.7多集群建设2017.122017.12可用性改造2018.42018.4资源管理平台建设2018.82018.8Cache改造201920192017.102017.10平滑扩容2018.22018.2Mirror集群化建设2018.62018.6资源隔离2018.112018.11消费智能限速平滑扩容213平滑扩容为什么一定要从partition最初offset开始迁移数据呢？原有扩容流程问题：数据迁移从Partition最初的offset开始,触发读盘，物理资源大量消耗=produce延迟增高且抖动；扩容不平滑平滑

4、扩容 解决思路：从最新offset开始迁移 同步一定时间，保障所有consumer都已经跟上https:/issues.apache.org/jira/browse/KAFKA-8328技术演进时间线2017.72017.7多集群建设2017.122017.12可用性改造2018.42018.4资源管理平台建设2018.82018.8Cache改造201920192017.102017.10平滑扩容2018.22018.2Mirror集群化建设2018.62018.6资源隔离2018.112018.11消费智能限速Mirror集群化 MirrorMaker主要问题：1.静态管理，运维成本高，易

5、出错 mirror的topic（1000+）mirror的机器列表2.变更操作导致正在运行的数据Mirror整体断流 增减topic 增减机器Mirror集群化KReplicator是基于UReplicator的改进版本UReplicator：https:/ Controller：动态管理topic、worker节点的增减 Topic partition的分配策略（变更时支持局部partition的迁移）检测worker异常，并重新分配 KReplicator worker：支持动态增加或者减少topic partition 执行mirror任务（一个worker支持多个源到多个目标集群的传输

6、）执行dump到HDFS的任务 ZooKeeper：协调controller与worker的交互Mirror服务集群化管理：减低运维，避免出错，支持快速调整，应对突增流量技术演进时间线2017.72017.7多集群建设2017.122017.12可用性改造2018.42018.4资源管理平台建设2018.82018.8Cache改造201920192017.102017.10平滑扩容2018.22018.2Mirror集群化建设2018.62018.6资源隔离2018.112018.11消费智能限速资源隔离 问题1.不同业务线topic缺少物理隔离，会相