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

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

出现这种情况以后，在系统架构上就采用如图19-1的架构，在W e b 服务器和数据库中间加入一层异步处理的队列，缓解数据库的读写压力。
当W e b服务器收到页面请求时，会将消息添加到队列中。在数据库端，创建一个工作处理层定期从队列中取出消息进行处理，例如每次读取100条消息。这相当于在两者之间建立了一个缓冲。

这一方案并没有从本质上解决数据库过载(Overload) 的问题，且当工作处理层无法跟上业务对于数据修改的请求时，就需要增加多个工作处理层并发执行，数据库又将再次成为响应请求的瓶颈。一个解决办法是对数据库进行分区 (Horizontal Partitioning)。 分区的方式通常以Hash值作为key。 这样就需要应用程序端知道如何去寻找每个key所在的分区。

当系统的用户访问量持续增加时，就需要考虑读写分离技术 (Master-Slave)和分库分表技术。

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

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

序号	总结	核心内容
1	非结构化数据处理难题	大数据以非结构化、半结构化数据为主，存在高维、随机、不确定等特征；需多学科交叉研究数据建模与转换，依托一次挖掘、二次挖掘，实现粗糙知识向智能知识升级
2	复杂不确定性建模困难	需研究大数据复杂、不确定特征的刻画与系统建模；短期统一多类型数据转换规则，长期完善大数据基础理论；结合管理科学与人机交互完成二次挖掘评估
3	双重异构影响决策分析	存在数据异构、决策异构两大问题，颠覆传统决策模式；需通过二次挖掘生成智能知识，衔接数据与决策，融入主观经验优化管理决策

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

序号	总结	核心内容
1	鲁棒容错，抗双重故障	应对硬件宕机、程序Bug、人为操作失误，具备错误适配与快速恢复能力
2	低延迟读写更新	满足业务毫秒级访问诉求，在保障健壮性基础上实现高速读写与更新
3	横向弹性扩容	依托Scale-out横向增加节点，负载与数据量增长时保持性能稳定、线性扩展
4	业务场景通用	适配金融、社交、电商等多类行业，支撑多样化大数据业务应用
5	功能可扩展迁移	支持新增业务功能，具备大规模数据与架构迁移的扩展适配能力
6	支持即席查询	允许用户自定义临时查询，灵活处理数据，提升数据利用价值
7	低运维、少维护	简化底层组件与算法复杂度，降低故障概率，实现长期平稳运行
8	全链路可调试	数据可全程追踪溯源，清晰记录数据生成链路，便于问题排查

19.3Lambda架构

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

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

19.3.2Lambda架构应用场景

序号	总结	核心内容
1	赋能机器学习场景	Lambda架构统一处理多类数据，为算法提供高质量数据源，支撑模式识别与模型训练分析
2	承接物联网海量输入	物联网终端产生海量实时数据流，作为数据输入端，同步送入批处理层与速度层加工处理
3	流处理存在固有挑战	速度层低延迟实时计算、数据即时处理不落地；速度层近似计算、批处理层精准计算，依靠最终精度机制逐步修正；实时流处理逻辑复杂，需搭配专用数据库与索引系统优化

19.3.3Lambda架构介绍

序号	总结	核心内容
1	批处理层：离线全量计算	持久化存储全量数据，离线预计算生成批量视图，适合全量、精准的离线分析
2	加速层：增量实时计算	处理新增增量数据流，持续更新实时视图，弥补批处理延迟，保障低延迟查询
3	服务层：结果聚合输出	整合批量视图与实时视图数据，统一对外提供最终查询结果

1.批处理层

Batch Layer 有两个核心功能：存储数据集和生成 Batch View。
该层负责管理主数据集。主数据集中的数据必须具有以下三个属性：
(1)数据是原始的。
(2)数据是不可变的。
(3)数据永远是真实的。

2.加速层

对加速层批处理视图建立索引，便于能快速进行即席查询 (Ad Hoc Queries)。 它存储实时视图并处理传入的数据流，以便更新这些视图。
Batch Layer 可以很好地处理离线数据，但有很多场景数据不断实时生成，并且需要实时查询处理。 Speed Layer正是用来处理增量的实时数据。
Speed Layer和 Batch Layer 比较类似。如图19-7所示， Speed Layer对数据进行计算并生成Realtime View, 其主要区别在于：
(1)Speed Layer处理的数据是最近的增量数据流， Batch Layer处理的全体数据集。
(2)Speed Layer为了效率，接收到新数据时不断更新Realtime View, 而 Batch Layer根据全体离线数据集直接得到 Batch View。

Lambda架构将数据处理分解为 Batch Layer和 Speed Layer 有如下优点

序号	总结	核心内容
1	容错性强，具备最终一致性	实时层数据同步写入批处理层，批量重算可修正实时计算错误，依托最终一致性保障数据准确
2	隔离复杂度，提升稳定性	离线批处理逻辑简单可控，高复杂的增量实时计算单独隔离，降低整体系统故障风险
3	支持横向弹性扩展	依托Scale-out横向增加节点，应对数据量与负载增长，实现性能线性扩展

3.服务层

Lambda架构的 Serving Layer用于响应用户的查询请求，合并Batch View 和Real-time View中的结果数据集到最终的数据集。该层提供了主数据集上执行的计算结果的低延迟访问。读取速度可以通过数据附加的索引来加速。与加速层类似，该层也必须满足以下要求，例如随机读取，批量写入，可伸缩性和容错能力。

19.3.4Lambda架构的实现

19.3.5Lambda架构优缺点

序号	优点总结	核心内容
1	容错性好	支持修复算法或全量重算视图，可快速修正错误，保障大数据系统稳定运行
2	查询灵活度高	批处理层支持对全量数据开展即席查询，数据分析自由度高
3	易伸缩	三层均为分布式设计，通过横向新增节点即可扩容，适配业务增长
4	易扩展	新增视图仅需补充计算函数，无需改动底层主数据集，拓展成本低

序号	缺点总结	核心内容
1	双链路开发成本高	需同时维护批处理与实时两套逻辑，整体编码开发工作量大
2	离线训练性价比低	特定业务场景下，重复全量离线重新训练，实际收益有限
3	部署迁移代价大	架构体系复杂，整体环境重新部署、跨环境迁移的成本与难度较高

19.3.6Lambda与其他架构模式对比

Lambda架构的诞生离不开很多现有设计思想和架构的铺垫，如事件溯源 (Event Sourcing)架构和命令查询分离 (Command Query Responsibility Segregation,CQRS) 架构， Lambda架构的设计思想和这两者有一定程度的相似。
下面对 Lambda架构和这两者进行分析。

序号	总结	核心内容
1	事件溯源：同源容错设计	以事件驱动为核心，持久化存储原始事件，业务数据为事件生成的视图；与Lambda架构数据思想一致，可通过事件重算修复错误、保障容错
2	CQRS：读写分离架构	拆分数据读查询与写修改操作，属于DDD架构模式；Lambda通过批处理、流处理生成视图，查询直接读取视图，天然实现读写分离，提升海量数据处理效率

19.4Kappa架构

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

数据系统=数据+查询

1.数据的特性
数据是一个不可分割的单位，数据有两个关键的性质： When和What。

(1)When。When是指数据是与时间相关的，数据一定是在某个时间点产生的。
(2)What。What 是指数据的本身。由于数据跟某个时间点相关，所以数据的本身是不可变的 (Immutable), 过往的数据已经成为事实 (Fact), 你不可能回到过去的某个时间点去改变数据事实。

2.数据的存储
Lamba架构中对数据的存储采用的方式是：数据不可变，存储所有数据。

序号	总结	核心内容
1	模型简洁，仅追加写入	不可变数据采用追加式存储，无需更新、索引等复杂操作，相比可变模型大幅简化存储设计
2	容错恢复能力强	原始数据永久保留、不会被覆盖丢失；可依托时序全局顺序，全量重算视图，快速修复人为、机器故障
3	工程落地成熟通用	不可变模型已广泛应用，如Datomic分布式数据库、Kafka日志追加存储，架构落地稳定可靠

19.4.2Kappa架构介绍

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

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

Kappa架构与 Lambda相比，主要有两点区别

序号	总结	核心内容
1	Kappa：简化流式、适配时序增量场景	作为Lambda的简化方案，舍弃独立批处理层，统一采用流式计算；适配时序、增量写入类业务，兼顾实时计算与历史数据补偿
2	Lambda：批流一体、擅长全量历史分析	保留批处理能力，支持全量历史数据任意组合查询、即席探索分析，兼顾历史海量分析与实时性需求

19.4.3Kappa架构的实现

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

序号	总结	核心内容
1	配置数据留存周期	部署Kafka并设置日志保留期，限定可重处理的历史数据范围，支持固定时长或永久保存
2	算法迭代，重跑历史数据	业务逻辑更新时，新建作业实例，将偏移量置为0，从头消费历史日志，生成全新数据视图
3	平滑切换版本	待新视图数据进度追上旧视图后，前端切换读取新视图，下线旧作业与旧视图，完成迭代

19.4.4Kappa架构的优缺点

序号	总结	核心内容
1	优势：代码统一、口径一致	实时与离线共用一套流式代码，降低维护成本，统一数据标准；通过重放历史数据即可完成历史查询，无需批流结果合并
2	存储与回溯存在性能瓶颈	消息中间件长期存储海量历史数据压力大，大规模历史数据回溯计算，会占用大量集群资源
3	多流关联易出现数据异常	多股实时数据流关联场景下，受数据到达顺序影响，容易引发数据错乱、丢失等问题
4	舍弃离线计算稳定性	去除独立批处理层，丧失离线全量计算高可靠、高稳定的优势
5	Lambda互补短板	离线计算稳定可靠，但存在双架构、双代码，运维复杂、开发与维护成本更高

19.4.5常见Kappa架构变形

1.Kappa+ 架构
Kappa+是 Uber提出流式数据处理架构，它的核心思想是让流计算框架直接读 H D F S里的
数据仓库数据，一并实现实时计算和历史数据backfll 计算，不需要为 backfll 作业长期保存日
志或者把数据拷贝回消息队列。

2.混合分析系统的Kappa架构

Lambda和 Kappa架构都还有展示层的困难点，结果视图如何支持热点数据查询分析，一个解决方案是在 Kappa基础上衍生数据分析流程。

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

19.5.1Lambda架构与Kappa架构的特性对比

Lambda架构将批处理层和速度层分为两层，分别进行离线数据处理和实时数据处理
Kappa架构在同一层次内进行实时处理和离线处理，在满足延迟要求的流式计算技术成熟的前提，比 Lambda更优秀。

序号	总结	核心内容
1	开发维护成本对比	Lambda需维护批处理、流式两套系统与双份代码，架构复杂、运维成本高；Kappa仅一套流处理架构，依托Kafka+Flink实现，开发简单、维护成本更低
2	整体计算开销对比	Lambda需双系统长期不间断运行，资源与I/O开销大；Kappa仅面向流式计算，全量计算按需触发，整体资源消耗更少
3	实时实现机制不同	二者均支持实时响应；Lambda通过批流视图合并输出，运行稳定、实时成本可控；Kappa依靠消息队列并发计算，多流关联易受数据顺序影响，存在数据丢失风险
4	历史数据处理能力	Lambda依托独立批处理层，可高效处理超大规模历史数据，离线计算与实时业务互不干扰；Kappa依赖消息队列存储历史数据，海量回溯压力大，长周期重算稳定性较差

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

序号	总结	核心内容
1	依托技术栈选型架构	强依赖Hadoop、Spark、Storm等技术，适配Lambda；以流式计算为主、依赖Flink引擎，优先选用Kappa
2	结合复杂度与算法特性	算法频繁迭代、需一份代码统一批流处理，选Kappa；离线训练+实时推理、批流结果无法统一，必须选用Lambda
3	匹配人力与运维成本	技术资源充足、可承担双系统运维开销，适配Lambda；追求低成本、轻量化运维，单架构维护，选择Kappa
4	按历史数据规模选型	需频繁分析超大规模、长周期海量历史数据，Lambda批处理优势明显；仅处理小规模增量数据，Kappa流式架构更适配

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

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

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

该平台基于Lambda架构，由数据集成层、数据存储层、数据计算层和数据应用层构成。数据集成层支持将P C端、A p p端和 T V端采集到的用户行为数据进行整理，数据集成层分为离线数据集成和实时数据集成两部分。实时数据集成集群采用Nginx和 Flume服务器对实时流数据聚合并传输至Kafka 队列中，由Kafka将实时流数据分发至实时流计算引擎中分析。离线数据集成集群使用开源组件sqoop将数据不断追加存储到主数据集中，采用分布式列数据库 Hbase存储主数据集。两个集群之间通过 Kafka 的Mirror功能实现同步。

本平台利用云存储技术构建平台的存储系统，该存储系统不仅集成了分布式列数据 Hbase、内存关系型数据库M e m S Q L , 而且还增加了统一的监控管理功能和开放更多的访问接口。数据存储将结构化数据、半结构化数据以及非结构化数据储存于分布式文件系统中，且数据以三重副本的形式分布在文件系统，支持自动存储容错、系统错误监控、故障自动迁移等技术，确保数据的安全性和接近100%的数据可用性。
数据计算层为了实现 I/O的负载分离，通过对实际业务解析，将数据计算层分为离线计算、实时计算和合并计算三部分。

序号	总结	核心内容
1	离线计算：全量预计算降负载	存储海量离线数据，通过Spark、MapReduce做预聚合压缩数据；依托Hadoop调度保障资源公平分配，基于Hive、Impala构建数仓，结果落地HDFS并更新批量视图
2	实时计算：增量处理保障时效	面向持续产生的增量业务数据，采用Spark Streaming做增量计算，只处理近期数据，持续更新实时视图，满足高时效查询诉求
3	合并计算：统一视图对外查询	接收用户查询请求，整合批量视图与实时视图数据；融合内存数据库与离线计算结果，写入HBase，统一提供完整查询数据

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

版本	总结	核心内容 & 存在问题
第一版架构	标准Lambda，业务聚合压在应用层	批处理：每日同步Kafka日志至HDFS、Hive计算后落地MySQL；实时层：Spark Streaming消费Kafka写入Redis；服务层Java需多库查询、手动合并离线与实时数据。 问题：应用层逻辑复杂、性能瓶颈明显；第三方指标无实时同步，无法支撑广告实时调优。
第二版架构	优化实时数据源，下沉离线聚合	新增Python常驻脚本分级拉取第三方API数据，规避调用限额；批处理层提前在Hive完成多表Join聚合，减少服务层计算。 问题：瓶颈转移至Redis多层关联查询；离线导表链路长、依赖复杂，故障恢复成本高。
第三版架构	架构改良，统一单表存储消除聚合	统一维护一张全指标MySQL表，按日期区分离线/实时数据；实时计算不再写入Redis，通过接口直接更新MySQL当日指标；将查询聚合前置到数据写入阶段。 优势：服务层仅单表查询，逻辑极简，彻底解决查询性能瓶颈。

19.6.3某证券公司大数据系统

序号	总结	核心内容
1	数据采集接入	业务端实时采集点击、下单、曝光、出价等行为数据，统一推送至Kafka进行消息缓冲
2	实时清洗聚合	依托Kappa架构与Flink统一引擎，消费流式数据，完成字段过滤、时段聚合、指标加工处理
3	分层存储落地	处理后数据存入Hive做离线归档；模型计算所需热点数据存入Tair分布式缓存，加速读取
4	微服务决策联动	决策服务为微服务架构，读取Tair数据完成模型运算，生成决策参数；借助Zookeeper实现配置同步，业务客户端无感更新、无缝调用