024、大数据技术栈概览：Hadoop、Spark与Flink

排查一个线上问题，集群凌晨ETL任务突然卡住，日志里反复报"No space left on device"。查了半天发现不是磁盘满，而是HDFS的DataNode线程池耗尽------某个MapReduce任务开了上千个Mapper，把节点拖垮了。这事儿让我重新审视团队的技术栈选型：我们是否还在用"大炮打蚊子"？今天聊聊Hadoop、Spark、Flink这三个老伙计，它们不只是技术选项，更是不同数据处理哲学的体现。

Hadoop：笨重但扎实的基石

Hadoop的核心其实是HDFS和MapReduce。现在很少有人直接写MapReduce代码了，但它的设计思想还在影响整个生态。记得刚接触时，我对着WordCount例子琢磨了半天------为什么要把简单的事情拆成map、shuffle、reduce三步？后来在处理TB级日志时才明白：数据大到放不进单机内存时，你只能切碎了慢慢啃。

java 复制代码

// 典型MapReduce结构（伪代码）
map(key, value): 
    // 这里踩过坑：别在map里做全局统计，它看不到全量数据
    emit(intermediate_key, intermediate_value)

reduce(key, values):
    // 小心内存溢出，values可能是海量迭代器
    result = aggregate(values)
    emit(key, result)

Hadoop生态的精致在于YARN的资源调度。但它的痛点也很明显：中间结果写磁盘太慢，迭代计算（比如机器学习训练）能让你等到怀疑人生。我们团队现在只拿它做冷数据归档和超大规模批处理------就像仓库里那台老式冲床，平时不用，但压钢板时还得它上。

Spark：内存计算的暴力美学

Spark最初就是针对Hadoop的磁盘IO瓶颈来的。第一次看到RDD（弹性分布式数据集）概念时，我拍大腿了------把数据抽象成内存里的对象图，这才是程序员该有的思维。但早期Spark调优简直是玄学：内存分多少给storage？多少给execution？shuffle分区数设多少？记得有个任务设了2000个分区，结果调度开销比计算时间还长。

scala 复制代码

// Spark典型操作（Scala）
val rdd = sc.textFile("hdfs://...")
  .filter(_.contains("ERROR"))      // 转换懒加载，这里不触发计算
  .cache()                          // 重要：复用RDD一定要cache，否则重复算
  
// 行动操作触发DAG执行
rdd.count()                         // 这里才真正跑任务

// 踩坑提醒：collect()小心点，数据量大会把driver内存撑爆

Spark Structured Streaming出来之后，我们一度用它替换了部分流处理任务。但后来发现它的"微批处理"本质------底层还是按批次调度，对秒级延迟敏感的场景还是勉强。不过MLlib和GraphX确实香，特别是做图计算时，比MapReduce版本快几十倍。

Flink：流处理的本质洞察

Flink最颠覆的设计是把流作为一等公民，批只是流的特例。刚开始接触时很不适应：它的时间窗口、水位线、状态后端这些概念比Spark复杂得多。但做过一次实时风控系统后就真香了------事件时间处理、精确一次语义（exactly-once）这些特性，在金融场景里是刚需。

java 复制代码

// Flink流处理片段（Java API）
DataStream<Event> stream = env
  .addSource(new KafkaSource<>())
  .keyBy(Event::getUserId)
  .window(TumblingEventTimeWindows.of(Time.minutes(5)))
  .process(new MyWindowFunction());

// 关键理解：水位线是"事件时间进度"的信使
// 设太激进会丢数据，设太保守延迟高------需要根据业务权衡

我们在物联网场景用Flink处理传感器数据时，遇到过状态后端爆内存的问题。后来切到RocksDB状态后端才稳住，但IO开销又上来了。Flink的调优像走钢丝：托管内存、网络缓存、检查点间隔......每个参数都可能成为瓶颈。

技术选型的现实考量

去年做数据平台升级时，我们画了张二维图：横轴是数据延迟要求（小时级到毫秒级），纵轴是开发运维成本。结果发现：

离线报表和天级T+1任务：还是跑在Hadoop上最经济，资源利用率高，失败重试机制成熟
交互式查询和机器学习：Spark占主导，特别是Notebook开发模式，算法同事喜欢直接写PySpark
实时监控和事件驱动流程：Flink一揽子解决，但得配个懂内部机制的团队盯着

有个经验之谈：别盲目追求技术时髦。我们曾用Spark Streaming处理每分钟几个事件的数据流，结果资源开销是Flink的3倍------杀鸡用牛刀还费电。

调试心法

Hadoop出问题先看资源：检查YARN队列资源、HDFS磁盘平衡、DataNode线程数。它的错误信息经常是"症状"而非"病因"
Spark应用慢时看DAG图：Stage划分不合理会导致大量shuffle。记住：窄依赖比宽依赖快，合理分区数是核心技能
Flink背压（backpressure）报警：大概率是sink写慢了，而不是计算逻辑问题。Kafka连接器配置不对能把整个管道拖垮

最后说个反直觉的观点：这三个框架未来可能都会淡出。云厂商的Serverless数据服务（比如AWS Glue、Google Dataflow）正在抽象掉集群管理的痛苦。但理解它们的核心思想------分而治之、内存优先、流式本质------比掌握API更重要。就像你会开车就行，不必精通发动机原理，但知道变速箱怎么工作，至少能在半路抛锚时判断是不是该叫拖车。

下次聊聊我们在混合架构里怎么让这三个系统共存：Hadoop做数据湖底层存储，Spark跑日终批量分析，Flink处理实时流------像一支分工明确的工程队，挖地基的、砌墙的、装修的各司其职。技术栈没有银弹，只有适不适合你的业务节奏。