数据流基础：实时计算的核心概念

大家好，我是你们的老朋友。今天我们来聊聊数据流。

说实话，很多刚入行的同学，一听到「数据流」三个字，就觉得很高大上。其实没那么玄乎。我个人的理解很简单——数据流就是「源源不断、持续到达的数据序列」。就像自来水管道里的水，不是一桶一桶搬过来的，而是拧开龙头就一直流。

什么是数据流？

数据流，英文叫 Data Stream。它有几个关键特征：

• 持续到达：数据是连续产生的，没有明确的终点
• 无界：你不知道下一秒会来多少数据，也不知道什么时候结束
• 实时性：数据产生后，需要尽快被处理

举个例子。你在淘宝上买东西，每秒钟都有成千上万的用户在下单、浏览、加购物车。这些行为数据就是一条条数据流。我当年在电商公司做风控时，每天要处理上亿条这样的实时行为数据。嗯，那时候才真正体会到什么叫「数据流」。

数据流 vs 批处理：到底差在哪？

很多同学会问：数据流和批处理，不都是处理数据吗？有什么区别？

区别大了去了。我做个对比你就明白了。

对比维度	批处理	数据流处理
数据范围	有界数据（已知大小）	无界数据（持续到达）
处理时机	数据全部到位后处理	数据到达即处理
延迟	分钟级到小时级	毫秒级到秒级
典型场景	日报、月报、离线分析	实时风控、实时推荐、监控告警
存储方式	HDFS、数据仓库	消息队列、内存状态

说白了，批处理是「先攒着，攒够了再一起算」。数据流是「来一条算一条，边来边算」。你想想看，做实时风控的时候，用户刚点了一下「支付」，你总不能等攒够一万条再判断这笔交易是不是欺诈吧？那黄花菜都凉了。

实时数据流的三大特征

做实时数据流处理，你必须理解它的三个核心特征。我当年踩过的坑，大多跟没理解透这些特征有关。

1. 高吞吐

什么叫高吞吐？就是单位时间内处理的数据量非常大。在风控场景中，每秒几万甚至几十万条事件是家常便饭。

为什么会这样？因为互联网用户太多了。双十一的时候，支付宝每秒要处理几十万笔交易。每一笔交易背后，还有点击、浏览、加购等行为数据。这些数据全部汇入数据流，压力可想而知。

我曾经遇到过一个项目，上线第一天流量就超过了预估的10倍。结果消息队列直接被打爆，数据大量积压。嗯，从那以后，我再也不敢低估「高吞吐」这三个字了。

2. 低延迟

低延迟，就是数据从产生到处理完成的时间非常短。在实时风控中，这个时间通常要求在100毫秒以内。

为什么这么苛刻？你想想看，用户点击「支付」按钮后，如果系统要等3秒才告诉你「这笔交易有风险」，用户早就等得不耐烦了。更糟糕的是，如果延迟太高，欺诈分子可能已经完成了交易，钱都转走了。

我个人的习惯是：把延迟目标定在50毫秒以内。这样即使有波动，也能保证在100毫秒内完成处理。

3. 无序性

这个特征最容易被忽视，也最容易出问题。

数据流的无序性，指的是数据到达的顺序，不一定等于数据产生的顺序。举个例子：用户在手机上操作，网络信号不好，第一条数据可能比第二条数据晚到。或者数据经过多个节点转发，路由路径不同，到达时间也不同。

为什么会这样？因为网络传输本身就不保证顺序。再加上分布式系统的复杂性，数据乱序是常态，有序才是特例。

我记得有一次做实时风控，用户先登录、后下单，结果系统先收到了下单事件，后收到了登录事件。如果按照到达顺序处理，就会判断「用户没登录就下单」，直接拦截掉。这显然是个误判。

知识体系总览

说了这么多，我们来画一张图，把今天的内容串起来。

这张图把今天的内容都串起来了。中心是数据流，左边是它和批处理的对比，右边是三大特征以及对应的应对策略。你保存下来，以后做架构设计时可以参考。

小结

今天的内容就到这里。总结一下：

• 数据流是持续到达、无界的实时数据序列
• 数据流处理和批处理有本质区别，延迟和范围是核心差异
• 实时数据流的三大特征：高吞吐、低延迟、无序性
• 处理无序数据，要用事件时间和水位线机制

这些概念是后续所有内容的基础。你把它吃透了，后面学窗口计算、状态管理、背压机制都会轻松很多。