Kafka 集群在马蜂窝大数据平台的优化与应用扩展

马蜂窝技术原创文章，更多干货请订阅公众号：mfwtech

Kafka 是当下热门的消息队列中间件，它能够实时地处理海量数据，具有高吞吐、低延时等特性及可靠的消息异步传递机制，能够很好地解决不一样系统间数据的交流和传递问题。

Kafka 在马蜂窝也有很是普遍的应用，为不少核心的业务提供支撑。本文将围绕 Kafka 在马蜂窝大数据平台的应用实践，介绍相关业务场景、在 Kafka 应用的不一样阶段咱们遇到了哪些问题以及如何解决、以后还有哪些计划等。

 

Part.1 应用场景

从 Kafka 在大数据平台的应用场景来看，主要分为如下三类：

第一类是将 Kafka 做为数据库，提供大数据平台对实时数据的存储服务。历来源和用途两个维度来讲，能够将实时数据分为业务端 DB 数据、监控类型日志、基于埋点的客户端日志 (H五、WEB、APP、小程序) 和服务端日志。

第二类是为数据分析提供数据源，各埋点日志会做为数据源，支持并对接公司离线数据、实时数据仓库及分析系统，包括多维查询、实时 Druid OLAP、日志明细等。

第三类是为业务方提供数据订阅。除了在大数据平台内部的应用以外，咱们还使用 Kafka 为推荐搜索、大交通、酒店、内容中心等核心业务提供数据订阅服务，如用户实时特征计算、用户实时画像训练及实时推荐、反做弊、业务监控报警等。

主要应用以下图所示：

 

Part.2 演进之路

四个阶段

早期大数据平台之因此引入 Kafka 做为业务日志的收集处理系统，主要是考虑到它高吞吐低延迟、多重订阅、数据回溯等特色，能够更好地知足大数据场景的需求。但随着业务量的迅速增长，以及在业务使用和系统维护中遇到的问题，例如注册机制、监控机制等的不完善，致使出现问题没法快速定位，以及一些线上实时任务发生故障后没有快速恢复致使消息积压等, 使 Kafka 集群的稳定性和可用性得受到挑战，经历了几回严重的故障。

解决以上问题对咱们来讲迫切而棘手。针对大数据平台在使用 Kafka 上存在的一些痛点，咱们从集群使用到应用层扩展作了一系列的实践，总体来讲包括四个阶段：

第一阶段：版本升级。围绕平台数据生产和消费方面存在的一些瓶颈和问题，咱们针对目前的 Kafka 版本进行技术选型，最终肯定使用 1.1.1 版本。

第二阶段：资源隔离。为了支持业务的快速发展，咱们完善了多集群建设以及集群内 Topic 间的资源隔离。

第三阶段：权限控制和监控告警。

首先在安全方面，早期的 Kafka 集群处于裸跑状态。因为多产品线共用 Kafka，很容易因为误读其余业务的 Topic 致使数据安全问题。所以咱们基于 SASL/ SCRAM + ACL 增长了鉴权的功能。

在监控告警方面，Kafka 目前已然成为实时计算中输入数据源的标配，那么其中 Lag 积压状况、吞吐状况就成为实时任务是否健康的重要指标。所以，大数据平台构建了统一的 Kafka 监控告警平台并命名「雷达」，多维度监控 Kafka 集群及使用方状况。

第四阶段：应用扩展。早期 Kafka 在对公司各业务线开放的过程当中，因为缺少统一的使用规范，致使了一些业务方的不正确使用。为解决该痛点，咱们构建了实时订阅平台，经过应用服务的形式赋能给业务方，实现数据生产和消费申请、平台的用户受权、使用方监控告警等众多环节流程化自动化，打造从需求方使用到资源全方位管控的总体闭环。

下面围绕几个关键点为你们展开介绍。

核心实践

1. 版本升级

以前大数据平台一直使用的是 0.8.3 这一 Kafka 早期版本，而截止到当前，Kafka 官方最新的 Release 版本已经到了 2.3，因而长期使用 0.8 版本过程当中渐渐遇到的不少瓶颈和问题，咱们是可以经过版本升级来解决的。

举例来讲，如下是一些以前使用旧版时常见的问题：

• 缺乏对 Security 的支持:存在数据安全性问题及没法经过认证受权对资源使用细粒度管理
• broker under replicated：发现 broker 处于 under replicated 状态，但不肯定问题的产生缘由，难以解决。
• 新的 feature 没法使用：如事务消息、幂等消息、消息时间戳、消息查询等。
• 客户端的对 offset 的管理依赖 zookeeper, 对 zookeeper 的使用太重, 增长运维的复杂度
• 监控指标不完善：如 topic、partition、broker 的数据 size 指标, 同时 kafka manager 等监控工具对低版本 kafka 支持很差

同时对一些目标版本的特性进行了选型调研，如：

• 0.9 版本, 增长了配额和安全性, 其中安全认证和受权是咱们最关注的功能
• 0.10 版本，更细粒度的时间戳. 能够基于偏移量进行快速的数据查找，找到所要的时间戳。这在实时数据处理中基于 Kafka 数据源的数据重播是极其重要的
• 0.11 版本, 幂等性和 Transactions 的支持及副本数据丢失/数据不一致的解决。
• 1.1 版本，运维性的提高。好比当 Controller Shut Down，想要关闭一个 Broker 的时候，以前须要一个很长很复杂的过程在 1.0 版本获得很大的改善。

最终选择 1.1 版本, 则是由于出于 Camus 与 Kafka 版本的兼容性及 1.1 版本已经知足了使用场景中重要新特性的支持的综合考量。这里再简单说一下 Camus 组件，一样是由 Linkedin 开源，在咱们的大数据平台中主要做为 Kafka 数据 Dump 到 HDFS 的重要方式。

2. 资源隔离

以前因为业务的复杂性和规模不大，大数据平台对于 Kafka 集群的划分比较简单。因而，一段时间之后致使公司业务数据混杂在一块儿，某一个业务主题存在的不合理使用都有可能致使某些 Broker 负载太重，影响到其余正常的业务，甚至某些 Broker 的故障会出现影响整个集群，致使全公司业务不可用的风险。

针对以上的问题，在集群改造上作了两方面实践：

• 按功能属性拆分独立的集群
• 集群内部 Topic 粒度的资源隔离

(1) 集群拆分

按照功能维度拆分多个 Kafka 物理集群，进行业务隔离，下降运维复杂度。

以目前最重要的埋点数据使用来讲, 目前拆分为三类集群，各种集群的功能定义以下：

• Log 集群：各端的埋点数据采集后会优先落地到该集群, 因此这个过程不能出现因为 Kafka 问题致使采集中断，这对 Kafka 可用性要求很高。所以该集群不会对外提供订阅，保证消费方可控；同时该集群业务也做为离线采集的源头，数据会经过 Camus 组件按小时时间粒度 dump 到 HDFS 中，这部分数据参与后续的离线计算。

• 全量订阅集群：该集群 Topic 中的绝大部分数据是从 Log 集群实时同步过来的。上面咱们提到了 Log 集群的数据是不对外的，所以全量集群就承担了消费订阅的职责。目前主要是用于平台内部的实时任务中，来对多个业务线的数据分析并提供分析服务。

• 个性定制集群：以前提到过，咱们能够根据业务方需求来拆分、合并数据日志源，同时咱们还支持定制化 Topic，该集群只须要提供分流后 Topic 的落地存储。

集群总体架构划分以下图：

(2) 资源隔离

Topic 的流量大小是集群内部进行资源隔离的重要依据。例如，咱们在业务中埋点日志量较大的两个数据源分别是后端埋点数据源 server-event 和端上的埋点 mobile-event 数据源，咱们要避免存储两个数据的主题分区分配到集群中同一个 Broker 上的节点。经过在不一样 Topic 进行物理隔离，就能够避免 Broker 上的流量发生倾斜。

3. 权限控制和监控告警

(1) 权限控制

开始介绍时咱们说过，早期 Kafka 集群没有设置安全验证处于裸跑状态，所以只要知道 Broker 的链接地址便可生产消费，存在严重的数据安全性问题。

通常来讲, 使用 SASL 的用户多会选择 Kerberos，但就平台 Kafka 集群的使用场景来讲，用户系统并不复杂，使用 Kerberos 就有些大材小用, 同时 Kerberos 相对复杂，存在引起其余问题的风险。另外，在 Encryption 方面, 因为都是运行在内网环境，因此并无使用 SSL 加密。

最终平台 Kafka 集群使用 SASL 做为鉴权方式, 基于 SASL/ SCRAM + ACL 的轻量级组合方式，实现动态建立用户，保障数据安全。

(2) 监控告警

以前在集群的使用中咱们常常发现，消费应用的性能平白无故变差了。分析问题的缘由, 一般是滞后 Consumer 读取的数据大几率没有命中 Page- cache，致使 Broker 端机器的内核要首先从磁盘读取数据加载到 Page- cache 中后，才能将结果返还给 Consumer，至关于原本能够服务于写操做的磁盘如今要读取数据了, 影响了使用方读写同时下降的集群的性能。

这时就须要找出滞后 Consumer 的应用进行事前的干预从而减小问题发生，所以监控告警不管对平台仍是用户都有着重大的意义。下面介绍一下咱们的实践思路。

总体方案：

总体方案主要是基于开源组件 Kafka JMX Metrics+OpenFalcon+Grafana：

• Kafka JMX Metrics：Kafka broker 的内部指标都以 JMX Metrics 的形式暴露给外部。1.1.1 版本 提供了丰富的监控指标，知足监控须要
• OpenFalcon：小米开源的一款企业级、高可用、可扩展的开源监控系统
• Grafana：Metrics 可视化系统，你们比较熟悉，可对接多种 Metrics 数据源。

关于监控：

• Falcon-agent：部署到每台 Broker 上, 解析 Kafka JMX 指标上报数据
• Grafana：用来可视化 Falcon Kafka Metrics 数据，对 Cluster、Broker、Topic、Consumer 4 个角色制做监控大盘。
• Eagle：获取消费组 Active 状态、消费组 Lag 积压状况，同时提供 API，为监控告警系统「雷达」提供监控数据。

关于告警：

雷达系统: 自研监控系统，经过 Falcon 及 Eagle 获取 Kafka 指标，结合设定阈值进行告警。以消费方式举例，Lag 是衡量消费状况是否正常的一个重要指标，若是 Lag 一直增长，必需要对它进行处理。

发生问题的时候，不只 Consumer 管理员要知道，它的用户也要知道，因此报警系统也须要通知到用户。具体方式是经过企业微信告警机器人自动提醒对应消费组的负责人或使用者及 Kafka 集群的管理者。

监控示例：

 

4. 应用扩展

(1) 实时数据订阅平台 

实时数据订阅平台是一个提供 Kafka 使用全流程管理的系统应用，以工单审批的方式将数据生产和消费申请、平台用户受权、使用方监控告警等众多环节流程化自动化, 并提供统一管控。

核心思想是基于 Kafka 数据源的身份认证和权限控制，增长数据安全性的同时对 Kafka 下游应用进行管理。

(2) 标准化的申请流程

不管生产者仍是消费者的需求，使用方首先会以工单的方式提出订阅申请。申请信息包括业务线、Topic、订阅方式等信息；工单最终会流转到平台等待审批；若是审批经过，使用方会分配到受权帐号及 Broker 地址。至此，使用方就能够进行正常的生产消费了。

(3) 监控告警

对于平台来讲，权限与资源是绑定的，资源能够是用于生产的 Topic 或消费使用的 GroupTopic。一旦权限分配后，对于该部分资源的使用就会自动在咱们的雷达监控系统进行注册，用于资源整个生命的周期的监控。 

(4) 数据重播

出于对数据完整性和准确性的考量，目前 Lamda 架构已是大数据的一种经常使用架构方式。但从另外一方面来讲，Lamda 架构也存在资源的过多使用和开发难度高等问题。

实时订阅平台能够为消费组提供任意位点的重置，支持对实时数据按时间、位点等多种方式的数据重播, 并提供对 Kappa 架构场景的支持，来解决以上痛点。

(5) 主题管理

为何提供主题管理？举一些很简单的例子，好比当咱们想让一个用户在集群上建立他本身的 Kafka  Topic，这时显然是不但愿让他直接到一个节点上操做的。所以刚才所讲的服务，无论是对用户来说，仍是管理员来说，咱们都须要有一个界面操做它，由于不可能全部人都经过 SSH 去连服务器。

所以须要一个提供管理功能的服务，建立统一的入口并引入主题管理的服务，包括主题的建立、资源隔离指定、主题元数据管理等。

(6) 数据分流

在以前的架构中, 使用方消费 Kafka 数据的粒度都是每一个 Kafka Topic 保存 LogSource 的全量数据，但在使用中不少消费方只须要消费各 LogSource 的部分数据，可能也就是某一个应用下几个埋点事件的数据。若是须要下游应用本身写过滤规则，确定存在资源的浪费及使用便捷性的问题；另外还有一部分场景是须要多个数据源 Merge 在一块儿来使用的。

基于上面的两种状况, 我人实现了按业务方需求拆分、合并并定制化 Topic 支持跨数据源的数据合并及 appcode 和 event code 的任意组个条件的过滤规则。

 

Part.3 后续计划

• 解决数据重复问题。为了解决目前平台实时流处理中因故障恢复等因素致使数据重复的问题，咱们正在尝试用 Kafka 的事务机制结合 Flink 的两段提交协议实现端到端的仅一次语义。目前已经在平台上小范围试用, 若是经过测试，将会在生产环境下推广。

• Consumer 限流。在一写多读场景中, 若是某一个 Consumer 操做大量读磁盘, 会影响 Produce 级其余消费者操做的延迟。l 所以，经过 Kafka Quota 机制对 Consume 限流及支持动态调整阈值也是咱们后续的方向

• 场景扩展。基于 Kafka 扩展 SDK、HTTP 等多种消息订阅及生产方式，知足不一样语言环境及场景的使用需求。

以上就是关于 Kafka 在马蜂窝大数据平台应用实践的分享，若是你们有什么建议或者问题，欢迎在马蜂窝技术公众号后台留言。

本文做者：毕博，马蜂窝大数据平台研发工程师。