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 架构也存在资源的过多使用和开发难度高等问题。 （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
