面向对话式BI的实时数据流：架构模式.docxVIP

面向对话式BI的实时数据流：架构模式

01批处理与流式处理：当两者都有意义时

并非每个指标都需要实时数据，而真正需要的那些指标其实很容易识别：凡是驱动小时级运营决策的指标，都值得流式处理。月度收入报告、季度预测和人力资源人数，用每日批量负载完全足够——强行把它们塞进流式管道，买来的新鲜度根本没有人消费。实时流式处理值得为之承担复杂度的，是那些每小时都在变化、且变化会触发行动的指标：库存水平、销售管道、产量、设备运行时间和现金状况。

关键在于决策节奏，而不是技术。如果一个指标到月底才复盘，每日批量负载已经是过度交付；如果一个指标上午9点被查看、10点就要据此行动——补货、促销限流、生产再平衡——那么数据管道必须跟上决策的节奏，而不是反过来。大多数分析架构恰恰在这里失败：它们对每一份数据集都套用同一种新鲜度策略。

一个有用的启发式方法：把指标按答案晚一小时会损失多少价值来排序。答案晚一小时就很危险的指标（现金状况、产量、正在运行的广告活动效果）是流式候选；晚一小时也无所谓的指标（月活跃用户、留存队列）留在批处理上。这份排序只需做一次、写在一页纸上，就能避免实时项目最常见的浪费。

图：延迟和新鲜度

02流媒体堆栈

一条典型的实时管道由少数几个稳定的阶段组成，可以一次说清：源系统发出变更事件，流平台负责缓冲和路由，流处理器完成转换和丰富，结果落到?MCP?语义层可以查询的服务层。