新一代Hologres实时数仓大揭秘

一、传统数仓痛点

1）传统数据仓库痛点

目前来说，大数据相关的业务场景一般有实时大屏、实时BI报表、用户画像和监控预警等，如下图所示。

实时大屏业务，一般是公司领导层做决策的辅助工具，以及对外成果展示，比如双十一实时成交额大屏等场景。

实时BI报表，是运营和产品经理最常用到的业务场景，适用于大部分的报表分析场景。

用户画像，常用在广告推荐场景中，通过更详细的算法给用户贴上标签，使得营销活动更加有针对性，更加有效的投放给目标人群。

预警监控大屏，比如对网站、APP进行流量监控，在达到一定阈值的时候可以进行报警。

对于上面这些大数据业务场景，业界在很早之前就开始通过数据仓库的建设来满足这些场景的需求，比较传统的做法是如下图所示的离线数据仓库，其大致流程就是：首先将各类数据收集起来，然后经过ETL处理，再通过层层建模对数据进行聚合、筛选等处理，最后在需要的时候基于应用层的工具对数据进行展现，或者生成报表。

上面这种方式虽然可以对接多种数据源，但是存在一些很明显的痛点：

ETL逻辑复杂，存储、时间成本过高；

数据处理链路非常长；

无法支持实时/近实时的数据，只能处理T+1的数据。

2）Lambda架构痛点

随着实时计算技术的兴起，出现了Lambda架构。Lambda架构的原理如下图所示，其思路其实是相当于在传统离线数仓的基础上再加上一个处理实时数据的层，然后将离线数仓和实时链路产生的数据在Serving层进行Merge，以此来对离线产生的数据和实时产生的数据进行查询。从2011年至今，Lambda架构被多数互联网公司所采纳，也确实解决了一些问题，但是随着数据量的增大、应用复杂度的提升，其问题也逐渐凸显，主要有：

由多种引擎和系统组合而成，开发和维护成本高，学习成本高；

数据在不同的View中存储多份，空间浪费，数据一致性的问题难以解决；

从使用上来说，Batch，Streaming以及Merge Query等处理过程中均使用不同的language，使用起来并不容易；

学习成本非常高，增大了应用成本。

上面讲到的问题，在阿里内部其实也都遇到过。如下图所示是阿里巴巴在2011-2016年沉淀下来的一套实时数仓架构，其本质上也是Lambda架构，然而随着业务量及数据的增长，关系复杂度越来越大，成本急剧增加，因此，我们迫切的需要一种更优雅的方案去解决类似的问题。