流批一体不只有Flink，还有实时数据模型

|0x00 从流批一体诞生的必然性说起

通常来讲，数据仓库的建设，都是以离线作为主要的密报，下游的应用，不论是报表还是接口，所提供的数据也大多是T-1时效性。

但伴随着业务的变化，当离线做到没什么可以继续做的时候，实时就会被拿出来，作为新一个阶段的目标进行攻克。

在流批一体建设之前，这种实时诉求通常会开发成分钟级的任务，通过近实时的方案来解决业务的问题，但分钟级会带来诸如任务过多、资源挤占较大、无法支持复杂逻辑等问题。

因此专门支持实时计算的框架，比如早期的Storm，能够尝试从纯实时的角度解决业务问题，就被拿出来作为尝试。然而Storm的局限性也很大，因为那会的任务开发只能通过Java的方式来进行，与Hive所推崇的纯SQL方案相比，上手难度大了不少，同时两套代码的逻辑几乎没有可比性，这种方案也就一直没有什么声音。

尽管实时技术有各种缺陷，但作为一种能够很容易讲清楚价值的项目，同时又非常便于向上汇报的技术方案，实时技术还是被或多或少的做了起来。在大多数的公司里，实时和离线就会有不同的团队进行维护，或者是同一个团队，但分成不同的项目来执行。这个阶段，优先高效的把业务做起来，哪怕场景再简单，但能够证明实时有价值和前景，这个阶段的目标就算完成了。

以上的各种方案，难免会带来三个特别难以解决的问题：

（1）数据的口径上，实时和离线很容易不统一；
（2）数据模型的规范上，实时和离线也往往是分开建设；
（3）即便是同一种口径和同一种规范，实时和离线也要分成两套代码来维护。

这三个问题短时间内会被高速发展掩盖掉，但当业务对实时的诉求越来越多、压力越来越大的时候，口径和代码的不统一，就会越来越成为阻碍敏捷开发的障碍，需要有方案进行解决。

后来Flink出现了，带来了流批一体的全新方案，这个问题便出现了解决的曙光，这也比较接近我们对于实时计算的理想方案，因为其意义堪比Hive，也成为了各个大厂面试的标配问题。

然而，仅仅学会Flink是不够的，因为流批一体带来的并不仅仅是技术方案或者是框架的改变，同样带来了数据模型的改变，这就要求我们从数据模型上，而不是技术方案上，来制定我们的实时方案。

|0x01 实时的数据模型方案是怎样的

那么我们如何理解“实时数据模型”这件事情呢