Kafka 集群在马蜂窝大数据平台的优化与应用扩展
|
Kafka 是当下热门的消息队列中间件，它可以实时地处理海量数据，具备高吞吐、低延时等特性及可靠的消息异步传递机制，可以很好地解决不同系统间数据的交流和传递问题。 Kafka 在马蜂窝也有非常广泛的应用，为很多核心的业务提供支撑。本文将围绕 Kafka 在马蜂窝大数据平台的应用实践，介绍相关业务场景、在 Kafka 应用的不同阶段我们遇到了哪些问题以及如何解决、之后还有哪些计划等。 Part.1应用场景 从 Kafka 在大数据平台的应用场景来看，主要分为以下三类： 第一类是将 Kafka 作为数据库，提供大数据平台对实时数据的存储服务。从来源和用途两个维度来说，可以将实时数据分为业务端 DB 数据、监控类型日志、基于埋点的客户端日志(H5、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 的支持及副本数据丢失/数据不一致的解决。幂等性意味着对于同一个 Partition，面对 Data 的多次发布，Kafka broker 端就可以做到自动去重；对 Transactions 的支持使一个事务下发布多条信息到多个 Topic Partition 时，我们可以使它以原子性的方式被完成。在我们的下游消费者中，很多都是用 Flink 做一些流处理的工作，因此在数据处理及故障恢复时仅一次语义则显得尤为重要。而 0.11 版本对于事务的支持则可以保证与 Kafka 交互的 Flink 应用实现端到端仅一次语义, 支持 EOS 可以对数据可靠性有绝对要求, 比如交易、风控等场景下的重要支持。Leader Epoch：解决了原先依赖水位表示副本进度可能造成的数据丢失/数据不一致问题。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 物理集群，进行业务隔离，降低运维复杂度。 以目前最重要的埋点数据使用来说, 目前拆分为三类集群，各类集群的功能定义如下： （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
