1. 背景：为什么需要实时流数据库？
过去十年，后端的数据处理主要分为两类：
- OLTP（联机事务处理） ：MySQL、PostgreSQL 等关系型数据库，擅长事务处理。
- OLAP（联机分析处理） ：Hive、ClickHouse 等分析引擎，擅长大规模批量分析。
问题是：
- OLTP 侧重事务，却不适合大规模分析。
- OLAP 偏向离线分析，时效性差。
在实时推荐、风控、物联网监控、金融风控等场景下，我们需要一种 “实时 ingest + 实时计算 + 实时查询” 的数据库 —— 这就是 Streaming Database。
2. 什么是实时流数据库？
实时流数据库（Streaming Database）是一种 结合消息队列（如 Kafka）与数据库查询能力 的新型系统。
它的核心特点是：
- 数据实时写入：秒级甚至毫秒级的数据到达即可被处理。
- 流式 SQL 查询：支持类似 SQL 的查询语法，但语义是“持续执行”。
- 状态存储：支持有状态计算（如窗口聚合、实时 join）。
代表性项目：
- Materialize（SQL-first 的实时流数据库）
- RisingWave（国产新秀，云原生流数据库）
- KSQLDB（基于 Kafka 的流处理数据库）
3. 关键技术点
3.1 流式 SQL
传统 SQL 是“执行一次，返回结果”。
而流式 SQL 是“持续执行，结果动态更新”。
例子：
-- 实时统计过去 5 分钟内的订单总额
SELECT window_start, SUM(amount) AS total_sales
FROM TUMBLE(ORDERS, INTERVAL '5' MINUTES)
GROUP BY window_start;
每当有新订单写入 ORDERS 表时，查询结果会实时刷新。
3.2 存算分离架构
流数据库普遍采用 存算分离：
- 计算层：处理实时 SQL、窗口聚合、JOIN
- 存储层：保存状态、快照、历史数据
- 消息层：与 Kafka、Pulsar 集成
这样能做到 水平扩展、弹性伸缩。
3.3 增量计算
传统分析往往全量扫描，流数据库采用 增量计算：
- 只计算新增/变更的数据
- 用状态存储保存中间结果
- 输出结果时延大幅缩短（从分钟降到秒级）
4. 应用场景
4.1 实时推荐与个性化
电商/短视频平台需要根据用户行为实时调整推荐结果，流数据库能实时更新用户画像和推荐模型。
4.2 金融风控
在支付场景中，流数据库可在毫秒级别内检测出异常交易，触发风控策略。
4.3 IoT 监控
物联网设备数据持续产生，流数据库可以实现实时监控与告警。
4.4 运维日志分析
结合 Kafka 日志，实时发现异常请求和服务瓶颈。
5. 与传统数据库的对比
| 特性 | 传统数据库 (OLTP/OLAP) | 流数据库 |
|---|---|---|
| 查询模式 | 一次性查询 | 持续执行 |
| 时效性 | 批量，分钟~小时级 | 毫秒~秒级 |
| 数据源 | 静态表 | 动态数据流 |
| 应用场景 | 事务 / 离线分析 | 实时推荐、风控、监控 |
6. 总结
实时流数据库正推动后端架构发生根本性变化：
- 从“事后分析”走向“实时决策”
- 从批处理模式走向流式处理
- 从存储优先走向计算优先
可以预见，随着 AI、IoT、金融实时性需求 的增强，Streaming Database 会逐渐成为后端系统的“标配”。
