一、大数据 5V 特征

1. Volume 大量 数据规模达到 TB、PB、EB 级别。传统单库难以承载，必须分布式存储。

考点：不是数据多就叫大数据，是多种特征共同决定。

1. Velocity 高速 数据生成速度快、需要快速处理。日志、支付、传感器数据不停产生；分为高速写入、低延迟产出结果。 区分两类：离线数据（小时 / 天级别延迟）、实时数据（毫秒‑秒级延迟）

2. Variety 多样性

• 结构化：数据库表（MySQL、Oracle）
• 半结构化：JSON、XML、日志、CSV
• 非结构化：图片、视频、音频、文档

传统关系型数据库只擅长结构化，这就是传统数据库最大短板。

1. Value 价值密度低 海量数据里面有用的数据很少。 举例：监控录像几百小时，有用片段只有几秒；海量用户行为日志，有效行为占比很低。 大数据思路：找相关关系，而非因果关系，适合用户画像、推荐、风控。

2. Veracity 真实性 / 准确性 原始数据大量脏数据：乱码、缺失、重复、错误、异常值。 必须经过数据清洗、数据治理，保障数据可信。

记忆口诀：量大、速快、种类多、价值稀、数据准。

---

二、大数据完整处理全流程

1. 数据采集

收集所有业务源头的数据

• 业务数据库、服务器运行日志、前端埋点、物联网设备、第三方接口、爬虫数据 工具：Flume、Canal、Sqoop、Kafka

Kafka 在这里最关键：削峰、缓冲、解耦。高峰期海量数据流不会直接压垮计算引擎。

2. 数据预处理（ETL）

E 抽取‑T 转换‑L 加载

• 清洗：剔除脏数据、缺失值、去重、过滤无效日志
• 转换：格式统一、字段标准化、编码统一、时间格式统一
• 集成：多源数据表合并

现在新词 ELT：先加载到数据湖里面，之后再做转换，适配非结构化数据。

3. 数据存储

根据数据类型、冷热程度选择存储组件 分布式文件、KV 数据库、数仓、数据湖、时序数据库。

4. 计算与分析，分为 4 大类

1. 离线批计算：处理昨日、历史数据，生成日报月报
2. 流式实时计算：处理源源不断到来的增量数据，实时大屏、风控
3. 交互式即席查询：分析师临时自定义 SQL 查询
4. 高级分析：数据挖掘、机器学习、算法模型（用户画像、商品推荐）

5. 数据服务与应用层

对外提供能力：API 接口、OLAP 多维分析、报表、可视化大屏、指标平台、自助分析平台。

---

三、大数据系统八大架构特性

1. 鲁棒性（容错性）

集群机器一定会故障。架构需要做到节点宕机之后数据不丢失、任务可以自动重启。 实现手段：多副本、任务重试、状态持久化、检查点 Checkpoint。

2. 低延迟的读写更新

区分场景： 离线任务优先高吞吐，可以接受高延迟； 实时业务必须做到低延迟。

3. 横向可扩展性（水平扩展）

大数据最核心要求：水平扩容 遇到性能瓶颈，增加服务器节点就可以提升存储、计算能力。 垂直扩展：更换更高配置服务器，有硬件上限，大数据架构禁止依赖垂直扩容。

4. 通用性

一套架构可以处理日志、IoT、业务数据库、视频等多种数据源，不能只适配单一业务。

5. 可延展性

后续新增指标、新增数据源、新增业务的时候，不需要推翻整体架构。

6. 即席查询

业务分析师随时写临时 SQL 进行查询，查询条件不确定。Hive 不适合即席查询，Presto、Impal 适合。

7. 最低可维护性

集群组件众多，架构设计尽量降低运维压力，减少需要人工维护的地方。

8. 可调试性

支持数据血缘、任务日志，定位脏数据、计算错误、数据倾斜问题。

---

四、Lambda 架构

1. 三大核心设计原则

1. 数据不可变性 原始数据只允许追加写入，绝不原地修改更新。 如果业务数据出错，新增一条修正记录即可；历史原始数据永久保存，计算任务随时可以重新跑一遍。

这是大数据和传统数据库最本质区别，传统数据库支持 update 原地修改。

1. 读写分离 数据写入链路、查询服务链路完全分开，写入压力不会影响用户查询。

2. 复杂性隔离 复杂、重量级的全量计算交给批处理层；实时层只负责简单增量计算，降低实时层压力。

2. Lambda 三层结构详细拆解

① Batch‑Layer 批处理层

1. 存储：保存全部、完整、不可修改的原始数据集（HDFS）
2. 周期性（每日凌晨）执行全量批计算
3. 产出批视图：预计算好的指标、报表结果
4. 引擎：Hive、Spark

优点：全量数据计算，结果最准确，可以修正前一天所有脏数据。 缺点：延迟很高，只能第二天拿到前一日结果。

② Speed‑Layer 加速层 / 实时层

专门处理新到来的增量流式数据

1. 从消息队列 Kafka 读取实时新增数据
2. 做轻量级增量计算，产出实时视图
3. 引擎：Storm、Spark‑Streaming、Flink

实时层不去处理全部历史数据，只管新来的数据，因此延迟很低（秒级）。

③ Serving‑Layer 服务层

接收用户的查询请求，合并批视图 + 实时视图两份结果，返回完整结果。 举例子：查询今日 UV 批层计算 00:00‑凌晨 2 点数据；实时层计算凌晨 2 点到现在；服务层合并总数。 存储服务组件：HBase、ES、Cassandra，支持高速随机读取预计算视图。

3. Lambda 架构优缺点

优点

1. 容错能力极强，原始数据不可变，任务随时重跑
2. 批计算保证计算结果精准可靠
3. 水平扩展能力优秀
4. 离线、实时两条链路互不干扰

缺点

1. 两套业务代码：批处理代码、流处理代码分开开发维护 同一个指标需要写两套逻辑，容易出现两边计算逻辑不一致、结果对不上。
2. 两套计算引擎，组件多，部署复杂、运维压力大
3. 需要手动合并两份视图，开发工作量大

适用场景

离线报表为主、实时为辅；日志分析、用户画像、T+1 业务报表。

---

五、Kappa 架构

1. 出现原因

受不了 Lambda 两套代码、重复开发的缺陷。

2. 核心原理

抛弃独立的批处理层，只用一套流处理引擎（Flink） 所有数据全部当成无边界的数据流。

• 新来的数据：实时流计算
• 历史全量数据：把存储里面的历史原始数据重新回放成数据流，流引擎执行全量计算，等价批处理。

3. Kappa 三层结构

数据源 → Kafka 消息队列 → 统一流处理引擎 (Flink) → 查询服务层

4. Kappa 优缺点

优点

1. 一套业务代码，离线计算、实时计算共用同一套逻辑，不会出现逻辑不一致
2. 架构组件更少，架构简洁，运维简单
3. 可以随时回放历史数据重新计算指标

缺点

1. 对流处理器要求极高：需要强大状态管理、Checkpoint、故障恢复
2. 海量历史数据回放的时候，会产生巨大集群压力

适用场景

实时业务优先：实时风控、实时大屏、实时推荐、实时告警。

Sigma 架构

Kappa 升级版；按照热、温、冷数据分层流式处理，冷热数据分开存储。 热数据放在高速存储、冷数据低成本归档，用来节约存储成本，适合超大规模物联网平台。

Z‑Order 架构

面向多维索引优化，专门服务 OLAP 多维分析场景，考试只需要记住用途即可。

---

六、Lambda 架构 VS Kappa 架构 深度对比

对比项	Lambda 架构	Kappa 架构
计算引擎	批引擎 + 流引擎两套	单一流处理引擎，一般 Flink
业务实现代码	两套计算逻辑，重复开发	一套代码复用
全量历史计算	定时批任务扫描全量数据	回放历史数据流
数据延迟	批层延迟高	延迟可控，可以做到低延迟
开发难度	高，需要维护两套代码	低，统一一套逻辑
集群运维	组件繁多、运维复杂	架构精简
风险点	批‑实时逻辑不一致	历史回放压力大
适用业务	T+1 离线报表为主	实时业务优先场景

七、大数据五层技术栈详细拆解

1. 数据采集层

1. 日志采集

• Flume：分布式日志收集，适合海量服务器日志
• Logstash：ELK 组件，轻量化日志采集

1. 数据库数据同步

• Sqoop：关系数据库 ↔ HDFS 之间数据导入导出
• Canal：监听 MySQL binlog，实时抓取数据库增量数据
• Debezium：支持多种数据库 CDC 增量同步

1. 消息中间件（缓冲层，必懂） Kafka：高吞吐、分区机制、可以保存历史消息，Kappa 架构依靠 Kafka 实现数据回放。

2. 数据存储层 逐个详解

（1）HDFS 分布式文件系统

HDFS 三大机制

1. 文件分块：大文件切成固定大小数据块
2. 多副本：默认 3 副本，副本存放在不同机器，机器宕机数据不丢失
3. 数据本地化：计算任务调度到数据所在节点，减少网络传输 IO（重要设计原则） NameNode：管理元数据；DataNode：存储真实数据块。

（2）KV 分布式数据库 HBase

适合海量数据随机读写；列族存储；常用于 Serving 层保存预计算视图。

（3）数据仓库

分层标准 ODS‑DWD‑DWS‑ADS（案例大题经常考数仓分层）

1. ODS：原始数据层，同步过来的原始业务数据
2. DWD：明细数据层，经过清洗之后干净明细数据
3. DWS：汇总层，按照用户、商品等维度聚合出宽表
4. ADS：应用层，直接供报表、大屏使用指标表 主流组件：Hive、ClickHouse、Greenplum、Kylin、Druid

Hive 本质不是数据库，是 MapReduce/Spark 的 SQL 封装，把 SQL 翻译成分布式计算任务，适合离线分析。

(4) 数据湖

存储所有原始结构化、半结构化、非结构化数据； 特点：Schema‑on‑Read，写入的时候不需要定义表结构，读取的时候再解析结构。 主流框架：Iceberg、Hudi、Delta‑Lake（湖仓三巨头）

(5) 湖仓一体

融合数据湖和数据仓库；原始数据存数据湖；经过分层建模之后具备数仓能力，现在主流架构。

3. 计算引擎层重难点对比

① MapReduce

计算模型 Map → Shuffle → Reduce 缺点：每一个阶段结束，结果写入磁盘；磁盘 IO 开销巨大；迭代型任务性能很差。

② Spark Core

核心概念 RDD 弹性分布式数据集、DAG 有向无环图。 核心优势：内存计算，中间计算结果优先放内存，减少频繁磁盘读写； 任务划分 DAG，划分 Stage，性能远超 MapReduce。

③ Spark‑Streaming

微批处理：每隔一段时间（比如 1s）收集数据流，当成一个小批数据交给 Spark 处理。 本质依旧是批处理，因此延迟下限受批次间隔约束；无法做到真正流式。

④ Flink（现在工业界主流实时引擎）

1. 原生流式计算，数据流是无界流
2. 事件时间、水印 Watermark，解决乱序数据
3. 强大状态后端、Checkpoint 检查点机制，实现 Exactly‑Once 精准一次语义

考试必背区别：SparkStreaming = 微批；Flink = 原生流处理，适合低延迟、乱序数据流。

⑤ 即席查询引擎

Presto (Trino)、Impala；专门用于分析师临时 SQL 查询，低延迟交互式查询。

4. 数据治理层

大数据架构不只是搭建组件，数据治理是重中之重

1. 元数据管理：记录表结构、字段注释
2. 数据血缘：追踪数据从哪里采集、经过哪些计算任务生成；排查脏数据必备
3. 数据质量四大指标：完整性、唯一性、准确性、时效性、一致性
4. 数据标准：统一字段命名、统一编码
5. 安全治理：敏感字段脱敏、权限控制、行级列级权限、数据加密

5. 数据服务应用层

对外提供标准化 API、指标平台、可视化大屏、用户画像、机器学习平台。

---

八、大数据架构七大设计原则

1. 原始数据不可变原则，只追加不修改
2. 读写分离，写入链路与查询链路隔离
3. 计算向数据靠拢（数据本地化，减少网络 IO）
4. 冷热分层存储：热数据 SSD 高速盘，冷数据低成本归档存储，节约成本
5. 副本容错、任务检查点保障容错
6. 计算任务幂等性，保证多次运行结果一致、Exactly‑Once
7. 分层解耦：采集层、存储层、计算层、服务层之间解耦，可以独立扩容。

---

九、数仓 VS 数据湖

1. 数据仓库

• 只保存清洗过后结构化数据
• Schema‑on‑Write：写入前定义表结构
• 适合固定报表、指标分析 缺点：无法方便存储日志、视频等非结构化数据

1. 数据湖

• 保存全部原始异构数据，结构化、半结构化、非结构化
• Schema‑on‑Read：读取的时候解析结构 优点：原始数据永久保存，后期可以随时更换分析方式 缺点：缺少治理很容易变成「数据沼泽」，数据杂乱无法使用

---

十、大数据系统常见问题与优化

1. 数据倾斜 现象：大部分 task 很快跑完，少数任务处理海量数据、执行极慢。 成因：key 分布不均匀，部分 key 数据量巨大。 优化：加盐打散 key、预聚合、拆分热点 key。

2. Kafka 消息堆积 消费速度小于生产速度；优化：增加消费者、拆分 topic 分区、优化消费逻辑。

3. 乱序数据流 实时数据流到达顺序错乱；Flink 依靠水印 Watermark 处理迟到数据。

4. 任务故障 开启 Checkpoint、状态持久化，故障之后从最近检查点恢复计算。