忽如一夜春风来，千树万树梨花开！

　　眼下，实时数仓市场可以用“百花齐放”来形容，众多企业都在部署这个“新赛道”。那么，什么是实时数仓？到底是分钟级，还是秒级，有没有一个判断依据或者是标准？如何看待实时数仓发展现状？

　　实时数仓并不是一个新概念

　　“传统数仓已经发展了30多年，至于实时数仓为什么会出现，业务需求是最大推动力。”PostgreSQL ACE Director、南京基石数据技术有限责任公司CTO 白鳝（徐戟）老师，一语中的。

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

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

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

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

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

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

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

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

　　“真需求”还是“伪命题”？

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

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

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

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

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

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

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

　　建设成本过高是实时数仓落地的最大挑战

　　既然实时数仓是“刚需”，为什么很多企业一直没有建起来呢？成本是最大挑战！

　　以一家制造企业为例，随着智能制造的发展，企业全部采用机械臂代替人工完成工作，之前一个2800人的车间，现在已经变成13个人管理，每天能产生几千万的数据，如果能对这些数据及时处理和分析，可以发现生产工艺中的很多问题，大大提升良品率。但这么多数据，只是存储成本企业就无法承担。

　　再以国家电网为例，现在正在建的一个叫“量测”的系统，这也是数仓类的应用，只一个江苏省就有4300万的电表，包括各种用电户、个人、企业等。如果要实现精准的源网互动，需要每五分钟要采样一次，每一次有八条数据。

　　需要注意的一点是，这种采集和运营商打电话不一样，运营商可能是一个省有上亿用户，但是不会每五分钟都会有一个人必须打通电话。或者说，不会在某一个时间点上，所有的人全打一个电话。而做计量采样的话，必须在同一个时间点上才有意义，为什么呢？因为需要计算总的用电量。这个用电量的数据大到无法想象，可能只是一个广西电网七天的数据就是300个T，这样的数据如果以年为单位进行采集，再加上营销数据，其规模的庞大和复杂程度，可想而知 。

　　当然，这些困难都是暂时的，随着企业业务发展的需要，随着云数仓、湖仓一体技术以及各种计算框架的发展，实时数仓会更便宜、更好用、更易用。其实，公有云数仓已经在国外发展得很成熟，国内因为观念原因，会更愿意把数据资产放在自己的本地数据中心，以私有云的形式部署业务。从长远发展来看，公有云数仓可能是最佳选择，无论是技术路线，还是成本上，都能让企业获得更弹性的业务能力。但是，像一些特殊行业，比如国家电网，更重视数据安全问题，不可能把数据放在公有云上。

　　总而言之，不同的企业，有不同的用法，不管是公有云还是私有云，都有各自的发展方向。比如：企业用了阿里云，可能后续的云数仓就会尽可能的贴近阿里云的技术栈来实现；如果企业用的是华为云，那他的技术路线就更贴近华为云。在技术架构上，不管是哪家的云，都有很多共通性，最大的区别是应用层承载的业务不同。（进入专题>>ITPUB-焦点focus）