漫谈实时数仓

什么是实时数仓

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

实时数仓主要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP分析、实时的数据看板、业务指标实时监控等场景。总之就是一句话：实时数仓是在离线数仓的基础上进一步满足时效性的要求。

实时数仓 vs 离线数仓

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

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

如何做实时数仓

流式处理框架出现之前，我们会有MPP数据库来做实时的OLAP计算，甚至是关系型数据库都可以做。后来Storm出现了，真正的流式处理框架来了，结合消息队列中间件，我们实现了真正的流式计算。

但它无法很好支持复杂计算，另外新的技术总是迭代的非常快，你懂的。所以现在用Spark或者Flink进行实时处理：

Flink和Spark的技术社区都很活跃，而且现在很多企业本身都一直在用Spark SQL做离线数仓，这样用Spark做实时计算的运维成本也会比较低。

这是之前做的一个对标，可以参考：

另外，现在阿里、腾讯、华为等都宣传的有自己的实时数仓解决方案，可以去官网看一下。

实时数仓的应用场景

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

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

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

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

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

实时数仓的展望

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

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