共计 1842 个字符，预计需要花费 5 分钟才能阅读完成。
简介：还在花精力去选型 Kafka 组件去做荡涤转化？来试试 Kafka ETL 工作性能！
一说到数据孤岛，所有技术人都不生疏。在 IT 倒退过程中，企业不可避免地搭建了各种业务零碎，这些零碎独立运行且所产生的数据彼此独立关闭，使得企业难以实现数据共享和交融，并造成了 ” 数据孤岛 ”。
因为数据散落在不同数据库、音讯队列中，计算平台间接拜访这些数据时可能遇到可用性、传输提早，甚至零碎吞吐问题。如果回升到业务层面，咱们会发现这些场景随时都会遇到：汇总业务交易数据、旧零碎数据迁徙到新零碎中、不同零碎数据整合。因而，为了能让数据更加实时、高效的交融并反对各业务场景，企业通常抉择应用各种 ETL 工具以达到上述目标。
因而，咱们能够看到企业自行摸索的各种解决方案，比方应用自定义脚本，或应用服务总线（Enterprise Service Bus，ESB）和音讯队列（Message Queue，MQ），比方应用企业应用集成（Enterprise application integration，EAI）通过底层构造的设计来横贯企业异构零碎、利用、数据源等，实现数据的无缝共享与替换。
只管以上伎俩都算实现了无效实时处理，但也给企业带来更难决断的选择题：实时，但不可扩大，或可扩大。但批处理。与此同时，随着数据技术、业务需要的一直倒退，企业对 ETL 的要求也一直晋升：
- 除了反对事务性数据，也须要可能解决诸如 Log、Metric 等类型越来越丰盛的数据源；
- 批处理速度须要进一步晋升；
- 底层技术架构须要反对实时处理，并向以事件为核心演进。
能够看到，流解决 / 实时处理平台作为事件驱动交互的基石。它向企业提供了全局化的数据 / 事件链接、即时数据拜访、繁多零碎统管全域数据以及继续索引 / 查问能力。也正是面对以上技术与业务需要，Kafka 提供了一个全新思路：
- 作为实时、可扩大音讯总线，不再须要企业应用集成；
- 为所有音讯解决目的地提供流数据管道；
- 作为有状态流解决微服务的根底构建块。
咱们以购物网站数据分析场景为例，为了实现精细化经营，经营团队以及产品经理须要将泛滥用户行为、业务数据以及其余数据数据进行汇总，这其中包含但不限于：
- 用户各类点击、浏览、加购、登陆等行为数据；
- 根底日志数据；
- APP 被动上传数据；
- 来自 db 中的数据；
- 其余。
这些数据会集到 Kafka，而后数据分析工具对立从 Kafka 中获取所需的数据进行剖析计算。因为 Kafka 采集的数据源十分多且格局也各种各样。在数据进入上游数据分析工具之前，须要进行数据荡涤，例如过滤、格式化。在这里研发团队有两个抉择：（1）写代码去生产 Kafka 中的音讯，荡涤实现后发送到指标 Kafka Topic。（2）应用组件进行数据荡涤转换，例如：Logstash、Kafka Stream、Kafka Connector、Flink 等。
看在这里，大家必定会有疑难：Kafka Stream 作为流式解决类库，间接提供具体的类给开发者调用，整个利用的运行形式次要由开发者管制，方便使用和调试。这有什么问题吗？尽管以上办法的确可能很快解决问题，但其问题也不言而喻。
- 研发团队须要自行编写代码，且须要前期继续保护，运维老本较大；
- 对于很多轻量或简略计算需要，引入一个全新组件的技术老本过高，须要进行技术选型；
- 在某组件选定后，须要研发团队进行学习并继续保护，这就带来了不可预期的学习老本、保护老本。
为了解决问题，咱们提供了一个更加轻量的解决方案：Kafka ETL 性能。
应用 Kafka ETL 性能后，只需通过 Kafka 控制台进行简略配置，在线写一段荡涤代码，即可实现 ETL 的目标。可能存在的高可用、保护等问题，齐全交由 Kafka。
那么接下来，咱们为大家展现如何疾速的创立数据 ETL 工作，仅需 3 步即可。
Step 1 : 创立工作
抉择 Kafka 起源实例、起源 Topic，以及对应的抉择 Kafka 指标实例、指标 Topic。并配置音讯初始地位、失败解决以及创立资源形式。
Step 2：编写 ETL 主逻辑
咱们能够抉择 Python3 作为函数语言。与此同时，这里提供了多种数据荡涤、数据转化模板，比方规定过滤、字符串替换、增加前 / 后缀等罕用函数。
Step 3：设置工作运行、异样参数配置，并执行
能够看到，无需额定的组件接入或者简单的配置，更轻量、更低成本的 Kafka ETL 仅需 3-5 步的可视化配置，即可开始 ETL 工作。对于数据 ETL 要求绝对简略的团队而言，Kafka ETL 成为最佳抉择，能够将更多精力放在业务研发上。
原文链接
本文为阿里云原创内容，未经容许不得转载。
