Kappa架构取代Hadoop的Lambda架构成为主流 - Waehner

Kappa架构取代Hadoop的Lambda架构成为主流 - Waehner

实时数据胜过慢速数据。几乎每个用例都是如此。然而，企业架构师使用 Lambda 架构构建新的基础架构，其中包括单独的批处理层和实时层。这篇博文探讨了为什么称为 Kappa 架构的单个实时管道更适合。迪斯尼、Shopify 和优步等公司的真实示例探索了Kappa的好处，但也展示了批处理如何在不需要 Lambda 的情况下积极地融入这一讨论。

这篇文章在很大程度上来自杰伊·克雷普斯的文章‘质疑Lambda架构’2014年和他的想法，映射到2021年今天现实世界的情况，几乎所有的商业解决方案，数据存储和分析工具供应商，和业务应用程序利用事件流和异步、真正解耦的基于事件的通信范式进行数据处理。出于这个原因，许多人从 Lambda 迁移到 Kappa 架构。

现代企业架构

现代企业架构提供云原生特性：灵活性、弹性、自动化、不同应用程序之间的真正解耦以及实时功能（在需要时）。

真正解耦的微服务、数据网格和领域驱动设计

让我们快速探索一下流行语，以了解当今大多数人如何构建现代企业架构：

• 领域驱动设计 (DDD)在服务通信和去中心化应用程序环境之间实施严格的界限。
• 微服务支持使用不同的编程语言和通信范式构建灵活、解耦的应用程序。
• 数据网格允许围绕数据构建服务。数据是数据网格中的产品。自助服务功能和联合使业务部门能够专注于他们的业务问题。

我的博客文章“微服务、Apache Kafka 和领域驱动设计”更详细地探讨了这一讨论（尽管在撰写本文时还没有流行语“数据网格”）。事件驱动的流媒体基础设施，如 Apache Kafka，独特地实现了正确的解耦和实时数据处理（与传统的基于 Web 服务/REST/HTTP 的微服务架构相反，与传统的消息传递系统（MQ、ESB）相反。关于Kafka 与 MQ/ETL/ESB的博客文章也可能有助于了解更多信息。

实时数据胜过慢速数据，但并非总是如此！

想想您的行业、业务部门、您解决的问题以及您构建的创新应用程序。实时数据胜过慢速数据。这种说法几乎总是正确的。要么增加收入，降低成本，降低风险，要么改善客户体验。

静态数据意味着将数据存储在数据库、数据仓库或数据湖中。这样，在许多用例中数据处理得太晚了——即使实时流组件（如 Kafka）摄取了数据。数据处理仍然是 Web 服务调用、SQL 查询或 map-reduce 批处理，而不是为您的问题提供结果。

不要误会我的意思。静止数据并不是一件坏事。报告（商业智能）、分析（批处理）和模型训练（机器学习）等几个用例非常适合这种方法。但是在几乎所有其他用例中实时数据会击败批处理。

我在博客文章“ Serverless Kafka in a Cloud-native Data Lake Architecture ”中分析了静态数据和动态数据之间的关系，以及这种关于企业架构的观点如何随着大多数公司的云优先战略而改变。

实时数据处理的事实标准就是Apache卡夫卡。因此，本文中涵盖的真实示例使用 Kafka。

考虑到这种情况，让我们重新审视 Lambda 架构。

Lambda 架构

Nathan Marz 创造了 Lambda 架构：一种数据处理架构，旨在通过利用批处理和流处理方法来处理大量数据。

Lambda 架构包括批处理、速度和服务层。这种方法不仅可以实时处理数据，还可以轻松地重新处理批量静态数据集。乱序数据的问题也解决了。

这种方法试图通过使用批处理来提供批处理数据的全面和准确的视图，同时使用实时流处理来提供在线数据的视图来平衡延迟、吞吐量和容错性。lambda 架构的兴起与大数据、实时分析的稳定增长以及减少 map-reduce 延迟的驱动相关。

 Lambda 架构的两种不同方法：

1. 最初的方法提供了一个统一的服务层。一个统一的服务层加入了实时层和批处理层：
2. 另一种选择是两个独立的服务层。一层用于实时消费，另一层用于批量消费：

我在该领域更多地看到了第二种选择。最后，两者都有相同的概念，即为数据摄取和处理构建两个独立的层。

Hadoop的销售商投巨资Lambda架构部署和操作与许多大数据框架的一个超级复杂的基础设施。

今天，我只听到企业抱怨这种复杂性和商业价值缺失的痛苦。毫不奇怪，这些供应商中的大多数都没有生存下来，或者有一个非常混乱和不明确的未来产品战略。

迪士尼在一张幻灯片上总结了 Lambda 架构的问题。。。。。

批处理和流处理两侧各自需要不同的代码库必须保持，并且使得处理后的数据从产生两个路径相同的结果保持同步。此外，对于批处理、速度和服务层，所有内容都需要（至少）处理两次。这增加了存储、网络和计算的成本和运营工作。

Jay Kreps在 2014 年提出 Kappa 架构时也有类似的论点：“Lambda 架构的问题在于，维护需要在两个复杂分布式系统中产生相同结果的代码就像看起来一样，这将是痛苦”。

Kappa 架构

是基于事件的，并且能够在实时的事务和分析工作负载的所有规模来处理所有的数据。

Kappa 架构背后的核心前提是您可以使用单个技术堆栈执行实时处理和批处理。基础设施的核心是流式架构。首先，事件流平台日志存储传入数据。从那里，流处理引擎实时连续处理数据，或通过任何通信范式和速度（包括实时、近实时、批处理、请求-响应）将数据摄取到任何其他分析数据库或业务应用程序中。

与 Lambda 架构不同，在这种方法中，您仅在处理代码发生变化时才进行重新处理，并且需要重新计算结果。而且，当然，重新计算的工作只是相同代码的改进版本，运行在相同的框架上，采用相同的输入数据。

Kappa 架构有几个好处：

• 使用单一架构处理所有用例（流、批处理、RPC）
• 一个始终同步的代码库
• 一套基础设施和技术
• 基础设施的核心是实时、可扩展和可靠
• 提高数据质量，保证排序且无错配
• 无需为新用例重新设计

Kappa 架构利用单一的事实来源，专注于企业架构中的简单性。人们可以在实时和批处理系统的单一处理框架上开发、测试、调试和操作他们的系统。需要明确的是：某些应用程序的领先系统仍然可以是另一个系统。比如ERP的主导系统仍然是SAP，而消费的真实来源是Kafka日志。

用于事务性和分析性工作负载的 Kappa

与数据湖相反，事件流驱动的Kappa 架构除了支持分析工作负载外，还支持事务性工作负载。

例如，Kafka 及其生态系统支持仅一次语义，因此您可以使用关键任务 SLA、低延迟和内置容错功能构建下一个用于售后或客户交互的支付平台。独立地，数据科学团队使用历史事件来使用机器学习在批处理过程中寻找洞察力。

迪斯尼迁移教训：

Kappa 架构听起来好得令人难以置信？嗯，一个基本的经验法则仍然有效：为工作使用正确的工具！

事件流是一种范式转变。大爆炸迁移是行不通的。以下是迪士尼在引入 Kappa 架构方面的一些经验教训：

由于大爆炸不起作用，一个好方法是重新思考数据和数据库。Martin Kleppmann 称其为“将数据库翻过来”。让我们看看这种方法以及它如何帮助利用 Kappa 架构与其他数据库和分析平台的结合。

解决 Kappa 挑战的内外视角

将数据库由内而外是企业架构的一种新思维。基础设施的核心是基于事件和实时的。在需要时，您可以批量使用事件，或者在使用事件后将它们连同它们的概念和范例存储在额外的存储和分析工具中。

Kappa的内在视角：中枢神经系统

想想像 Kafka 这样的事件流平台：

• 数据可用性/保留：压缩主题、分层存储
• 数据一致性和容错：恰好一次语义、多区域集群、集群链接
• 处理迟到的数据：事件时间和处理时间不同。流应用程序中的状态管理、适当的数据接收器、保证排序的重放和时间戳。
• 数据再处理和回填：动态集群（理想情况下是无服务器云产品或至少是云原生自管理集群）、有状态应用程序（Kafka Streams、ksqlDB、外部流处理框架，如 Apache Flink）。
• 数据集成：用于源和接收器的Kafka Connect、用于任何语言的客户端、REST 代理（实时但也可以批处理和 RPC）

其他问题：Kafka 不能很好地扩展动态突发工作负载。复杂的 SQL 查询和连接还需要另一个数据库。

想想任何业务应用程序、数据存储或分析平台：

• 数据消耗：消耗来自中枢神经系统的数据。以您的速度（实时、近实时、批处理、RPC）使用数据。
• 数据存储：根据需要将数据存储在您的存储中（内存中、短期存储、长期存储）。
• 数据处理：处理用例的数据（实时通知、查询引擎的索引、报告或模型训练的批处理等）。复杂的处理在事件流平台中是不可行的（例如，复杂的连接、使用批处理算法的密集计算）。

讨论“ Apache Kafka可以用作数据库吗？”也有助于理解使用 Kafka 作为数据存储的观点和权衡。

Kappa 架构的真实示例

• 优步的 Kappa 每天处理数万亿条消息和 PB

优步是一家非常著名的科技巨头。他们经常公开谈论他们的软件架构和部署。优步是世界上最重要的 Kafka 用户之一。与此同时，他们每天处理超过 4 万亿条信息和 3PB。

作为这篇博文的完美契合，优步在最近的 Kafka 峰会上展示了他们的 Kappa 架构。

• Shopify 的 Kappa 用于无状态和有状态数据流

Shopify 在最近的Kafka 峰会演讲中展示了他们的 Kappa 架构：“是时候停止使用 Lambda 架构了”该会议涵盖了 Kappa 架构的问题以及 Shopify 如何使用不同的构建块来解决这些问题。三个关键组件是日志（Kafka）、流框架（Kafka Streams 和 Apache Flink）和数据接收器（任何实时消费者或数据存储）。

• 迪斯尼的Kappa作为唯一的真相来源

迪斯尼卡夫卡峰会演讲“大数据Kappa ”很有启发性。它可能包括现实世界 Kappa 部署的最多经验教训和权衡。我鼓励您观看点播视频 — 构建您自己的 Kappa 架构的许多见解和指南。

迪士尼的所有数据写入都通过 Kafka 作为真实来源。

• 示例项目：用于机器学习的 Kappa，包括模型训练、评分和监控

在 Uber、Shopify 和 Disney 的真实示例之后，我想分享一个更实际的代码示例：连接到 100,000 个 IoT 设备以进行流式机器学习的技术演示。用例是关于集成数以万计或数十万个物联网设备并实时处理数据。演示用例是联网汽车基础设施中的预测性维护（即异常检测），以预测发动机故障。

实现的 Kappa 架构为各种非常不同的用例和处理范例提供了单一的实时基础设施：

• 通过 MQTT 代理从 IoT 设备以高吞吐量实时摄取数据：与数百万个接口（在本例中为模拟车辆）集成。
• 模型训练的批处理：来自数据科学家的 TensorFlow Python 应用程序使用来自 Kafka 日志的历史数据来训练分析模型。
• 用于模型评分的实时流处理：基于 Java 的流应用程序由 Kafka Streams / ksqlDB 提供支持，并由具有关键任务 SLA 和低延迟的生产工程师操作。
• 近乎实时地将数据摄取到数字孪生中以进行分析：Kafka Connect 将数据摄取到不同的数据库和应用程序中，在本例中为 MongoDB Atlas 云服务。
• 用于移动应用程序集成和事务性工作负载的同步请求-响应/RPC 通信：Confluent REST 代理（或任何其他 Web/移动代理）向人类发送实时警报。

整个基础设施都是云原生的。它在 Kubernetes 上运行，可以部署在数据中心或任何超大规模机上。以下博客文章详细解释了该演示：IoT Live Demo — 100.000 辆互联汽车与 Kubernetes、Kafka、MQTT、TensorFlow。代码在Github 项目中可用。

下一代软件产品和 SaaS 产品下的 Kappa

软件公司面临着与优步、Shopify 或迪士尼等最终用户相同的挑战。因此，软件供应商将 Kappa 架构和实时功能作为其基础架构的核心也就不足为奇了。

本节展示了一些软件供应商的示例，这些供应商在其下一代软件产品中转向基于事件的架构、事件流和异步外部接口。

• 业务解决方案（Salesforce、SAP、Slack 等）

跨不同业务解决方案的几个示例：

1. Salesforce：内部“平台事件”架构严重依赖 Apache Kafka 进行大规模解耦实时数据处理。外部 API，例如与 Salesforce 专有 sObject 数据类型的集成，从 SOAP 和 REST Web 服务转移到流 API PushTopics、企业消息传递平台事件和变更数据捕获事件。
2. SAP：SAP不再依赖 BAPI 和 iDoc 等传统专有接口，而是在其下一代 SAP S/4 Hana ERP 平台中转向基于事件的 API。博客“ Apache Kafka 的 SAP 集成选项”展示了众多遗留接口和替代现代基于事件的集成选项的混乱。
3. Slack：作为本质上的消息传递平台，其核心后端基础设施的核心利用事件流也就不足为奇了。Slack 的数据流团队专注于在亚马逊数据中心的数十个集群中以每天数万亿条消息的规模为公司提供 Kafka 即服务。对于前端，Slack 当前的架构利用了使用 Envoy 和 WebSockets 构建的服务网格

• 数据库、数据仓库、日志分析

数据存储和分析供应商传统上是用于长期存储、仪表板、报告和交互式查询的批处理技术。大多数解决方案的核心仍然是用于分析工作负载的批处理系统。这是这些产品和服务的核心业务。

尽管如此，由于客户需求，几乎所有这些供应商都进入了（近）实时业务。因此，基于事件的集成功能和近乎实时的摄取、处理和分析变得越来越普遍。一些例子：

1. MongoDB：“更改流”允许应用程序从基于文档的 NoSQL 数据存储访问实时数据更改。
2. Snowflake：“Snowpipe”可以帮助组织将持续生成的数据无缝加载到云数据仓库中。
3. Elasticsearch：“数据流”让您可以跨多个索引存储仅追加的时间序列数据，同时为请求提供单个命名资源。数据流非常适合日志、事件、指标和其他连续生成的数据，以将数据提取到 Elastic 搜索引擎中。

这些解决方案的共同点是，它们从批处理转变为近乎实时地摄取到其数据存储或数据湖中。尽管如此，他们仍然存储和分析静态数据。因此，这是对事件流的补充而非替代。

市场的新进入者试图通过在其核心提供实时基础设施来与上述数据存储供应商区分开来。Rockset就是一个很好的例子，它是一个可扩展的云实时分析平台。由于它是一个原生的实时解决方案，Rockset 原生地与 Apache Kafka 等事件流平台集成。