25、实时Hadoop应用架构：从Lambda到未来-优快云博客

本文链接：https://blog.youkuaiyun.com/a3b4c5/article/details/149550883

实时Hadoop应用架构：从Lambda到未来

1. 解决实时与批量处理问题的架构探索

在处理实时和批量数据时，存在诸多挑战。一种解决方案是使用一种能抽象实时和批量框架的语言或框架，这样代码就能按需用于流处理或MapReduce。Kappa架构和Butterfly架构就是为克服这些问题而提出的。

Lambda架构有其优缺点，并非适用于所有类型的数据或业务目标。它管理和调优批量与速度层两个操作系统的运营负担很高，添加新特性时也受限，还可能无法使用一些流行的Hadoop组件和工具。

2. Kappa架构详解

2014年夏天，Jay Kreps提出了Kappa架构。其概念简单，使用流处理引擎（如Spark、Kafka等）保留可能需要重新处理的数据的完整日志。若需重新处理，启动流处理作业的第二个实例，从保留数据的开头开始处理，并将输出写入新的目的地。处理完成后，将应用切换到从新的输出目的地读取数据，然后停止旧作业并删除旧输出目的地。

Kappa架构有两层：流处理层和服务层。流处理层负责执行流处理作业，通常一个流处理作业处理实时数据，若代码更改需要重新处理数据，则额外执行修改后的流处理作业。服务层用于查询结果。

实现Kappa可使用多种开源技术：
- 数据摄取：可使用像Apache Kafka这样的发布 - 订阅消息系统。
- 持久存储：可使用HDFS。
- 流处理层实现：可使用低延迟系统，如Apache Storm、Samza或Spark Streaming。

选择架构时，若实时数据和历史数据应用的算法相同，适合使用Kappa架构；若实时和批量算法的预期输出不同，则需使用Lambda架构。例如，批量层需处理十亿条记录并计算每日和每周平均值时，生成批量模型耗时耗资源，实时视图需使用近似模型，此时不能合并批量和实时层的处理，只能使用Lambda架构。不过，Kappa架构也并非适用于所有情况，还有其他替代架构，如Zeta架构或Iot - a。

3. 数据架构的历史演变

在关系数据库流行之前，使用多种数据模型，其中基于大型机的系统广泛使用层次和导航数据系统。随着关系模型的提出，它在银行、保险和金融服务等行业的大多数数据应用中变得非常流行，关系数据库系统成为各种垂直领域的默认后端数据系统。

客户端 - 服务器系统的出现使得前期数据建模、SQL、正式数据操作语义（ACID）变得重要，带来了查询并发改进、基于规则和基于成本的查询优化以及标准访问方法（ODBC和JDBC），还催生了大量用于构建数据库应用和数据可视化的可视化工具。

操作数据库的访问模式主要是对单条或少量记录的CRUD操作，为保证一致性引入了事务概念，这类系统被称为OLTP系统，性能以每秒事务数衡量。而商业智能（BI）和报告工作负载的访问模式不同，主要是对大量历史数据的只读查询。由于操作数据系统无法同时满足低延迟事务和高吞吐量分析的需求，专门的OLAP系统应运而生。

OLAP系统通常是基于无共享分布式架构的MPP系统，这在组织中形成了结构化事务和结构化分析两个数据孤岛。为整合多个事务数据存储的数据到分析数据系统，出现了周期性ETL的概念。

半结构化数据（如服务器日志）和非结构化数据（如客户交互中的自然语言通信）要么被丢弃，要么为合规性原因存于存档存储中。集中式文件系统成为半结构化和非结构化历史数据集的流行存储选择。

Apache Hadoop通过在通用硬件上提供HDFS并结合MapReduce分布式数据处理范式，解决了半结构化和非结构化数据分析工作负载问题。随着Hadoop生态系统的扩展，出现了Pig、Hive等工具，以及使用HDFS进行持久存储的NoSQL存储HBase。后来，计算资源管理能力与批量编程模型分离，使得各种数据处理框架可以在HDFS存储的数据上运行，形成了数据湖的概念。

然而，Hadoop的核心组件HDFS并非为交互式、流式和事务性工作负载设计，成为实现统一分析平台的障碍。因此，提出了Lambda和Kappa等架构，但实现起来仍有困难。

4. 不同存储类型的性能与成本对比

存储类型	每GB近似成本	I/O OPS/秒	吞吐量	每十亿IOPS的每GB成本	每GB/s吞吐量的每GB成本
DRAM	$6	2000万	50 GB/s	$300	$0.12
SCM（预计）	$2	1000万	10 GB/s	$200	$0.20
NAND Flash	$0.50	100万	1 GB/s	$500	$0.50
HDD	$0.03	100	100 MB/s	$30000	$0.30

从表中可以看出，当前DDR4 DRAM对于吞吐量导向的工作负载最具成本效益，新兴的存储类内存（SCM）对于随机访问工作负载最具成本效益。但构建系统时，不仅要考虑成本，还要考虑存储密度和功耗。SCM具有更高的密度和更低的功耗，有潜力成为快速统一数据平台的主要存储层。

5. Butterfly架构介绍

Butterfly架构旨在将批量、服务和速度层的数据处理任务统一在一个平台上。为此，需要用新的、更通用的抽象来处理数据，它将数据组织为三种类型的抽象：
- 数据集（Datasets） ：最灵活的抽象，是任意记录的分区集合，不施加结构，记录内容的解释由处理框架借助系统目录完成，相当于“读时模式”数据。系统目录存储每个数据集的信息及多个数据集之间的关系，每个数据集有唯一标识符，目录是逻辑上的RDF三元组集合。数据集可存储在多个存储系统上，序列化和反序列化格式由用户或操作员定义。
- 数据帧（Dataframes） ：结构化数据集，按用户指定的分区键分区，可分为可变和不可变的。不可变数据帧创建后不能修改，适合分析工作负载；可变数据帧的单个记录可插入、更新或删除，用于事务性CRUD工作负载。
- 事件流（Event streams） ：无界数据帧，记录（事件）中至少有一个字段大多单调递增，通常是时间戳或序列号。可指定窗口大小，窗口内事件可能乱序到达，但窗口间序列号或时间戳严格单调递增。

Butterfly架构的主要特点是在这些数据抽象之上的计算范式具有灵活性，多种计算引擎，如MPP SQL引擎（Apache Impala、Apache Drill或Apache HAWQ）、MapReduce、Apache Spark、Apache Flink、Apache Hive或Apache Tez等都可以处理数据集、数据帧和事件流。这些计算步骤可串连形成数据管道，由外部调度器编排，实现Butterfly架构需要资源管理器和数据感知的可插拔资源调度器，Apache YARN和Apache Mesos以及Kubernetes或Apache Myriad等框架可发挥作用。

6. Butterfly架构的存储需求

为有效实现Butterfly架构，需要快速的存储引擎进行数据管道间的数据交换以及流摄取和分析。需要针对不可变和可变数据帧进行优化实现，以支持快速批量查询和快速事务，使多种工作负载能在单个系统中共存。传统基于磁盘的存储系统难以实现这种统一，而NVMe连接的闪存、NVDIMMS和新型持久内存（SCM）提供了高吞吐量扫描导向工作负载和低延迟随机访问工作负载可以共存的完美存储介质。

7. Ampool助力Butterfly架构实现

Ampool的核心产品是一种以内存为中心、分布式、数据感知的对象存储，针对事务和分析工作负载进行了优化：
- 以内存为中心 ：虽然DRAM成本逐年下降，但仍比其他存储介质（如SSD和硬盘驱动器）高。Ampool实现了智能分层，监控数据使用情况，自动将数据在不同存储层之间移动，减少手动操作的繁琐和错误。
- 分布式 ：增加单个系统的DRAM和存储不能按比例提升系统性能，Ampool存储从底层设计为分布式系统，数据在集群中各机器的地址空间中复制以保证高可用性，数据更改通过可扩展消息总线在广域网上传播以实现灾难恢复。
- 对象存储 ：与传统的块存储和文件系统相比，对象存储具有扁平层次结构，访问对象只需桶ID和对象ID，且具有丰富的元数据，可将过滤和内容搜索等操作下推到存储层，减少网络带宽需求和CPU负载，适合新型存储介质。
- 数据感知 ：大多数现有对象存储不能原生解释对象内容，而Ampool对象存储存储了关于对象的大量元数据，如模式、版本、分区键和各种统计信息，可将投影、过滤和聚合等常见操作下推到对象存储，加快分析计算并避免网络瓶颈。

综上所述，在选择数据处理架构时，需要综合考虑数据特点、处理需求、业务目标和可用硬件资源等因素。随着技术的发展，未来可能会出现更多高效、灵活的架构来满足不断变化的需求。

实时Hadoop应用架构：从Lambda到未来

8. 架构选择决策流程

在选择Lambda、Kappa还是Butterfly等架构时，可以参考以下决策流程：

graph TD
    A[开始] --> B{实时和历史数据算法是否相同?}
    B -- 是 --> C{是否需要同时处理批量和实时数据?}
    B -- 否 --> D[选择Lambda架构]
    C -- 是 --> E{是否能统一批量、服务和速度层处理?}
    C -- 否 --> F[选择Kappa架构]
    E -- 是 --> G[选择Butterfly架构]
    E -- 否 --> D

这个流程图可以帮助我们根据具体情况做出合适的架构选择。例如，如果实时和历史数据算法相同，且不需要同时处理批量和实时数据，那么Kappa架构可能是一个不错的选择；如果算法不同，则需要选择Lambda架构；若能统一各层处理，则Butterfly架构更合适。

9. 不同架构的性能对比

从这个表格可以看出，不同架构在实现难度、数据一致性、处理灵活性和存储需求等方面各有优劣。在实际应用中，需要根据具体的业务场景和资源情况进行权衡。

10. 未来数据架构的发展趋势

随着技术的不断发展，未来数据架构将面临更多的挑战和机遇。以下是一些可能的发展趋势：
- 融合多种技术 ：未来的架构可能会融合更多的技术，如人工智能、机器学习、物联网等，以满足更复杂的业务需求。例如，结合人工智能技术可以实现更智能的数据处理和分析。
- 强调实时性 ：随着业务对实时数据的需求不断增加，未来的架构将更加注重实时性，能够更快地处理和响应数据。
- 绿色节能 ：考虑到环保和成本因素，未来的架构将更加注重节能，采用低功耗的硬件和优化的算法。
- 云原生架构 ：云原生技术的发展将使数据架构更加灵活和可扩展，能够更好地适应不同的业务场景。

11. 实际应用案例分析

为了更好地理解这些架构的应用，我们来看一个实际的电商业务案例。
假设一个电商平台需要处理实时订单数据和历史销售数据分析。实时订单数据需要快速处理以更新库存和生成实时报表，而历史销售数据需要进行复杂的分析以支持业务决策。
- 如果选择Lambda架构 ：
- 速度层：使用Kafka和Spark Streaming处理实时订单数据，快速更新库存和生成实时报表。
- 批量层：使用Hadoop和MapReduce处理历史销售数据，进行深入分析。
- 服务层：使用HBase存储处理结果，提供查询服务。
- 操作步骤：首先，订单数据通过Kafka摄入速度层，Spark Streaming实时处理数据并更新库存和报表；同时，数据也会存储到HDFS中，定期由批量层的MapReduce进行处理；最后，服务层从HBase中获取数据，提供给用户查询。
- 如果选择Kappa架构 ：
- 流处理层：使用Kafka和Spark Streaming处理所有数据，包括实时订单和历史数据的重新处理。
- 服务层：使用HBase存储处理结果，提供查询服务。
- 操作步骤：订单数据通过Kafka摄入流处理层，Spark Streaming实时处理数据；如果需要重新处理数据，启动新的流处理作业；处理结果存储在HBase中，供用户查询。
- 如果选择Butterfly架构 ：
- 数据抽象：将订单数据组织为数据集、数据帧和事件流。
- 计算引擎：使用Apache Spark和Apache Drill等计算引擎处理数据。
- 存储：使用Ampool进行数据存储和管理。
- 操作步骤：订单数据首先被抽象为相应的数据类型，然后由计算引擎进行处理；处理过程中，Ampool负责数据的存储和交换；最后，用户可以通过服务层查询处理结果。

12. 总结与展望

在当今的数据处理领域，Lambda、Kappa和Butterfly等架构都有其独特的优势和适用场景。我们在选择架构时，需要综合考虑数据特点、处理需求、业务目标和硬件资源等因素。
未来，随着技术的不断进步，数据架构将不断演进和创新。我们需要密切关注技术发展趋势，不断学习和探索新的架构和方法，以应对日益复杂的数据处理挑战。同时，我们也应该注重架构的实际应用，通过实际案例不断优化和改进架构，为业务发展提供更强大的支持。

希望本文能够帮助读者更好地理解不同的数据处理架构，在实际应用中做出更明智的选择。