前言

本文隶属于专栏《大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见大数据理论体系

---

姊妹篇

《分布式数据模型详解：OldSQL =＞ NoSQL =＞ NewSQL》

《分布式计算模型详解：MapReduce、数据流、P2P、RPC、Agent》

《大数据存储架构详解：数据仓库、数据集市、数据湖、数据网格、湖仓一体》

《大数据处理架构详解：Lambda架构、Kappa架构、流批一体、Dataflow模型、实时数仓》

《实时数仓详解》

---

思维导图

---

Lambda 架构

Lambda 的由来

我们通常认为这个希腊字母与这一模式相关联是因为数据来自两个地方。

批量数据和快速的流式数据代表Lambda符号的弯曲部分，然后通过服务层(线段与曲线部分合并)合并，如上图所示。

WHAT

Lambda架构（Lambda Architecture）是由Twitter工程师南森·马茨（Nathan Marz）提出的大数据处理架构。

它的目标是构建一个通用的、健壮的大数据系统，能够同时满足实时查询和历史数据批处理的需求。

随着大数据的兴起，越来越多的公司开始面临海量数据的处理问题。传统的批处理系统无法满足实时数据处理的需求，而简单的流式处理系统又无法进行复杂的历史数据分析。这就需要一种混合架构，能够兼顾实时性和复杂分析。Lambda架构应运而生。

关于 Lambda 架构的详情请参考我的博客——《什么是Lambda架构？》

组成

Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。

在 Lambda 架构中，每层都有自己所肩负的任务。

批处理层

批处理层存储管理主数据集（不可变的数据集）和预先批处理计算好的视图。

批处理层使用可处理大量数据的分布式处理系统预先计算结果。

它通过处理所有的已有历史数据来实现数据的准确性。

这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。

输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。

速度处理层

速度处理层会实时处理新来的大数据。

速度层通过提供最新数据的实时视图来最小化延迟。

速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。

而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。

本质上，速度层弥补了批处理层所导致的数据视图滞后。

比如说，批处理层的每个任务都需要 1 个小时才能完成，而在这 1 个小时里，我们是无法获取批处理层中最新任务给出的数据视图的。

而速度层因为能够实时处理数据给出结果，就弥补了这 1 个小时的滞后。

服务层

所有在批处理层和速度层处理完的结果都输出存储在服务层中，服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。

---

Kappa 架构

Kappa架构是对Lambda架构的改进和优化，由Jay Kreps于2014年首次提出。

随着流式计算系统的发展，Lambda架构存在的一些问题逐渐显现出来：

1. 系统复杂度高：需要同时开发和维护批处理系统和流式系统。
2. 通过日志重播实现低延迟查询，会导致数据冗余。
3. 实时视图和批处理视图存在延迟不一致的问题。

为了解决这些问题，Jay Kreps提出了Kappa架构。Kappa架构去除了Lambda架构的批处理层，直接通过流式处理系统实现整个流程。

关于 Kappa 架构的详情请参考我的博客——《什么是Kappa架构？》

组成

Kappa架构主要包含两个层:

1. 流式处理层：通过流式处理系统接收所有数据，并进行实时计算，更新存储中的结果视图。
2. 服务层：对外提供查询服务，直接基于流式处理层更新的结果视图进行查询返回。

Kappa架构减少了系统复杂度，避免了数据冗余和数据不一致的问题。但需要流式处理系统能够保证Exactly-once语义，以保证流式计算的正确性。而且，去除批处理系统后，对历史数据的复杂计算会更加困难。

以 Apache Kafka 为例来讲述整个Kappa架构的过程

1. 部署 Apache Kafka，并设置数据日志的保留期（Retention Period）。这里的保留期指的是你希望能够重新处理的历史数据的时间区间。例如，如果你希望重新处理最多一年的历史数据，那就可以把 Apache Kafka 中的保留期设置为 365 天。如果你希望能够处理所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久（Forever）”。
2. 如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。我们需要做的就是重新启动一个 Apache Kafka 作业实例（Instance）。这个作业实例将重头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中。我们知道 Apache Kafka 的底层是使用 Log Offset 来判断现在已经处理到哪个数据块了，所以只需要将 Log Offset 设置为 0，新的作业实例就会重头开始处理历史数据。
3. 当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。
4. 停止旧版本的作业实例，并删除旧的数据视图。

与 Lambda 架构不同的是，Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层。 你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。

当然了，也可以在上面讲到的步骤中做一些优化。 例如不执行第 4 步，也就是不删除旧的数据视图。这样的好处是当你发现代码逻辑出错时可以及时回滚（Roll Back）到上一个版本的数据视图中去。又或者是你想在服务层提供 A/B 测试，保留多个数据视图版本将有助于你进行 A/B 测试。

---

Lambda 架构 vs Kappa 架构

Lambda架构和Kappa架构的区别可以通过下表进行对比说明:

对比项	Lambda架构	Kappa架构
组成	批处理层 速度层 服务层	流式处理层 服务层
数据处理方式	批处理系统处理历史数据 流式系统处理实时数据	仅用流式系统处理全部数据
系统复杂度	较高，需要开发和维护两个系统	较低，只需要一个流式系统
延迟一致性	存在，实时视图和批处理视图有延迟差异	更好，没有批处理系统
数据冗余	存在，需要重播日志到实时系统	较少，无需重播日志
历史数据处理	批处理系统可进行复杂历史分析	相对复杂，只有流式系统

总结来说:

Lambda架构通过批处理层和速度层的组合，兼顾了低延迟和复杂分析，但系统较复杂，存在数据冗余和延迟不一致问题。

Kappa架构只通过流式系统实现所有处理，简化了架构，但历史数据分析相对复杂，需要流式系统保证精确一次语义。

两者都有各自的优缺点，需要根据具体场景进行技术选型和设计权衡。

---

Kappa 架构变种

Kappa-S

Kappa-S架构是在Kappa架构的基础上进行的优化和改进。

Kappa架构通过单个流式处理系统实现低延迟的实时计算以及历史数据的处理。

但原始的Kappa架构依然存在一些问题:

1. 历史数据的处理还是相对复杂，不如Lambda架构中的批处理系统。
2. 单个流式系统需要承担全部数据的处理，面临较大的压力。
3. 流式系统需要保证精确一次语义，实现较为复杂。

为了解决这些问题，Jay Kreps等人提出了Kappa-S架构。该架构在Kappa架构的基础上，引入了Stream-Serving层。

Kappa-S架构包含以下组件:

1. Stream层:实时流式处理层。
2. Serving层:查询服务层。
3. Stream-Serving层:用来预计算并服务历史数据的查询，减轻Stream负载。

通过引入Stream-Serving层针对历史数据进行预计算，Kappa-S架构减轻了流式处理的压力，使历史数据的查询和分析更加简单，同时也避免了流式系统需要提供精确一次语义的复杂性。可以看作是Kappa架构和Lambda架构的折中方案。

Kappa-Lambda

Kappa-Lambda架构是在Kappa架构的基础上，引入了Lambda架构中的批处理层组件，形成的一种混合架构。

Kappa-Lambda架构包含以下组件:

• Stream层:实时流式处理层。
• Serving层:查询服务层。
• Batch层:批处理层，用于复杂的历史数据分析。
• Speed层:速度层，用于低延迟的实时计算。

  其工作流程如下:

  1. Stream层接收实时数据，进行实时计算。
  2. Speed层从Stream层获取实时结果，进行低延迟的实时分析。
  3. Serving层查询时，实时部分从Speed层获取，历史部分从Batch层获取。
  4. Batch层定期从Stream层获取数据，进行复杂的历史数据分析和处理。

  可以看出，Kappa-Lambda架构相比Kappa架构，引入了批处理层组件，以便进行复杂的历史数据分析。同时保留了Speed层，进行低延迟的实时计算。

  这种设计兼顾了Kappa架构的简单性，以及Lambda架构在复杂分析上的优势。既能实时处理，也能进行复杂的批处理。

  Kappa-DB

  Kappa-DB架构是在Kappa架构的基础上，通过引入数据库组件，实现流式数据到数据库的持久化保存，形成的一种架构设计。

  

  Kappa-DB架构通常包含以下组件:

  • Stream层:实时流式处理层。
  • Serving层:查询服务层。
  • Database:数据库层，用于存储流式处理的结果数据。

    其工作流程如下:

    • Stream层接收实时数据，进行实时处理。
    • Stream层将处理结果写入数据库进行持久化存储。
    • Serving层接收查询请求，从数据库中读取数据，进行计算后返回结果。
    • 定期进行归档或聚合，避免数据库数据过多。

      引入数据库组件的优点包括:

      • 通过数据库持久化存储，避免数据丢失。
      • 简化历史数据查询，数据库可以进行索引优化。
      • 可以通过归档降低存储成本。
      • 可以重用数据库的计算能力，减少流计算开销。

        需要注意数据库写入成为系统瓶颈的问题，通常要控制写入数据库的频率，进行归档优化等。

        总体上，Kappa-DB架构通过融合流式处理和数据库，实现了数据的持久化存储，同时也继承了Kappa架构的优点。

        Kappa 系列架构对比

        架构类型	组成	优点	缺点
        Kappa	流式处理层 服务层	简单，一致性好	历史处理复杂
        Kappa-S	流式处理层 服务层 预计算层	减轻流量压力 历史处理简单	额外一层复杂度
        Kappa-Lambda	流式处理层 服务层 速度层 批处理层	兼顾实时和批处理	架构比较复杂
        Kappa-DB	流式处理层 服务层 数据库层	数据持久化 利用DB计算	DB成为瓶颈

        综合来看:

        • Kappa架构简单但历史处理复杂
        • Kappa-S通过预计算层减轻实时流量压力，但增加了系统复杂度
        • Kappa-Lambda引入批处理能力，但架构非常复杂
        • Kappa-DB使用数据库实现持久化，但可能面临DB瓶颈

          需要根据具体业务需求，平衡实时处理、历史处理、一致性、范畴等方面的需求，选择适合的架构。

          ---

          流批一体

          

          流批一体(Unified Batch and Streaming Processing)是指将流式处理和批处理统一在一个运行时框架中，进行一体化的处理。

          在流批一体架构中，实时数据流和历史数据批量处理可以使用同一组数据处理工具和技术，例如Apache Spark、Apache Flink等。流批一体架构可以将实时数据和历史数据进行统一的处理和分析，以简化数据处理的复杂性和提高数据处理的效率。

          在流批一体架构中，实时数据流和历史数据批量处理可以使用同一套数据处理代码。这意味着，数据处理人员可以使用同一种编程语言、框架和工具来处理实时数据和历史数据。这样可以减少数据处理人员的学习和使用成本，并提高数据处理的效率和精度。

          流批一体架构还可以将实时数据和历史数据存储在同一套数据存储系统中，例如Apache HBase、Apache Cassandra等。这样可以简化数据存储的管理和维护，并提高数据的可用性和可靠性。

          总之，流批一体是一种将流数据处理和批数据处理整合在一起的数据处理架构，它可以简化数据处理的复杂性和提高数据处理的效率。流批一体架构可以在实时数据处理和历史数据批量处理之间实现无缝切换，以满足不同的数据处理需求。

          诞生背景

          流批一体的诞生主要有以下背景:

          1. Lambda架构的复杂性问题：Lambda架构需要同时开发和维护批处理系统和流式处理系统，系统复杂，开发和运维困难。
          2. 实时计算和历史计算的需求融合：越来越多的应用同时需要实时数据处理和历史数据分析，需要一个统一的框架。
          3. 流式处理系统的发展成熟：流式处理系统的计算模型和性能已经发展成熟，可以用于替代传统的批处理任务。
          4. 微批流式处理技术的出现：Spark Streaming等系统采用微批流式处理，简化了流式处理的事件时间管理。
          5. 云原生技术的兴起：Kubernetes等技术为流批一体提供了更好的资源调度和技术支撑。

          综上，流批一体可以看作是对Lambda架构的简化，也是实时处理和批处理融合的产物，以应对实时数据和历史数据双需求的场景。

          ---

          Dataflow 模型

          DataFlow 模型是一种用于描述数据处理流程的计算模型，它描述了数据从源头到目的地的流动过程，并指定了数据处理的方式和顺序。

          DataFlow 模型常用于并行计算和数据流处理领域，例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。

          在 DataFlow 模型中，数据被视为流动的实体，数据处理被视为一系列的数据转换操作。数据可以从一个或多个输入源中流入数据处理系统，经过一系列的处理操作，最终输出到一个或多个输出目的地中。在数据处理的过程中，数据可以被分割成多个数据块，这些数据块可以并行处理，以提高数据处理的效率。

          DataFlow 模型中的数据处理操作通常被描述为有向图中的节点，数据流动则被描述为有向边。每个节点可以执行一些特定的数据处理操作，例如数据过滤、数据转换、数据聚合等。节点之间的边表示数据的流动方向和数据处理顺序。在 DataFlow 模型中，数据处理操作可以被组合成复杂的数据处理流程，以实现不同的数据处理需求。

          总之，DataFlow 模型是一种用于描述数据处理流程的计算模型，它描述了数据从源头到目的地的流动过程，并指定了数据处理的方式和顺序。DataFlow 模型常用于并行计算和数据流处理领域，例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。

          关于 Dataflow 模型的更多细节请参考我的博客——《DataFlow 模型是什么？》

          诞生背景

          Dataflow模型的主要诞生背景:

          1. 大数据时代的数据规模爆炸，需要并行计算能力
          2. 流式计算和批处理的需求融合
          3. MapReduce模型的局限性：MapReduce模型对迭代计算和DAG支持不友好，而Dataflow模型通过Operator图更适合表达复杂的数据处理流程。
          4. 分布式资源管理与集群调度技术的进步：YARN、Mesos、Kubernetes等技术为Dataflow模型提供了更好的运行时支撑。
          5. 内存计算的发展：Spark等内存计算框架更适合Dataflow模型。

          综上，Dataflow模型是对MapReduce模型的重要发展和延伸，可以更好地处理迭代、流式、DAG等复杂数据处理任务，在大数据时代得到广泛应用。

          关于 MapReduce 模型请参考我的博客——《MapReduce 编程模型到底是怎样的？》

          Dataflow 模型全流程

          

          DataFlow 模型的全流程可以分为以下几个步骤：

          1. 数据源输入：数据源可以是各种类型的数据，例如文件、数据库、消息队列等。在 DataFlow 模型中，数据源被视为数据处理流程的起点，数据从数据源中流入数据处理系统。
          2. 数据切割：在 DataFlow 模型中，数据可以被分割成多个数据块，这些数据块可以并行处理，以提高数据处理的效率。数据切割可以根据数据的大小、时间戳、键值等方式进行，以便更好地实现数据并行处理。
          3. 数据转换：在 DataFlow 模型中，数据可以经过一系列的数据转换操作，例如数据清洗、数据过滤、数据聚合等。数据转换操作被描述为有向图中的节点，每个节点可以执行一些特定的数据处理操作，节点之间的边表示数据的流动方向和数据处理顺序。
          4. 数据聚合：在 DataFlow 模型中，数据可以经过多个数据转换操作后被聚合起来，以便更好地实现数据分析和挖掘。
          5. 数据输出：在 DataFlow 模型中，数据输出可以是各种类型的数据目的地，例如文件、数据库、消息队列等。数据输出被视为数据处理流程的终点，数据从数据处理系统中输出到数据目的地中。

          在 DataFlow 模型中，数据处理操作可以被组合成复杂的数据处理流程，以实现不同的数据处理需求。数据处理流程可以使用各种数据处理框架和工具来实现，例如 Apache Flink、Apache Beam、Apache Kafka 等。

          Dataflow 模型怎样保证数据的准确性和一致性

          DataFlow 模型可以通过以下方式来保证数据的准确性和一致性：

          1. 数据校验：在数据流入数据处理系统之前，可以进行数据校验，例如数据格式、数据类型、数据范围等。这可以保证数据的准确性和完整性。
          2. 数据清洗：在数据处理过程中，可以进行数据清洗，例如去除重复数据、填充缺失数据等。这可以保证数据的一致性和准确性。
          3. 事务处理：在数据处理过程中，可以使用事务机制来确保数据的一致性。例如，如果一个节点的数据处理失败，整个数据处理流程可以回滚到之前的状态，以保证数据的一致性。
          4. 数据分区：在数据处理过程中，可以将数据分成多个数据块，每个数据块可以并行处理。这可以提高数据处理的效率，同时也可以避免数据竞争和数据冲突，以保证数据的一致性。
          5. 数据重试：在数据处理过程中，如果某个节点处理失败，可以进行数据重试，直到数据处理成功。这可以保证数据的完整性和准确性。

          ---

          实时数仓

          实时数仓是一种现代化的数据仓库，具有大数据规模的小数据语义和性能。它可以处理实时数据、最新数据和历史数据，并且能够跨数据域进行相关性分析。实时数仓具有更快的数据到达和查询速度，可以在集成且安全的平台上完成所有功能。

          实时数仓的优势包括更快的决策、数据民主化、个性化的客户体验、提高业务敏捷性和解锁新的业务用例。然而，实时数仓也面临着ETL性能和复杂实时计算场景等挑战。

          典型的实时数仓架构包括数据收集层、数据存储层、实时计算层和实时应用层。数据收集层负责接收和传输数据，数据存储层用于实时数据存储，实时计算层用于实时计算和分析，实时应用层用于数据分析和挖掘。

          实时数仓可以应用于实时OLAP分析、实时数据看板、实时业务监控和实时数据接口服务等场景。其技术实现通常包括消息总线、实时存储、流处理和分析以及应用层。

          常用的实时数仓技术包括Apache Kafka、Apache Druid、Apache Spark、Hadoop、TiDB等，具体选择取决于需求和偏好。

          关于实时数仓的更多细节请参考我的博客——《实时数仓详解》

          诞生背景

          实时数仓的主要诞生背景有:

          1. 对实时数据分析需求的增长：越来越多的企业希望能够立即分析操作数据，以便及时做出决策。
          2. 传统数仓延迟大的问题：传统的数仓以批量方式定期更新，无法满足对实时数据的分析需要。
          3. 流式计算技术的发展：大数据技术使得流式数据的采集、传输和计算成为可能。
          4. 内存计算的进步：Spark等内存计算技术使得内存级的交互式分析成为可能。
          5. 对用户体验的提高要求：用户希望立即获取分析见解，不能等待传统数仓的延迟。
          6. 云计算技术的进步：云计算提供了实时数仓弹性扩展的能力。

          架构

          实时数仓通常具有四个组件：数据收集层、数据存储层、实时计算层和实时应用层。这些组件协同工作，以便在事件发生后立即或短时间内支持事件数据的处理和分析。所有数据处理阶段（数据摄取、丰富、分析、基于 AI/ML 的分析）都是连续的，具有最小延迟，并且能够实现实时报告和即席分析。

          一个比较典型的实时数仓架构如下所示：

          

          • 数据收集层：第三方服务和协同系统通过 Apache Kafka/Apache Nifi 之类的消息总线传输数据到实时数仓；第三方数据源通过调用实时数仓的 API；物联网系统通过直接连接并推送数据的方法传输数据
          • 数据存储层：使用 Apache Kudu/Apache Druid/Amazon Redshift 来进行实时数据存储
          • 实时计算层：使用 Apache Spark/Amazon Kinesis/Hadoop 来进行实时计算和分析
          • 实时应用层：使用 AI 和机器学习技术对数据进行分析和挖掘，使用 SQL Server/Oracle BI 来支持查询、报告和即席查询；使用 Apache Impala 来支持实时报告和告警。

            ---

            对比

            架构类型	组成	优点	缺点
            Lambda架构	批处理层 速度层 服务层	兼顾低延迟和复杂分析	系统复杂,数据冗余
            Kappa架构	流式处理层 服务层	系统简单,一致性好	历史处理相对复杂
            流批一体	统一运行时框架	处理简化,效率高	实时性打折扣
            Dataflow模型	数据源、转换操作、数据汇聚	灵活性强,可扩展性好	需要解决一致性等问题
            实时数仓	收集层 存储层 计算层 应用层	实时分析,低延迟	基础设施要求高

            ---

            总结

            本文详细介绍了几种主要的大数据处理架构:

            • Lambda架构：组合批处理层和速度层，兼顾低延迟和复杂分析，但系统较复杂，存在数据冗余和延迟不一致问题。Lambda架构的批处理层可以基于Hadoop、Spark等技术来实现，速度层可以基于Storm、Flink等流式处理系统来实现。服务层需要实现查询接口，可以使用REST API。Lambda架构适合大数据场景，但维护批处理层和速度层的重复开发较为麻烦。
            • Kappa架构：仅通过流式处理实现所有处理，简化了架构，但历史数据分析相对复杂。Kappa架构还有几种变种，如Kappa-S、Kappa-Lambda、Kappa-DB。Kappa架构中的流式处理层可以基于Flink、Spark Streaming等来实现，需要实现Exactly-once语义。服务层同样需要查询接口。Kappa架构简单高效，但对实时流有较高要求，历史数据处理不如Lambda架构方便。
            • 流批一体：将流式处理和批处理统一在一个运行时框架中，可以简化处理，提高效率。流批一体需要统一运行时框架，如Flink、Spark等，可以通过DataStream和DataSet在流式处理和批处理之间无缝切换。计算模型也需要统一，如Dataflow模型。流批一体简化系统，但实时性不如纯流式处理。
            • Dataflow模型：将数据处理视为数据流经转换操作的流程，可以表达复杂的数据处理流程。Dataflow模型通常用有向图表达，并基于并行运行时框架实现，如Flink。需要解决数据一致性、容错等问题。Dataflow模型可以灵活表示复杂处理流程。
            • 实时数仓：通过流式处理实现对实时数据的快速存储和计算分析，满足了对实时分析的需求。实时数仓中的消息总线可以用Kafka实现，存储系统可以使用HBase、Druid等，计算使用Spark Streaming、Flink。实时数仓可以快速分析数据并实时更新，但对基础设施要求较高。

              总的来说，大数据处理架构的发展趋势是实时性增强、处理统一简化、满足复杂分析需求。需要根据具体业务场景需求选择合适的架构方案。未来可能是基于流式处理的架构为主，同时引入批处理能力进行复杂分析。

               
               优化公司网站  作者自己建立的网站  山西网页制作  微信网站开发公司  西宁到青海湖怎么坐车  六安做网站公司