我相信很多人都听过这么一个言论：数据具有时效性，其经济价值会随时间快速贬值。

最著名的案例则是，Netflix（奈飞）发现 90% 的数据分析集中在最近 7 天的数据，超过 3 个月的历史数据仅占查询总量的 2% 。

但，对于更多的企业来说，实时数仓则鲜有用武之地。

实时数仓就像一辆新能源汽车，很诱人，很想要来一辆，但多数人真实的需求是一辆电瓶车。

我不知道读者中，有多少是专门干实时数仓平台的团队成员或创业者，下面的内容仅限个人观点，非砸你饭碗，如有冒犯之处，还请见谅。

若有不当言论，平息情绪后，可在评论区评论交流探讨。

先说一下我个人的经历。

我大概在 19 年的时候，开始关注流批一体的概念，那时候 Apache Flink 也初露锋芒，大有终结 Lambda  架构之势。

公司也立项，基于 Flink 引擎构建流批一体化的大数据开发平台，来取代传统的离线数据开发平台。

司内已经有一套基于 Hadoop 框架运营多年的离线数仓及开发平台，但是，这块平台不归属我们团队。

因此，我们视实时数仓为一个“千载难逢”的机会，且当时市场很热，每年的双十一实时大屏，更是让人看得亢奋。

那时候，直播业务还属于纯娱乐范畴，主要盈利模式靠送虚拟礼物和打赏，和实物电商基本没多大交集。

直播间的实时数据展示及互动数据分析成为我们团队的种子场景，和业务团队沟通也是一拍即合。

万事俱备，只差平台上线了。

经过半年的努力，团队终于把司内首个实时数仓开发平台给干上线了。

本该敲锣打鼓祝贺，可最终结果，可以说：惨败收场。

产品上线，即面临巨大的运营压力。

种子场景上线后，我们试图寻找更多实时场景时，却处处碰壁。

后来，我们团队也复盘过，实时场景太窄了，相对比巨量的离线数仓，数据量太小，容错率太低，但成本又太高。

如果离线数仓是生活中的一日三餐，那么，实时数仓就是高档餐厅。

一家人平均下来一个月去一趟餐厅，但是，一日三餐是顿顿少不了。

那，可能会说，市面上也有很多高档餐厅啊，人家不是都经营的挺好，活得好好的？你们为什么不行？

是啊，如果平均按一个家庭一个月去一趟高档餐厅，只需要 30 个家庭就可以确保餐厅每天都有人光顾，而真实的家庭数远远大于 30 个。

但是，我们支撑内部业务，业务数量一把手都说的过来。

这就导致，基础盘和频率都不足，我们基本处于饥寒交加的状态，吃不饱，根本吃不饱...

再后来，离线数仓平台也上线了实时数据开发相关的能力，我们也就撤出了这块业务。

本想顺势而为，没想到顺的势头不足，浪太小~

一转眼 5 年多了，实时数仓如何了呢？

本以为实时场景会不断增长，怎么也干个 20%的业务场景吧。

结果，前两天和老同事聊天，他提到流式任务占比还是太低，成不了大气候，公司的实时任务占比 1% 都不到。

虽然，我已知实时相关的场景表窄，但坦白讲，听到这个比例，我还是干到惊讶。

惊讶于，要知道这可是头部互联网企业，他们按道理有很多业务场景，会有很高的数据实时性要求，但是，整体实时任务的数量和离线比却如此悬殊。

同时，这也给了我们一个危险的信号。

我们在技术和产品架构上，不断地去追求实时相关的能力，以实现更低的延迟、更快的查询性能。

可，这些是不是真的产生了业务价值，企业业务是否真的有那么高的数据时效性要求，我们是不是在做一件技术自嗨的事情？

坦白说，我不知道，市场太复杂了。

我相信很多人都听过这么一个言论：数据具有时效性，其经济价值会随时间快速贬值。

最著名的案例则是，Netflix（奈飞）发现 90% 的数据分析集中在最近 7 天的数据，超过 3 个月的历史数据仅占查询总量的 2% 。

因此，企业纷纷追求更快的收集数据、更实时的数据处理及挖掘分析。

回过头来看，如果，互联网大厂数据实时性的场景都如此少的情况下，那么，传统企业做数字化转型，他们难道会有更多的高数据时效性的场景吗？

显然，不会，只会更少。

难道，实时数据没有价值？

不不不，这不是我的观点，也不是我想要传递的信息。

从我的经历及接收到的外部信息中，我逐渐的意识到：实时数仓这件事情对于多数企业来说属于 nice-to-have，而非 must-have。

原因主要在于 业务需求、技术成本和ROI 三方面的考量。

适合实时数仓的场景主要有：金融风控（如实时反欺诈）、电商秒杀、智能推荐、在线广告投放、智能制造（实时设备监测）等。

而，传统零售、制造业的供应链管理、HR数据分析、财务报表、BI月度/季度汇总等，通常T+1的数据时效已足够。

实时数仓通常涉及 Flink、Kafka、Doris/StarRocks、ClickHouse 等组件，技术栈复杂，运维成本高。

与离线数仓不同，实时数据受数据延迟、补数机制等影响，更难保证高一致性。

同时，低延迟查询需要大量计算资源，如高并发查询、数据预计算、索引优化，而这往往带来额外成本。

对于传统数据分析场景（如经营分析、市场营销数据、供应链优化）大多使用日级、小时级数据，完全可以通过离线或准实时（Near Real-time）的方式实现。

如果业务不依赖毫秒级响应，建设实时数仓可能是资源浪费。

所以，对于多数企业来说，实时数仓更多是一种增强型能力，而非必需品，只有当业务场景明确需要时，才值得投入资源去构建。

是不是，传统企业根本就没必要追求数据实时性了呢？

这倒也不能一棒子打死。

数据的完整链路，比多数人理解或想象的都要长和复杂很多，上面讲的更多是从全链路实时角度出发的，局部环节追求实时性依然有必要。

比如企业在数据采集或集成领域，通过 FlinkCDC 采集数据库日志来完成近实时的数据采集，依然具有普遍性和价值。

举个例子，电商系统的订单更新、用户状态变化、库存变动等，这些数据需要及时传递到下游系统进行处理。

通过跨系统间数据传递的实时性，能够确保后续数据处理（如数据仓库加载、分析模型训练等）能够基于最准确的最新数据做出决策。

因此，断不可认为追求数据的实时性毫无价值，而是应该辩证性的基于实际情况来灵活选择数据架构及工具。