想象你正在看一条永不停息的河流（这就是数据流），你需要统计和分析河里的鱼（数据）。这就是流式计算的场景。 **传统计算 vs 流式计算** - 传统计算就像钓鱼：等收集够了鱼再一起处理 - 流式计算就像在河边实时数鱼：鱼游过来就立即处理，不用等收集完 **举个具体例子：双十一实时销售数据统计** 1. 数据像流水一样不断产生：订单、支付、物流... 2. 需要实时处理：销售额、热门商品、区域统计... **窗口概念（Windows）** 想象你在河边放了一个捕鱼网： 1. **固定窗口（Tumbling）** - 每隔1小时统计一次 - 比如：9:00-10:00的订单总额，10:00-11:00的订单总额 - 特点：时间段不重叠，数据不重复计算 1. **滑动窗口（Sliding）** - 每10分钟统计过去1小时的数据 - 比如：9:00-10:00，9:10-10:10，9:20-10:20... - 特点：像放电影一样，平滑移动，数据会被重复计算 1. **会话窗口（Session）** - 基于用户行为划分时间段 - 比如：一个用户连续操作，超过30分钟无操作就算一个会话结束 - 特点：根据实际活动动态调整，更符合用户行为特征 **处理乱序和延迟** 想象河里的鱼有时会倒游（数据乱序）或迟到： 1. **水位线（Watermark）** - 就像水位标记，表示"这个时间点之前的数据应该都到了" - 比如：现在是10:05，我们认为10:00之前的订单都已经到达了 - 容忍一定延迟，但不会无限等待 1. **迟到数据处理** - 处理特别慢的鱼（迟到数据） - 可以选择： - 丢弃（不管它） - 更新之前的结果 - 单独统计 **实际应用场景** 1. 电商实时销售统计 2. 网站实时访问监控 3. 股票交易实时分析 4. IoT设备数据处理 5. 社交媒体热点监测 流式计算的核心就是： 1. 数据不停地流动 2. 必须实时处理 3. 要处理乱序和延迟 4. 要权衡实时性和准确性 理解了这些，你就基本掌握了流式计算的核心概念。它就像一个永不停息的流水线，需要我们不断地处理和分析数据。 **为什么需要流式计算？** 1. **实时性需求** - 实时推荐 - 实时风控 - 实时监控预警 - 实时数据大屏 1. **批处理的局限** - 延迟高 - 资源利用不均衡 - 不适合实时业务场景 **主流框架对比**： 1. **Apache Flink** - 原生流处理 - 真正的流式计算 - 低延迟、高吞吐 - 精确一次语义 1. **Spark Streaming** - 微批处理 - 构建在Spark之上 - 更适合准实时场景 1. **Apache Storm** - 早期流处理系统 - 实时性好 - 吞吐量相对较低 **应用场景**： 1. **互联网公司** - 用户行为分析 - 实时推荐 - 广告投放 1. **金融行业** - 实时风控 - 交易监控 - 欺诈检测 1. **物联网** - 传感器数据处理 - 实时监控 - 预测性维护 1. **游戏行业** - 玩家行为分析 - 实时匹配 - 作弊检测 总的来说，[[流式处理]]是大数据生态中的一个重要组成部分，主要解决实时数据处理的需求。它与传统的批处理相比，更注重数据的实时性和持续处理能力。在现代应用中，流式计算正变得越来越重要，因为很多业务场景都需要实时的数据洞察和决策支持。