3、实时计算引擎选型：Flink、Spark Streaming、Storm在流式图计算中的对比

做实时图计算，选引擎是个绕不开的坎。

我记得2018年刚带队做交易监控系统时，团队内部吵了整整两周。有人坚持用Storm，说它够轻量；有人推Spark Streaming，毕竟生态成熟；我则倾向于Flink。最后怎么定的？嗯，咱们今天就把这三个家伙拉出来遛遛，看看它们在流式图计算场景下到底谁更靠谱。

3.1 三个引擎的核心差异

先给个直观对比。你想想看，实时图计算最怕什么？怕状态丢失、怕延迟爆炸、怕图结构更新时数据不一致。这三个引擎处理这些问题的思路完全不同。

维度	Flink	Spark Streaming	Storm
处理模型	真正的逐条流处理	微批次（Micro-batch）	逐条流处理
延迟	毫秒级	秒级（取决于批次间隔）	毫秒级
状态管理	内置Keyed State，强一致性	依赖外部存储（Redis/HBase）	无内置状态，需自己维护
图计算支持	Gelly API + 自定义算子	GraphX（偏批处理）	无原生支持，全手写
容错机制	分布式快照（Chandy-Lamport）	RDD血缘 + Checkpoint	Ack机制 + 记录重放
背压处理	天然支持，自动反压	通过批次大小间接控制	需手动实现

说白了，选型就是做取舍。你要低延迟，就得接受状态管理的复杂度；你要生态丰富，可能就得牺牲一点实时性。

3.2 Flink：实时图计算的首选

我个人习惯把Flink排在第一位。为什么？因为它天生就是为流处理设计的。

做交易监控时，我们需要维护一个动态的「账户-订单-持仓」图结构。每来一笔交易，图里的边和节点都要更新。Flink的Keyed State可以精确到每个账户ID，状态一致性有保障。

看一段实际代码，这是我在项目中用来维护图邻接表的Flink算子：

// 使用Flink的KeyedState维护动态图
DataStream<Transaction> txStream = env.addSource(kafkaConsumer);

txStream
    .keyBy(tx -> tx.getAccountId())
    .process(new KeyedProcessFunction<String, Transaction, GraphUpdate>() {
        
        // 存储账户的邻接关系
        private MapState<String, List<Edge>> adjacencyState;
        
        @Override
        public void open(Configuration parameters) {
            MapStateDescriptor<String, List<Edge>> descriptor = 
                new MapStateDescriptor<>("adjacency", 
                    TypeInformation.of(String.class),
                    TypeInformation.of(new TypeHint<List<Edge>>() {}));
            adjacencyState = getRuntimeContext().getMapState(descriptor);
        }
        
        @Override
        public void processElement(Transaction tx, Context ctx, Collector<GraphUpdate> out) {
            // 更新图结构
            String accountId = tx.getAccountId();
            List<Edge> edges = adjacencyState.get(accountId);
            if (edges == null) {
                edges = new ArrayList<>();
            }
            edges.add(new Edge(tx.getFromAccount(), tx.getToAccount(), tx.getAmount()));
            adjacencyState.put(accountId, edges);
            
            // 检测环形交易（洗钱模式）
            if (detectCycle(edges)) {
                out.collect(new GraphUpdate(accountId, AlertType.CYCLE_DETECTED));
            }
        }
    });

这里有个坑。我曾经在状态后端选型上栽过跟头——默认的RocksDB在频繁更新图结构时，读写放大很严重。后来改成FsStateBackend + 增量Checkpoint，性能才稳住。

3.3 Spark Streaming：生态丰富但延迟硬伤

Spark Streaming的微批次模型，说白了就是把流切成一个个小批。每5秒处理一批，延迟就在5秒左右。做交易监控时，5秒可能已经够资金转好几圈了。

不过它有个优点——生态好。如果你团队已经用Spark做离线图计算（比如GraphX做全量图谱分析），那复用同一套代码栈确实省事。

但要注意，GraphX本身是为静态图设计的。你想想看，交易图每秒钟都在变化，GraphX每次都要重建整个图结构，计算开销非常大。

// Spark Streaming + GraphX 的伪代码
// 每5秒重建一次图
val graphStream = ssc.graphStream()  // 自定义DStream

graphStream.foreachRDD { rdd =>
    // 每次都要重新构建图
    val graph = Graph.fromEdges(rdd, defaultValue)
    
    // 执行PageRank检测异常节点
    val ranks = graph.pageRank(0.0001).vertices
    
    // 输出结果
    ranks.saveAsTextFile(hdfsPath)
}

这段代码看着简单，但实际跑起来你会发现：每次重建图的时间可能比批次间隔还长。我在一个客户现场遇到过，批次间隔设了3秒，但图重建花了8秒，结果数据越积越多，最终OOM。

3.4 Storm：轻量但太「裸」

Storm是最早的流处理引擎之一。它够轻量，延迟也低，但问题在于——太裸了。

做图计算时，你需要自己管理所有状态。没有Keyed State，没有内置的窗口函数，连计数器都得自己写。我早期用Storm做过一个实时风控系统，光维护图节点状态就写了2000多行代码。

而且Storm的容错机制是记录级别的Ack，一旦图状态出问题，恢复起来非常痛苦。我记得有一次线上故障，图结构状态丢失，我们花了整整一天手动重建。

// Storm Bolt中手动维护图状态
public class GraphUpdateBolt extends BaseRichBolt {
    private Map<String, List<Edge>> graphState;
    private OutputCollector collector;
    
    @Override
    public void prepare(Map conf, TopologyContext context, OutputCollector collector) {
        this.graphState = new HashMap<>();
        this.collector = collector;
    }
    
    @Override
    public void execute(Tuple input) {
        String accountId = input.getStringByField("accountId");
        Edge edge = (Edge) input.getValueByField("edge");
        
        // 手动维护状态
        List<Edge> edges = graphState.getOrDefault(accountId, new ArrayList<>());
        edges.add(edge);
        graphState.put(accountId, edges);
        
        // 手动处理容错
        collector.ack(input);  // 必须显式ack
    }
}

看到没？每个Bolt都要自己管理状态、自己处理容错。在复杂图计算场景下，这种「裸奔」方式很容易出问题。

3.5 选型决策树

说了这么多，到底怎么选？我画了个决策图，你可以对照着看：

这个图是我根据实际项目经验总结的。你顺着走一遍，基本能锁定目标。

3.6 我的最终建议

做了这么多年实时图计算，我的结论很明确：

• 新项目、从零开始 → 直接上Flink。它的事件时间、状态管理、容错机制，简直就是为图计算量身定做的。
• 已有Spark全家桶 → 可以选Spark Streaming，但要做好延迟和状态管理的心理准备。建议只做秒级以上的监控场景。
• 极简场景、团队能力强 → Storm也能用，但我不推荐。除非你像我当年一样，有足够的时间去填坑。

好了，引擎选型就聊到这儿。下一节咱们会深入Flink的图计算实战，包括如何设计图数据结构、如何优化状态访问——嗯，那些才是真正磨人的细节。

---

公众号:蓝海资料掘金营，微信deep3321