当你直播购物的时候，系统会实时推荐你感兴趣的商品，当有新闻事件发生，百度搜索、微博的热词排名会实时更新，当你可能遇到网络诈骗的时候，立马收到告警电话……这些场景我们并不陌生，而他们背后可能就有实时数仓在提供支持。

近年来，实时分析场景越来越丰富，实时数仓概念变得非常火热，引发市场关注。IT168&ITPUB策划了实时数仓系列选题，与业内专家共同探讨新技术、新趋势、新应用。本文为其中一篇，采访嘉宾是公众号【数据社】主理人数据一哥，他是大数据资深人士，专注于MPP数据库研究、流处理计算、数据仓库架构和数据分析领域。

实时数仓是一个产品还是解决方案?

数据仓库大家非常熟悉，在1991年出版的“Building the Data Warehouse”，数据仓库之父比尔·恩门首次提出数据仓库的概念，数据仓库是一个面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理决策。

而对于目前比较火热的实时数仓，市场还没有形成共识，并没有统一的定义。数据一哥认为，实时数仓和传统数仓都是一个数据仓库，只是随着业务变化，针对对不同业务场景提供支持。虽然实时数仓这个概念现在才被提到，但是很早就出现了，经历了几个重要的发展阶段。

在早期，企业数据量并没有特别大，实时分析需求没有那么高，通过关系型数据库如Oracle、MPP数据库等业务库能够直接做统计分析，满足实时分析需求。

到了大数据时代，数据量爆发式增长，大数据技术出现，企业会使用Storm流计算框架支持实时热点排名等简单实时计算查询，但是Storm不能很好支持复杂计算。

近些年出现了Spark和Flink等流批一体计算引擎，现在也有很多数据库厂商声称自己在做实时数仓。

在过去，由于业务人员实时分析需求不迫切，且存在技术限制，企业会使用Hive、其他OLAP数据库离线跑批，业务分析只能做到T+1，即前一天的数据到第二天再进行分析展示，现在很多业务场景也是如此。随着实时业务需求推动，实时数据增多，实时计算技术不断发展，Storm、Flink等实时流计算引擎逐渐发展起来，实时计算框架由原来的流批分离的Lambda架构，发展到流批一体的Kappa架构，且新的架构也在不断涌现。

“可能往后实时数仓更偏向一个解决方案。不同行业不同业务场景，对实时数仓有不同选型。”数据一哥说，离线数仓与实时数仓都是数据仓库，离线分析一般会对大数据量进行批量处理，而实时一般会从大数据量中选小数据量进行处理。现在可以看到有不同的数据库厂商，包括一些开源的OLAP厂商，都说自己能够做实时数仓，不同的业务场景下都有各自的优势。

目前市场上见到的实时数仓更多是一个“数据仓库+流计算引擎”的解决方案组合，而非单独的数仓产品，比如阿里云提供Hologres+Flink实时数仓解决方案，星环科技提供ArgoDB+实时流计算引擎Transwarp Slipstream实时数仓解决方案，偶数科技由OushuDB+Lava组合成实时湖仓方案等。据了解，也有数据库厂商正在尝试将流处理内置到数据库中提供实时处理能力。

业务需求与技术发展是一个螺旋上升的过程，实时数仓的发展也源自实时业务需求的推动，那么现在实时数仓有哪些应用场景?在哪些行业应用较快?

实时数仓应用场景有哪些?

数据一哥介绍，实时数仓有一些典型的应用场景，比如实时Top排名、热词展现，在百度热搜、微博热词中可以看到;实时告警监控，如物联网方面，特别是现在火热的新能源汽车，电池不稳定，对电池使用提供预警等;实时推荐，比较常见，如现在火热的电商直播推荐。或者在一些购物平台点击某些商品后，微信朋友圈可能会出现实时推荐广告等;金融反欺诈，近两年国家在大力推行网络防诈骗，银行反欺诈实时预警是实时数仓的一个重要应用场景。

以火热的电商直播为例，在今年火山引擎原动力大会上，字节跳动副总裁杨震原介绍，抖音电商实时需求场景非常多，业务活动的频次很高。需要在不断爆发的需求之下，保证数据支持能够很实时地完成，火山引擎实时数仓为抖音电商提供了实时大屏、实时分析、实时预警、实时营销的全套实时数据。

“实时数仓挺火，但是应用场景可能没有那么多。”数据一哥认为实时数仓整体上还处在初级发展阶段，即便是一些中大型企业，实时业务场景也不是很多，有的企业可能没有专门的实时数仓技术团队，或者团队规模很小，几十甚至上百人做离线数仓，只有几个人做实时数仓。而中小型企业，由于数据量没有那么大，使用关系型数据库或者MPP数据库便可以进行实时统计分析，无需进行复杂计算，可能不需要运用Flink这样的实时计算引擎，或者某些大厂宣称的实时计算框架。

据数据一哥了解，实时数仓在不同行业的落地也参差不齐。整体来看，实时数仓在互联网行业发展最快，占有先机，因为一方面技术储备充足，互联网企业有大量的相关技术人员，另一方面，组织架构有优势，传统行业技术选型需要在流程上层层审批，互联网行业架构更为扁平灵活。但是目前很多互联网企业建设实时数仓，都是在进行技术预研或者创新尝试，并不一定会立马应用到业务场景中。

另一个对实时数仓应用比较靠前的是金融行业，因为在金融行业有政策监管等多方面的需求，实时分析是刚需，所以实时业务场景应用比较靠前。另一个对实时要求较高的是新能源电动汽车对数据实时收集，除了企业自身需求，还包括国家监管要求，要求对汽车实时数据进行监控。

在大部分传统企业，目前对实时分析的需求并没有那么明显。这些企业更多使用离线数仓，就像传统的BI，甚至并不急于知道前一天的数据，只需要针对过去一年的数据分析预判未来一年的趋势，助力公司决策。

实时数仓选型与落地

数据一哥介绍，在实时数仓选型时，企业会关注以下因素：一是数据同步实时写入能力，将源端数据同步过来;二是对复杂业务、复杂事件支持。如Storm以前也可以做实时分析，但无法很好支持复杂计算，所以现在用Spark、Flink进行实时处理;三是能做到实时计算的“Exactly-once”，只计算一次，计算多次就会出现计算重复，实时计算与批计算不同，需要对每个操作进行状态记录;四是，运维成本低;五是稳定性，需要保证业务稳定性。

不过，数据一哥发现，目前有不少企业在应用实时数仓时采用一些开源组件自研，而不是购买第三方产品或解决方案。因为自研能够更加灵活应对企业自身的业务需求。但是自研也不是完全从头创新，企业会借鉴其他厂商成熟的落地方案，结合自己的应用场景，对企业量体裁衣，打造合适的数据展示平台。特别是近两年，受疫情以及外部环境影响，很多企业都在降本增效，对于研发等IT投入变得越来越谨慎。

此外，实时数仓在企业的落地与其原有技术栈有很大关系，如果企业没有相关技术储备，重新引入一个新的技术体系，会产生很高的成本。比如他所在公司原来使用Spark进行批处理，后来进行实时分析时使用Spark进行流批一体处理，并没有引入Flink这样新的实时计算引擎。

需要指出的是，虽然Flink和Spark都是流批一体计算引擎，但是二者的实时数据处理并不相同，Flink与之前的Storm一样是事件驱动，像水龙头流水一样24h不间断处理，也有人指出像自动扶梯。而Spark是时间驱动将任务进行“微批处理”，相当于电梯，一定时间内处理一部分数据，只能用于一些对于时延要求不是很高的流处理业务。据悉，Spark能够达到亚秒级，也能满足很多实时业务场景。

随着实时数据产生的价值越来越多，未来实时数仓的应用也会更广泛深入，企业需要结合自身发展需要选择合适的解决方案。

数据一哥认为实时数仓未来会有以下发展趋势，一是云会是实时数仓的重要发展趋势，公有云可能更有成本优势。二是，统一技术栈，实时与离线技术栈走向统一，比如企业原来使用Spark做离线计算，未来可能也会使用Spark做实时计算;三是统一数据入口与出口，避免离线与实时统计结果不一致。

而实时数仓想要加速落地，除了增强技术能力，更加简单易用，还需要建设更完善的技术生态。“技术想要推广，想要应用发展，生态是很重要的。”