原子标签索引：[概念×10 | 机制×5 | 流程×4 | 决策×1 | 分类体系×4 | 判据×4 | 案例×4 | 数据×3] 上游：第6章（数据库/数据仓库基础）、CAP 相关理论 下游：论文科高频素材（架构风格/质量属性论述常用）
标准表述
- 传统架构痛点：应用直连数据库，用户量增长时数据库成为响应瓶颈；分区后 reshard 代价高；对人为错误无工程设计，仅靠备份不能治本。
- 数据系统 = 数据 + 查询（Kappa 作者对数据系统的本质定义）。
- 数据的两大关键性质：When（时间性，决定全局先后顺序）与 What（数据本身不可变，已是事实）。
- 数据不可变存储下，CRUD 退化为 CR：Update/Delete 本质是新产生的数据信息，用 C 记录。
- 主数据集三属性：数据是原始的、数据是不可变的、数据永远是真实的。
- Lambda 架构 = 批处理层 + 加速层 + 服务层，整合离线计算与实时计算，由 Storm 作者 Nathan Marz 提出。
- Kappa 架构由 Jay Kreps 提出，只保留流计算一条数据链路，本质是改进 Lambda 的 Speed Layer 使其可重演历史数据。
- View 是针对查询预先计算并保存的结果，是 Lambda 架构的核心概念，作用是查询优化。
- Monoid（幺半群）满足结合律，是分布式并行计算与视图合并的数学基础。
- 速度层只处理最近的增量数据流，数据即到即处理、处理完即丢弃，提供低延迟实时视图。
- 批处理层关注精确计算，速度层关注近似计算，近似结果由下一组批视图取代，向"最终精度"迈进。
- Lambda 的容错本质是 CAP 中的最终一致性：速度层引入的错误在批处理层重算时得到修正。
- 不可变性 + 重新计算是应对人为和机器错误的两种常用方法。
- 大数据中结构化数据约占 15%，非结构化约占 85%；约 90% 的数据来自开源数据。
- 选择架构的考虑因素：业务需求、技术要求、系统复杂度、开发维护成本、历史数据处理能力；计算开销差别不大，不作为因素。
蒸馏笔记
概念
- 大数据挑战：海量、多源（85% 非结构化）、高维多变强随机性带来的处理难题。
- 一次挖掘 / 二次挖掘：从数据中提取粗糙知识为一次挖掘；粗糙知识与量化后的主观知识（经验、常识、情境、偏好）结合生成智能知识为二次挖掘，是"量"到"质"的飞跃。
- 数据异构性 / 决策异构性：大数据环境下管理决策面临的两个异构问题；智能知识是二者的桥梁。
- Lambda 架构：同时处理离线与实时数据的可容错、可扩展分布式系统；融合不可变性、读写分离、复杂性隔离三原则。
- Kappa 架构：删除批处理层、以消息队列替代数据通道、仅用流计算链路的大数据架构。
- 主数据集（Master Dataset）：原始、不可变、永远真实的全量数据存储，Lambda 的数据基石。
- View（视图）：针对查询预先计算并保存的结果；分 Batch View 与 Real-time View。
- Monoid（幺半群）：源自范畴论、满足结合律的函数特性；不满足的函数常可拆解为多个 Monoid 运算（如平均值拆成分子/分母加法）。
- Event Sourcing（事件溯源）：Martin Flower 提出的持久化模式；事件驱动、事件为核心、业务数据只是事件产生的视图。
- CQRS（命令查询职责分离）：DDD 的架构模式，分离读（查询）与写（修改）操作，主要用于解决数据库报表输出。
机制
- 分区用 Hash 作 key → 应用须知道 key 所在分区 → 负载再增须 reshard → 迁移数据+改客户端地址+改代码，耗时且易写错分区。
- 读写分离动机：读比写省时 → 读写混置时写操作时长拖累整体业务效率 → 海量数据下必须读写分离。
- Monoid 结合律 → 计算可拆到多机并行 → 部分结果可存储共享 → 减少重复运算。
- 不可变存储 → 错误数据不被覆盖丢失 → 遍历全量、依时间序重算 → 必然得到正确结果。
- Lambda 容错链：Speed 层数据持续写入 Batch 层 → 批层重算覆盖该数据集后 → 实时视图可丢弃 → 错误被修正（最终一致性）。
- 复杂性隔离：离线可控、增量算法复杂 → 把复杂性隔离在 Speed Layer → 提升整体鲁棒性。
流程
Kappa 架构实现（以 Kafka 为例） 1. 部署 Kafka，设置日志保留期（如重算一年设 365 天，全量则设 Forever）。 2. 改进算法时启动新 Kafka 作业实例，Log Offset 置 0，从头重算历史数据输出到新视图。 3. 新视图进度追上旧视图后，应用切换到新视图读取。 4. 停止旧作业实例，删除旧视图。
某证券实时日志平台处理流程（Kappa） 1. 采集：各系统部署 Filebeat，实时输出日志到 Kafka。 2. 清洗解析：Flink 读取 Kafka，提取关键内容转指标并二次加工衍生指标。 3. 存储：日志分类存 ElasticSearch 日志库，指标存 OpenTSDB 指标库。 4. 监控：独立告警消息队列保证监控消息有序管理与实时推送。 5. 应用：搜索/可视化分析/全息监控，预警中心按优先级呈现告警。
某电商智能决策系统流程（Kappa） 1. 数据采集：B 端实时收集点击、下单、曝光、出价数据输出到 Kafka。 2. 清洗聚合：Flink 过滤参与计算的字段，按时间窗口聚合转换成指标。 3. 存储与决策：结果存 Hive 与 Tair；决策服务从 Tair 读数据算新参数，经 Zookeeper 通知客户端拉取参数本地存储。
Lambda 典型实现选型 1. 存储：Hadoop(HDFS) 存主数据集。 2. 计算：Spark 或 Storm 构成速度层。 3. 服务：HBase 或 Cassandra 作服务层。 4. 视图：Hive 创建可查询视图。
决策
| 选项 | 适用条件 | 代价 |
|---|---|---|
| Lambda | 依赖 Hadoop/Spark/Storm 等关键技术；需频繁海量历史数据分析；实时与离线结果无法统一（如 ML 先离线训练再实时验证）；人力/技术/资金充足 | 维护两套系统两套代码，复杂度、开发维护成本高 |
| Kappa | 偏好流式计算、依赖 Flink；业务为增量写入场景（时序数据天然带时间窗）；希望一份代码；频繁改算法模型参数；小规模数据集 | 抛弃离线计算的稳定可靠；消息中间件缓存与回溯有性能瓶颈；多流关联可能因乱序丢数据 |
分类体系
大数据系统八大理想属性（Marz 提出） 1. 鲁棒性和容错性——机器不可靠且人会犯错，人为操作容错比机器容错更重要。 2. 低延迟读取和更新——毫秒到几百毫秒级，须在保证鲁棒性前提下实现。 3. 横向扩容——scale out（加机器）而非 scale up（增强单机）。 4. 通用性——支持金融、社交、电商等各类应用。 5. 延展性——新功能可添加，且具备大规模迁移能力。 6. 即席查询——用户可按自己要求进行 Ad Hoc 查询。 7. 最少维护——用机制简单的组件降低底层复杂度，不再基于增量更新设计。 8. 可调试性——每个运行时产生的值都可追踪其产生途径。
大数据三大挑战 1. 用信息技术处理非结构化/半结构化数据。 2. 复杂性、不确定性特征的刻画方法与系统建模（知识发现的前提和关键）。 3. 数据异构性与决策异构性对知识发现与管理决策的影响。
Lambda 三层职责 - 批处理层：存储主数据集 + 预计算生成 Batch View；结果精准且全量；时延高。 - 加速层：只处理最近增量数据流，持续更新 Real-time View；结果可能不精确、不全量；时延低。 - 服务层：合并两类视图为最终数据集，提供低延迟随机读，要求批量写入、可伸缩、容错。
Kappa 架构变形 1. Kappa+（Uber 提出）：流计算框架直接读 HDFS 数仓数据，一并完成实时计算与历史 backfill；任务分无状态任务与时间窗口任务；配套 Apache Hudi 支持 parquet 数据更新/删除与增量消费。 2. 混合分析系统：Kafka+Flink 构建流计算，再对接 ElasticSearch 弥补分析能力，只适合合理量级热点数据，属 Kappa 与 Lambda 间的折中。
判据
- 视图合并判据：查询函数满足 Monoid 性质 → 直接合并 Batch View 与 Real-time View；不满足 → 转换成多个 Monoid 函数分别合并再计算，或按业务规则合并。
- 服务层要求：随机读取、批量写入、可伸缩性、容错能力（与加速层要求类似）。
- Lambda 缺点判据（3 条）：全场景覆盖带来编码开销；针对具体场景重新离线训练益处不大；重新部署和迁移成本很高。
- Kappa 缺点判据（3 条）：消息中间件缓存量与回溯有性能瓶颈（如算法需 180 天数据时压力大）；多实时流关联依赖实时计算能力且可能因乱序丢数据；抛弃离线模块的同时抛弃了离线计算稳定可靠的特点。
案例
- 某网里约奥运（2016）Lambda 应用：当日概览需秒级刷新千万级实时指标（实时层增量计算）、赛事回顾需不可变存储全部历史数据（批层追加式主数据集）；平台分数据集成/存储/计算/应用四层，实时链 Nginx+Flume→Kafka→Spark Streaming，离线链 sqoop→HBase 主数据集，两集群经 Kafka Mirror 同步。→ 19.6.1
- 某网广告平台 Lambda 三版演进：V1 标准 Lambda 但服务层过重成瓶颈；V2 常驻 Python 脚本按活跃时段（10min/30min 间隔）同步第三方曝光数据；V3 只维护一张 MySQL 表（st_day 字段区分实时/离线），把关联工作前移到收集计算层。→ 19.6.2
- 某证券基于 Kappa 的实时日志分析平台：Flink 统一处理 + ElasticSearch/OpenTSDB 存储，自研可配置化通用计算框架（Ruby 脚本 + Logstash 语法转 Flink 算子，Yarn 分配资源），解决 Flink 原生 API 不支持配置化开发的问题。→ 19.6.3
- 某电商外卖基于 Kappa 的智能决策系统：Flink 实时处理流数据存 Hive/Tair，实时数据参与当日参数计算（对比离线词表 T+1 模式），Zookeeper 通知客户端本地取参无网络延迟。→ 19.6.4
数据
Lambda 与 Kappa 对比（表 19-1 改写）
| 对比维度 | Lambda | Kappa |
|---|---|---|
| 复杂度与开发维护成本 | 两套系统，复杂、成本高 | 一套系统，复杂度低、成本低 |
| 计算开销 | 批+实时须一直运行，开销大 | 仅必要时全量计算，开销较小 |
| 实时性 | 满足 | 满足 |
| 历史数据处理 | 批式全量，吞吐大、能力强 | 流式全量，吞吐较低、能力较弱 |
比例数据：结构化数据约 15%、非结构化约 85%；约 90% 数据来自开源数据（适用条件：大数据语境的普遍统计口径）。
典型量级：Kappa 算法常需过去 180 天数据；Kafka 保留期示例 365 天；答题场景某网广告数据为秒级到 10min 级准实时。
易错点 / 边界情况
- 两个"之父/作者"别混淆：Nathan Marz = Storm 之父，提 Lambda，也提大数据系统八属性；Jay Kreps = Kafka/Samza 作者之一，提 Kappa。Event Sourcing 是 Martin Flower 提出。
- "加速层"即"速度层"（Speed Layer），两种译名同义；但批处理层 ≠ 服务层，服务层不计算、只合并与响应查询。
- Kappa 不是 Lambda 的替代，而是简化版；Kappa 放弃批处理，Lambda 保留批处理——历史数据探索性分析场景应选 Lambda。
- 速度层不存储其处理的数据：数据流入即处理、处理完即丢弃；而 Kappa 的中间结果与历史数据需要统一存储。
- "最终精度"≠"最终一致性"：前者指批层精确+速层近似、随视图更替逼近精确；后者（Eventual Consistency）指速层错误被批层重算修正的容错性质。
- Monoid 易错：平均值不满足 Monoid（多个平均值无法直接结合），须拆成"总和/个数"两个加法分别合并。
- 计算开销在两架构间差别不大，教材明确不作为选型考虑因素——选择题常在此设陷阱。
- Kappa+ 的 HDFS 直接读取仅指历史 backfill 场景（Uber 方案），不要与"Kappa 用消息队列长期存日志、存储成本大"的缺陷混谈；分层存储（如 Pulsar）的历史日志只能用于 backfill 作业，利用率仍低。