六、大数据
6.4、大数据 Lambda 架构
6.4.1、架构流程
数据源 (Data Source) 同时推送到 批处理层 和 加速层。
批处理层 ：Map Reduce 进行大量数据处理，产生批处理结果视图 。结果认为是精准且全量 的，但数据处理时延很高。
加速层 ：只处理最近产生的实时数据 ，产生流处理结果视图 。流处理层的数据可能是不准确 的，也不是全量的，但数据处理时延很低。
服务层 ：用于响应用户的查询请求，合并 Batch View 和 Real-time View 中的结果数据集到最终的数据集。
查询视图：汇总流处理视图 & 批处理视图，产生查询视图。
6.4.2、三层定义
批处理层 (Batch Layer) ：两个核心功能：存储数据集 和生成 Batch View。
加速层 (Speed Layer) ：存储实时视图并处理传入的数据流，以便更新这些视图。
服务层 (Serving Layer) ：用于响应用户的查询请求，合并 Batch View 和 Real-time View 中的结果数据集到最终的数据集。
6.4.3、设计初衷
解决 Hadoop（MapReduce）处理速度慢的问题。由于离线计算T+1才能出结果，无法满足业务实时性，因此引入加速层（Speed Layer）来处理当天的增量数据。
6.4.4、CAP定理的应用
Lambda 架构在一定程度上是在权衡 CAP。Batch Layer 保证了最终一致性（C）和分区容错性（P），Speed Layer 保证了可用性（A）和低延迟。
6.4.5、核心痛点
代码维护成本高 。你需要为 Batch Layer 写一套代码（如 Hive/MapReduce），又要为 Speed Layer 写一套代码（如 Spark Streaming/Storm），两套逻辑必须保持业务一致，维护极其痛苦。这也催生了后来的 Kappa 架构。
6.4.6、逻辑架构图
Lambda 核心三层
生成 Batch View
生成 Real-time View
数据源 Data Source
汇总 | QueryView(查询视图)
User(用户查询)
批处理层 Batch Layer
MapReduce/全量/高延迟/精准
加速层 Speed Layer
Stream/增量/低延迟/可能不准
服务层 Serving Layer
合并视图
6.4.7、Lambda 架构的优缺点分析
| 优点 | 缺点 |
|---|---|
| (1) 容错性好：Batch Layer 可以反复重算，修正 Speed Layer 的错误。 | (1) 全场景覆盖带来的编码开销：同一套业务逻辑需要在两套系统（批/流）中实现。 |
| (2) 查询灵活度高：支持实时和历史数据的任意组合查询。 | (2) 针对具体场景重新离线训练一遍益处不大：有时实时流的结果已经足够好，重算浪费资源。 |
| (3) 易伸缩：各层组件（Hadoop/Kafka/HBase）都支持分布式扩展。 | (3) 重新部署和迁移成本很高：涉及多套系统的运维。 |
| (4) 易扩展：可以轻松添加新的视图。 |
6.4.8、技术选型与实战案例
6.4.8.1、通用技术选型
输入：Kafka (Kafka_Topic)。
加速层计算：Spark (Processing_Job)。
批处理层计算：Hadoop (Processing_Job)。
存储/服务层：HBase (Speed_Table + Batch_Table)。
6.4.8.2、实战案例分层细节
数据采集层：PC端、App端、TV端。
数据集成层：
- 实时：Nginx -> Flume -> Kafka。
- 离线：Sqoop -> ETL。
数据存储层：MemSQL、Hbase、HDFS。
数据计算层：
- 实时计算：Spark Streaming（计算直播在线人数、地域分布）。
- 离线计算：Impala、Hive、Spark、M-R（查询历史最高在线人数、逐日走势）。
数据展现层：当日概览（实时）、赛事回顾（离线）。
6.4.8.3、数据合并策略
在 Hbase 中，通常使用 Timestamp 版本控制或应用层逻辑来合并数据。查询时，优先读 Speed Layer，如果 Speed Layer 没有（数据过期或被清洗），再读 Batch Layer。
6.4.8.4、Sqoop
这是一个连接关系型数据库（MySQL/Oracle）和 Hadoop 的桥梁，常用于 T+1 的数据抽取。
6.4.8.5、Impala vs Hive
Hive 适合跑批（吞吐量大但慢），Impala 适合交互式查询（基于内存，速度快）。
6.4.8.6、实战架构图
数据展现层
数据存储与服务层
数据计算层
数据集成层
数据采集层
日志
PC/App/TV
Nginx
Flume
Kafka: 实时管道
业务库
Sqoop: 离线抽取
Spark Streaming
实时计算
Hadoop MR/Hive
离线计算
HBase Speed Table
HBase Batch Table
HDFS: 归档
当日概览/实时大屏
赛事回顾/历史报表
User
6.5、大数据 Kappa 架构
6.5.1、架构流程
输入数据 ：直接由实时层的实时数据处理引擎对源源不断的源数据进行处理。
服务层：再由服务层的服务后端进一步处理以提供上层的业务查询。
数据存储 ：而中间结果的数据都是需要存储的，这些数据包括历史数据 与结果数据，统一存储在存储介质中。
6.5.2、结构流程
输入数据 -> 实时层 (实时引擎) -> 服务层 (服务后端) <- 外部查询。
底层包含：历史数据存储 和 结果数据存储。
6.5.3、核心理念
"万物皆流" (Everything is a stream) 。在 Kappa 架构中，没有离线批处理（Batch Layer），批处理被视为有界流处理（Bounded Stream）。
6.5.4、数据重算机制（Re-processing）
"没有离线层，如果代码逻辑改了，如何重算历史数据？"
答案 ：利用消息队列（如 Kafka）的长期保留策略 。当逻辑修改后，启动一个新的流任务，将 Kafka 的 Consumer Offset（消费位移）重置到最早的时间点（Rewind），快速"回放"历史数据重新计算一遍，生成新的视图。
6.5.5、Kappa+ 架构
为了弥补 Kappa 在处理超大规模历史数据回溯时的性能短板，有时会保留离线数仓做归档，称为 Kappa+。
6.5.6、逻辑架构图
Kappa 架构核心
服务层
实时层
读写
数据存储
历史数据存储
结果数据存储
输入数据
实时引擎 / Flink
服务后端
外部查询
6.5.7、Kappa 架构的优缺点分析
| 优点 | 缺点 |
|---|---|
| (1) 将实时和离线代码统一起来了。开发人员只需要维护一套 Flink SQL 或 Spark Structured Streaming 代码。 | (1) 消息中间件缓存 的数据量和回溯数据有性能瓶颈。 |
| (2) 方便维护 而且统一了数据口径。 | (2) 在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序 问题，导致数据丢失。 |
| (3) 避免了 Lambda 架构中与离线数据合并的问题。 | (3) Kappa 在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。 |
消息中间件瓶颈：Kafka 通常不是设计用来存PB级历史数据的。如果回溯一年的数据，Kafka 的存储成本和回放速度都是挑战。
乱序问题 (Out-of-Order) ：流计算中最头疼的问题。比如"下单"事件比"浏览"事件先到达。架构师需要利用 Watermark (水位线) 机制来处理乱序。
6.5.8、技术选型与实战案例
6.5.8.1、系统定位
实时日志分析平台基于 Kappa 架构。
6.5.8.2、核心逻辑
使用统一的数据处理引擎 Flink 可实时处理全部数据；并将结果存储到 ElasticSearch 与 OpenTSDB 中。
6.5.8.3、架构分层
展现层：日志智能搜索、可视化图表、在线开发、告警中心。
逻辑处理层：
- 采集 ：Filebeat (在源系统上) -> Kafka 缓存。
- 解析分析 ：解析、编译、任务提交 -> 基于 Flink。
- 日志告警：规则转换、告警控制、告警队列。
存储计算层 ：计算集群 (CDH)、日志库 (ElasticSearch )、指标库 (OpenTSDB)。
6.5.8.4、技术栈选择
Filebeat vs Flume：Filebeat 是轻量级采集器（Go语言写，不依赖JVM），适合部署在业务服务器端；Flume 较重，适合做聚合。
OpenTSDB ：这是一个专门的时序数据库（Time Series DB），底层依赖 HBase。在物流领域，它常用于存储轨迹点、温度传感数据。
6.5.8.5、案例架构图
存储计算层
逻辑处理层
展现层
日志告警
规则转换
告警控制/队列
基于 Flink 解析分析
交互控制
脚本解析/作业编译
任务提交
日志采集
Filebeat 源系统1
Filebeat 源系统2
Filebeat 源系统3
日志智能搜索
可视化图表
告警中心
Kafka 缓存
计算集群 CDH
日志库 ElasticSearch
指标库 OpenTSDB
6.6、Lambda与Kappa架构深度对比
6.6.1、基本比对
| 对比内容 | Lambda架构 | Kappa架构 |
|---|---|---|
| 复杂度与开发、维护成本 | 需要维护两套系统（引擎），复杂度高，开发、维护成本高。 | 只需要维护一套系统（引擎），复杂度低，开发、维护成本低。 |
| 计算开销 | 需要一直运行批处理和实时计算，计算开销大。 | 必要时进行全量计算，计算开销相对较小。 |
| 实时性 | 满足实时性。 | 满足实时性。 |
| 历史数据处理能力 | 批式全量处理 ，吞吐量大，历史数据处理能力强。 | 流式全量处理 ，吞吐量相对较低，历史数据处理能力相对较弱。 |
| 使用场景 | 直接支持批处理，更适合对历史数据分析查询的场景，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求。 | 不是Lambda 的替代架构 ，而是简化，Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求。 |
| 选择依据 | (1) 根据两种架构对比分析，将业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能力 作为选择考虑因素。 (2) 计算开销虽然存在一定差别，但是相差不是很大，所以不作为考虑因素。 |
6.6.2、为什么说 Kappa 不是 Lambda 的替代者？
误区：很多人认为 Kappa 是 Lambda 的进化版，所以任何时候都应该用 Kappa。
真相 ：Kappa 是为了降低复杂度 而做的权衡（Trade-off）。它牺牲了"批处理的高吞吐量"来换取"开发运维的统一"。
瓶颈 ：当需要回溯的数据量达到 PB级，或者算法逻辑极其复杂（涉及全量数据的复杂的Join）时，流计算引擎（如 Flink）在回放 Kafka 历史数据时的性能，通常不如专门的离线批处理引擎（如 Spark/MapReduce 在 HDFS 上跑）效率高。
6.6.3、"计算开销"为什么不是主要因素？
这是因为在企业级架构中，硬件成本（服务器） 通常远低于 人力成本（开发维护两套代码）。Lambda 虽然费机器（跑两遍），但最痛的其实是费人；Kappa 省机器，但如果遇到极端的数据倾斜或乱序问题，调优也很费人。综合来看，算力成本的差异在架构选型中权重较低。
6.6.4、选型关键判据
选 Lambda：业务逻辑复杂、必须确保 100% 数据准确性（需要 Batch Layer 兜底修正）、历史数据量巨大且需频繁重算。
选 Kappa：业务逻辑相对简单（或者是纯追加的日志型数据）、开发人力紧缺、对实时性要求高且能容忍极少量的数据偏差（或有其他对账机制）。
6.6.5、架构选型决策流
Kappa 核心理由
Lambda 核心理由
海量/频繁/高吞吐要求
中量/偶尔/流式回放可接受
充足/追求极致准确
有限/追求统一技术栈
开始选型
历史数据重算需求?
Lambda 架构
开发维护资源?
Kappa 架构
批处理能力强
容错性高/兜底
代码统一/维护低
业务本身是增量写入