通过Kafka连接简化从Kafka到Pulsar的迁移工作

HackerNews什么值得看
573 阅读7分钟

任何系统的大规模实施，如事件流平台Apache Kafka，往往涉及到定制和内部开发的工具和插件。当需要从一个系统过渡到另一个系统时，这个任务可能会变得复杂、冗长和容易出错。通常情况下，替代系统的好处（可能包括显著的成本节约和其他效率）会被迁移的风险和成本所抵消。结果是，一个组织可能最终被锁定在一个次优的情况下，支付比必要的更大的账单，并错过了帮助企业更快地向前发展的现代功能。

这些风险和成本可以通过使过渡过程迭代，以小的、可管理的步骤打破对供应商的锁定，以及避免 "大爆炸 "式的转换来减轻，因为这种转换往往会导致延迟交付，并增加并行运行两个系统的成本，以进行A-B测试。

让我们快速浏览一下有助于引导从Kafka向Apache Pulsar过渡的现有生态系统，深入了解Pulsar 2.8中新加入的生态系统，并看看Pulsar IO API和Pulsar Schema API的重要变化，这些变化使Sinks中的模式处理自动化并得到简化。

在这篇文章中，我们将按照惯例讨论流媒体源，即从另一个系统向Pulsar推送数据，以及汇，即从Pulsar向另一个目的地发送数据。

Pulsar-Kafka生态系统的现状

Kafka的内置连接器

内置连接器可以简化Pulsar和Kafka主题之间的数据拉动/推送。

如果你想让现有的系统在Kafka上运行，同时在Pulsar上构建新的功能，这就很有用。

更多细节可在Pulsar文档中找到。

Pulsar上的Kafka

Kafka on Pulsar（KoP）是推荐使用Pulsar的本地Kafka客户端的方式。

KoP是一个协议处理程序。这意味着它在网络层面上解释Kafka协议，并将其翻译成Pulsar请求。这种方法有三个关键优势。

  1. KoP适用于所有Kafka客户端。
  2. KoP使用Kafka客户端和服务器之间定义好的接口。
  3. 客户端代码根本不需要改变。

Kafka连接适配器

大多数人通过与其他系统的连接器来使用Kafka（和Pulsar），而不是手工编写低级别的客户端代码。Pulsar为最流行的系统提供了原生连接器，但截至目前，还有很多Kafka的连接器还不存在于Pulsar中，包括在内部创建的供单个公司使用的私有连接器。

Kafka Connect Adaptor（KCA）弥补了这一空白。KCA是一个运行Kafka Connect Sink或Source的Pulsar Source和Sink。Kafka Connect Adaptor Sink是Pulsar 2.8中的新功能。

目前，文档很少，但使用KCA很简单。我们将在下面看一下使用KCA Sink和Source的例子。

使用Kafka Connect Adaptor Sink

使用Kafka Connect Adaptor Sink是相当简单的。你所需要做的就是打包Kafka Connect连接器，创建配置，并将其作为普通的Pulsar Sink使用。

第1步：打包

使用Kafka Connect Adaptor NARgithub.com/apache/puls…作为起点（为简单起见，我将直接编辑它），并将你的Kafka Connector Sink添加到pom.xml中的依赖项列表中。下面是使用Kinesis Kafka连接器汇的情况。

diff

diff --git a/pulsar-io/kafka-connect-adaptor-nar/pom.xml b/pulsar-io/kafka-connect-adaptor-nar/pom.xml
index ea9bedbd056..c7fa9a1ebca 100644
--- a/pulsar-io/kafka-connect-adaptor-nar/pom.xml
+++ b/pulsar-io/kafka-connect-adaptor-nar/pom.xml
@@ -36,6 +36,11 @@
       pulsar-io-kafka-connect-adaptor
       ${project.version}
     
+ 
+ com.amazonaws
+ amazon-kinesis-kafka-connector
+ 0.0.9-SNAPSHOT
+

构建NAR。

$ mvn -f pulsar-io/kafka-connect-adaptor-nar/pom.xml clean package -DskipTests

第2步：配置

Sink希望 "processingGuarantees "为 "EFFECTIVELY_ONCE"`，配置指向Pulsar实例和主题，以存储处理后的偏移量，从主题读取数据，并配置传递给Kafka Connect Sink。

比如说。

YAML

processingGuarantees: "EFFECTIVELY_ONCE"
configs:
  "topic": "my-topic"
  "offsetStorageTopic": "kafka-connect-sink-offset-kinesis"
  "pulsarServiceUrl": "pulsar://localhost:6650/" 
  "kafkaConnectorSinkClass": "com.amazon.kinesis.kafka.AmazonKinesisSinkConnector"
  # The following properties passed directly to Kafka Connect Sink and defined by it
  "kafkaConnectorConfigProperties":
     "name": "test-kinesis-sink"
     'connector.class': "com.amazon.kinesis.kafka.AmazonKinesisSinkConnector"
     "tasks.max": "1"
     "topics": "my-topic"
     "kinesisEndpoint": "kinesis.us-east-1.amazonaws.com"
     "region": "us-east-1"
     "streamName": "test-kinesis"
     "singleKinesisProducerPerPartition": "true"
     "pauseConsumption": "true"
     "maxConnections": "1"

第3步：获利!

按照常规Pulsar的步骤来使用打包的连接器：pulsar.apache.org/docs/en/io-…

使用Kafka Connect Adaptor Source

KCA Source从Pulsar 2.3.0版本开始使用。在最简单的情况下，它的用法与KCA Sink类似：添加依赖关系并构建，提供配置并运行。

目前，KCA Source只支持以Apache Avro或JSON格式返回数据的Source。

关于使用源适配器的详细例子，请看Pulsar的Debezium连接器。

引擎盖下：为Pulsar IO建立一个更好的开发者体验

Apache Pulsar 2.8对Java Pulsar Schema API和Pulsar IO API进行了许多改进，帮助填补了Kafka Connect和Pulsar IO之间的空白。这些改进是Kafka Connect Adaptor Sink的基础，使Pulsar IO Sink的开发总体上更加容易。

Kafka Connect用户必须明确配置Sink（或Kafka Consumer）的反序列化器配置，以便使用正确的反序列化器，即使代码不与特定模式绑定。更新后的Pulsar模式API的力量使一切都自动进行，并消除了显式配置的需要。

下面让我们深入了解一下Pulsar IO API的改进；更多技术细节，请参考PIP-85。

模式的运行时处理

我们贡献了对编码模式感知的Pulsar IO汇的支持，这些汇在构建时不依赖于特定的模式。换句话说，在Pulsar 2.7中，你必须在汇中声明模式类型。

Java

class MySink implements Sink {
     public void write(Record record) {
     }
}

为了支持 "String "和 "GenericRecord"（JSON和Avro结构），你必须创建两个类，部署Sink的用户必须使用"--classname "参数来为给定主题设置正确的实现。

在Pulsar 2.8中，你可以简单地使用这种语法。

Java

class MySink implements Sink {
      public void write(Record record) {}
}

这个水槽可以与每一种模式类型以及没有模式的主题一起工作。它还支持模式演变和KeyValue模式类型。

对KeyValue消息的无缝支持

Kafka Connect和Pulsar IO之间的第二个差距是缺乏对KeyValue消息的无缝支持。

在许多版本中，Pulsar提供了强大的KeyValue模式类型，支持为Key和Value设置一个模式。有了Sink，你也可以处理KeyValue模式，只需写一次代码，并保持更简单。

访问用Schema.AUTO_CONSUME消耗的消息的消息和模式细节

Pulsar使用一个特殊的AUTO_CONSUME模式来验证和反序列化使用从代理处收到的模式的消息。目前，它支持Avro、JSON和ProtobufNativeSchema模式。你可以在文档中找到更多细节pulsar.apache.org/docs/en/sch…

在Pulsar 2.8之前，AUTO_CONSUME允许你根据附加在消息上的模式的版本来解码消息，但不允许访问确切的模式定义。Pulsar 2.8通过提供对这一信息的访问加强了API。

Java

Schema schema = message.getReaderSchema().get();

org.apache.avro.Schema avroSchema = (org.apache.avro.Schema) schema.getNativeSchema().get();
org.apache.avro.generic.GenericRecord nativeRecord = (org.apache.avro.generic.GenericRecord) consumedRecord.getNativeObject();

Message.getReaderSchema()方法返回用于解码消息的实际模式，即使是在特殊的AUTO_CONSUME模式的情况下。这样的模式会在主题发展的同时自动下载新版本的模式。

Schema.getNativeSchema()和GenericRecord.getNativeObject()方法提供对模式的底层实现和消息的Java模型的访问。特别是，你可以访问Avro模式和Avro GenericObject实例的盖子。

总结

新的Kafka连接适配器完成了Pulsar-Kafka兼容生态系统。这个生态系统目前允许从Kafka到Pulsar的迭代过渡，支持在Pulsar上使用本地Kafka客户端，在Pulsar上使用Kafka Connect连接器，以及两个系统之间的数据传输。

有了所有这些伟大的功能，我们希望人们的关注点从担心Pulsar在现有Kafka实施上的复杂性转移到寻找新的方式，使他们的业务能够从Pulsar的力量中受益。

avatar
文章
阅读
粉丝