基于速度的数据架构简介

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

两种最流行的基于速度的架构是 Lambda 和 Kappa。数据架构也根据其操作模式或拓扑进行分类，包括数据结构、数据中心和数据网格——但我将这些解释留到以后的博文中。

什么是数据架构？

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

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

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

基于速度的数据架构

数据速度是指数据生成的速度、数据移动的速度以及数据被处理成可用的见解的速度。

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

Lambda 数据架构

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

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

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

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

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

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

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

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

Lambda 架构很复杂。它使用多个技术栈来处理和存储数据。
它可能很难以设置和维护，尤其是在资源有限的组织中。
批处理层和速度层在每个阶段都复制了底层逻辑。这种复制有成本：数据差异，尽管具有相同的逻辑，但实现方式从一层到另一层不同。因此，错误/错误概率更高，您可能会遇到批处理层和速度层的结果不同。

Kappa 数据架构

2014 年，当他还在 LinkedIn 工作时，Jay Kreps 指出了 Lambda 架构的一些缺点。讨论导致大数据社区转向使用更少代码资源的替代方案。

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

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

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

数据重新处理是 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 架构将需要一组机制，例如水印、状态管理、重新处理或回填，来克服这个问题。

探索数据流模型

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

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

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

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

“批处理作为流处理的特例”的概念越来越普遍，Flink 和 Spark 等框架采用了类似的方法。

关于数据架构讨论的另一个方面是速度模型：与物联网 (IoT) 协作的合适设计选择。但我将在单独的讨论中对此进行说明。

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