Hadoop、Spark、Flink怎么选？从批处理到流处理的技术演进与实战权衡

选型之前，先看清三个引擎各自站在什么位置

上个月我帮一家做供应链系统的公司做技术选型评审，数据团队负责人一上来就问我：我们要不要放弃Hadoop，全量切到Flink？我反问他为什么想切，他说因为领导看到社区里都在说“Hadoop已死，Flink才是未来”。这个回答我听过太多次了。过去几年里，“XX已死”的句式几乎每年换一个主角——先是MapReduce被Spark“拍死”，接着Spark Streaming被Flink“拍死”。可现实是，HDFS到现在依然是很多企业数据底座的一部分，Spark承担着大量离线ETL和机器学习任务，Flink则在实时数仓里越来越吃香。这三个引擎并不是一代淘汰一代的关系，而是各自占据了不同的计算边界。

这篇想把Hadoop、Spark、Flink的选型逻辑讲透：它们底层到底差在哪儿，各自擅长什么，哪些业务场景该用哪个，以及我过去几年做选型时反复权衡的那几个问题。适合正在搭大数据平台的技术负责人、准备转行数据开发的工程师，以及被各种面试题里Hadoop/Spark/Flink搞得头疼的同学。

1. 选型不是比新老，先回答三个问题再说

1.1 从磁盘批处理到内存计算再到流优先：三个时代的不同答案

把时间倒回2006年左右，Google发表MapReduce论文之后，Hadoop迅速成为大数据的事实标准。那时候的数据处理，核心思路是“先把数据切块放到HDFS上，再用MapReduce任务把结果算出来”。MapReduce的设计目标是吞吐优先，它能用成百上千台机器处理PB级数据，但代价是每一步中间结果都要落盘，所以一个复杂任务跑几十分钟甚至几小时很正常。

2014年前后Spark开始大规模流行，它的核心贡献是把中间结果尽量留在内存里。同样是跑一个多阶段的复杂作业，Spark可能比MapReduce快一个数量级。再加上Spark SQL把门槛降到“会写SQL就行”，很多人都觉得Spark就是大数据的终极答案。

再往后，业务对实时性的要求上来了。风控要毫秒级识别异常操作，大促要实时盯流量和订单，监控要秒级看到指标变化。批处理无论如何都满足不了这种时效性，所以Flink这种“天生以流为核心”的引擎开始登上主舞台。注意，Flink不是“处理得更快的批处理”，它在架构设计上和批处理完全是两条路。

1.2 选型先回答的三个问题

我一般会把选型决策压缩成三个问题，尤其适合第一次搭数据平台的团队：

• 你的数据能容忍多久的延迟？分钟到小时级别，批处理就够了，Spark和Hive都能胜任；秒级到分钟级，考虑Spark Structured Streaming这类准实时方案；毫秒到秒级，才需要上Flink这样的真流处理。
• 你的数据是有界的还是无界的？这里的“有界”指的是数据在某个时间点就结束了，比如昨天的订单表；“无界”指的是数据永远在产生，比如App里每时每刻的点击日志。无界数据天然适合流式处理框架，因为你需要“持续计算”，而不是“跑完就结束”。
• 团队能长期维护哪种技术栈？这是最容易被忽视的问题。Hadoop、Spark、Flink全都涉及Java/Scala体系，但上手成本差异很大。只写SQL的团队，可能一开始用Hive或Spark SQL更顺手；有Java/Scala底子的团队，才有余力把Flink的流式任务真正玩明白。

1.3 “新引擎替代旧引擎”是最大的误读

不少读者会把“Hadoop”和“MapReduce”画等号，然后得出“Hadoop过时了”的结论。但Hadoop生态里不只是MapReduce，还包括HDFS分布式文件系统、YARN资源调度、ZooKeeper协调服务。哪怕你完全不用MapReduce，只用Spark和Flink，HDFS依然可以充当底层存储，YARN依然可以是任务调度平台。换句话说，Hadoop这个“底座”并没有消失，消失的只是“必须用MapReduce写作业”这个习惯。

我见过很多团队喊着“去Hadoop”，结果只是把MapReduce换成了Spark SQL，HDFS换成对象存储或者保留原样。所以不要被“谁替代谁”这种口号带偏，先看业务需要什么，再看引擎擅长什么。

2. 从运行原理看本质区别：磁盘、DAG与状态流

2.1 Hadoop MapReduce为什么慢，以及它“慢但稳”的价值

用一个最经典的WordCount来感受MapReduce的运行方式：输入文本被切成一个个分片，map阶段把每个词拆出来打上“词, 1”的标签，输出先写到本地磁盘；shuffle阶段系统把相同key的记录拉到一个reduce节点上并排序；reduce阶段再做累加。中间结果反复落盘，是MapReduce慢的根本原因。但换个角度看，这种设计换来了极强的稳定性，每一步都有中间文件和容错兜底，哪怕某个节点挂了，数据也可以从上一个阶段恢复。

直到今天，MapReduce仍然在某些超大规模离线场景里有存在价值，比如数据量极大、又不能把所有中间结果都塞进内存的任务。但在绝大多数实际项目里，Spark已经能承接这类离线批处理的活儿，而且快得多。所以现在很多企业里的MapReduce作业，主要是一堆历史遗留任务，新任务基本不会再写了。

2.2 Spark的RDD、DAG与惰性求值：内存红利到底是怎么来的

Spark的核心抽象是RDD（弹性分布式数据集）。你的数据被切分到多个分区，分布在集群的不同机器上。开发者对RDD调用一系列转换算子，比如map、filter、join，Spark不会立刻执行这些操作，而是先构建出一张由操作构成的有向无环图（DAG）——我喜欢把它想成一张“菜谱”，上面记录了每一步该做什么，但真正开火做饭要等“行动算子”出现，也就是需要输出结果的那一刻。

这种“惰性求值”的设计，配合“血缘”机制，是Spark能比MapReduce快的关键。血缘记录了一个分区是怎么由源头数据一步步转换来的。某个分区算到一半节点挂掉了，Spark可以根据血缘从原始数据重新算出来，不需要像MapReduce那样把每一步中间结果都落盘。再加上引擎会把多个窄依赖的算子尽量在一个阶段内串起来执行，减少shuffle次数，性能自然就上来了。

Spark的另一个红利是内存计算对迭代式算法极友好。机器学习里很多算法要反复扫描数据调整参数，如果每轮迭代都要读写磁盘，那基本没法训练。Spark把训练数据缓存在内存里，迭代效率直接成倍提升。这也是为什么到目前为止，Spark MLlib在机器学习流水线里仍然比Flink更适合。但内存不是无限的，数据量超过executor内存时就会溢写到磁盘，所以后面我要专门说Spark内存配置的坑。

2.3 Flink的Checkpoint、状态与事件时间：它凭什么敢叫真流式

Flink一上来就按“事件驱动”设计。数据流里的每个事件，到了算子就立刻触发计算，不存在“攒一批再算”的概念。但这只是“流式计算”的表面，Flink真正强大的是三个配套能力：状态管理、Checkpoint和时间语义。

先看状态。如果一个算子在持续接收同一个用户的登录事件，要统计这个用户连续登录几天，那“这个用户之前登录了几天”就属于算子内部的中间状态。Spark Streaming的微批模型天然弱化状态概念，你需要把状态放到外部存储里反复对账；而Flink把状态做成引擎一级的能力，直接保存在StateBackend里，读写都在本地，速度很快。

再看Checkpoint。分布式系统里节点随时可能挂掉，Flink通过给“算子状态 + 数据源的位置”定期做分布式快照，实现故障后的精确恢复。这个概念听起来简单，但“流”是无穷无尽的，你把状态快照刷到哪、怎么保证快照之间数据不重不漏，全都要靠barrier对齐这类机制来实现。这也是Flink代码学习曲线比较陡的原因之一。

最后是时间语义。Flink支持事件时间（Event Time）、处理时间（Processing Time）和摄取时间（Ingestion Time），配合Watermark机制处理乱序数据。比如一个传感器事件晚到了10秒，用处理时间统计就会算错窗口，但用事件时间配合Watermark，可以在一定容忍范围内把它归到正确的窗口里。Spark Structured Streaming虽然也支持事件时间，但底层仍然是微批调度，在事件驱动和低延迟场景下始终不如Flink“原汁原味”。

3. 一张对比表收拢核心差异，外加几个容易搞混的边界

3.1 从延迟、状态、SQL、生态看三者的真实位置

从这张表能清楚地看到：Spark最舒服的位置在“需要跑复杂批处理、又要兼顾一些准实时需求的场景”；Flink最舒服的位置在“低延迟、高状态、强一致性要求的实时链路”；Hadoop则更多以HDFS、YARN这些基础设施身份出现，而不是“写MapReduce作业”这件事。

3.2 被误读最多的四个边界问题

“Hadoop已死”不等于“HDFS已死”。HDFS作为分布式存储到今天仍是很多平台数据湖的地基，只是新架构里它和对象存储（比如MinIO、云上OSS/S3）经常共存，计算层让位给了Spark和Flink。

“Spark Streaming不等同于Flink”。Spark Structured Streaming在2.x以后已经很不错，但微批调度的本质决定了它在窗口粒度、事件时间和状态一致性上会比Flink吃力。实时场景不要轻易拿Spark Streaming硬顶Flink的位。

“Flink也扛得住批处理，不代表你该把离线全切给Flink”。Flink 1.x开始推流批一体，思路是对的，但生产环境里批处理生态如Hive元数据、Spark SQL各种成熟语法、成千上万的历史调优参数，不是说换就换。

“Hive还没死”。很多公司把Hive当数仓的SQL入口，底层引擎可能换成了Spark或者Tez，但Hive Metastore这个元数据服务反而越来越重要，Spark SQL和Flink SQL都会去连它。所以“Hadoop生态过时”这个说法，根本不成立。

4. 从真实的搜索需求看三者的典型使用方式

4.1 集群搭建和安装配置类需求：入门者的必经之路

回头看大家的搜索记录，“hadoop安装与配置”“ubuntu 安装hadoop”“hadoop伪分布式搭建”“hadoop集群搭建”“hadoop的docker镜像”这一类占了很大的比例。这背后的需求很明确：新人入坑大数据，第一关就是环境搭建。

我的建议是，不要贪多求快。按“单机伪分布式 → 三节点集群 → 容器化部署”的顺序走。伪分布式有两个作用：一是验证HDFS读写流程，二是搞懂配置文件的依赖关系，比如namenode和datanode怎么互相发现、ZooKeeper参与HA时起什么作用。伪分布式跑通之后，立刻上三节点集群，因为单机环境里你根本体会不到“数据被切到多台机器、shuffle跨节点传输”是什么滋味。

有条件的话，再用Docker镜像起一个包含HDFS、YARN、Hive的小集群，这个过程基本就是在帮你复习“Hadoop生态由哪些组件构成”。热搜词里有“hadoop和zookeeper整合实战”，很多人顺手就把ZooKeeper忽略掉，其实NameNode高可用和好多分布式协调场景都离不开它。

4.2 Spark做用户行为分析：离线数仓里的中坚力量

“用户复购率 spark 脚本 redshift”这个热搜词特别有代表性。用户复购率这类问题，数据往往存到数据仓库里，比如Redshift，然后你用Spark脚本把用户订单明细读出来，按用户ID聚合，统计“多次下单的用户占比”或者“间隔多少天再次购买”。这种场景天然适合Spark SQL或DataFrame API：数据是“有界的”历史数据，计算一次可能要扫描几亿行，但对结果时效性没那么敏感。

我见过很多团队把“跑批”的任务从Hive往Spark迁移之后，执行时间缩短一大截，但过程中也踩过不少坑。比如Spark默认并行度和实际文件数量不匹配，导致executor忙闲不均；比如某个用户的订单量极端大，group by的时候出现数据倾斜。这些都是离线分析的经典问题，后面避坑部分我会展开。

4.3 Flink CDC和Flink SQL：实时数仓绕不开的组合

“flink cdc”“flink sql client sql gateway”“flink 数据血缘”“flink的jdbc连接器异常”这些热搜词，背后是一群真正在做实时数仓的工程师。什么是Flink CDC？简单说，让Flink直接监听MySQL、PostgreSQL这类数据库的binlog，把增删改操作变成流式事件，加上Flink SQL做过滤、关联、聚合，实现“业务库变更 → 数仓实时同步 → 下游消费”的端到端链路。

这套东西对传统数据同步方式（比如每天全量拉取或定时增量拉取）是一个很大的升级：原来你看到的数据普遍有半小时甚至一天的延迟，现在可以做到秒级。而且Flink SQL把门槛压得很低，很多不写Java的同学也能用SQL完成清洗和聚合逻辑，再配合SQL Gateway之类的组件，整个团队可以把流式任务当成“SQL脚本”来管理。

当然，Flink CDC绝不是“装上就能用”。MySQL的binlog格式要设置成ROW；多个Flink作业读同一个MySQL实例时，server-id不能冲突；DDL变更怎么同步到下游；连接池被耗尽怎么排查。热搜词里那个“flink的jdbc连接器异常”，大概率就是这类问题引起的。这些我都会在第六部分专门讲。

5. 真正的生产组合拳：HDFS打底，Spark和Flink各司其职

你以为选型是“三选一”，但真实生产环境里，它们往往是“三合一”。

5.1 离线链路：HDFS/Hive打底，Spark SQL处理T+1

很多公司的离线数仓仍然是这样的结构：业务库每天定时同步到Hive ODS层，再经过DWD、DWS层的清洗汇总，最终输出报表和指标。这套链路里，HDFS负责海量数据的低成本存储，Hive Metastore负责表格元数据，计算引擎换成Spark SQL，调度用Azkaban或DolphinScheduler。

这条链路的优势是稳、成本低、生态成熟。Spark SQL可以直接读Hive表，语法和传统SQL几乎一样，团队不用专门学一套新的编程模型。对于“今天出昨天的经营报表”这种需求，它比任何流式计算都合适。

5.2 实时链路：Flink CDC进Kafka，Flink SQL清洗入仓

当业务开始要“今天实时看今天的营收”“异常订单立刻报警”时，离线链路就不够用了。这时候需要一条实时链路，常见骨架是：业务库 → Flink CDC → Kafka → Flink SQL → Doris/ClickHouse/StarRocks → 应用端。

Flink CDC监听binlog，把变更事件打到Kafka；实时链路里的Flink SQL做数据清洗、维表关联、多流Join；结果写入OLAP引擎供查询和展示。Kafka在这里起到削峰填谷和消息缓冲的作用，不至于让下游一波动就丢数据。

为什么要搞两条链路？因为离线链路成本低、适合复杂大查询，在线链路成本高、适合低延迟的小查询。两条链路存储的都是同一份业务数据，只是建模粒度和刷新频率不同。早期很多团队用Lambda架构就是这个思路，只是当时实时引擎是Storm或Spark Streaming。现在换成Flink，原理相通。

5.3 什么时候不需要Flink

不是所有公司都要立刻上Flink。如果实时指标只有一两个，用Spark Structured Streaming定时跑个微批也能交差；如果数据量没到每秒几十万事件，用Canal监听binlog然后写到消息队列，再让一个定时任务去消费，也撑得住。

判断标准很简单：当你的实时任务开始涉及复杂状态、精确一次、事件时间窗口，或者一个简单的实时任务消耗了大量运维精力时，才是认真考虑Flink的节点。否则，为了“跟上技术潮流”而引入Flink，只会让团队陷入checkpoint失败、状态后端调优、版本兼容这些无底洞。

6. 选型后最容易翻车的五个实操坑

6.1 伪分布式不等于真分布式，环境搭建只是第一步

很多人在自己电脑上搭了个hadoop伪分布式或spark local模式，就跑任务、调代码，感觉一切顺利。可真上了集群，问题全来了：网络传输导致的shuffle成本、多节点间的资源竞争、节点故障带来的任务重试，这些在单机上都体验不到。

我的建议是，学完单机后尽早接触一个至少三台机器的小集群，用真实数据规模跑一跑。不需要多高的配置，4核16G内存起步就够了。环境搭建本身不是目的，目的是让你对“分布式的瓶颈到底在哪”有真实感知。

6.2 Spark内存参数不调，集群再大也救不了OOM

Spark性能优化里，“内存”是绕不开的坎。常见的坑是：给executor配了过大的内存，反而因为GC变慢拖垮任务；或者driver内存太小，收集结果时直接OOM；更常见的是没理解堆内和堆外内存的关系，导致缓存数据挤占了shuffle所需的内存。

一个靠谱的起步配置是：每个executor 4~8核，内存16~32G，同时留出20%左右的内存给系统开销；动态资源分配要打开，让集群按负载自动伸缩。不要抄一个网上配置就到处用，要结合你的数据量做压测。然后是熟悉几个关键参数：spark.executor.memory、spark.executor.cores、spark.sql.shuffle.partitions、spark.memory.offHeap.enabled，这几个参数写对了，大部分性能问题能缓解一多半。

另外，数据倾斜比内存不够更隐蔽。group by或join时，某个key的数据量特别大，会导致少数executor忙、其他全空闲。遇到这种问题，不要急着加资源，先定位是不是几个热点key在作怪，该加盐加盐，该广播广播，效果往往立竿见影。

6.3 Flink的“精确一次”是端到端承诺，别被一个引擎误导

Flink官方说的exactly-once，是指“在Flink引擎内部，基于checkpoint机制保证状态一致性”。但一条实时数据要经过Source（比如读取Kafka）、Flink内部计算、Sink（比如写入MySQL或Kafka），如果Source端不记录消费位点，Sink端不实现幂等或事务性写入，那数据依然可能丢或重。

真实项目中，我见过太多人以为“用了Flink就能精确一次”，结果下游出现重复数据才回过头来排查。正确的认知是：Flink负责中间状态的精确一次，两端需要配合。比如Kafka Source会保存offset，Sink端Kafka Connector支持两阶段提交，JDBC Sink需要靠幂等写或者事务表来保证最终一致。选型时如果业务对一致性要求极严（比如金额相关），一定要把整条链路的一致性模型画清楚。

6.4 版本兼容矩阵不看，分分钟踩JDBC连接器的坑

热搜词里“flink的jdbc连接器异常”这个搜索词，背后几乎都是同一个故事：你下载了一个Flink版本，再引入一个Connector，结果运行时报出ClassNotFoundException或者奇怪的序列化错误，去GitHub搜了一圈发现是版本不匹配。

Flink生态里有两套版本特别容易混：一套是Flink主版本，一套是各个Connector自己的版本。比如Flink CDC的某些版本要对应特定Flink版本，MySQL CDC和PostgreSQL CDC支持的参数也各不相同。项目初始化时最稳妥的做法是：先选定一个Flink主版本，再去官网查这张版本兼容矩阵，把Connector版本固定住，整个项目统一管理依赖，不要各自用各自的最新版。

还有个很典型的坑是JDBC驱动冲突。Flink自带的老版本MySQL驱动，和你项目里新引入的mysql-connector-java打架，导致连接报错。遇到这种情况，优先看是不是驱动被shade进作业jar包里，或者flink的lib目录里混入了重复驱动。排查思路一般是这样：先确认Connector和Flink版本兼容→再确认驱动版本一致→再检查时区、SSL参数是否匹配程序运行环境→最后看是不是连接池耗尽导致“看起来像连接异常”。按这个顺序，大多数“JDBC连接器异常”都能在半小时内定位。

6.5 数据倾斜和小文件：两个容易被热搜词掩盖的硬骨头

数据倾斜不只是Spark的问题，Flink里也会出现。比如按用户维度聚合时，某个大用户的事件量占了一大半，导致下游算子背压；Flink的窗口聚合遇到热点key，也会造成某个subtask长期瓶颈。解决思路有两条：先看业务上能不能拆key，把一个热点key加随机后缀拆开，再分别聚合；不行的话再考虑加资源，但治标不治本。

Hadoop生态里还有个老生常谈的小文件问题。HDFS默认块大小128MB，如果一个任务生成了几万个小文件，NameNode内存会被元数据压垮，读取性能也大幅下降。根源经常出在“分区字段太多、写入过于频繁”。治理手段包括：写入前合并小文件、定期用任务做文件合并、把流式写入的目标改成对象存储再做批式落Hive。这个问题在实时链路里尤其突出，Flink写Hive或写S3时，如果不对文件滚动策略做设置，一天下来就是几十万个碎片文件。

7. 选型之外，我最后想说的三条实在话

7.1 入门路线可以更朴素

如果你还在纠结学Hadoop还是Spark还是Flink，我的建议是：用最朴素的方式把链路跑通。先装一个Hadoop伪分布式，跑通HDFS上传下载，再装一个Spark，用一份百万级的数据，写几条SQL完成同比环比、分组TopN这类分析。然后把MySQL的一个订单表用Flink CDC同步到另一张表，观察数据怎么实时流动。这三步做完，你对“离线”和“实时”的差别，会有比看十篇对比文章更深刻的体感。

7.2 中小团队先离线后实时，别一上来就全家桶

我见过不少中小团队，一上来就把Hadoop + Spark + Flink + K8s全套铺开，结果运维压力立刻超过业务收益。如果你团队只有两三个人，又刚刚开始做数据平台，不妨先让“离线链路跑起来”，把数仓分层、调度、元数据管理这些基本功做扎实。等业务方明确提出“我要看到实时指标”时，再引入Flink，一上来就盯住一两个核心场景，比如实时大屏或实时告警，千万不要把实时链路铺得太宽。

7.3 已有Hadoop资产不要轻易推翻

如果你们现在已经有了一套稳定的Hadoop集群，HDFS里存着好几个P的数据，Hive Metastore里管着几百张表，我的建议很直接：别为了“跟上技术潮流”就推翻重来。HDFS可以继续当底座，Spark继续跑离线批处理，Flink作为新增的实时引擎接进来。你不一定要“切换技术栈”，你只需要“在合适的位置新增一个组件”。

最后说一个我的个人习惯。做选型评审的时候，我从来不看哪个框架的GitHub Star多、哪个框架又在社区刷了屏，我只问业务三个问题：你的数据延迟底线是多少，你的团队能养活多少套组件，你的核心指标值不值得为低延迟多付出两倍运维成本。把这三个问题想明白，Hadoop、Spark、Flink的答案其实已经写在你的业务里面了。