批处理ETL已死，Kafka才是数据处理的将来？

最近的一些数据发展趋势推进了传统的批处理抽取 - 转换 - 加载（ETL）架构发生了巨大的变化：数据平台要在整个企业范围内运行；数据源的类型变得更多；流数据获得了广泛性增加。 在 QCon 旧金山 2016 会议上，Neha Narkhede 作了“ETL 已死，而实时流长存”的演讲，并讨论了企业级数据处理领域所面临的挑战。该演讲的核心前提是开源的 Apache Kafka 流处理平台可以提供灵活且统一的框架，支持数据转换和处理的现代需求。

Narkhede 是 Confluent 的联合创始人和 CTO，在演讲中，他首先阐述了在过去的十年间，数据和数据系统的重要变化。该领域的传统功能包括提供联机事务处理（online transaction processing，OLTP）的操做性数据库以及提供在线分析处理（online analytical processing，OLAP）的关系型数据仓库。来自各类操做性数据库的数据会以批处理的方式加载到数据仓库的主模式中，批处理运行的周期多是天天一次或两次。这种数据集成过程一般称为抽取 - 转换 - 加载（extract-transform-load，ETL）。

最近的一些数据发展趋势推进传统的 ETL 架构发生了巨大的变化：

单服务器的数据库正在被各类分布式数据平台所取代，这种平台在整个公司范围内运行；

除了事务性数据以外，如今有了类型更多的数据源，好比日志、传感器、指标数据等；

流数据获得了广泛性的增加，就业务需求而言，须要有一种比每日批处理更快的方案。

这些趋势所形成的后果就是传统的数据集成方式最终看起来像一团乱麻，好比组合自定义的转换脚本、使用企业级中间件如企业服务总线（ESB）和消息队列（MQ）以及像 Hadoop 这样的批处理技术。

在探讨现代流处理技术如何缓解这些问题以前，Narkhede 简要回顾了一下数据集成的历史。在上世纪 90 年代的零售行业中，业务获得了一些新形式的数据，因此对购买者行为趋势进行分析的需求迫切增加。

存储在 OLTP 数据库中的操做性数据必需要进行抽取、转换为目标仓库模式，而后加载到中心数据仓库中。这项技术在过去二十年间不断成熟，可是数据仓库中的数据覆盖度依然相对很是低，这主要归因于 ETL 的以下缺点：

须要一个全局的模式；

数据的清洗和管理须要手工操做而且易于出错；

ETL 的操做成本很高：它一般很慢，而且是时间和资源密集型的；

ETL 所构建的范围很是有限，只关注于以批处理的方式链接数据库和数据仓库。

在实时 ETL 方面，早期采用的方式是企业应用集成（Enterprise application integration，EAI），并使用 ESB 和 MQ 实现数据集成。尽管这能够说是有效的实时处理，但这些技术一般很难普遍扩展。这给传统的数据集成带来了两难的选择：实时但不可扩展，或者可扩展但采用的是批处理方案。

Narkhede 指出现代流处理对数据集成有了新的需求：

可以处理大量且多样性的数据；

平台必需要从底层就支持实时处理，这会促进向以事件为中心的根本转变；

必须使用向前兼容的数据架构，必须可以支持添加新的应用，这些新的应用可能会以不一样的方式来处理相同的数据。

这些需求推进一个统一数据集成平台的出现，而不是一系列专门定制的工具。这个平台必须拥抱现代架构和基础设施的基本理念、可以容错、可以并行、支持多种投递语义、提供有效的运维和监控而且容许进行模式管理。Apache Kafka 是七年前由 LinkedIn 开发的，它就是这样的一个开源流平台，可以做为组织中数据的中枢神经系统来运行，方式以下：

做为应用的实时、可扩展消息总线，不须要 EAI；

为全部的消息处理目的地提供现实情况来源的管道；

做为有状态流处理微服务的基础构建块。

Apache Kafka 在 LinkedIn 目前天天处理 14 万亿条的消息，而且已经部署到了世界范围内成千上万的组织之中，包括财富 500 强的公司，如 Cisco、Netflix、PayPal 和 Verizon。Kafka 已经快速成为流数据的存储方案，而且为应用集成提供了一个可扩展的消息支撑（backbone），可以跨多个数据中心。

Kafka 的基础是 log 的理念，log 是只能往上追加（append），彻底有序的数据结构。log 自己采用了发布 - 订阅（publish-subscribe，pubsub）的语义，发布者可以很是容易地以不可变的形式往 log 上追加数据，订阅者能够维护本身的指针，以便指示当前正在处理的消息。

Kafka 可以经过 Kafka Connect API 实现流数据管道的构建，也就是 ETL 中的 E 和 L。Connect API 利用了 Kafka 的可扩展性，基于 Kafka 的容错模型进行构建而且提供了一种统一的方式监控全部的链接器。流处理和转换能够经过 Kafka Streams API 来实现，这提供了 ETL 中的 T。使用 Kafka 做为流处理平台可以消除为每一个目标 sink、数据存储或系统建立定制化（极可能是重复的）抽取、转换和加载组件的需求。来自 source 的数据通过抽取后能够做为结构化的事件放到平台中，而后能够经过流处理进行任意的转换。

在演讲的最后一部分，Narkhede 详细讨论了流处理的概念，也就是流数据的转换，而且提出了两个相互对立的愿景：实时的 MapReduce 和事件驱动的微服务。实时的 MapReduce 适用于分析用例而且须要中心化的集群和自定义的打包、部署和监控。Apache Storm、Spark Streaming 和 Apache Flink 实现了这种模式。Narkhede 认为事件驱动微服务的方式（经过 Kafka Streams API 来实现）让任何用例都能访问流处理，这只需添加一个嵌入式库到 Java 应用中并搭建一个 Kafka 集群便可。

Kafka Streams API 提供了一个便利的 fluent DSL，具备像 join、map、filter 和 window 这样的操做符。

这是真正的每次一个事件（event-at-a-time）的流处理，没有任何微小的批处理，它使用数据流（dataflow）风格的窗口（window）方式，基于事件的时间来处理后续到达的数据。Kafka Streams 内置了对本地状态的支持，而且支持快速的状态化和容错处理。它还支持流的从新处理，在更新应用、迁移数据或执行 A/B 测试的时候，这是很是有用的。

Narkhede 总结说，log 统一了批处理和流处理，log 能够经过批处理的窗口方式进行消费，也能在每一个元素抵达的时候进行检查以实现实时处理，Apache Kafka 可以提供“ETL 的崭新将来”。

欢迎工做一到五年的Java工程师朋友们加入Java程序员开发： 854393687 群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！