为什么说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变更的解析能力

通过这样的实时数据通道，上下游系统恢复到了对等通讯关系，基本清除了下游的冗余工作量。

 

​