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 间的折中方案。

5 Lambda 架构与 Kappa 架构的对比和设计选择

5.1 Lambda 架构和 Kappa 架构的特性对比

Lambda 架构和 Kappa 架构在复杂度、开发维护成本、计算开销、实时性、历史数据处理能力等方面存在差异。

  • 表 19-1 Lambda 架构和 Kappa 架构对比
    • Lambda 架构需要维护两套系统，复杂度高，开发维护成本高，计算开销大，但满足实时性，历史数据处理能力强。
    • Kappa 架构只需要维护一套系统，复杂度低，开发维护成本低，计算开销相对较小，实时性满足，但历史数据处理能力相对较弱。

5.2 Lambda 架构与 Kappa 架构的设计选择

根据两种架构对比分析，将业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能力作为选择考虑因素。

5.2.1 业务需求与技术要求

  • 用户需要根据自己的业务需求来选择架构，如果业务对于 Hadoop、Spark、Storm 等关键技术有强制性依赖，选择 Lambda 架构可能较为合适。

5.2.2 复杂度

如果项目中需要频繁地对算法模型参数进行修改，Lambda 架构需要反复修改两套代码，而 Kappa 架构简单方便。

5.2.3 开发维护成本

Lambda 架构需要有一度的开发维护成本，包括两套系统的开发、部署、测试、维护，适合有足够经济、技术和人力资源的开发者。

5.2.4 历史数据处理能力

有些情况下，项目会频繁接触海量数据集进行分析，比如过去十年内的地区降水数据，这种数据适合批处理系统进行分析，应该选择 Lambda 架构。

6 大数据架构设计案例分析

6.1 Lambda 架构在某网奥运中的大数据应用

6.1.1 系统建设背景

某网作为某电视台在互联网上的大型门户入口，2016年成为里约奥运会中国大陆地区的持权转播商，独家全程直播了里约奥运会全部的赛事。

6.1.2 数据需求与场景

  • 里约奥运期间需要对增量数据在当日概览和赛事回顾两个层面上进行分析。
  • Lambda 架构实时处理层采用增量计算实时数据的方式，可以满足集群规模不变的前提下，秒级分析出当日概览所需的信息。

6.1.3 系统架构

某网采用以 Lambda 架构搭建的大数据平台处理里约奥运会大规模视频和网络观看数据。

某网奥运中的 Lambda 架构: 数据采集层 -> 数据计算层 -> 数据存储层 -> 数据集成层 -> 数据展现层。

6.1.4 应用效果

在数据展现层用户可以通过调用数据计算层的相应接口，简单快速进行计算流程，从而呈现出日概览、赛事回顾等模块的各类信息。

6.2 Lambda 架构在某网广告平台的应用与演进

6.2.1 系统建设背景

某网广告平台依托于某网微商城，帮助商家投放广告。通过该网广告平台，商家可以在腾讯广点通、云堆、小博无线等流量渠道投放广告。

6.2.2 数据需求与场景

  • 大数据处理技术需要解决数据的可伸缩性与复杂性。首先需要很好地处理分区与复制，不会导致错误分区引起查询失败。
  • 某网广告平台展示的数据指标包含两类：曝光类（包括曝光数、点击数、点击单价、花费）、转化类（包括转化下单数、转化下单金额、转化付款数、转化付款金额）。

6.2.3 系统架构

6.2.3.1 第一版架构
  • 第一版采用了典型的 Lambda 架构形式，批处理层每天凌晨将 Kafka 中的浏览、下单消息同步到 HDFS 中，再将 HDFS 中的日志数据解析成 Hive 表，用 Hive SQL/Spark SQL 计算出分区的统计结果 Hive 表，最终将 Hive 表导出到 MySQL 中供服务层读取。
  • 实时处理层是用 Spark Streaming 程序监听 Kafka 中的下单、付款消息，计算出每个追踪链接维度的转化数据，存储在 Redis 中。
6.2.3.2 第二版架构
  • 第二版架构在第一版的基础上做了一些修改。在实时处理层做了一个常驻后台的 Python 脚本，不断调用第三方 API 的小时报表，更新当日的曝光数据表。
  • 批处理层，把转化数据表和曝光数据表导入到 Hive 中，用 Hive SQL 做好 join，将两张表聚合而成的结果表导出到 MySQL，提供给服务层。
6.2.3.3 第三版架构
  • 第三版架构考虑到 MySQL 方便聚合、方便服务层读取的优点，对 Lambda 架构做了一些改动，在数据层面只维护一张 MySQL 数据统计表，每天的离线任务会生成两张 hive 表，分别包含转化数据和曝光数据。这两张 Hive 表分别更新 MySQL 表中的数据。

6.2.4 应用效果

  • 该平台经历了三版的架构演进，历时大半年，最终做到了结合内部、外部两个数据源，可以在多维分析业务实时的数据。
  • 在数据架构的设计中，一开始完全遵照标准的 Lambda 架构设计，实现了当数据来源比较多的时候，标准 Lambda 架构会导致服务层的任务过重，成为性能的瓶颈。

6.3 某证券公司大数据系统

6.3.1 系统建设背景

某证券公司的信息系统每天会产生大量的日志，需要实现监控并将异常信息发送给运维平台告警。

6.3.2 数据需求与场景

实时日志分析平台针对日志数据分析需求重点集中于三大核心功能：日志智能搜索、可视化分析、全息场景监控。

6.3.3 系统架构

实时日志分析平台基于 Kappa 架构，使用统一的数据处理引擎 Flink 可实时处理全部数据，并将其存储到 Elastic-Search 与 OpenTSDB 中。实时处理过程如下：

  1. 日志采集
    • 各应用系统部署采集组件 Filebeat，实时采集日志数据并输出到 Kafka 缓冲。
  2. 日志清洗和解析
    • 基于大数据计算集群的 Flink 计算框架，实时读取 Kafka 中的日志数据进行清洗和解析，提取日志关键内容并转换成指标，以及对指标进行二次加工形成衍生指标。
  3. 日志存储
    • 将解析后的日志数据分别存储于 Elastic-Search 日志库中，各关联日志的指标存储于 OpenTSDB 指标库中，供前端组件搜索与查询。
  4. 日志监控
    • 通过单键的告警消息队列来保持监控消息的有序管理与实时推送。
  5. 日志展现
    • 基于可视化分析和全息场景监控可实时展现各种指标和趋势，并在预警中心查看各类告警的优先级和详细信息，进而结合告警信息关联查询系统日志内容来分析解决问题。

某证券大数据系统架构

  • 展现层：日志智能搜索可视化图表、在线开发、告警中心、配置管理、功能区
  • 逻辑处理层：Filebeat、Kafka、Flink、任务提交、计算集群 CDH
  • 存储计算层：计算集群、日志库 Elastic-Search、指标库 OpenTSDB

6.3.4 应用效果

  • 该平台的数据处理功能均基于 Kappa 架构实时处理框架实现，数据源头是 Filebeat 从各系统中分布式采集的日志，然后再通过 Kafka 由 Flink 实时计算引擎统一处理并输出到 Elastic-Search 与 OpenTSDB 中存储。
  • 平台还支持基于实时日志流形成实时指标，并按照时间维度更新到每日、每周、每月的指标汇总值，或是在 OpenTSDB 中查询指标的历史值。

6.4 某电商智能决策大数据系统

6.4.1 系统建设背景

某电商作为行业的外卖平台，需要根据用户实时的点击、出价以及广告的曝光，计算出合适的出价数据，使得广告主的利益最大化。

6.4.2 数据需求与场景

传统的参数和模型计算均是依赖于人工调参，模型计算也大多采用离线计算的模式。为了提升算法的迭代速度和模型的更新速度，某电商打造了基于 Kappa 架构的智能决策大数据系统。

6.4.3 系统架构

  • 实时智能决策大数据平台基于 Kappa 架构，使用统一的数据处理引擎 Flink 可实时处理流数据，并将其存储到 Hive 与 Tair 中，以供后续决策服务的使用。
  • 实时处理的过程如下：
    1. 数据采集：B 端系统会实时收集用户的点击、下单以及广告的曝光和出价数据并输出到 Kafka 缓存。
    2. 数据的清洗与聚合：基于大数据计算集群 Flink 计算框架，实时读取 Kafka 中的实时流数据，提出需要参与计算的字段，聚合指定时间端的数据并转换成指标。
    3. 数据存储：将 Flink 计算得到的数据存储到 Hive 日志库中，需要参与模型计算计算的字段存储到 Tair 分布式缓存中。

某电商智能决策大数据系统架构

  • 应用层：结果本地存储、决策结果展示、参数更新、配置分发、模型验证
  • 逻辑处理层：B 端实时流数据、Kafka 缓存、参数过滤、数据获取、脚本解析、任务提交、基于 Flink
  • 存储计算层：计算集群 CDH、日志库 Hive、实时计算数据 Tair

6.4.4 应用效果

  • 计算结果的准确性方面，应用基于 Kappa 架构的实时处理框架，能够将 B 端产生的实时流数据用于决策服务中，极大地提升了参数和模型计算的准确性。
  • 业务方系统响应的及时性，由于参数计算在服务端完成，服务端计算完成后会通过 Zookeeper 通知客户端，客户端会拉取最新参数存储到本地，业务方系统中会引入客户端，因此当业务方系统使用最新的参数，只需从本地获取即可，不会产生任何网络延迟，响应速度快。