现在在一些大型企业里，实时数仓是个筐，什么东西都要往里装。只要是OLTP系统中考虑不周的，亦或做起来挺麻烦的，开发商都会往实时数仓里推。前阵子参加一个项目方案的评审会，很多专家提出一些历史数据分析、即席查询等相关的业务实现，开发商直接就说这个交给数据中台来实现，本项目不建设。这位大哥实际上是知道的，目前的数据中台里压根没有实时数仓，目前数仓里的数据是T+1的，即席查询是肯定没戏的。从这个甩锅的故事也说明数据中台在企业里的地位和作用，以及实时数仓的作用了，实时数仓可以解决大量的OLTP系统中十分麻烦，不容易实现的功能。
实时数仓是相对于传统数仓而言的，以前的传统的数仓都是T+N的，因为数据要从生产环境到ODS再经过ETL进入数仓成为明细数据，经过计算加工形成轻度汇总汇总数据和统计数据，再根据主题组织为数据集市，再提供给数据应用使用。
在信息化发展到现在阶段，传统数仓已经很难满足实时性较高的应用需求了。比如面向客户服务类应用的用户画像，当用户和我们的信息系统交互的时候，系统应该很快的对该用户进行精准的画像，从而更好的为这个客户服务，为客户提供个性化的信息与服务。这种分析的复杂度不算太高，但是并发量是万级甚至十万百万级的。并且随着客户在享受服务的时候，还需要对客户当前所在的地理位置、点击菜单的行为、上网时间、上网方式、站内搜索的行为等进行实时性的分析，从而更好的达成商业目标。利用传统数仓是实现不了的。
另外一个案例是能源行业的源网荷储互动，最近我们遇到了数十年一遇的极端炎热干旱天气。水电发电量不足，工农业与居民用电量激增，导致电网负荷与电网调度难度加大。电能是无法储存的，发电，用电，输变电必须协同。发多了，用不了必须储存起来，否则就浪费了。电能不够了，只有两条路，一条是从储能中释放，另外一条是拉闸限电。哪怕发电用电是匹配的，电网调度出现了失误，用电侧缺点，发电侧送不出去，一边是弃电，一边是拉闸限电，就更不划算了。要想增加协同能力，就必须优化电网调度计划，这种优化只有实时数仓才能做得到。
某些业务对于指标的分析，不仅仅需要看历史的数据，而是要根据当前的指标与一些历史的数据进行联合分析，才能够对实时性的指标产生更为准确的反馈。传统数仓向实时数仓的演进是随着技术发展而不断进步的。最初是准实时ETL替代了以前T+N的传统ETL工具，比较典型的是ORACLE的ODI(Oracle号称ODI不是ETL，是ELT)。不过准实时ETL还是很难解决数仓业务的实时性分析需求，因此随着流式计算和内存计算的快速发展，LAMBDA/KAPPA等计算架构逐渐成为实时数仓应用的主要计算框架。这主要是因为在数仓中不可避免的存在实时数据和离线数据这两种数据规模，数据处理模式差异极大的类型。因此分层计算成为必然。
另外ODS的地位十分重要，但是传统的ODS又无法满足实时处理的要求，在大量的实时数仓应用中通过KAFKA等消息中间件或者数据湖来替代ODS，实现数据的订阅，分发工作。
不管怎么样，目前实时数仓建设往往都需要企业具有较为严格的数据管理，有比较规范化和相对固定的数据流，同时也需要有较强的研发能力，才能真正把实时数仓建好。拥有上面的一切，意味着两个字-“有钱”。目前实时数仓建设的成本还是过高，因此也阻碍了资金不足的客户和中小客户建设实时数仓。这个情形和30年前中国的电算化发展初期类似，当时建设一个信息管理系统是十分昂贵的，很多企业没有实力完成。正是数据库厂商解决了这一难题，FOXPRO的大行其道让MIS系统的建设门槛一下子降低了数个级别，而Oracle等关系型数据库功能的日益强大让网络时代的信息系统建设成本变成了白菜价。
在实时数仓这件事上，我好像又回到了三十年前为企业建设MIS系统的时代了。如果数据库厂商能够解决其中的一些问题，让实时数仓建设变得越来越简单，那么实时数仓才真正能迎来大爆发。
而数据库厂商也在自己的产品中增加更多的跨界能力，来支撑需要实时数仓能力的需求。交易型数据库厂商希望通过提供具有HTAP能力和多模能力的数据库系统来解决数仓的应用。不过HTAP的交易型数据库只能解决一部分数仓的问题，解决不了所有的问题。当一个企业的业务系统可以简化到可以放在一个数据库里的时候，HTAP数据库是可以承担实时数仓的功能的，这对于一些中小企业来说，是有可能的。而对于大企业，或者业务相对比较复杂的企业，就很难做到。
传统数仓的ODS被计算框架改良后，实际上没有办法十分完美的解决传统数仓应用中的业务明细数据的共享问题，还是会影响到一些业务的实现，因此湖仓一体化的需求又涌现出来了。复杂的计算框架让很多研发能力相对较弱的客户感到很困难，因此很多数据库厂商也尽可能想让用户能够用傻瓜机的模式来构建其实时数仓，因此云数仓，湖仓一体等解决方案也变得越来越复杂，功能也越来越强。
实际上实时数仓既可以是一种解决方案，也可以是一种计算框架，也可以被做成一个产品或者一个数据库加上一组工具。实时数仓的应用场景，客户需求差异很大，因此我不大相信一个方案能够包打天下。一些实时数仓方面的从业人员认为KAPPA是LAMBDA的进化和升级替代，而我从我的经验上隐隐感觉，不是这样的，不同的用户与需求场景，用户会选择不同的计算框架，二者不是集成升级和替代的关系。
数据库厂商能不能像三十年前那样，用一个标准化的IT基础设施，完美地解决企业实时OLAP分析的需求，解决流式计算与离线计算分层的问题呢?我想会的，同时也十分期待。
