江苏龙网

  1. 首页 > 资讯 > 科技 > >

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


举例来说 ， 以下是一些之前使用旧版时常见的问题：
缺少对 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 粒度的资源隔离 。
①集群拆分
按照功能维度拆分多个 Kafka 物理集群 ， 进行业务隔离 ， 降低运维复杂度 。
以目前最重要的埋点数据使用来说, 目前拆分为三类集群 ， 各类集群的功能定义如下：
Log 集群：各端的埋点数据采集后会优先落地到该集群, 所以这个过程不能出现由于 Kafka 问题导致采集中断 ， 这对 Kafka 可用性要求很高 。因此该集群不会对外提供订阅 ， 保证消费方可控；同时该集群业务也作为离线采集的源头 ， 数据会通过 Camus 组件按小时时间粒度 dump 到 HDFS 中 ， 这部分数据参与后续的离线计算 。
全量订阅集群：该集群 Topic 中的绝大部分数据是从 Log 集群实时同步过来的 。上面我们提到了 Log 集群的数据是不对外的 ， 因此全量集群就承担了消费订阅的职责 。目前主要是用于平台内部的实时任务中 ， 来对多个业务线的数据分析并提供分析服务 。
个性定制集群：之前提到过 ， 我们可以根据业务方需求来拆分、合并数据日志源 ， 同时我们还支持定制化 Topic ， 该集群只需要提供分流后 Topic 的落地存储 。


推荐阅读


上一篇：：已婚男人有多难：旧电脑翻新小记——酷冷MB400L机箱篇

下一篇：■都说正版好，但国人却更喜欢用“破解版”软件，这是为什么呢？