为什么说Kafka才是数据处理的未来？

在旧金山举行的QCon会议上，Neha Narkhede进行了题为《ETL已消失，请关注实时流》的演讲，并深入探讨了企业级数据处理领域面临的主要挑战。该演讲的核心在于开源Apache Kafka流处理平台提供了灵活而统一的设计架构，并非仅仅支持数据转换与处理的需求。

Narkhede 是 Confluent 的联合创始人和技术 lead，在他的演讲中他分享了过去十年间数据与数据分析体系的关键转变。传统的功能主要包括支持在线事务处理（OLTP）的操作型数据库以及在线分析处理（OLAP）的关系型数据库仓库体系。来自不同操作性数据库的数据通常会以批量处理的方式导入到数据仓库的主要存储结构中。这些批量处理的任务周期通常是每天或每两天运行一次的时间间隔。这种基于抽取、转换和批量导入的过程一般被称为提取-转换-加载（ETL）。

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

单机式数据库系统已被多种分布式数据存储方案所替代，在组织内部得到了广泛部署

不局限于事务性数据之外，则现已有更加丰富的类型化的非事务性数据来源可供使用；基于实时采集机制下的流数据显示出了持续增长的趋势，在其处理速度上较日常规批量处理任务高出显著比例。

这些趋势导致的结果表现为传统数据集成方案呈现出错综复杂的状态，在实际应用中通常会遇到以下挑战：例如集成自定义的数据转换脚本，并采用Enterprise Service Bus (ESB)和Message Queue (MQ)等企业级中间件进行数据交互；同时还要运用如Hadoop这类分布式批处理技术来解决大规模数据处理问题。

为了缓解相关问题而探索现代流处理技术的应用前景之前,Narkhede 对数据集成历史进行了简明回顾.在上世纪 90 年代的零售业中,随着业务进入新的形态阶段,在分析消费者行为趋势方面的需求也日益增强.

存储在OLTP数据库中的操作性数据必须经过抽取、转换为目标数据库模式并导入至中央数据中心仓库中。这项技术在过去二十年间持续发展和完善，在一定程度上提高了效率与效果；然而，在当前系统架构下，目标数据库中的数据覆盖率仍显偏低，并非由于现有技术本身的缺陷。

需要一个全局的模式；

数据的清洗和管理需要手工操作并且易于出错；

ETL 的操作成本很高：它通常很慢，并且是时间和资源密集型的；

ETL所涵盖的内容较为局限，在操作上主要专注于批量处理的方法连接数据库和数据仓库。

在实时ETL领域中过去所采用的技术主要是Enterprise application integration (EAI)，它通过结合Enterprise Service Bus (ESB)和Message Queue (MQ)来完成数据整合。然而这种技术虽然具备高效处理的能力，在面对大规模需求时往往难以实现有效的扩展能力。传统的方法面临着两难困境：要么选择即时响应而无法扩展规模；要么扩大处理能力却不得不依赖串行处理方案。

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

能够处理大量且多样性的数据;

为了实现实时处理的需求, 平台必须从底层开始支持这一功能; 这样做将会推动整个系统向基于事件的核心发生根本性的转变

采用向前兼容的数据架构设计系统结构，并具备能力支持新增的应用。这些新增的应用可能采用不同的方式来处理相同的输入数据。

在您看来这里有一个大数据开发交流群：658558542 （☛点击即可加入群聊）内部我已经整理了一份丰富的学习资源包涵盖了一些关键的技术点包括但不限于：从零开始掌握大数据技术入门到深入理解其核心原理；还有涉及的数据离线处理与实时分析两大类体系；具体来说这些资源涵盖了Hadoop 101基础操作Spark并行计算Flink流处理框架以及各种主流的推荐系统算法实现案例还有部分代码解析等内容这些都是我们团队经过实践积累的经验分享希望对您有所帮助无论是初学还是有一定经验的开发人员都能找到所需的学习资料

欢迎所有热爱大数据开发的朋友加入我们的交流圈一起探讨技术问题互相学习共同进步！不仅有大量实用的学习资料还可以随时与群里经验丰富的老铁们交流解答您的各种疑问

这些需求促使一个统一的数据集成平台应运而生而非多个专门定制的工具。该平台必须具备现代架构和基础设施的核心理念，并且具备容错能力以及并行处理能力；同时支持多种投递语义，并提供有效的运维与监控机制；此外还需要允许进行模式管理以满足多样化的需求。Apache Kafka是由LinkedIn于七年前开发的一个开源流处理平台；它本质上就是一个开源流处理平台，在组织中能够充当数据中枢的角色运行方式如下：

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

为所有的消息处理目的地提供现实状况来源的管道;

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

Apache Kafka 每日管理着 LinkedIn 的 14 万亿条消息，并在全球范围内广泛部署。
包括财富500强公司如 Cisco、Netflix、PayPal 和 Verizon。
Kafka 已迅速发展成为一个流数据存储方案，并提供了可扩展的应用集成消息基础（backbone），能够跨越多个数据中心运行。

Kafka 是基于 log 的核心理念。日志（log）是一种仅允许向上追加（append）且具有严格顺序的数据结构。日志采用发布-订阅机制（pubsub），允许发布者将数据以不可变形式添加至日志中。发布者能够以不可变形式轻松地将数据添加至日志中。订阅者通过维护自身指针来跟踪当前处理的消息。

Kafka 连接API 为构建流数据管道提供了功能支持, 即为ETL流程中的抽取（E）和加载（L）环节. 其中, 连接API 利用了 Kafka 的异步架构设计, 在容错机制的基础上实现了可靠的连接建立. 此外, 该Kafka Streams API为此场景提供了完善的流处理与转换能力. 从而实现了ETL流程中的转换（T）环节. 使用Kafka 作为流处理平台则能有效规避因各个目标点如存储系统、下游应用或中间件等而产生的各自化的数据抽取、转换与负载配置需求. 原始数据被提取后会被整合到该平台上, 然后即可对这些结构化事件进行灵活多样的转换操作.

在演讲的最后一部分中，Narkhede深入阐述了流数据转换的核心概念，并提出了两种相互矛盾的目标：一种是实时MapReduce方案（特别适用于那些需要快速数据分析的应用场景），另一种是基于事件驱动型微服务架构的设计理念（通常依赖于Kafka Streams API）。他指出，在实时MapReduce模式下，默认情况下会采用中心化的集群环境，并伴随着复杂的打包、部署及监控流程；而Apache Storm、Spark Streaming与Flink等工具则成功实现了这一模式；相比之下，则认为通过Kafka Streams API的方法构建事件驱动型微服务架构能够使得任何应用无需额外开发即可接入流处理系统

Kafka Streams API 为用户提供了一个便捷的 fluent API 库，并包含 join、map、filter 和 window 等一系列操作符。

这种方案是逐事件（event-by-event）模式下的真实流处理方案，在这种设计中不存在任何微 batching操作。它采用基于时间的数据接收机制，在完成当前事件后会自动切换到接收下一个事件的状态。Kafka Streams框架内置本地状态管理功能，并提供高效的故障恢复能力，在需要快速恢复服务可用性的情况下表现突出。此外该系统具备重利用率功能，在需要更新应用迁移数据或执行 A/B 测试等场景下能够重利用之前的数据流量

Narkhede 对此进行了总结：统一机制整合了批次数据和流式数据的管理流程；该系统采用窗口机制对批次数据进行集中接收和分析，并能在数据流实时到达的过程中能够及时触发相关处理逻辑；Apache Kafka 技术平台实现了传统ETL流程与现代数据分析方法的有效结合。

感谢您的关注！如有任何意见或建议，请随时提出（如有些地方不够完善），我们定当虚心接受并及时改进）。最后祝愿每一位陷入工作上的瓶颈期的大数据程序员都能够超越自我，在未来的求职和工作中一帆风顺！