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

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

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 的支持及副本数据丢失/数据不一致的解决。
  • 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 在马蜂窝大数据平台应用实践的分享,如果大家有什么建议或者问题,欢迎在马蜂窝技术公众号后台留言。

本文作者:毕博,马蜂窝大数据平台研发工程师。

Image placeholder
aming
未设置
  66人点赞

没有讨论,发表一下自己的看法吧

推荐文章
从0到1,马蜂窝大交通团队如何构建高效研发流程体系?

“旅游之前,先上马蜂窝”已经成为许多人习惯性的选择。2019年5月,马蜂窝完成了新一轮融资,金额达2.5亿美元。这也标志着通过集内容、社区、交易为一体的消费决策场景构建,从攻略社区起家的马蜂窝开始迈入

百分点万亿级大数据平台的建设实践

从互联网、移动互联网到物联网,数据量之巨大已突破想象边界。与此同时,实时数据分析的需求日益增长,那么,当数据量达到亿级、百亿级甚至万亿级规模,实时数据分析如何来做?尤其在ToB/G来说,大多数企业和政

耗时6年生成代码1.6亿行,农业银行大数据平台打造攻略!

摘要: 耗时6年,135个项目,8000页需求,累计投入11000多人月,生成的代码行1.6亿行,支持了8大业务领域,33条业务线,120多个应用场景,这就是中国农业银行大数据平台。近日,中国人民银行

Oracle ADW业务数据平台点亮DTCC2019数据库技术大会!

数字大脑、互联网+、智能+、人工智能、边缘计算……信息技术领域好像从不缺少概念,但无论世界如何变化,数据是一切业务的核心。要想有效管理、分析和挖掘数据带来的价值,数据库一定是必需品。2019年5月8日

Disruptor的简单介绍与应用

前言最近工作比较忙,在工作项目中,看了很多人都自己实现了一套数据任务处理机制,个人感觉有点乱,且也方便他人的后续维护,所以想到了一种数据处理模式,即生产者、缓冲队列、消费者的模式来统一大家的实现逻辑。

DTCC 干货 | 腾讯营销数据平台

摘要:广告平台是一个数据驱动的平台,数据在系统中高效流动,形成闭环,产生价值。腾讯广告系统每天有上百亿次请求量,以及上百T的数据,保证数据流的稳定可靠和高性能是数据系统的核心问题。对于数据分析场景,腾

从P4到P9, 在马云家写代码到双11前端PM

导读:今年的双11已经是阿里资深前端技术专家舒文来阿里的第11年,从应届生到双11前端PM,他一路升级打怪,实现了岗位上从P4到P9的晋升。这第11届双11顺利结束之际,他把在阿里这些年的成长经历做一

使用Electron构建跨平台的桌面应用

作者:李晓健。苏宁视频云前端部门经理。拥有7年前端业务研发和架构经验,目前负责苏宁云视频前端研发和架构工作。Electron简介Electron是一个使用JavaScript,HTML和CSS等Web

详解layui模块化与非模块化的不同引用方式

layui模块化与非模块化的不同引用方式:1、模块化与非模块化的区别layui中有许多不同的内置模块,如弹出层、日期与时间选择器、分页等不同模块。模块化:使用时加载相应的模块。非模块化:一次性加载所有

如何构建批流一体数据融合平台的一致性语义保证?

一、批流一体架构 批和流是数据融合的两种应用形态 下图来自Flink官网。传统的数据融合通常基于批模式。在批的模式下,我们会通过一些周期性运行的ETLJOB,将数据从关系型数据库、文件存储向下游的目标

Kafka 如何优化内存缓冲机制造成的频繁 GC 问题?

目录1、Kafka的客户端缓冲机制2、内存缓冲造成的频繁GC问题3、Kafka设计者实现的缓冲池机制4、总结一下“ 这篇文章,给大家聊一个硬核的技术知识,我们通过Kafka内核源码中的一些设计思想,来

建立开放的大数据精准扶贫平台,让全社会参与进来!

精准扶贫”的重要思想最早是在2013年11月,习近平主席到湖南湘西考察时首次作出了“实事求是、因地制宜、分类指导、精准扶贫”的重要指示。2015年6月,习近平主席在贵州召开部分省区市党委主要负责同志座

Kubernetes1.14 版发布,增强了云原生平台的Windows节点支持

Kubernetes1.14GA版本,是开源云原生平台Kubernetes在2019年的一次重大更新。自3月25日开始,这一版本正式推出,供开发者全面使用。  Kubernetes,由云原生计算基金会

大数据对移动应用开发的影响

大数据如何影响移动应用程序开发?目前,数据量正以前所未有的速度在增长。由于产生的总数据将在几年内跨越泽字节级别,因此更加需要进行大数据高级分析,并从庞大的数据池中获取有价值的信息。数字互联为移动应用开

滴滴大数据在汽车金融风控场景中的应用

桔妹导读:滴滴独有的出行场景大数据在金融领域有着非常广泛的应用前景,未来可与银行,保险,支付和理财等机构深入合作,帮助传统金融机构提升资源配置效率,降低获客和风险管理成本。出行场景大数据在交易欺诈识别

人社部大数据应用场景思考

文/涵诚人社部尹蔚民部长在2017年5月全国“互联网+人社”座谈会指出,要充分运用大数据手段,通过“互联网+人社”,实现决策科学、管理精准化、服务人本化,人社的统计数据对于服务决策、研究政策、支撑事业

大数据时代,数据湖并不能完全取代数据仓库

数据仓库为组织了解其历史业务表现和推动持续运营提供了一个接入窗口,为数据分析师和业务用户提供了诸如客户行为、业务趋势、运营效率和销售等方面的信息。尽管出现了基于Hadoop和其他一些大数据技术的数据湖

如何基于 Kafka 构建一个关系型数据库

在这篇文章里,我将分享如何通过扩展KCache(https://github.com/rayokota/kcache)来实现一个全功能的关系型数据库,我把这个数据库叫作KarelDB(https://

DTCC观察:华为云数据库的优势积累与技术选择

摘要:作为公有云市场的重磅参与者,华为云数据库相比竞争对手有哪些优势?这可能是很多不了解华为云数据库人的第一反应。华为云数据库产品架构如何布局?作为第一个基于MySQL8.0开发的云原生分布式数据库,

从关系型数据库到分布式机器学习,揭秘腾讯大数据十年发展历程

大数据技术在过去10多年中极大改变了企业对数据的存储、处理和分析方式。如今,大数据技术逐渐成熟,涵盖了计算、存储、数仓、数据集成、可视化、NOSQL、OLAP分析、机器学习等丰富领域。在未来,大数据技

大数据是个技术,数据库才是它最好的产品形态

星环科技(以下简称:星环)的定位是大数据基础软件公司,而非数据库公司,却在数据库方面,做的比很多数据库公司更好更猛?这是为何?“我们认为,大数据是个技术,数据库才是它最好的产品形态”,星环科技研发总监

做银行家里的数据专家:ING探索大数据时代下的金融最佳实践

大数据文摘出品记者:高延6月18-21日,O’ReillyAIConference在北京召开。大会上,来自荷兰的金融公司ING的IT主管BasGeerdink带来了《关于数字驱动企业》的主题分享。进入

Spring Cloud Stream整合Kafka

引入依赖 org.springframework.cloud spring-cloud-stream-binder-kafka 或 org.springframework.cloud spr

Kafka 优秀的架构设计!它的高性能是如何保证的?

应大部分的小伙伴的要求,今天这篇咱们用大白话带你认识Kafka。Kafka 基础消息系统的作用大部分小伙伴应该都清楚,这里用机油装箱举个例子:所以消息系统就是如上图我们所说的仓库,能在中间过程作为缓存

全网最通俗易懂的Kafka入门

前言只有光头才能变强。文本已收录至我的GitHub仓库,欢迎Star:https://github.com/ZhongFuCheng3y/3y众所周知,消息队列的产品有好几种,这里我选择学习Kafka