流处理技术概览

calendar Oct 1, 2020 · 2 分钟阅读 · 大数据 流计算  ·
分享到: linkedin copy

文章目录

一、大数据发展简史

2003-2004              2006                ~2014                   现在
Google 三篇论文         Hadoop 诞生         Spark/Storm 崛起        Flink 成为主流
· GFS                  · HDFS             · Spark                 · Flink
· MapReduce            · MapReduce        · Spark Streaming       · 流批一体
· BigTable             · HBase            · Storm

整个大数据领域的发展脉络清晰可见——从 Google 的基础理论，到 Hadoop 的开源实现，再到 Spark 的快速崛起，最终走向 Flink 的流批统一。每一个阶段都为数据处理提供了新的手段和工具。

二、大数据的四种计算模式

模式 说明 代表框架
批处理（Batch） 离线、一次性处理静态数据 MapReduce、Spark、Hive、Pig
流处理（Stream） 实时、持续处理动态数据 Storm、Spark Streaming、Flink、Samza
交互式处理（Interactive） 即时查询与探索 （不展开）
图处理（Graph） 图结构数据计算 （不展开）

三、流计算 vs 批计算 —— 四个维度的对比

维度 流计算（Stream） 批计算（Batch）
数据时效性 实时（毫秒-秒级）延迟 非实时，高延迟（分钟-小时级）
数据特征 动态数据，无边界（Unbounded） 静态数据，有边界（Bounded）
应用场景 实时推荐、实时风控、实时监控 离线报表、数据分析、ETL
运行方式 持续运行，永不停止 一次性完成，跑完即停

四、为什么流计算正在成为主流？四个驱动力

4.1 业务对实时性要求越来越高

  • 实时推荐、实时风控等业务天然需要低延迟
  • 越来越多的业务场景不再接受「T+1」的时效性

4.2 流处理技术日趋成熟

  • Storm、Spark Streaming、Flink 等框架越来越稳定、易上手
  • 社区活跃，生态完善，降低了使用门槛

4.3 批计算存在存储成本问题

  • 离线处理需要先将数据存储在分布式存储系统中再进行计算
  • 数据「先存后算」模式导致存储成本相对较高

4.4 批计算本身就是一种特殊的流计算

  • 批和流本质相通，批是有界流，流是无界批
  • 当前多数企业维持「离线 + 实时」双平台并存
  • 未来趋势：流处理占比会越来越大
当前：离线平台 + 实时平台（双轨并行）
未来：流处理占比持续增长 → 流批一体

五、流计算的典型应用场景

行业 场景 数据来源
交通/工业/农业 传感器数据 → 检测设备缺陷 → 自动订购备件 IoT 传感器
金融 实时跟踪股票波动 → 计算风险价值 → 自动平衡投资组合 行情数据
房地产 根据用户地理位置 → 实时建议周边房源 移动设备 GPS
电商/广告 分析用户行为+人口统计 → 优化内容投放 点击流、用户画像
游戏 收集玩家互动数据 → 实时分析 → 优化游戏体验 游戏日志

这些场景的共同特点：数据持续产生，需要毫秒到秒级的响应速度。

六、流计算框架全景图

6.1 两大类产品

类别 代表产品 特点
商业平台 IBM InfoSphere Stream、IBM Streams 闭源商业方案，普通用户无法获取
开源框架 Storm, Heron, Spark Streaming, Flink, Kafka Streams, Samza 互联网公司根据自身需求开发并开源

6.2 三大主流框架深度对比

⚡ Storm（Twitter 开源，第一代流处理系统）

数据 → [一条一条处理] → 结果
         ↑
    原生逐条流处理
维度 评价
延迟 ✅ 极低，毫秒级
消息保障 ⚠️ At-Least-Once（可能重复，但不丢失）
吞吐量 ❌ 在流处理框架中相对最低
适用场景 吞吐量要求不高、但实时性要求极高的场景

Heron 是 Twitter 开发的第二代流处理系统，是 Storm 的继任者。

🔄 Spark Streaming（Spark 核心的批处理扩展）

输入数据 → [切分为微批 Batch] → Spark 引擎处理 → 输出
                ↑
           固定时间间隔（如几秒）
维度 评价
延迟 ⚠️ 秒级（微批处理固有延迟）
消息保障 ✅ Exactly-Once（不丢不重）
吞吐量 ✅ 高
处理模式 微批处理（Micro-Batch），不是原生流处理
适用场景 数据量大、但对延迟要求不高的场景

核心机制：将流数据按固定时间窗口切成一个个小 Batch，每个 Batch 走批处理流程。

🔥 Apache Flink（真正的原生流处理框架）

数据 → [逐条流处理 + DataFlow Model] → 结果
         ↑
    原生流处理 + 批处理统一引擎
维度 评价
延迟 ✅ 毫秒级
消息保障 ✅ Exactly-Once
吞吐量 ✅ 高吞吐
处理模式 原生流处理（一条一条处理）
批处理 ✅ 同时支持（流批一体）

6.3 三框架综合对比

维度 Storm Spark Streaming Flink
架构/处理模式 原生流处理 微批处理 原生流处理 + 批
延迟 毫秒级 ✅ 秒级 ⚠️ 毫秒级 ✅
消息保障 At-Least-Once ⚠️ Exactly-Once ✅ Exactly-Once ✅
吞吐量 低 ❌ 高 ✅ 高 ✅
容错 一般 好 好
API 易用性 较弱 好（Spark 生态） 好
状态存储 — 有限 完善

七、评估流处理框架的四个标准

标准 含义 Flink 是否满足
低延迟 毫秒级处理延迟 ✅
高吞吐 每秒千万级别的处理能力 ✅
准确性 Exactly-Once 语义，不丢不重 ✅
易用性 提供 SQL 等结构化编程接口 ✅

结论：四个标准全部满足的，只有 Flink。

八、小结

本文梳理了流处理技术的整体格局：

  1. 大数据从 Google 三篇论文出发，经历了 Hadoop → Spark → Flink 的演进
  2. 流计算和批计算有本质不同（时效性、数据特征、场景、运行方式）
  3. 流计算成为主流是业务+技术+成本+理念四重驱动的结果
  4. 三大框架中，Storm 适合低吞吐高实时场景，Spark Streaming 适合高吞吐可容忍秒级延迟场景，Flink 是唯一同时做到低延迟 + Exactly-Once + 高吞吐的框架