从单机到集群

【分而治之：大数据的总纲】
  100 亿条数据 → 切成 1 万块 → 100 台机器各算 1 万条
  → 汇总 → 结果。这就是 MapReduce 和一切分布式计算的雏形

【CAP 理论（必考）】
  C 一致性：所有节点同时看到同一份数据
  A 可用性：任何时刻都能读写（不报错）
  P 分区容错：网络断了系统还能工作
  → 网络断是必然（P 必须选），所以只能 CP 或 AP 二选一
  → MySQL 集群选 CP，缓存 Redis 选 AP（最终一致）

【数据本地性（Data Locality）】
  与其把数据搬到计算处，不如把计算搬到数据处
  → 谁存着数据，谁就来算——少搬数据，快十倍

【故障是常态】
  100 台机器里，每天坏一台是「正常」的
  分布式系统必须「设计成能容忍故障」：副本、重试、自愈

【面试必问金句】
  「分布式系统的本质：一群会坏的单机，协同完成单机做不了的事」

        ┌─────────────┐
        │  NameNode    │ ← 老大：只管元数据（目录/块位置/副本）
        └──────┬──────┘
        ┌──────┼──────┐
   ┌────┴──┐ ┌┴─────┐ ┌┴─────┐
   │DN-01  │ │DN-02 │ │DN-03 │  ← DataNode 小弟们：各存数据块
   └───────┘ └──────┘ └──────┘
   写入 300MB 文件：
   切成 3 块（128+128+44MB）
   块1 → DN-01, DN-02, DN-03（3 副本，跨机器！）
   块2 → DN-02, DN-03, DN-01
   → 任意坏 2 台，数据不丢

【对象存储（现代新宠）】
  S3 / 阿里云 OSS / MinIO（自建）
  优势：无限扩容、按量付费、和 Spark/Flink 无缝对接
  大数据新项目：对象存储 + 计算分离 已成主流

【考点：NameNode 单点】
  老大挂了整个集群不可用 → 高可用方案（Active/Standby + JournalNode）

-- 100 亿条订单，算各分类营收（Spark 自动分布式执行）
SELECT category, SUM(amount) AS revenue
FROM orders
WHERE dt BETWEEN '2026-09-01' AND '2026-09-30'
GROUP BY category
ORDER BY revenue DESC;

-- 背后发生了什么：
-- 读 HDFS/对象存储 → 自动分区并行扫描（Map）
-- 按 category 打散重排（Shuffle）
-- 各节点局部聚合 → 汇总（Reduce）
-- 100 台机器并行，20 分钟出结果

【Spark 核心概念】
  RDD / DataFrame：分布在不同机器上的数据集合
  宽依赖 vs 窄依赖：窄依赖不用 Shuffle（快），宽依赖要（慢）
  血缘（Lineage）：计算步骤记录，故障可重算
  惰性求值：只记「计算计划」，真正要结果才执行
  Spark SQL / DataFrame API：写起来像 SQL，跑起来分布式

-- Flink SQL：流上直接写 SQL
INSERT INTO revenue_per_minute
SELECT TUMBLE_START(ts, INTERVAL '1' MINUTE) AS win_start,
       SUM(amount) AS revenue
FROM orders_stream              -- Kafka 里的实时订单流
GROUP BY TUMBLE(ts, INTERVAL '1' MINUTE);  -- 1 分钟窗口

【Flink 核心概念】
  有状态计算：记住历史累计（每分钟营收要基于之前的状态）
  窗口：滚动窗口/滑动窗口/会话窗口
  Checkpoint：状态快照 → 故障从快照恢复（不从头算）
  Exactly-Once：精确一次语义——账不能多记也不能少记
  背压（Backpressure）：下游慢了，上游自动减速（别挤爆）

【Kafka 核心概念】
  Topic（主题）/ Partition（分区）/ Offset（偏移量）
  消费者组：一组消费者并行消费同一 Topic
  Broker：Kafka 节点；副本机制保消息不丢

【埋点日志流】
App 埋点 → 日志文件 → Filebeat(采集) → Kafka(transport)
  → Flink 清洗/解析 → 数仓 ODS 层 → 质量规则校验（第8本）

【数据库 CDC 流】
MySQL 订单表 ──binlog──→ Canal → Kafka(CDC topic)
  → Flink → 实时数仓 / 宽表更新
  → 好处：业务库不用改一行代码，变更自动同步

【采集设计要点】
  埋点规范：事件名 snake_case、必填属性、版本号（防乱埋）
  幂等采集：重复投递不产生重复数据（配合去重）
  分区策略：按时间/用户 hash 分区，保证有序与并行
  背压与重试：下游慢了自动缓冲，别丢数据

【Kafka 在采集中的角色】
  削峰填谷：业务高峰瞬间百万条，Kafka 先存着慢慢消费
  解耦：生产者和消费者互不等待——「高速公路服务区」

查询：SELECT category, SUM(amount) FROM orders GROUP BY category

【MySQL（行式存储）】
  一行的所有列挨着存 → 就算只要 category+amount，
  也得把整行的其他列全读出来 → 10 亿行 × 全列 = 慢

【ClickHouse（列式存储）】
  每列单独存 → 只读 category、amount 两列！
  读的数据量少 90% + 向量化批量计算
  → 10 亿行聚合，秒级返回

【Hive vs ClickHouse 分工】
  Hive：超大表离线全量算（小时级）→ 结果灌给 ClickHouse
  ClickHouse：对外提供秒级查询（老板看板直接查它）
  → 「重活给 Hive，快活给 OLAP」

【数仓技术栈配合】
  明细/汇总（DWS）→ ClickHouse/Doris 加速层 → BI 看板
  宽表建模、物化视图、预聚合——OLAP 提速三板斧

                    02:00 定时触发
                        │
               ┌────────┴────────┐
          采集任务A          采集任务B（并行！）
               └────────┬────────┘
                        │
                   清洗任务（等 A、B 都完成）
                        │
              ┌─────────┼─────────┐
         汇总任务C    汇总任务D   质量校验
              └─────────┼─────────┘
                        │
                  报表生成任务（等全部完成）
                        │
                    08:00 老板看到日报 ✓

【编排要点】
  DAG：有向无环图——任务依赖的「流程图」
  失败重试：网络抖了？重试 3 次再说
  超时告警：跑超 4 小时 → 钉钉提醒
  补数据：昨天失败了？支持「回刷」历史日期

【资源管理】
  YARN 队列：dev/prod 隔离，生产任务优先
  K8s 化：容器调度 Spark/Flink——云原生新趋势
  成本：错峰跑批（晚上便宜）、弹性扩缩容

┌─────────────────────────────────────────┐
│  应用层：BI看板 / 数据服务API / 账小灵    │
├─────────────────────────────────────────┤
│  分析层：Hive | Spark SQL | ClickHouse    │
├─────────────────────────────────────────┤
│  计算层：Spark(批) | Flink(流) | MR(老)  │
├─────────────────────────────────────────┤
│  存储层：HDFS | 对象存储 | HBase | 数仓  │
├─────────────────────────────────────────┤
│  资源层：YARN | K8s                      │
├─────────────────────────────────────────┤
│  协调层：Zookeeper（选主/配置）           │
├─────────────────────────────────────────┤
│  采集层：Filebeat | Canal CDC → Kafka    │
└─────────────────────────────────────────┘

【HBase 何时用】
  海量 + 随机读写 + 准实时查询
  例：亿级订单明细「按用户查最近 100 条」
  行键设计（RowKey）是性能关键——热门考点

【自建 vs 云上（选型决策）】
  自建：数据敏感/量超大/已有机房 → CDH/Doris 自建集群
  云上：起步快/弹性/省运维 → EMR / MaxCompute / Databricks
  混合：核心自建 + 弹性上云（峰时扩容）

【核心组件部署形态】
  传统：Hadoop 全家桶一套集群
  现代：对象存储 + Spark/Flink + OLAP，轻量云原生

【架构演进】
  第一代：HDFS + Hive（仓）与 数据湖（分开两套）→ 数据双份、同步难
  第二代：湖仓一体 —— 对象存储 + Iceberg/Delta + Spark/Flink
          ↓
  一份存储（湖） + 一套表格式（ACID/时间旅行）+ 多种引擎（批/流/BI）

【Iceberg 核心概念】
  Table Format（表格式）：给数据湖加「事务层」
  Snapshot（快照）：每次写入产生一个快照 → 时间旅行的基础
  Metadata（元数据）：表结构、分区、快照的管理

【应用方式】
  离线：Spark 读写 Iceberg 表（全量 + 增量）
  实时：Flink 流式写入 Iceberg（分钟级可见）
  查询：Spark SQL / 引擎直接查

【和数仓的关系（不是替代！）】
  湖仓一体 = 底座；数仓分层思想照用（ODS/DWD/DWS/ADS）
  只是「住在湖里」+「有了 ACID」+「能时间旅行」

【数据倾斜】
  症状：99% 任务 5 分钟跑完，最后 1% 跑了 3 小时
  原因：某个 key（如「北京」）数据量巨大
  解法：加盐打散（随机前缀拆分再合并）、两阶段聚合、
       广播小表（Join 时小表广播到每台机器）

【小文件问题】
  症状：几百万个小文件，任务启动就花了 10 分钟
  解法：合并小文件（Coalesce/Repartition 控制分区数）、
       写入前设置目标文件大小、分区裁剪

【Shuffle 优化】
  症状：任务 70% 时间在「搬数据」
  解法：减少宽依赖、合理分区键、使用广播变量、
       聚合类算子优先（reduceByKey 优于 groupByKey）

【资源与内存】
  症状：OOM 内存溢出 / 并行度不够
  解法：调整 Executor 内存/并行度、Flink 状态 TTL、
       背压排查（下游消费不过来）

【Flink 特有】
  状态过大 → 调大 RocksDB 状态后端 / 清理过期状态
  窗口乱序 → Watermark 水位线设计

【面试加分金句】
  「先看数据特征（倾斜/大小/分布），再谈调优——
   调优的本质是『让每一台机器都吃饱，且不多干活』」