大数据白皮书：Kafka版本进化全解析

Posted 2021-05-02 长风云帆

长风云帆大数据培训认为，合理的数据损耗和汰换机制是现阶段分布式平台亟需解决的重要问题，削减过多的冗余占用现象仍是Kafka之后长期工作的重点。

 

KIP-283：降低信息格式向下转换时的内存消耗

在一个多客户端组群的环境下，客户端与服务器端的版本不匹配是常见现象。早在 0.10.0 版本中，Kafka 已经加入了允许不同版本客户端与服务器交互的功能，即高版本的 Kafka 客户端依然可以与低版本的服务器进行数据传导，反之亦然。然而当低版本的消费者客户端和高版本的服务器进行交互时，服务器有时需要将数据向下转换（format down-conversion）成为低版本客户端可以认知的格式后才能发回给消费者。向下转换有两个缺点：

 

丢失了 Kafka 数据零拷贝（zero-copy）的性能优势；

 

向下转换需要额外的大量内存，在极端情况下甚至会导致内存溢出。

 

在大数据分析领域前者无法避免，但是后者依然可以改进：在即将发布的 2.0 版本中，Kafka使用了一种新的基于分块（chunking）的向下转换算法，使得需要同时占据的内存需求大幅缩减。这使得高低版本的客户端与服务器之间的交互变得更加有效。

更多的可监控指标

 

对于企业级数据平台来说，另一个很重要的要求就是提供各种实时的监控能力。在 LinkedIn 的时候，同事间流传着据传是我们公司传奇人物 David Henke 的一句话：what gets measured gets fixed，充分体现了监测的重要性。

 

长期以来，Apache Kafka 社区不断地完善各种区块的各种指标，这每一个新添加的指标背后都有一个我们曾经踩过的坑，一段在线调试和修 bug 的痛苦经历。

 

举一个具体的例子：Kafka 长期以来被诟病添加分区太慢，因此在 1.1.0 版本里面来自六个不同企业的贡献者共同完成了重新设计 Kafka 控制器（Kafka Controller）这个规模巨大的 JIRA。在这个长达九个月的项目里，被谈论很多的一点就是如何增添控制器操作的各种指标。在未来更多的新功能和新属性，比如继续增强 Kafka 的伸缩性，包括多数据中心支持等等，如何能够让用户继续便捷地实时监测这些新增功能的性能，及时发现可疑问题，并且帮助缩短需要的在线调试时间，都将是讨论的重要一环，因为这也是任何一个企业级流数据平台必须要注意到的。

 

在 2.0.0 版本中，我们进一步加强了 Kafka 的可监控性，包括添加了很多系统静态属性以及动态健康指标，比如 KIP-223、KIP-237、KIP-272 等等。

指哪打哪不再是空话，Kafka的更新准确地命中了大数据服务过于离散的问题核心，可以预见的是，今后很长一段时间里，“深度，准确，智能”会成为分布式储存，并行计算，数据挖掘领域的主要要求。

长风云帆大数据培训，高瞻科技，远瞩未来。