首先

东京的卡桑德拉日

今年，2023年6月1日，Cassandra Day将在日本举办。去年，Cassandra Day还在柏林、伦敦、阿姆斯特丹、河内、雅加达、休斯顿、圣塔克拉拉、西雅图和新加坡等地举办过。

我们将发布关于Apache Cassandra的文章，以备本次在东京举行的活动。

关于Apache Cassandra的相关内容。

如果用一句话来形容Apache Cassandra，那就是一个开源的分布式数据库管理系统。

与其他分布式数据库管理系统一样，可以使用多个通用服务器构建一个数据库（也可以仅使用一个服务器进行开发等目的）。

在这里，不详细解释，我们将把介绍感兴趣的人的角色留给官方网站和维基百科。

 

现代的“实时”是什么？：从Lambda架构到Kappa架构

关于这篇文章

这篇文章是将Kai Waehner的以下博客文章的内容进行改写，以适应日本读者，并加以介绍。

 

关于文章的成立，作者写道如下。

这篇帖子受到2014年Jay Kreps的文章“质疑Lambda架构”的强烈影响，并将他的思想应用到2021年的现实世界中。

 

我在2022年时，涉及到机器学习的”在线商店”概念时，开始意识到Kappa架构的重要性。

在中国，虽然Lambda架构已经出现了相当长的时间，但在日本，《可扩展实时数据分析入门 – 通过Lambda架构进行大数据处理》一书出版于2016年，因此可以说Jay Kreps的文章确实是相当先进的立场（「！」标记是Kai Waehner本人提供的）。

那么，下面将作为以上文章的自由改编进行记录。

作为继承的Lambda架构

实时数据胜过低速数据。这适用于几乎所有的用例。然而，许多企业的架构师正在使用由批处理层和实时层组成的Lambda架构来构建新的基础设施。

以下我们将探讨被称为Kappa架构的单一实时流水线的卓越性原因。

Kappa架构实际上已经被诸如Disney、Shopify、Uber、Twitter等企业采用。该文章还提到了这些实际例子与本文主题的关系。

今天，几乎所有的商业解决方案都跨越企业架构的各个组成部分（例如数据存储、分析提供商、业务应用、事件流等），利用异步的、真正独立的基于事件的通信范式来进行数据处理。

这个在某种意义上对从Lambda到Kappa架构的转变做出了响应。

Apache Kafka Pulsar数据湖的Kappa架构与Lambda架构的比较

-Kappa架构和Lambda架构是Apache Kafka Pulsar数据湖的两种不同架构方式的比较。

最新的企业架构

最新的企业架构提供了云原生的特性，包括灵活性、弹性、自动化、真正的应用程序间隔离以及实时功能（如果需要）。

为实现真正的解耦，可以采用微服务、数据网格和领域驱动设计。

为了理解大多数人如何构建最新的企业架构，让我们简单地查阅一下流行词。

• ドメイン駆動設計 (DDD) は、サービス通信と分散型アプリケーション ランドスケープの間に厳密な境界を適用します。

 

• マイクロサービスを使用すると、さまざまなプログラミング言語と通信パラダイムを使用して、柔軟で分離されたアプリケーションを構築できます。

 

データ メッシュを使用すると、データに関するサービスを設計できます。データは、データ メッシュの積です。セルフサービス機能とフェデレーションにより、ビジネス ユニットはビジネス上の問題に集中できます。

在我的博客文章“微服务、Apache Kafka和领域驱动设计”中，我更详细地探讨了这个问题（尽管在撰写时还没有“数据网格”这个流行词）。总结一下：像Apache Kafka这样的事件驱动流式基础设施可以实现适当的解耦和实时数据处理（不同于传统的基于Web服务/REST/HTTP的微服务架构和传统的消息系统（MQ、ESB））。有关Kafka和MQ/ETL/ESB的博客文章也可能对了解问题有帮助。

 

数据静止和数据运动

当我们考虑使用数据的服务和实现这些服务的应用程序时，我们会发现实时数据胜过慢速数据。在大多数情况下，我们会意识到这个陈述是正确的。
通过提高数据的实时性，我们可以实现增加收益、削减成本、减少风险或提升客户体验等结果。这就是为什么数据流动的重要性得到认识的原因。

一方，Data-at-Rest指的是将数据存储在数据库、数据仓库或数据湖中，但这并不意味着Data-at-Rest是毫无意义的。报告（商业智能）、分析（批处理）、模型训练（机器学习）等一些使用案例在这种方法下能够非常有效。然而，在许多其他使用案例中，实时性比批处理更重要。

考虑到这个背景，我们将重新审视Lambda架构。

拉姆达体系结构

Nathan Marz 提出了 Lambda 架构，这是一个设计用于处理大量数据的数据处理架构，它同时利用了批处理和流处理的方法。

Lambda架构包括批处理、速度和服务层。这种方法允许数据实时处理，并且可以轻松重新处理批处理静态数据集。

这种方法旨在通过使用批处理提供综合且准确的批量数据视图，同时使用实时流处理提供在线数据的视图，以实现等待时间、吞吐量和容错性的平衡。Lambda架构的兴起与大数据分析的低延迟趋势息息相关。

Lamba 架构的两个选择

Lambda 架构有两种不同的方法。

最初的方法提供了一个统一的存储层。这个统一的存储层将实时层和批量层结合在一起。

另一种方法是使用两个独立的服务层。一个层面是用于实时操作，另一个层面是用于批处理。

在实际场景中，通常可以看到第二个选项。无论哪个选项，都意味着具有两个独立层（实时层和批处理层）来处理数据的导入和处理。

Lambda 架构的问题

迪士尼将有关Lambda架构的关注点总结在一张幻灯片上。

批处理和流处理两侧都需要不同的代码基础来保持和同步，以生成处理后的数据以相同结果通过两个路径。此外，在批处理、速度和服务层中，需要至少处理两次。这将增加存储、网络和计算成本以及运营工作量。

2014 年（！）に Kappa アーキテクチャを提案した際、Jay Kreps はすでに同様の議論をしていた。

Kappa 架构有何不同之处？

Kappa 架构

Kappa架构是一种基于事件的软件架构，可以实时处理所有规模的事务工作负载和分析工作负载的数据。

Kappa架构的主要前提是能够通过单一技术栈实现实时处理和批处理。基础架构的核心是流式处理架构。
首先，接收到的数据被存储在事件流平台的日志中。然后，流式处理引擎通过实时、准实时、批处理、基于请求等任意通信范式将数据提供给其他分析数据库或业务应用程序。

Kappa 架构的优点：

Kappa 架构具有几个优点。

• 単一のアーキテクチャですべてのユースケース (ストリーミング、バッチ、RPC) を処理します

 

• 常に同期している 1 つのコードベース

 

• インフラストラクチャとテクノロジの 1 つのセット

 

• インフラストラクチャの心臓部は、リアルタイム、スケーラブル、そしてリライアブル（信頼性を有する）です

 

• 順序が保証され、不一致がないため、データ品質が向上します

 

新しいユースケースのために再設計する必要はありません

用于事务和分析负载的 Kappa

与数据湖相反，使用事件流处理的Kappa架构不仅可以支持分析工作负载，还可以支持事务工作负载。

使用Apache Kafka实现Kappa架构，用于处理事务和分析工作负载。

例如，Kafka及其生态系统通过支持精确一次语义，可以构建用于售后或与客户交互的支付平台，具备关键业务 SLA、低延迟和内置的容错能力。
同时，数据科学团队可以使用历史事件来使用机器学习在批处理过程中发现洞察。

事件流媒体的范式转变

Kappa 架构听起来很酷吗？嗯，基本经验规则仍然有效。请使用适合工作的工具！

事件流动是一种范式转变。以下是迪士尼从Kappa体系结构实施中学到的一些教训。

对于现实的Kappa架构的处理方法

在引入现实的Kappa架构时，我们需要重新考虑自然界、数据及其管理（数据库）。
Martin Kleppmann 将其称为“翻转数据库”。

将数据库颠倒过来指的是基础设施的中心转向事件驱动的实时数据。

在这里，我们来考虑一下事件流平台（以Apache Kafka为例，更容易理解）。事件流平台需要具备以下功能。

• データの可用性/保持

 

• データの一貫性と耐障害性

 

• 時間差を伴うデータの処理

 

• データの再処理とバックフィル

 

データ統合

换言之，事件流平台提供了构建Kappa架构所需的许多特性，但无法称之为万应灵药。在某些应用场景中，需要额外的数据库和分析工具。例如，Kafka无法有效地扩展应对动态爆发的工作负载。对于复杂的SQL查询和连接操作，也需要另一个数据库。

以下的文章「Can Apache Kafka Replace a Database?（Apache Kafka可以替代数据库吗？）」对于理解将Kafka作为数据存储使用的观点和权衡有所帮助。

 

最后

在这篇稿件中，我介绍了以下文章的前半部分内容。

 

我将尝试用中文进行总结。

由于Lamda架构向Kappa架构的转变，事件流平台作为数据库的替代方面受到了关注。

虽然没有涉及到上述文章，但是可以考虑将上述“结果”部分替换为“实时、可扩展和可靠（具有可信度）”的另一个数据库。

此外，在这篇文章中，提到了 Kafka，但我们也可以考虑一些更现代化的事件流平台。

作为作者的立场，我也想分别给予Apache Cassandra和Apache Pulsar这两个名称，但是关于具体细节，我愿意在另外一篇文章中详细介绍。