传统数仓已经发展了30多年，至于实时数仓为什么会出现，业务需求是最大推动力。

以2015年一家企业自建的全业务统一数据中心为例，之前都是传统数仓，是T+N模式，企业把整个业务分为TP域和AP域。其中，AP域是以传统数仓为核心。现在，由于业务发展，企业开始向实时数仓转型。

一般来说，实时数仓不是简单的一款产品，而是“数据存储+数据计算+数据管理”这样一套体系，主要通过内存计算、流式计算、分布式存储系统、分布式数据库等等技术来实现。

实时数仓与离线数仓的最大区别是，数据服务的供给能力不一样。离线数仓一般处理的是一种相对来说比较成熟的数据，但随着数字化时代的到来，离线数仓的延时已经制约了某些业务场景的发展。现在，企业需要一种新的数据服务能力，而这种能力只有实时数仓才能满足业务的时效性要求。

至于，到底是秒级、分钟级，还是小时级数仓？白鳝老师认为，要根据业务场景去构建，没必要做具体定义，企业最终目标是解决业务问题。

当前，实时数仓的典型特征是，几种技术路线并行，以KAPPA为例，虽然比LAMBDA出来的晚一些，但二者并不是替代关系。同时，数据湖和数据仓库也不是层级替代关系，而是走向融合趋势，比如湖仓一体。

所以，从传统离线数仓到实时数仓，确实是“里程碑式”的跨越，但单独把实时数仓拎出来看，只不过才几年时间，还处于初级阶段。如果非要用一个词来概括实时数仓发展现状，应该是处于爆发期的“前夜”。

其实，实时数仓需求一直存在，只不过在传统技术条件下，无法实现。20年前，设计新一代金融交易系统时，就有人想基于客户画像提供个性化服务，不仅要基于历史数据进行分析，还要了解用户登录系统时候的位置、时间、上网方式等等，需要根据现有数据进行即时计算，需要实时数仓能力的“加持”，只不过当时的计算、存储、技术框架等能力都不具备，也就无法做准确的故障诊断、指标分析、根因分析等。

问题是，最终哪种技术会占上风？现在还不能确定！虽然，对于具有海量数据的企业来说，实时数仓需求确实强烈，但采用的技术路线并不相同，未来也许会有新的技术推出。

值得一提的是，单从业务角度来看，有些业务存在“真需求”，有些业务存在“伪需求”，如何理解呢？

一些大型企业，决策周期就是以天为单位，对实时数仓的要求其实没有那么高，但业务部门会提出来，这就是伪需求。而有些场景确实是业务发展在推动，以四川今夏缺电为例，本来是电力大省，为何会缺电呢？了解情况后才知道，是极端天气导致的电力不足。这其中会涉及“源网荷储互动”的问题。源，是指发电厂；网，是电网、网络；荷，是负荷；储，是储能。最早，我们没有储这个概念，只有源网，尽可能通过电网调度技术来实现发电侧的发电，并且及时送到用电侧。现在看来，传统调度技术已经无法平衡发电和用电侧的供给，因为缺少秒级或者毫秒级的负荷计算，传统负荷计算周期太长，导致出现重大损失。

所以说，实时数仓在很多场景下确实有需求。与之相对比的是，德国的一个清洁能源案例，在七年前这个国家就已经有超过30%的清洁能源了，有一次因为日食的原因，导致太阳能发电量下降，缺失的用电量得从其他地方购买。而实际情况是，日食的影响没那么大，买多了的电该如何处理？如果不及时卖出去，得损失几千万美金，最终通过实时计算，准确评估出用电量，有效防范了风险。

实时数仓不仅确实有需求，而且落地方案越来越丰富，技术落线越来越多。比如，很多人提到的LAMBDA、KAPPA这样一些计算框架。至于，这些计算框架是怎么来的呢？和数据密切相关！很多应用都会涉及两层数据：一层是离线的历史数据；另一层是流式数据，也就是现实数据。这两层数据如何整合在一起，形成统一的数据库？如何有效计算、存储数据？计算框架将有效解决这些问题！

一些新型计算框架已经在弱化传统数仓功能，比如通过Kafka替代ODS，解决明细数据汇聚、系统内大量分享等问题。当然，也有很多企业采用数据湖技术来替代ODS。还有一些企业，希望通过HTAP来解决实时数仓的问题。很多用户甚至不要数仓，因为企业的生产系统就是数据仓库。同时，很多国产的数据库解决方案已经融合了Flink、Spark这样的计算框架，包括数据过来以后，可以实现行存和列存的自动转换，一般在TP域的数据是都是行存。

很多实时数仓的能力其实已经集成在数据库里，如果企业特别急迫地想解决时效性要求高的问题，而且是毫秒级的技术响应，前端可以通过HTAP解决方案来实现；但有些是秒级或者分钟级的业务响应，可以放到湖仓一体解决方案中去处理，可以实现更复杂的业务分析需求。

大体情况是，企业没有办法通过一种框架支撑所有业务，不同业务场景要采取应用分层的形式，或者通过差异化路线，去解决各种问题。