为什么说Kafka还不是完美的实时数据通道

 

本文重要谈谈Kafka用于实时数据通道场景的缺陷，以及如何在架构上进行增补。
Kafka归属于消息队列类产品，其他竞品还有RabbitMQ、RocketMQ等，总的来说它们都是基于生产者、中介和消耗者三种角色，提供高并发、大数据量场景下的消息传递。Kafka诞生自Hadoop生态，与生态中的其他组件具有更好的亲和性，在实时数据场景中每每是首选。随着数据实时应用的需求高涨，Kafka作为构建实时数据通道的焦点组件，得到了广泛的应用。
Kafka自己不介入消息内容，须要生产者和消耗者事先约定某种通讯契约（包括序列化框架和数据结构两部分）来编码和解码消息内容。这个通讯契约由到场双方系统约定而成，双方是对等关系，一旦发生变化须要双方重新协商。
对于消息队列场景，上述机制完全没问题。但在实时数据场景下，数据每每由生产侧CDC工具以抓取数据库的方式产生，那么通讯契约中的数据结构部分直接采取了生产系统的表结构，即由生产侧系统单方面定义的，对下游具有强制性。而且，当生产系统的表结构变化时，下游也不得不适配全表结构的变化，即使只须要部分字段的数据。可见，实时数据场景下，下游系统完满是从属关系，产生了大量冗余工作量。另外，表结构变更传递到下游系统，并没有自动化机制，容易产生时间耽误和沟通误差等问题。
Kafka作为一个实时数据的汇集点，并不能对上述两个问题进行有效控制，也就是本文所说的缺陷。
关于办理方案，首先是在Kafka上增加元数据管理模块，在实践中我们选择了Schema Registry，由confulent开源的元数据管理工具。团体架构如下图所示
 

 
每个topic都有schema，且随着topic中数据结构的变化，schema会产生多个版本，每个版本的schema具有全局唯一id。一条完整的消息就由schema id和data两部分构成，在消耗端读取消息时可以根据id找回schema，进而解析消息。
可见，引入SR后系统具备了在Kafka通道中获取上游系统表结构继而解析消息的能力。当表结构发生变化时，CDC工具会自动推送schema给SR。市场上主流的CDC工具，如Oracel Golden Gate（OGG），已经提供了对Schema Registry的适配。
如许，我们办理了schema在上下游之间自动更新同步的问题。
在此底子上，我们又增加了对表结构的裁剪能力，即可以基于不同下游系统的需求对同一个topic进行差异化的读取字段内容。而裁剪后，也就形成了一个上下游对等关系的契约，降低了下游系统的无效耦合，从而消除了冗余工作量。更重要的是，裁剪的过程是零编码的，仅在交互界面上点选操纵即可。这个裁剪工具并没有找到开源实现版本，所以我们自己进行了研发，取名为schema manager。
末了，我们基于schema registry和schema manager，开发了自适应的消息解析程序，封装为SDK。如许下游系统只须要按照SDK接口（兼容Kafka原生接口）订阅消息，即可完全屏蔽掉无关的上游变更内容，对上述一套实现机制完全无感。
末了，简单总结下答案，实时数据通道的四个能力：

• Kafka的消息队列能力
  
• 与生产侧打通的schema自动更新和管理能力
  
• 面向消耗侧需求的schema裁剪能力
  
• 自适应schema变更的解析能力
  

通过如许的实时数据通道，上下游系统规复到了对等通讯关系，基本清除了下游的冗余工作量。 
 ​
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。