Apache Kafka Connect - 2019完整指南

今天，我们将讨论Apache Kafka Connect。此Kafka Connect文章包含有关Kafka Connector类型的信息，Kafka Connect的功能和限制。此外，我们将了解Kafka Connect及其配置的必要性。与此同时，我们将讨论不同的模式和Rest API。
在本Kafka Connect教程中，我们将研究如何将数据从外部系统导入Apache Kafka主题，以及如何将数据从Kafka主题导出到外部系统，我们还有另一个Apache Kafka项目组件，即Kafka Connect。但是，有关Kafka Connect的更多信息。
那么，让我们开始Kafka Connect。

Apache Kafka Connect - 完整指南

1.什么是Kafka Connect？

我们使用Apache Kafka Connect在Apache Kafka和其他系统之间流式传输数据，既可靠又可靠。此外，connect使得快速定义Kafka连接器变得非常简单，这些连接器可以将大量数据移入和移出Kafka。
Kafka Connect收集指标或将整个数据库从应用程序服务器收集到Kafka主题中。它可以为流处理提供低延迟的可用数据。

工作 - Apache Kafka Connect

2. Kafka Connect功能

Kafka Connect有以下功能：

Kafka Connect - 功能

一个。Kafka连接器的通用框架
它标准化了其他数据系统与Kafka的集成。此外，还简化了连接器的开发，部署和管理。
湾分布式和独立模式
扩展到支持整个组织的大型集中管理服务，或者扩展到开发，测试和小型生产部署。
C。REST界面
通过易于使用的REST API，我们可以提交和管理Kafka Connect集群的连接器。
d。自动偏移管理
但是，即使只有连接器的一些信息，Kafka Connect也可以自动管理偏移提交过程。因此，连接器开发人员无需担心连接器开发中容易出错的部分。
即默认情况下分布式和可伸缩性
它基于现有的组管理协议。为了扩展Kafka Connect集群，我们可以添加更多工作人员。
F。流媒体/批处理集成
我们可以说，为了桥接流媒体和批处理数据系统，Kafka Connect是一个理想的解决方案。
Apache Kafka工作流程| Kafka Pub-Sub Messaging

3.为什么选择Kafka Connect？

正如我们所知，像F lume一样，有许多工具能够写入Kafka或从Kafka读取，或者也可以导入和导出数据。所以，问题出现了，为什么我们需要Kafka Connect。因此，我们列出了主要优势：

为什么Kafka Connect-需要Kafka

一个。失败后自动恢复

对于每个记录，“源”连接器可以附加它传递给Kafka Connect的任意“源位置”信息。因此，在发生故障时，Kafka Connect会自动将此信息提供给连接器。通过这种方式，它可以在失败的地方恢复。此外，“接收器”连接器的自动恢复更加容易。

湾自动故障转移

可以进行自动故障转移，因为Kafka Connect节点构建了一个Kafka群集。这意味着如果假设一个节点发生故障，它正在进行的工作将重新分配给其他节点。

C。简单并行

连接器可以定义数据导入或导出任务，尤其是并行执行的任务。

4. Kafka Connect Concepts

在子线程中执行连接器及其相关任务的操作系统进程（基于Java）就是我们所说的Kafka Connect 工作者。
此外，有一个对象定义了一个或多个任务的参数，这些任务实际上应该执行导入或导出数据的工作，我们称之为连接器。
要从某些任意输入读取并写入Kafka，源 连接器将生成任务。
为了从Kafka读取并写入一些任意输出，接收器连接器生成任务。

测试你对卡夫卡的了解程度

但是，我们可以说Kafka Connect不是重要数据转换的选择。尽管如此，为了定义基本数据转换，最新版本的Kafka Connect允许连接器的配置参数。然而，对于“源”连接器，此函数认为任务将其输入转换为AVRO或JSON格式; 在将记录写入Kafka主题之前应用转换。而且，虽然它涉及“接收器”连接器，但此函数认为输入Kafka主题上的数据已经是AVRO或JSON格式。

5. Kafka Connect的依赖性

Kafka Connect节点需要连接到Kafka消息代理群集，无论是以独立模式还是分布式模式运行。
基本上，对于分布式模式，没有其他依赖项。即使连接器配置设置存储在Kafka消息主题中，Kafka Connect节点也完全无状态。由于这个，Kafka Connect节点，它变得非常适合通过技术运行。
虽然要存储“当前位置”和连接器配置，但我们需要少量的本地磁盘存储，用于独立模式。
你必须阅读有关Kafka排队的信息

6.分布式模式

通过使用Kafka Broker地址，我们可以启动Kafka Connect工作器实例（即java进程），“内部使用”的几个Kafka主题的名称和“组ID”参数。通过“内部使用”Kafka主题，每个工作者实例与属于同一组ID的其他工作者实例进行协调。这里，一切都是通过Kafka消息代理完成的，不需要其他外部协调机制（没有Zookeeper等）。
工作人员之间（通过主题）就如何在可用的工作人员组中分发连接器和任务集进行协商。如果工作进程死亡，则会重新平衡群集，以便在剩余的工作人员上公平地分配工作。如果新员工开始工作，则重新平衡可确保其接管现有员工的一些工作。

7.独立模式

我们可以说，它只是分布式模式，其中工作者实例在Kafka消息代理中不使用内部主题。此进程运行所有指定的连接器及其生成的任务本身（作为线程）。
由于独立模式将当前源偏移存储在本地文件中，因此它不会使用Kafka Connect“内部主题”进行存储。作为命令行选项，以独立模式提供有关要执行的连接器的信息。
此外，在此模式下，运行连接器可以对生产系统有效; 通过这种方式，我们传统上执行大多数ETL样式的工作负载。
因此，我们再次以传统方式管理故障转移 - 例如，通过脚本启动备用实例。
一个。启动工人
工作者实例只是一个Java进程。通常，它是通过提供的shell脚本启动的。然后，从其CLASSPATH中，worker实例将加载连接器配置指定的任何自定义连接器。对于独立模式，配置在命令行上提供，对于从Kafka主题读取的分布式模式。
对于启动Kafka Connect工作程序，还有一个标准的Docker容器映像。因此，可以启动此映像的任意数量的实例，并且只要它们配置了相同的Kafka消息代理群集和group-id，它们也将自动联合在一起。

8. REST API

基本上，每个工作器实例都启动一个嵌入式Web服务器。因此，通过它，它为状态查询和配置公开了一个REST API。此外，对于处于分布式模式的工作人员，通过此REST API上载的配置将保存在内部Kafka消息代理主题中。但是，对于独立模式的工作程序，配置REST API不相关。
通过包装工作者REST API，Confluent控制中心提供了大量的Kafka-connect-management UI。
要定期获取系统状态，Nagios或REST调用可能会执行Kafka Connect守护程序的监视。
我们来讨论Apache Kafka + Spark Streaming Integration

9.卡夫卡连接器类型

通过实现特定的Java接口，可以创建连接器。我们有一套现有的连接器，或者我们可以为我们编写自定义连接器的设施。
它的工作者只是希望它执行的任何连接器和任务类的实现都存在于其类路径中。但是，如果没有子类加载器的好处，此代码将直接加载到应用程序，OSGi框架或类似代码中。
“Confluent开源版”下载包中有几个连接器，它们是：

JDBC
HDFS
S3
Elasticsearch

但是，没有办法单独下载这些连接器，但我们可以从Confluent Open Source中提取它们，因为它们是开源的，我们也可以下载并将其复制到标准的Kafka安装中。

10.配置Kafka Connect

通常，使用指向包含工作程序实例选项的config-file的命令行选项，每个工作程序实例都会启动。例如，Kafka消息代理详细信息，group-id。
但是，还会在独立模式下为工作者提供指向定义要执行的连接器的配置文件的命令行选项。然而，每个工作人员都以分布式模式从Kafka主题（在工作器配置文件中指定）中检索连接器/任务配置。
此外，工作进程在独立模式下为状态检查等提供REST API。
此外，要暂停和恢复连接器，我们可以使用REST API。
请务必注意，配置选项“key.converter”和“value.converter”选项不是特定于连接器的，它们是特定于工作者的。

11.从Kafka Connect Workers到Kafka Brokers的联系

出于管理目的，每个工作程序以分布式模式建立与Kafka消息代理群集的连接。但是，在worker配置文件中，我们将这些设置定义为“顶级”设置。
此外，为每个连接器建立了与Kafka消息代理群集的单独连接（套接字集）。许多设置都是从“顶级”Kafka设置继承的，但是可以使用配置前缀“consumer。”（由sink使用）或“producer。”（由源使用）覆盖它们以便使用不同的Kafka消息代理承载生产数据的连接与携带管理消息的连接的网络设置。

12.标准JDBC源连接器

连接器中心站点列出了JDBC源连接器，此连接器是Confluent Open Source下载的一部分。此外，请确保我们无法单独下载，因此对于已安装Apache的“纯”Kafka软件包而非Confluent软件包的用户，必须从Confluent软件包中提取此连接器并将其复制。
它有各种配置选项：

要扫描的数据库，指定为JDBC URL。
轮询间隔。
一个正则表达式，指定要监视的表; 对于每个表，都有一个单独的Kafka主题。
具有“递增id” 的SQL列，在这种情况下，连接器可以检测新记录（选择id> last-known-id）。
具有更新时间戳的SQL列，在这种情况下，连接器可以检测新的/已修改的记录（选择时间戳> last-known-timestamp的位置）。

奇怪的是，尽管连接器显然具有复制多个表的能力，但是“递增id”和“时间戳”列名是全局的 - 即，当复制多个表时，它们必须遵循相同的命名约定。列。

13. Kafka Connect Security

基本上，使用Kerberos安全的Kafka消息代理，Kafka Connect（v0.10.1.0）工作得非常好。通过与这些代理的SSL加密连接也可以正常工作。
但是，通过Kerberos或SSL，无法保护Kafka Connect节点公开的REST API; 但是，有一个功能请求。因此，在配置安全集群时，必须配置外部代理（例如Apache HTTP）以充当REST服务的安全网关。
看看Apache Kafka Security | Kafka的需求和组成部分

14. Kafka Connect的限制

除此之外，Kafka Connect也有一些限制：

目前，连接器的选择非常少。
商业和开源功能的分离非常差。
此外，它缺乏配置工具。
要部署自定义连接器（插件），有一种糟糕/原始的方法。
它非常以Java / Scala为中心。

因此，目前，它感觉更像是一个“工具包”，而不是当前的打包解决方案 - 至少在没有购买商业工具的情况下。
所以，这就是Apache Kafka Connect。希望你喜欢我们的解释。

15.总结

因此，我们已经看到了Kafka Connect 的整个概念。此外，我们已经了解了Kafka connect的好处。但是，如果有任何疑问，请随时在评论部分询问。