基于速度的数据架构简介

对数据架构进行分类和理解有多种方式，每种方式都有其优缺点。它们可以帮助您为自己的需求做出关于最佳设计的明智决策。在这里，我将解释基于速度的数据架构，以及它们在整体架构中的位置。

最流行的两种基于速度的架构是 Lambda 和 Kappa。数据架构也可以根据其运行模式或拓扑进行分类，包括数据织物（data fabric）、数据中心（data hub）和数据网格（data mesh）——但这部分解释我将留待后续博客文章。

什么是数据架构？

数据架构是企业架构中的一个要素，继承了其主要属性：流程、策略、变更管理和权衡评估。根据 Open Group 架构框架，数据架构是“对企业主要数据类型和来源、逻辑数据资产、物理数据资产以及数据管理资源的结构和交互的描述。”

根据数据管理知识体系，数据架构是“识别企业数据需求（无论结构如何）并设计和维护满足这些需求的主蓝图”的过程。它使用主蓝图来指导数据集成、控制数据资产并将数据投资与业务战略保持一致。

并非所有流程都是好的。糟糕的数据架构是紧耦合、僵化和过度中心化的。它使用了错误的工具，这会阻碍开发和变更管理。

基于速度的数据架构

数据速度指数据生成的速度、数据移动的速度以及数据处理成可用洞察的速度。

根据处理数据的速度，数据架构通常分为两类：Lambda 和 Kappa。

Lambda 数据架构

Lambda 数据架构由 Apache Storm 的创建者 Nathan Marz 于 2011 年开发，旨在解决大规模实时数据处理的挑战。

Lambda 一词源自 Lambda 演算 (λ)，描述了在分布式计算中并行运行于多个节点上的函数。Lambda 数据架构提供了一个可扩展、容错且灵活的系统来处理大量数据。它允许以混合方式访问批处理和流处理方法。

Lambda 架构非常适合处理各种工作负载和速度的数据。由于它可以处理大量数据并提供低延迟的查询结果，因此适用于仪表板和报告等实时分析应用。该架构适用于批处理任务（清洗、转换、数据聚合）、流处理任务（事件处理、开发机器学习模型、异常检测、欺诈预防）以及构建集中式存储库（称为“数据湖”）来存储结构化和非结构化信息。

Lambda 架构的关键区别在于它使用两个独立的处理系统来处理不同类型的数据处理工作负载。第一个是批处理系统，将结果存储在集中式数据存储中（例如数据仓库或数据湖）。Lambda 架构中的第二个系统是流处理系统，它实时处理到达的数据并将结果存储在分布式数据存储中。

Lambda 架构解决了计算任意函数的问题，系统必须对任何给定输入（无论是慢速还是实时）评估数据处理函数。此外，它通过确保如果一个系统发生故障或不可用时，来自任一系统的结果都可以用作另一系统的输入来提供容错能力。这种架构的效率在高吞吐量、低延迟和近实时应用中显而易见。

Lambda 架构由摄取层、批处理层、速度层（或流处理层）和服务层组成。

批处理层：批处理层处理大量历史数据，并将结果存储在集中式数据存储中，例如数据仓库或分布式文件系统。该层使用 Hadoop 或 Spark 等框架进行高效的信息处理，从而能够提供所有可用数据的整体视图。
速度层：速度层处理高速数据流，并使用 Apache Flink 或 Apache Storm 等事件处理引擎提供最新的信息视图。该层处理输入的实时数据，并将结果存储在分布式数据存储中，例如消息队列或 NoSQL 数据库。
服务层：Lambda 架构的服务层对于无论底层处理系统如何，都能为用户提供一致且无缝的数据访问至关重要。它在支持需要快速访问当前信息的实时应用（如仪表板和分析）方面发挥着重要作用。

Lambda 架构提供了许多优势，例如可扩展性、容错性以及处理各种数据处理工作负载（批处理和流处理）的灵活性。但它也有缺点

Lambda 架构很复杂。它使用多种技术栈来处理和存储数据。
它的设置和维护可能具有挑战性，特别是在资源有限的组织中。
底层逻辑在批处理层和速度层的每个阶段都会重复。这种重复是有代价的：尽管逻辑相同，但实现方式在不同层之间是不同的，这会导致数据差异。因此，错误/bug 的可能性更高，并且您可能会从批处理层和速度层获得不同的结果。

Kappa 数据架构

2014 年，当他还在 LinkedIn 工作期间，Jay Kreps 指出了 Lambda 架构的一些缺点。这次讨论促使大数据社区找到了一种使用更少代码资源的替代方案。

Kappa（以希腊字母 ϰ 命名，在数学中用于表示循环）背后的主要思想是，可以使用单一技术栈进行实时和批量数据处理。这个名称反映了该架构相对于基于批处理的方法，更强调连续数据处理或再处理。

其核心是，Kappa 依赖于流式架构。输入数据首先存储在事件流日志中。然后由流处理引擎（例如 Kafka）连续处理，既可以是实时处理，也可以摄取到另一个分析数据库或业务应用中。这样做使用了各种通信范例，例如实时、近实时、批处理、微批处理和请求响应。

Kappa 架构旨在提供一个可扩展、容错且灵活的系统，用于实时处理大量数据。Kappa 架构被认为是 Lambda 架构的更简单替代方案；它使用单一技术栈来处理实时和历史工作负载，并将所有内容视为流。Kappa 架构的主要动机是避免为批处理层和速度层维护两个独立的 codebase（管道）。这使其能够提供更精简和简化的数据处理管道，同时仍能快速可靠地访问查询结果。

数据再处理是 Kappa 的一个关键要求，它使得源端任何更改对结果的影响变得可见。因此，Kappa 架构仅由两层组成：流处理层和服务层。

在 Kappa 架构中，只有一个处理层：流处理层。该层负责收集、处理和存储实时流数据。这种方法消除了对批处理系统的需求。相反，它使用先进的流处理引擎（如 Apache Flink、Apache Storm、Apache Kafka 或 Apache Kinesis）来处理大量数据流并提供快速可靠的查询结果访问。

流处理层有两个组件

摄取组件：此层收集来自各种来源的输入数据，例如日志、数据库事务、传感器和 API。数据被实时摄取并存储在分布式数据存储中，例如消息队列或 NoSQL 数据库。
处理组件：此组件处理大量数据流，并提供快速可靠的查询结果访问。它使用事件处理引擎（例如 Apache Flink 或 Apache Storm）来处理实时输入数据和历史数据（来自存储区域），然后将信息存储在分布式数据存储中。

对于几乎所有用例，实时数据都优于慢速数据。然而，Kappa 架构不应被视为 Lambda 架构的替代品。相反，在批处理层的主动性能对于满足标准服务质量并非必要的情况下，您应该考虑 Kappa 架构。

Kappa 架构承诺可扩展性、容错性和简化的管理。然而，它也有缺点。例如，Kappa 架构理论上比 Lambda 简单，但对于不熟悉流处理框架的企业来说，它在技术上仍然可能很复杂。

从我的角度来看，Kappa 的主要缺点是扩展事件流平台的成本。将大量数据存储在事件流平台中可能会很昂贵，并带来其他可扩展性问题，特别是当数据量以 TB 或 PB 为单位时。

此外，事件时间和处理时间之间的延迟不可避免地会产生延迟到达的数据作为副作用。因此，Kappa 架构将需要一套机制，例如水位线（watermarking）、状态管理、再处理或回填（backfilling），来克服这个问题。

探索数据流模型

Lambda 和 Kappa 是试图通过集成本质上不兼容的复杂工具来克服 Hadoop 生态系统在 2010 年代的缺点。这两种方法都在努力解决协调批处理和流式数据的根本挑战。然而，Lambda 和 Kappa 为进一步的发展提供了启发和基础。

统一多个代码路径是管理批处理和流处理中的一个重大挑战。即使有了 Kappa 架构的统一队列和存储层，开发人员仍然需要使用不同的工具来收集实时统计信息和运行批量聚合作业。如今，他们正在努力解决这个挑战。例如，谷歌通过开发数据流模型及其实现 Apache Beam 框架取得了显著进展。

数据流模型的基本前提是将所有数据视为事件，并在不同类型的窗口上执行聚合。实时事件流是无界数据，而数据批次是具有自然窗口的有界事件流。

数据工程师可以选择不同的窗口，例如滑动窗口或翻滚窗口，用于实时聚合。数据流模型使实时处理和批处理可以在同一个系统中进行，使用几乎相同的代码。

“批处理是流处理的特例”的思想已经越来越普遍，像 Flink 和 Spark 这样的框架也采用了类似的方法。

关于基于速度模型的数据架构讨论还有另一个转折点：物联网 (IoT) 工作中适合的设计选择。但这部分我将留待单独讨论。

显然，关于如何最好地构建我们处理数据的方法的争论远未结束。我们才刚刚开始！请参阅我们的白皮书《金融服务现代化数据层最佳实践》，了解如何将僵化缓慢的传统 IT 系统现代化并转变为现代数据架构的最佳方法。