系统架构设计师 · 第 22 小时

大数据架构设计
理论与实践

— 对应教材第 19 章 · 涉及案例分析题与论文题 —

案例分析 论文题 Lambda Kappa Hadoop / Spark Kafka / Flink

§ 01 传统数据处理系统的问题

传统数据库的数据过载问题

传统应用的数据系统架构设计时,应用直接访问数据库系统。当用户访问量增加时,数据库无法支撑日益增长的用户请求的负载,从而导致数据库服务器无法及时响应用户请求,出现超时错误

常用解决方法(五种)

  1. 增加异步处理队列:通过工作处理层批量处理异步处理队列中的数据修改请求。
  2. 建立数据库水平分区:通常建立 Key 分区,以主键 / 唯一键 Hash 值作为 Key。
  3. 建立数据库分片或重新分片:通常专门编写脚本来自动完成,且要进行充分测试。
  4. 引入读写分离技术:主数据库处理写请求,通过复制机制分发至从数据库。
  5. 引入分库分表技术:按照业务上下文边界拆分数据组织结构,拆分单数据库压力。

大数据的特点

大数据具有体量大、时效性强的特点,并非构造单调,而是类型多样。处理大数据时,传统数据处理系统因数据过载、来源复杂、类型多样等诸多原因性能低下,需要采用以新式计算架构智能算法为代表的新技术。

大数据的应用重在发掘数据间的相关性,而非传统逻辑上的因果关系。因此,大数据的目的和价值就在于发现新的知识,洞悉并进行科学决策

现代大数据处理技术(三类)

  • 基于分布式文件系统 Hadoop
  • 使用 Map/ReduceSpark 数据处理技术
  • 使用 Kafka 数据传输消息队列及 Avro 二进制格式

大数据利用过程

▸ 记忆 大数据的利用过程分为四个阶段:采集 → 清洗 → 统计 → 挖掘

§ 02 大数据处理系统架构分析

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

  1. 如何利用信息技术等手段处理非结构化半结构化数据。
  2. 如何探索大数据复杂性、不确定性特征描述的刻画方法,及大数据的系统建模。
  3. 数据异构性决策异构性的关系,对大数据知识发现与管理决策的影响。

大数据处理系统应具有的属性和特征

▸ 八大特征 鲁棒性和容错性低延迟横向扩展(通过增强机器性能扩展)、通用可扩展即席查询(用户按照自己的要求进行查询)、最少维护可调试

§ 03 典型的大数据架构

Lambda 架构

Lambda 架构是一种用于同时处理离线和实时数据的、可容错的、可扩展的分布式系统。

架构分层(三层)

批处理层 Batch Layer
核心功能:存储主数据集,主数据集数据具有原始、不可变、真实的特征。
工作方式:周期性地将增量数据转储至主数据集,并在主数据集上执行批处理,生成批视图
实现:可使用 Hadoop HDFSHBase 存储主数据集,利用 SparkMapReduce 执行周期批处理,使用 MapReduce 创建批视图。
加速层 Speed Layer
核心功能:处理增量实时数据,生成实时视图,快速执行即席查询。
实现:可使用 Hadoop HDFSHBase 存储实时数据,利用 SparkStorm 实现实时数据处理和实时视图。
服务层 Serving Layer
核心功能:响应用户请求,合并批视图和实时视图中的结果数据集得到最终数据集。
工作流程:接收用户请求 → 通过索引加速访问批视图 → 直接访问实时视图 → 合并两个视图的结果数据集生成最终数据集 → 响应用户请求。
实现:可使用 HBaseCassandra 作为服务层,通过 Hive 创建可查询的视图。

优缺点

▲ 优点
  • 容错性好
  • 查询灵活度高
  • 弹性伸缩
  • 易于扩展
▼ 缺点
  • 编码量大
  • 持续处理成本高
  • 重新部署和迁移成本高
▸ 关联模式 与 Lambda 架构相似的模式有:事件溯源模式命令查询职责分离(CQRS)模式

Kappa 架构

Kappa 架构是在 Lambda 架构的基础上进行了优化,删除了 Batch Layer 的架构,将数据通道以消息队列进行替代。

架构分层(两层)

实时层 Real-time Layer
核心功能:处理输入数据,生成实时视图。
工作方式:采用流式处理引擎逐条处理输入数据,生成实时视图。
实现:采用 Apache Kafka 回放数据,然后采用 FlinkSpark Streaming 进行处理。
服务层 Serving Layer
核心功能:使用实时视图中的结果数据集响应用户请求。
实现:实践中使用数据湖中的存储作为服务层。
▸ 本质 Kappa 架构本质上是通过改进 Lambda 架构中的加速层,使它既能够进行实时数据处理,同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据

优缺点

▲ 优点
  • 将离线和实时处理代码进行了统一
  • 方便维护
▼ 缺点
  • 消息中间件有性能瓶颈
  • 数据关联时处理开销大
  • 抛弃了离线计算的可靠性

Lambda 架构与 Kappa 架构对比

对比维度 Lambda 架构 Kappa 架构
架构分层 批处理层 + 加速层 + 服务层(三层) 实时层 + 服务层(两层)
处理方式 批处理与流处理并行 统一使用流处理
数据通道 主数据集(HDFS / HBase) 消息队列(Kafka)
代码维护 需要维护两套代码(批 + 流) 统一一套流处理代码
历史数据处理 批处理层直接计算 通过 Kafka 回放重新处理
容错性 / 可靠性 高(批处理保证最终一致性) 依赖消息队列,抛弃了离线计算的可靠性
典型实现 Hadoop / Spark / Storm / HBase Kafka / Flink / Spark Streaming
适用场景 对准确性要求高、需要复杂离线分析 对实时性要求高、逻辑相对简单

§ 04 大数据架构的实践

大规模视频网站

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

LAMBDA 视频观看数据处理平台
离线计算部分
用于存储持续增长的批量离线数据,周期性地使用 SparkMap/Reduce 进行批处理,将批处理结果更新到批视图;之后使用 ImpalaHive 建立数据仓库,将结果写入 HDFS 中。
实时计算部分
采用 Spark Streaming,只处理实时增量数据,将处理后的结果更新到实时视图。
合并计算部分
合并批视图和实时视图中的结果,生成最终数据集,将最终数据集写入 HBase 数据库中用于响应用户的查询请求。

广告平台

某网基于 Lambda 架构的广告平台,分为批处理层(Batch Layer)、加速层(Speed Layer)、服务层(Serving Layer)。

LAMBDA 广告平台
批处理层
每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS 中,将 HDFS 中数据解析为 Hive 表,然后使用 HQLSpark SQL 计算分区统计结果 Hive 表,将 Hive 表转储到 MySQL 中作为批视图
加速层
使用 Spark Streaming 实时监听 Kafka 下单、付款等消息,计算每个追踪链接维度的实时数据,将实时计算结果存储在 Redis 中作为实时视图
服务层
采用 Java Web 服务,对外提供 HTTP 接口,Java Web 服务读取 MySQL 批视图表和 Redis 实时视图表。

证券公司智能决策大数据系统

某证券公司智能决策大数据系统是一个基于 Kappa 架构实时日志分析平台

KAPPA 证券实时日志分析平台
日志采集
用统一的数据处理引擎 Filebeat 实时采集日志并推送给 Kafka 缓存。
日志清洗解析
利用基于大数据计算集群的 Flink 计算框架实时读取 Kafka 消息并进行清洗,解析日志文本转换成指标。
日志存储
日志转储到 ElasticSearch 日志库,指标转储到 OpenTSDB 指标库。
日志监控
单独设置告警消息队列,保持监控消息时序管理和实时推送。

电商智能决策大数据系统

该智能决策大数据平台基于 Kappa 架构,使用统一的数据处理引擎 Flink 可实时处理流数据,并将其存储到数据仓库工具 Hive 与分布式缓存 Tair 中,以供后续决策服务的使用。

KAPPA 电商智能决策平台
数据采集
B 端实时采集用户点击、下单、广告曝光、出价等数据,然后推送给 Kafka 缓存。
数据清洗聚合
Flink 实时读取 Kafka 消息,按需过滤参与业务需求的指标,将聚合时间段的数据转换成指标。
数据存储
Flink 将计算结果转储至 Hive 日志库,将模型需要的参数转储至实时计算数据库 Tair 缓存,然后后续决策服务从 Tair 中获取数据进行模型训练。
▸ 案例归纳 Lambda 架构案例:大规模视频网站、广告平台。
Kappa 架构案例:证券公司智能决策、电商智能决策。
共同点:均以 Kafka 作为数据缓冲;Lambda 案例常配合 HDFS + Hive + Spark,Kappa 案例核心是 Flink 流处理引擎