19. 大数据系统架构设计理论与实践

发表于 分类于

1 传统数据处理系统存在的问题

数据量从 MB、GB 增长到 TB、PB 级别，数据管理系统和数据仓库系统面临挑战。

系统架构问题

  • 传统数据库系统无法及时响应用户请求，导致超时错误。
  • 通过在 Web 服务器和数据库中间加入异步处理队列缓解压力。

数据库过载

  • 数据库分区（Partitioning）和重分区（Resharding）增加复杂性，难以扩展。
  • 系统缺乏对人工错误的工程设计，导致性能瓶颈。

读写分离与分库分表

  • 读写分离技术（Master-Slave）和分库分表技术用于提升性能。
  • 新技术如 Kafka、Storm、Spark 等成为流行语，用于处理大数据。

大数据平台

  • 大数据平台需要了解数据存储位置、格式和组织结构。
  • 现代商业要求快速决策和高价值数据。

新技术应用

  • 基于 Hadoop 的 Map/Reduce 管道用于临时查询。
  • 新技术如 Amazon Redshift 提供了数据仓库技术二进制格式。

总结

  • 传统数据处理方式存在性能瓶颈，需要新技术和架构来处理海量数据。
  • 大数据系统设计理念旨在解决处理海量数据时的问题，提高系统性能和稳定性。

2 大数据处理系统架构分析

2.1 大数据处理系统面临挑战

  1. 如何利用信息技术等手段处理非结构化和半结构化数据
    • 非结构化数据：占比约 85%，处理难度大。
    • 不确定性：数据高维、多变、强随机性。
    • 需要多学科交叉研究，探索数据特征和建模方法。
  2. 如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模
    • 研究大数据的复杂性和不确定性，发展新的建模方法。
  3. 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响
    • 研究数据异构性对知识发现和管理决策的影响，适应大数据环境。

2.2 大数据处理系统架构特征

  1. 鲁棒性和容错性 (Robust and Fault-tolerant)
    • 系统需要健壮、行为正确，即使遇到机器错误。
    • 系统必须对有 Bug 的程序写入的错误数据有足够的适应能力。
  2. 低延迟读取和更新能力 (Low Latency Reads and Updates)
    • 系统应在保证鲁棒性的前提下实现低延迟。
  3. 横向扩容 (Scalable)
    • 当数据量/负载增大时，可扩展性的系统通过增加更多的机器资源来维持性能。
    • 通常采用 scale out (通过增加机器的个数) 而不是 scale up(通过增强机器的性能)。
  4. 通用性 (General)
    • 系统需支持绝大多数应用程序，包括金融、社交网络、电子商务数据分析等。
  5. 延展性 (Extensible)
    • 系统需能将新功能添加到系统中，且具备大规模迁移能力。
  6. 即席查询能力 (Allows Ad Hoc Queries)
    • 用户可按要求进行即席查询，这使用户可以通过系统多样化数据处理，产生更高的应用价值。
  7. 最少维护能力 (Minimal Maintenance)
    • 系统需在大多数时间下保持平稳运行，减少系统维护次数。
  8. 可调试性 (Debuggable)
    • 系统在运行中产生的每一个值，需要有可用途径进行追踪。

3 Lambda 架构

3.1 Lambda 架构对大数据处理系统的理解

Lambda 架构由 Nathan Marz 提出，设计目的是提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展等。它整合离线计算与实时计算，融合不可变性、读写分离和复杂性隔离等原则，可集成 Hadoop、Kafka、Spark、Storm 等各类大数据组件。Lambda 是用于同时处理离线和实时数据的，可容错的、可扩展的分布式系统。它具备强鲁棒性，提供低延迟和持续更新。

3.2 Lambda 架构应用场景

3.2.1 机器学习中的 Lambda 架构

在机器学习领域，数据量是多多益善的。机器学习可以受益于由 Lambda 架构建的数据系统、所处理的各类数据。据此，机器学习算法可以提出各种问题，并逐渐对输入到系统中的数据进行模式识别。

3.2.2 物联网的 Lambda 架构

物联网设备是适合作为大数据源的绝佳示例。物联网设备产生的海量数据，会被实时馈入 Lambda 体系架构的批处理层和速度层，进行后续处理。

3.2.3 流处理和 Lambda 架构挑战

速度层也被称为“流处理层”。其目的是提供最新数据的低延迟实时视图。Lambda 体系架构在其原始理论中，提到了最终精度（eventual accuracy）的概念。它是指批处理层更关注精确计算，而速度层则关注近似计算。

3.3 Lambda 架构介绍

Lambda 架构可分解为三层，即批处理层、加速层和查询层。

3.3.1 批处理层 (Batch Layer)

  • 处理的是全体数据集
  • 存储数据集，生成 Batch View
  • 负责管理主数据集，数据是原始的、不变的、真实的
  • 可以很好地处理离线数据，构建查询视图
  • 预先生成数据集上计算并保存查询函数的结果，查询时直接返回结果。

3.3.2 加速层 (Speed Layer)

  • 处理最近的增量数据流，生成 Real-time View
  • 为了效率，接收到新数据时不断更新 Real-time View
  • 与 Batch Layer 相比，Speed Layer 处理的是最近的增量数据流
  • 快速进行即席查询，存储实时视图并处理传入的数据流，以便更新这些视图。
  • 处理最近的增量数据流，与 Batch Layer 互补。

3.3.3 服务层 (Serving Layer)

  • 用于响应用户的查询请求
  • 合并 Batch View 和 Real-time View 中的结果数据集到最终的数据集。
  • 必须满足以下要求：可伸缩性、容错能力、最小维护能力、可调试性。

3.4 Lambda 架构的实现

一般在 Lambda 架构的实现中，Hadoop (HDFS) 用于存储主数据集，Spark (或 Storm) 构建加速层 (Speed Layer)，HBase (或 Cassandra) 作为服务层，Hive 创建可查询视图。

技术选型

  • Kafka：分布式发布订阅消息系统，用于处理实时数据流。
  • Spark：快速通用的计算引擎，适合大规模数据处理。
  • Hadoop：分布式文件系统，适合大规模数据存储。
  • HBase：高可靠性、高性能、可伸缩的分布式存储系统。
  • Hive：数据仓库工具，用于查询和分析存储在 Hadoop 文件系统中的数据。

3.5 Lambda 架构优缺点

  • 优点
    1. 容错性好：提供更友好的容错能力，一旦发生错误，可以修复算法或从头开始重新计算视图。
    2. 查询灵活度高：批处理层允许针对任何数据进行临时查询。
    3. 易伸缩：所有批处理层、加速层和服务层都很容易扩展。
    4. 易扩展：添加视图是容易的，只需给主数据集添加几个新的函数。
  • 缺点
    1. 全场景覆盖带来的编码开销。
    2. 针对具体场景重新离线训练一遍益处不大。
    3. 重新训练和迁移成本很高。

3.6 Lambda 与其他架构模式对比

Lambda 架构的诞生离不开很多现存设计思想和架构的铺垫，如事件溯源 (Event Sourcing) 架构和命令查询分离 (CQRS) 架构。Lambda 架构的设计思想和这两者有一定程度的相似。

3.6.1 事件溯源 (Event Sourcing) 与 Lambda 架构

  • Event Sourcing 本质上是一种数据持久化的方式，其由三个核心观点组成：
    1. 整个系统以事件为驱动，所有业务都由事件驱动来完成。
    2. 事件是核心，系统的数据库以事件为基础，事件要保存在某种存储上。
    3. 业务数据只是一些由事件产生的视图，不一定要保存到数据库中。

3.6.2 CQRS 与 Lambda 架构

  • CQRS 架构分离了对于数据进行的读操作（查询）和写（修改）操作。其将能够改变数据模型状态的命令和对于模型状态的查询操作实现了分离。
  • Lambda 架构中，数据的修改通过批处理和流处理实现，通过写操作将数据转换成查询时所对应的 View。

4 Kappa 架构

4.1 Kappa 架构下对大数据处理系统的理解

为了设计出能满足前述的大数据关键特性的系统，我们需要对数据系统有本质性的理解。数据系统可简单理解为：数据系统 = 数据 + 查询。

4.1.1 数据的特性

  1. When：数据是与时间相关的，数据一定是在某个时间点产生的。
  2. What：数据的本身是不可变的。

4.1.2 数据的存储

  • Lambda 架构中对数据的存储采用的方式是：数据不可变，存储所有数据。
  • 采用不可变方式存储所有的数据的好处：可以简化设计；应对人为和机器的错误。

4.2 Kappa 架构介绍

Kappa 架构由 Jay Kreps 提出，不同于 Lambda 同时计算流计算和批计算并合并视图，Kappa 只会通过流计算一条数据链路计算并产生视图。

Kappa 架构的原理

  • 在 Lambda 的基础上进行了优化，删除了 Batch Layer 的架构，将数据通道以消息队列进行替代。
  • 对于 Kappa 架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次即可。

Kappa 架构的特点

  1. 简化设计：Kappa 架构不是 Lambda 的替代架构，而是其简化版本。
  2. 更擅长流式计算：Kappa 架构更擅长流式计算，直接满足实时计算和历史数据分析查询的场景。

Kappa 架构的实现

  • Kappa 架构通过流计算一条数据链路计算并产生视图，简化了 Lambda 架构中的复杂性。
  • 使用类似 Kafka 的消息队列存储长期日志数据，数据无法压缩，存储成本很大。
  • 绕过方案是使用支持数据分层存储的管理系统（如 Pulsar，支持将历史消息存储到云上存储系统）。

Kappa 架构与 Lambda 架构的区别

  1. 简化版本：Kappa 不是 Lambda 的替代架构，而是其简化版本。
  2. 流式计算：Kappa 更擅长流式计算，适合对历史数据分析查询的场景。

4.3 Kappa 架构的实现

下面以 Apache Kafka 为例来讲述整个全新架构的过程。

  • 部署 Apache Kafka, 并设置数据日志的保留期 (Retention Period)。
  • 如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。
  • 当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。
  • 停止旧版本的作业实例，并删除旧的数据视图。

4.4 Kappa 架构的优缺点

优点

将实时和离线代码统一起来，方便维护而且统一了数据口径的问题，避免了 Lambda架构中与离线数据合并的问题，查询历史数据的时候只需要重放存储的历史数据即可。

缺点

  1. 消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。
  2. 数据丢失：在实时数据处理时，遇到大量不同的实时流进行关联时，依赖实时计算系统的稳定性，可能导致数据丢失。
  3. 维护成本高：双系统的维护成本高且两套代码带来代码难以维护问题。

4.5 Kappa 架构的变形

4.5.1 Kappa+ 架构

Kappa+ 架构是 Uber 提出流式数据处理架构，其核心思想是让流计算框架直接读 HDFS 里的数据仓库数据，并实现实时和历史数据 backfill 计算。

4.5.2 混合分析系统的 Kappa 架构

在基于使用 Kafka +Flink构 建 Kappa 流计算数据架构，针对 Kappa 架构分析能力不足的问题，再利用 Kafka 对接组合 Elastic-Search 实时分析引擎，部分弥补其数据分析能力。

但是 ElasticSearch 也只适合对合理数据量级的热点数据进行索引，无法覆盖所有批处理相关的分析需求，这种混合架构某种意义上属于 Kappa和 Lambda间的折中方案。