Kafka是当下热门的消息队列中间件，它可以实时地处理海量数据，具备高吞吐、低延时等特性及可靠的消息异步传递机制，可以很好地解决不同系统间数据的交流和传递问题。Kafka在马蜂窝也有非常广泛的应用，为很多核心的业务提供支撑。本文将围绕Kafka在马蜂窝大数据平台的应用实践，介绍相关业务场景、在Kafka应用的不同阶段我们遇到了哪些问题以及如何解决、之后还有哪些计划等。Part.1应用场景从Kafka在大数据平台的应用场景来看，主要分为以下三类：第一类是将Kafka作为数据库，提供大数据平台对实时数据的存储服务。从来源和用途两个维度来说，可以将实时数据分为业务端DB数据、监控类型日志、基于埋点的客户端日志(H5、WEB、APP、小程序)和服务端日志。第二类是为数据分析提供数据源，各埋点日志会作为数据源，支持并对接公司离线数据、实时数据仓库及分析系统，包括多维查询、实时DruidOLAP、日志明细等。第三类是为业务方提供数据订阅。除了在大数据平台内部的应用之外，我们还使用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的支持:存在数据安全性问题及无法通过认证授权对资源使用细粒度管理brokerunderreplicated：发现broker处于underreplicated状态，但不确定问题的产生原因，难以解决。新的feature无法使用：如事务消息、幂等消息、消息时间戳、消息查询等。客户端的对offset的管理依赖zookeeper,对zookeeper的使用过重,增加运维的复杂度监控指标不完善：如topic、partition、broker的数据size指标,同时kafkamanager等监控工具对低版本kafka支持不好同时对一些目标版本的特性进行了选型调研，如：0.9版本,增加了配额和安全性,其中安全认证和授权是我们最

转载请注明:http://www.aideyishus.com/lkyy/7556.html