共计 9735 个字符，预计需要花费 25 分钟才能阅读完成。
简介：目前 Kafka ETL 正处于收费公测阶段，欢送大家体验试用。
作者：竹恩、岁月、不周
关键词：Kafka ETL，高弹性、免运维、低成本
引言：阿里云音讯队列 Kafka 版提供兼容 Apache Kafka 生态的全托管服务，彻底解决开源产品长期的痛点，是大数据生态中不可或缺的产品之一。随着 Kafka 越来越风行，最后只是作为简略的音讯总线，起初逐步成为数据集成系统，Kafka 牢靠的传递能力让它成为流式解决零碎牢靠的数据起源。在大数据工程畛域，Kafka 在承接上下游、串联数据流管道方面施展了重要作用，Kafka 利用流式框架解决音讯也逐步成为趋势。
音讯流解决框架选型
说到流计算，罕用的便是 Storm、Spark Streaming 和 Flink，目前这些框架都曾经完满的反对流计算，并且都有相应的应用案例，但这些框架应用起来门槛绝对较高，首先要学习框架和各种技术、标准的应用，而后要将业务迁徙到这些框架中，最初线上应用、运维这些流计算框架，对于简略的流解决利用来说，可能较为简单。
在与传统流解决零碎对接中，因为所有的数据根底都要从一个零碎流入 Kafka 而后再流入到另一个零碎中，以至于引发 Kafka 社区的思考：与其把数据从一个零碎传递到下一个零碎中做解决，为何不本人实现一套流解决框架呢？基于这个考量，从 0.10.0 版本开始，Kafka 不仅为每一个风行的流式解决框架提供了牢靠的数据起源，还提供了一个弱小的流式解决类库 Kafka Streams，并将其作为客户端类的一部分。这样，开发人员就能够在应用程序里读取、解决和生成事件，而不须要再依赖内部的解决框架。
但因为 Kafka Streams 自身是一个 Java 客户端库，须要开发人员自行打包和部署；同时 Kafka Streams 是开源版本，可靠性和可用性不能失去很好的保障，也不能实现按需应用；此外应用过程中须要用到流的编程，应用的门槛也绝对较高。
音讯流解决框架次要面临的问题
通过后面对常见的音讯流解决的介绍，不论是传统的流解决架构还是 Kafka Streams，对于开发人员来说都会面临一些问题，尤其是在面对 70% 以上简略流场景的需要，原有的计划弊病被一直放大，客户依然须要投入较大的人力老本和较高的资源，同时整个架构也很简单。总体来说，目前面临次要是四个方面的问题：
1、运维老本较大，研发团队自行编写代码，前期继续保护，运维老本较大；
2、技术老本较大，对于很多轻量或简略计算需要，须要进行技术选型，引入一个全新组件的技术老本过高；
3、学习老本不可预期，在某组件选定后，须要研发团队进行学习并继续保护，这就带来了不可预期的学习老本；
4、自行选用开源组件后，可靠性和可用性不能失去无效保障。
面对这些问题，阿里音讯队列 Kafka 也推出了相应的解决方案：Kafka ETL。
阿里云的解决方案 – Kafka ETL
Kafka ETL 简介
阿里云音讯队列 Kafka 版推出更低成本的 Kafka –ETL 组件，是一款免运维的流计算组件，次要个性是反对配置化流式解决音讯。Kafka ETL 组件次要提供的是非工夫窗口相干的流计算服务，客户能够配置，甚至简略写入几行代码就能满足包含格局转换、内容富化、本地聚合、路由散发等罕用的数据处理需要。
Kafka ETL 在应用上拆分成有向无环图，在计算节点转换时，把 Topic 作为一个存储，在 Topic 里进行有状态的计算，还能够反对音讯的转储。
目前 Kafka ETL 已反对的模版包含：
1）数据荡涤：规定过滤；
2）转换模版：字符串替换，增加前后缀、字符串大小写转换、空格去除数；
3）数据富化模版：数据富化；
4）Split 模版：Topic Split；
5）路由模版：Topic 路由。
Kafka ETL 劣势
通过对 Kafka ETL 根底利用及性能的介绍能够看到，相比于 Storm、Spark Streaming、Flink、Kafka Streams，Kafka ETL 的劣势次要体现在以下四个方面：
1）开箱即用，免运维；
2）节省成本，不必额定购买其余流计算产品，目前 Kafka ETL 仍处于公测收费阶段；
3）低代码，反对疾速上线，学习成本低，一站式体验，技术投入小，工夫老本节俭 80%；
4）便于监控排查，管制台上相干日志信息比拟全面。
Kafka ETL 操作
通过以上 Kafka ETL 利用和劣势的介绍能够看到 Kafka ETL 在应用中的具备轻量、低成本等个性，不仅如此，Kafka ETL 的操作也比较简单，仅需三步便可实现 ETL 操作。
1）第一步：创立工作
抉择 Kafka 起源实例、起源 Topic，以及对应的抉择 Kafka 指标实例、指标 Topic。并配置音讯初始地位、失败解决以及创立资源形式。
2）第二步：编写 ETL 主逻辑
抉择 Python 3 作为函数语言。这里提供了多种数据荡涤、数据转化模板，比方规定过滤、字符串替换、增加前 / 后缀等罕用函数。
3）第三步：设置工作运行、异样参数配置，并执行
Kafka ETL 利用场景
基于 Kafka ETL 的性能和劣势，目前 Kafka ETL 次要利用在上面这些场景中：
1）转储场景，反对格式化数据，以不便数据进行转储；
2）流式解决场景，流式计算，反对音讯的流式解决，次要提供的是非工夫窗口相干的流计算服务；
3）实时行为计算场景，包含风控，金融，电商等须要实时行为计算场景；
4）还反对其余一些场景，包含实时报表，自动化经营场景等。
Kafka ETL 的架构解析
通过前三局部介绍，想必大家对阿里云 Kafka ETL 有了肯定理解，本节的次要内容是对 Kafka ETL 的架构进行解析，帮忙大家对 Kafka ETL 有更深刻的了解。Kafka ETL 是基于 Kafka connect + 函数计算，为云上的用户提供一套数据流转和计算的一站式解决方案。
在当今的大数据、云计算时代，一个简单的大型零碎个别都会由许多解决特定工作的子系统形成。各个子系统个别会由不同的团队开发，因而，各零碎中的数据在内容和格局上，存在人造的不一致性。当数据在各个子系统之间流转的时候，须要对数据进行格局解决，以打消各零碎数据之间格局的不同。此外，还可能须要收集来自各个子系统中的异构数据，对采集到的数据做一些加工和计算，而后投递到数据仓库进行后续的数据分析。在这个过程中，能够形象出两个典型场景：数据流转场景和数据计算场景。
数据流转场景次要面对的问题是，异构零碎间数据如何流转？
数据计算场景次要面对的问题是，如何在数据流转过程中，进行数据的加工计算？
上面就开展对这两个次要场景进行介绍。
数据流转场景
在数据流转场景中，可能须要将各种关系型和非关系型数据库中的数据导入到数据仓库；或是将 mysql 的数据导入到 ElasticSearch，用来进步查问体验；此外一些数据还会导入到图形数据库。这些场景面临的次要问题是：
1）各种不同源之间的数据如何拷贝；
2）如何满足传递的实时性。
比方，mysql 里的一个变更，心愿马上能在 ElasticSearch 中反映进去，不然就会导致后盾数据变更了，用户却查不出最新的数据。除此之外，还须要保证数据拷贝的高可用、可伸缩性以及可扩展性。
为应答这一问题，传统的计划可能是：为各数据源之间都专门做一个数据拷贝工具。这种计划会带来以下问题：
1）首先是工作量问题，须要为每个场景都写一个专门的工具，工作量会十分大；
2）业务耦合重大，比方想监听价格变动，就须要在所有变动价格的业务里，都加上一个 producer。假如下层 schema 产生了变动，上层就须要批改代码，因而下层须要感知到所有上层的存在。
专门的工具看起来不太可行，那么，是否做一个齐全通用的工具，让它反对任意数据源之间数据拷贝。这个听起来不错，然而理论却不可行，正因为它要求太通用了，很难去制订各种标准。
Kafka connect 正是为解决以上异构数据同步问题而生的。它解决的思路是在各个数据源之间加一层消息中间件，所有的数据都通过消息中间件进行存储和散发。这样做的益处有：
1）通过消息中间件做异步解耦，所有零碎只用和消息中间件通信；
2）须要开发的解析工具数量，也从原来的 n 平方个，变成线性的 2*n 个。
Kafka connect 则用于连贯音讯零碎和数据源，依据数据的流向不同，连贯能够分为 source connector 和 sink connector。其原理也很简略，souce connector 负责解析起源数据，转换成规范格局的音讯，通过 Kafka producer 发送到 Kafka broker 中。同理，sink connector 则通过 Kafka consumer 生产对应的 Topic，而后投递到指标零碎中。在整个过程中，Kafka connect 对立解决了任务调度、与音讯零碎交互、主动扩缩容、容错以及监控等问题，大大减少了重复劳动。然而，如何将起源零碎的数据解析成 message、或是将 message 解析成指标零碎数据，这两件事件是须要依据不同的数据系统而做不同实现的。对于目前支流的零碎，各大厂商均有提供相应的 connector 实现。
阿里云音讯队列 Kafka 版就提供了全托管、免运维的 Kafka Connect，用于音讯队列 Kafka 版和其余阿里云服务之间的数据同步。能够看到音讯队列 Kafka 版反对了 Mysql source connector、OSS sink connector、MaxCompute sink connector 以及 FC sink connector 等支流的 connector。如果用户想要应用这些 connector 进行数据同步，只用在音讯队列 Kafka 控制台的图形界面上做几个配置，就能够一键拉起 connector 工作。
数据计算场景
Kafka connect 解决了异构数据源之间数据同步的问题，尽管也提供了 transformer，解决局部数据转换需要，然而仍旧不足实时计算能力。为应答以上场景的数据实时处理需要，市场上呈现了许多优良的解决工具，从最后的 Hadoop，Hive 到 Spark，Flink 以及 Kafka streams 等，都提供了对应的组件模块和上下游解决方案。
但这些解决计划中都存在或多或少的问题，次要的问题是：
- 首先解决框架比拟重，占用资源多。比方当下风行的 Spark 和 Flink 都须要先搭建一个集群，集群自身运行起来就要不少资源。集群规模个别依照流量峰值配置，在大多数时候，资源是节约的。
- 其次在诸多框架中，须要依据理论需要做技术选型，前期可能须要专门的团队或者人去运维，这个过程须要较大的学习老本和前期保护老本。
针对局部无状态的简略计算，函数计算或者是一个很好的抉择。阿里云上的函数计算，是事件驱动的全托管计算服务。应用函数计算时，用户无需洽购与治理服务器等基础设施，只需编写并上传代码即可。函数计算会帮忙用户筹备好计算资源，弹性地、牢靠地运行工作，并提供日志查问、性能监控和报警等性能。能够看到，函数计算以简略易用的形式给用户的许多场景提供了计算能力。
阿里云音讯队列 Kafka 版近期推出的 Kafka ETL 组件，通过 Kafka+Kafka connect+ 函数计算的架构，可能很好的应答数据转储 + 实时计算问题。具备轻量，学习成本低，开发周期短，资源动静伸缩，简略疾速等长处。
Kafka+Kafka connect+ 函数计算的云原生数据利用解决方案，通过 Kafka connect 作为实时处理工作触发器，可能实时接管到新发送到音讯队列集群的数据，而后转发到函数计算，触发实时数据处理工作的运行。在这个数据流转阶段，将大量异构零碎中的数据以各种形式会集到 Kafka 中，而后围绕 Kafka 为核心，做后续的解决。作为后续数据流转中的一环，Kafka connect 除了保障数据的实时性以外，还解决了任务调度、与音讯零碎交互、主动扩缩容、容错以及监控等问题，大大减少了重复劳动。数据到了函数计算当前，会主动触发用户本人编写的数据处理逻辑，对原始音讯内容进行计算。最初，函数计算能够将加工实现的数据，投递到用户指定的指标端，例如投递回音讯队列 Kafka，或者是投递到 Max compute 进行下一步的数据分析。以上所说的整个工作的配置、创立、运行，都只用通过云上的 Kafka 控制台图形页面进行操作即可实现。
利用场景详解
接下来一起来看一个 Kafka ETL 的利用示例。在这个示例中，用户的一个大抵应用场景是这样的：从一个电商业务零碎中，采集日志，存储到 Kafka 侧，而后须要对日志数据进行加工，最初将加工好的数据投递到两个指标端：一个是投递到 MaxCompute 进行数据分析；另一个是投递到 ElasticSearch 进行日志检索。
当初分节点来看，如何利用音讯队列 Kafka 版来做这个事件：
1）第一步：采集原始日志到音讯队列 Kafka 版的 Topic 中
这里能够应用一些比拟成熟的开源组件例如 FileBeat、Logstash、Flume 等，将用户利用端的日志音讯，投递到 Kafka 中。个别状况下，这个步骤会将原始的日志信息投递到 Kafka。当然这里也能够做一些简略的转换，但个别不这么做，而是保留一份原始信息，原始的日志可能来自各个关联的利用，内容和格局会存在些许差别。
在这个例子，订单利用中生成一条日志。日志中蕴含用户 Id、action、订单 Id 以及以后状态：
从领取利用中，又生成一条日志。日志中同样蕴含以上信息，只是格局上存在一些小差异。
这两条来自不同子系统的日志，都被采集到 Kafka 的一个 Topic，叫做 user_order_raw。这两条日志，最终对应这个 Topic 里的两条音讯，key 均为 null，value 为日志的原始内容。能够看到，因为起源系统日志格局不一样，这个 Topic 里蕴含的这两条音讯，音讯格局上也存在肯定差异。
2）第二步是对 Topic 中的音讯，做简略的数据加工计算
数据达到 Kafka 的 Topic 之后，Kafka connect 会生产音讯，并投递到函数计算中。数据到了函数计算后，须要对这个数据进行加工计算，计算的指标是抽取 UserId、Action、OrderId 以及 Status，并将数据都转换为大写字母。而后所有解决后的音讯发往 MaxCompute 进行剖析，此外还须要筛选 Action 为 pay 的所有音讯发往 Elastic Search 中。
这个步骤，能够在 Kafka 控制台图形界面上创立 ETL 工作，用户抉择数据起源 Topic：user_order_raw，而后写一段对数据的解决代码。这里，ETL 曾经提供了局部模板，能够在模板的根底上，做稍许改变即可。
本示例的代码如下图所示。在这个例子中，用户须要写一段从不同格局的日志中，抽取 UserId、Action、OrderId 以及 Status 的代码，而后将所有解决过的音讯路由到指标 Topic。
3）最初一步，能够将解决完的音讯，再次投递到指标端。
函数计算将解决完的音讯，投递回 Kafka。通过这一步解决，所有音讯被路由到指标 Topic：user_order_processed，此时这个 Topic 中会蕴含两条音讯，音讯 key 为 null，value 如下所示：
另外，Action 为 pay 的音讯还会被路由到 Topic: user_order_pay_info 中，此时这个 Topic 会蕴含一条音讯，key 为 null，value 如下所示：
能够看到，此时的音讯格局曾经对立了。
这个例子中，将 Topic：user_order_processed 中所有解决完的订单相干音讯，投递到 MaxCompute 中进行数据分析。将 Topic: user_order_pay_info 中的领取信息，投递到 ElasticSearch 中进行后续搜寻。
这一步，能够一键创立相应的 Kafka connect 工作，将数据投递到相应的指标端。
总结一下上述整个过程。在这个示例中，所要做的仅仅是在音讯队列 Kafka 管制台上配置一个 ETL 工作，写一小段解决代码即可。上述步骤中，第二步解决完数据之后能够不通过第三步投递回 Kafka，而是在解决完之后，间接路由到 MaxCompute 和 ES 中。在该例子中采纳的形式是将解决完的数据再次发送回 Kafka 中，而后再投递到指标零碎中。这种形式能够在 Kafka 端保留一份解决后的数据，用户还能够比拟灵便地对这份数据做进一步解决或者持续投递到其余第三方零碎中。
阿里云音讯队列 Kafka 版的劣势
最初，给大家额定分享一下阿里云上的音讯队列 Kafka 在内核层面的差异化劣势。阿里云上的音讯队列 Kafka 版在倒退过程中除了解决易用性和稳定性方面的问题以外，还做到了有区分度，并在内核层面做出本人的外围竞争力和劣势。
阿里云音讯队列 Kafka 版反对云存储和 Local 存储这两种存储引擎。其中 Local Topic 指的就是以 Kafka 原生的形式存储数据，保留开源 Kafka 全副个性，100% 兼容开源 Kafka。云存储是接下来要介绍的重点，音讯队列 Kafka 通过自研云存储引擎，彻底解决了原生 Kafka 一些深层的 bug，以及因为自身架构而难以解决的问题，实现了反对海量分区、通过多正本技术升高存储老本，以及反对无缝迁徙弹缩性。接下来，将具体介绍这三大个性和其中的技术细节。
反对海量分区
在音讯引擎中，常见的音讯存储形式有碎片式存储和集中式存储。
碎片式存储通常以 Topic 或者分区纬度存储，其次要劣势是架构简略，能够针对 Topic 或者分区，管制长久化的容量。Kafka 在架构上，是基于分区的碎片式存储，在分区规模不大的状况下，能够通过磁盘的程序读写，取得高效的音讯读写性能。通常状况下，个别规格的 Kafka 集群能够反对到千级别的分区规模。如果分区规模继续扩充，且大部分分区都有读写申请时，因为这种设计上的问题，本来的程序读写就变成了随机读写，从而导致 Kafka 的读写性能急剧下降。
不同于碎片式存储，集中式存储则将所有音讯集中存储到同一个 Commit Log，而后依据 Topic 和分区信息构建队列，队列通常作为索引应用。相比于碎片式存储，集中式存储的次要劣势是，反对分区数多，很容易通过删除旧的 Commit Log 的模式管制磁盘水位。在阿里云音讯队列 Kafka 中，底层的自研云存储引擎正是采纳了集中式的存储形式，云存储引擎相比 Kafka 原生的存储的次要劣势有：
1）解决了 Kafka 分区规模扩充时，性能急剧下降的问题，相比于原生 Kafka 千级别的分区规模，其反对的分区规模能够达到十万级别；
2）在大量分区同时写的场景下，相比原生 Kafka 的碎片式存储，自研云存储引擎能取得更好的性能；同时，对写入耗时做了优化，缩小了毛刺的产生。
多正本技术优化
为保障 Kafka 集群的高牢靠和高可用性，通常状况下会为所有 Topic 设置 3 正本存储。这样，在呈现机器宕机时，Kafka 能够疾速从可用的 Follower 正本中选出新的 Leader，接替宕机机器上的 Leader 持续提供服务。音讯队列 Kafka 在抉择块存储设备时，抉择的是阿里云上的云盘。云盘是阿里云为云服务器 ECS 提供的，数据块级别的块存储产品，具备低时延、高性能、持久性、高牢靠等特点。云盘自身采纳了分布式三正本机制，为 ECS 实例提供了极强的数据可靠性和可用性保障。
在这种背景下，在 Kafka 层面设置 3 正本，因为应用了云盘，理论会有 9 个正本。同时，因为 Kafka 层面的 Follower 须要被动从 Leader 同步数据，这也会耗费集群的计算和网络资源，将用户的业务流量扩充至 3 倍。然而，如果在 Kafka 层面设置单正本，因为 Kafka 自身不能利用到云盘的 3 正本能力，其高可用性就不能保障。因而，如何利用好云盘的 3 正本能力，升高的存储老本和网络老本，就成了面临的一大挑战。
阿里云通过接入自研云存储引擎，解决了存储老本和网络老本问题。其外围原理次要是：在自研存储引擎中引入了逻辑队列和物理队列两个概念。逻辑队列也就是裸露给用户的概念，在这里能够间接了解成客户端看到的 partition，而物理队列则用于理论存储数据。通过映射关系，将逻辑队列和物理队列绑定在一起。在自研引擎中，所有的分区在逻辑上都是单正本的。数据的可靠性和可用性由云盘底层的 3 正本机制保障。在失常状况下，发送到特定逻辑 partition 的数据，都会依据映射关系，写入到对应的物理队列中。同理，生产也是依据映射关系从理论的物理队列中拉取。
接下来来看云存储是如何做到容错和高可用的。例如，在节点 0 的 ECS 宕机时，能够通过 QueueMapper，秒级切换逻辑队列 0 的映射关系到节点 1 中的已有队列 Queue-3，或者新增一个物理队列 Queue-4。此时，发往逻辑队列 -0 的音讯，将被路由到 Queue-3 或者 Queue-4 中。这种状况下，用户的发送业务不会受到影响，仍旧能够持续发送胜利，并且最新的音讯也能被生产到。当然，在这种 Failover 期间，会存在一个问题：逻辑队列 -0 在节点 -0 上的音讯，临时不能生产；然而，对大多数利用场景来说，短暂的局部音讯生产提早并不是大问题，只有不影响发送就能满足要求。
在节点 -0 的 ECS 宕机后，阿里云备用 ECS 会迅速生成新的机器替换节点 -0，挂载原有云盘，分钟级工夫内复原节点 -0 服务。在节点 -0 复原后，只用从新将逻辑队列 -0 的映射关系切回 Queue-0，零碎又从新复原了原有状态。此时，发送 / 生产仍旧能放弃原生 Kafka 的个性。
通过以上形式，将存储老本节俭到原生 Kafka 的大概三分之一。同时，因为在 Kafka 层面，正本数是 1，从而防止了 Follower 从 Leader 中同步数据的操作，网络流量也节俭到原生 Kafka 的大概三分之一。
程度扩容，秒级数据平衡
弹性扩缩能力是音讯队列的外围能力之一。因为 Kafka 服务端节点是有状态的，因而新增了若干节点之后，须要从新平衡各个 Topic 的队列，使得客户端往集群中发送或是生产的流量，能平衡地打到后端各个服务节点上。
开源 Kafka 在程度扩大了机器之后，做数据平衡的次要形式有两种：
第一种是在新的 broker 中新增队列。这种形式次要的痛点是：
1）零碎状态产生扭转，这种状况下一些多语言客户端的晚期版本，须要客户端被动重启，否则无奈生产新分区；
2）第二是 Kafka 设计上的问题，分片数无奈降落，导致后续无奈缩容。
第二种做法是数据迁徙。这种形式的次要痛点是：
1）流量复制，产生网络风暴，烦扰失常应用；
2）平衡与数据量无关，如果数据量微小，可能要花费几天来迁徙。
那么，云存储引擎是怎么解决以上弹缩问题的呢？
前文提到音讯队列 Kafka 引入了两级队列：第一级为逻辑队列，第二级为物理队列，也就是阿里云自研云存储队列。逻辑队列对外裸露，物理队列则用于存储理论数据。通过 QueueMapper 模块保护逻辑队列与物理队列之间的映射关系，如下图所示。
一个逻辑队列能够由多个物理队列拼接而成，通过位点分段映射，保障程序。扩容时，只须要将逻辑队列指向新机器上的物理队列即可，这样新写入的音讯就能够依据新的映射关系，间接写入到新加的机器。同样的，在生产时，能够依据位点分段映射关系，找到理论的物理队列，而后从物理队列中读取音讯。
能够看到，通过两级队列分段映射，解决了音讯队列弹缩和迁徙问题，具备如下长处：
1）服务端扩缩容后，不变更队列数量，放弃零碎状态不变；
2）扩缩容时无需迁徙数据，耗时短，能够在秒级工夫内实现 Topic 队列从新平衡；
3）兼顾了吞吐与扩展性，不影响原有音讯队列的性能。
总结
简略对次要介绍内容进行总结，Kafka 在流式解决场景中，传统计划个别会采纳 Storm、Spark Streaming、Flink 和 Kafka Streams 等流式解决框架，然而开发人员在应用的过程中会遇到不少问题，尤其是在面对 70% 以上简略流场景的需要，会遇到运维老本较高、技术老本较大、学习老本不可预期和可用性、可靠性较低等痛点问题，阿里云音讯队列 Kafka 公布 Kafka ETL 组件，是一款免运维的流计算组件，通过 Kafka+Kafka connect+ 函数计算的架构，可能很好的应答数据转储 + 实时计算问题，具备免运维、低成本、低代码、易监控等劣势。
原文链接
本文为阿里云原创内容，未经容许不得转载。
