全栈攻城狮

Appearance

大数据技术全景概述 ​

概述 ​

大数据不是某一种技术，而是一整套解决"数据量大、种类多、产生快、价值密度低"问题的技术栈。从 Hadoop 诞生到今天，大数据生态已经演化出存储、计算、调度、治理、分析等完整体系。本文作为系列开篇，先建立全局视图：大数据要解决什么问题、架构如何演进、生态里每个组件各司其职，以及面对技术选型时如何思考。

一、大数据要解决什么问题 ​

1.1 与传统数据处理的差异 ​

维度传统数据处理大数据处理
数据规模GB ~ TB 级TB ~ PB 级
数据类型结构化为主结构化 + 半结构化 + 非结构化
处理模式单机 / 单库分布式集群
时效性以离线批量为主离线 + 实时并存
存储成本相对可控需要低成本水平扩展

核心矛盾在于：单台机器的计算与存储能力有上限，而数据增长没有。解决思路是水平扩展——用大量普通机器组成集群，通过分布式技术把任务和数据分散处理。

1.2 大数据的四个 V ​

V含义带来的挑战
Volume（数据量）海量数据存储与计算如何扩展
Velocity（速度）产生与处理速度快实时性如何保障
Variety（多样性）类型多样异构数据如何统一
Value（价值）价值密度低如何从海量数据中挖掘价值

二、大数据架构演进脉络 ​

2.1 三代架构 ​

第一代（2006—2010）：Hadoop 生态
  单一批处理，HDFS + MapReduce
        │
        ▼
第二代（2010—2015）：离线 + 实时并存
  批（MapReduce/Spark）+ 流（Storm/Spark Streaming）
        │
        ▼
第三代（2015 至今）：湖仓一体 / 实时数仓
  流批一体（Flink）+ 数据湖（Iceberg/Delta/Hudi）+ 云原生
代际代表技术特点
第一代HDFS、MapReduce解决"能存下、能算动"，批处理为主
第二代Spark、Flink、Kafka引入内存计算与实时流处理
第三代数据湖、湖仓一体、云原生存算分离、流批一体、开放格式

2.2 Lambda 与 Kappa 架构 ​

  • Lambda 架构：批处理层（准确）+ 速度层（实时）+ 服务层（合并），两套代码，复杂度高
  • Kappa 架构：统一用流处理，消息系统做数据缓冲与回放，一套代码

两种架构的取舍在"实时与准确性"之间：Lambda 以复杂度换一致性，Kappa 以重放能力简化体系。

三、大数据生态图谱 ​

3.1 全链路技术分层 ​

┌─────────────────────────────────────────────────┐
│ 数据应用层：BI / 报表 / 大屏 / 推荐 / 风控 / AI  │
├─────────────────────────────────────────────────┤
│ 数据服务层：指标平台 / 自助分析 / 数据 API       │
├─────────────────────────────────────────────────┤
│ 计算引擎层：MapReduce / Spark / Flink / Presto   │
├─────────────────────────────────────────────────┤
│ 存储层：HDFS / HBase / 数据湖 / ClickHouse / Doris│
├─────────────────────────────────────────────────┤
│ 数据接入层：Flume / Sqoop / Canal / DataX / Kafka │
├─────────────────────────────────────────────────┤
│ 资源与调度：YARN / Kubernetes / Airflow / Dophin │
├─────────────────────────────────────────────────┤
│ 底层基础：ZooKeeper / 服务器集群 / 网络 / 存储   │
└─────────────────────────────────────────────────┘

3.2 核心组件职责一览 ​

类别组件职责
分布式存储HDFS海量文件的分布式存储，大数据的基础
资源调度YARN集群资源（CPU/内存）统一分配与任务调度
批计算MapReduce / Spark离线大规模数据处理
流计算Flink / Spark Streaming实时数据处理
列式数据库HBase海量结构化数据的随机读写
数据仓库Hive / Impala / PrestoSQL 化分析数仓数据
OLAPClickHouse / Doris / Kylin交互式多维分析
消息系统Kafka / Pulsar数据管道与解耦
数据湖Iceberg / Delta / Hudi统一存储与开放格式
数据集成Sqoop / DataX / Flume / Canal数据同步与采集
调度编排Airflow / DolphinScheduler工作流任务编排
数据治理Atlas / DataHub元数据、血缘、质量、安全
协调服务ZooKeeper分布式协调、选举、配置

3.3 数据流转全景 ​

以企业典型场景为例，数据从产生到消费的完整链路：

业务数据库 / 日志 / 埋点 / 传感器
        │
        ▼
采集同步（Canal / Flume / DataX / Kafka）
        │
        ▼
存储落地（HDFS / 数据湖 / HBase）
        │
        ▼
计算加工（Spark 离线 / Flink 实时 / Hive SQL）
        │
        ▼
数仓分层（ODS → DWD → DWS → ADS）
        │
        ▼
查询分析（Presto / ClickHouse / Doris / BI 工具）
        │
        ▼
应用消费（报表 / 大屏 / 推荐 / 风控 / 算法）

四、关键技术概念 ​

4.1 批处理 vs 流处理 ​

维度批处理流处理
数据形态静态数据集持续到达的事件流
延迟分钟 ~ 小时级秒级甚至毫秒级
代表MapReduce、SparkFlink、Spark Streaming
场景离线报表、全量分析实时监控、风控、大屏

4.2 存算分离 vs 存算一体 ​

  • 存算一体：计算与存储在同一批节点（传统 Hadoop），数据本地性友好
  • 存算分离：存储用对象存储/云存储，计算弹性伸缩（Spark on S3、数据湖方案），成本与弹性更优

4.3 OLTP 与 OLAP ​

维度OLTPOLAP
目标事务处理分析查询
数据形态行式存储列式存储为主
特点高并发小查询大扫描聚合分析
代表MySQL、PGClickHouse、Doris、Presto

五、技术选型指南 ​

5.1 选型决策框架 ​

选型不是"哪个最火选哪个"，而是围绕场景做权衡：

问题定义：数据量？实时性？查询模式？成本？团队能力？
    │
    ▼
方案空间：自建开源 / 云服务 / 混合
    │
    ▼
约束评估：运维能力、成本预算、SLA 要求、扩展预期
    │
    ▼
决策：主技术栈 + 演进路径

5.2 典型场景推荐组合 ​

场景推荐组合理由
离线数仓HDFS + Hive + Spark + 调度成熟稳定，生态齐全
实时链路Kafka + Flink + Doris端到端低延迟
湖仓一体对象存储 + Iceberg + Spark/Flink + Doris存储成本低、流批统一
交互式分析ClickHouse / Doris + Presto秒级响应
轻量起步单机 Hadoop / 云托管组件快速验证，避免过度建设

5.3 选型常见误区 ​

误区说明
追新不用旧稳定成熟的技术栈比"最新"更重要
上来就上全套从最小可行方案起步，按需扩展
忽视运维成本组件越多，运维负担越重
不评估团队能力技术方案要和团队技能匹配

六、技术栈覆盖范围 ​

大数据体系按"从底层到上层、从离线到实时、从存储到治理"组织，覆盖的板块包括：

  1. Hadoop 生态与存储基础：HDFS、YARN、MapReduce、HBase、ZooKeeper
  2. 数据仓库与 Hive：数仓建模、分层架构、Hive SQL 优化
  3. Spark 生态系统：Core、SQL、Streaming、调优
  4. Flink 实时计算：基础、进阶、CDC、CEP
  5. 数据湖与实时数仓：Iceberg/Delta/Hudi、实时分层
  6. OLAP 引擎：ClickHouse、Doris、Kylin、Druid
  7. 数据集成与调度：CDC、同步、Airflow、DolphinScheduler
  8. 数据治理与平台：元数据、血缘、质量、安全、数据平台
  9. Kafka 深度与消息平台：架构、副本、存储、Kafka Streams
  10. ML on Big Data 与前沿：机器学习平台、云原生大数据、数据网格

阅读时可以对照这个结构定位自己在体系中的位置，每个板块聚焦一个主题，原理、实践与常见问题放在一起讲透。

参考链接：