作者：果贝，阿里云资深技术专家 ，实时数仓Hologres负责人

2022年1月7日，阿里云实时数仓Hologres举行了年度发布会，在发布会上，来自阿里的资深技术专家从阿里的核心场景出发，为大家解读了实时数仓的新发展趋势“在线化、敏捷化、一站式”。通过本文，我们将会深入解读实时数仓发展所面临的问题，以及核心发展趋势，以帮助大家更好的做产品选型和数仓规划。

实时数仓是现在大数据领域非常热门的一个概念（和它同热度的大概就是湖仓一体了）。经过十多年的发展，大数据已经成为每家公司的标配。传统上，离线数仓（开源以Hive/Spark为代表，闭源以阿里MaxCompute、Snowflake、AWS Redshift、Google BigQuery等为代表，以及Vertica、Oracle、HANA等传统IT厂商），流式计算（以Flink/Spark Structured Streaming为代表），数据服务层（HBase、MySQL、ES、Redis等）共同组成了大数据处理的标准架构：Lambda架构。Lambda架构提供了实时数据的服务（serving）能力。但Lambda架构的典型问题是开发复杂、数据冗余和分析不灵活。

近几年，以ClickHouse、Apache Doris、阿里Hologres等为代表的实时数仓兴起，通过实时写入明细数据+灵活交互式查询部分实现了去Lambda架构，在实时性、灵活性、成本、管理和运维等多方面都达到了较好的平衡。

随着2021年双11的完美落幕，实时数仓技术在阿里双11场景也经历了多年的实践和发展。从早期的基于不同作业的烟囱式开发，到基于领域分层建模的数仓引入，再到分析服务一体化的新型融合式一站式架构，开发效率逐步提升，数据质量更有保证，也沉淀了更多技术创新，让我们看到了一些未来数仓开发、应用的可能性和趋势。

下面我们来聊聊从阿里双11看到的实时数仓发展的一些趋势。

一 实时数仓已经成为业务标配

第一个趋势是实时数仓已经成为标配。

业务对时效的要求、对灵活性的要求越来越高，从而使得实时数据变为一种刚需。而实时数仓在成本、灵活性上的巨大优势使得业务优先选择实时数仓作为实时数据的生产、存储和使用平台。在阿里巴巴，Hologres服务了约90%的BU，集群规模超过了60万core，并保持100%的增长速度。在这些业务中，有较常见的实时数仓场景，比如：

1. 数字化运营：这种场景上游对接Flink进行数据流式加工；下游对接BI工具、数据大屏等，实现业务的自助开发和上线。极大提升了开发效率和灵活性，支持所见即所得的开发体验。
2. 网络流量分析、Metrics分析：通过对网络流量、及其他Metrics类数据的实时存储和监控，可快速预警和定位设备潜在故障。在万亿级记录上查询秒级响应，故障秒级发现。
3. 实时物流跟踪：通过实时数仓实现物流信息的实时跟踪，保证物流流转状态的实时更新、实时查询。

在这些相对常见的实时数仓场景外，因为分析服务一体化（Hybrid Serving/Analytics Processing，以下简称HSAP）能力（以及与之对应的Hologres高速纯实时写入能力和点查能力），Hologres也被用在了很多非典型的实时数仓场景。例如：

1. 对商家的广告人群圈选：通过Hologres对广大商家（to B）提供高QPS、低延迟的人群圈选和广告投放服务。

2. 无人车送货：Hologres承载无人车上商品的订单、物流等指标信息，面向B端驿站，实时汇报物流信息，从而帮助驿站老板完成智能化包裹分拣、移动投柜等任务；面向用户，再通过系统调度运力，实现”定时上门、送货到楼”。

3. 搜索推荐中的特征存储和样本存储：利用Hologres的强大点查能力，实现实时样本（feature store）、实时特征（sample store）和实时算法效果分析。

4. 客户全链路体验：客服服务部门通过在Hologres存储客户的相关多渠道数据，实现直接对消费者提供各种明细查询能力（to C）。

   …

类似的场景还有很多，数据的实时“被看见”，“被使用”成为企业高速发展的原动力。

二 实时数仓支撑在线生产系统

第二个趋势就是实时数仓越来越成为生产系统的一部分。

传统上，实时数仓（数据仓库）是一个非生产系统。因为它主要面对的是内部客户，所以虽然大屏等重要性很高，但实时数仓本质上并不在生产关键链路上，也就是说，如果实时数仓不可用了，对客户的影响并不大。这也是为什么大部分实时数仓产品在高可用性、资源隔离、灾备等能力上和数据库等系统是有很大差距的。

传统上对外的服务是通过离线/流式加工+结果点查来提供的，即和用户交互的关键链路是结果点查（通过HBase、Redis、MySQL这样的系统去承载）。这种模式的好处是简单可靠，但限制也是巨大的，能提供的服务功能非常有限，且不灵活。业务迫切希望能将内部的实时数仓能力以可控的方式开放给外部客户（to B、to C），并且保持内外两套系统在数据和逻辑上的一致性。上面列举的阿里广告、无人车送货、客户全链路体验等场景都是这种to B，甚至to C的案例。

随着实时数仓作为一个服务对外提供，用户对服务的并发度、可用性、稳定性都提出了更高的需求。这也是Hologres在过去一年中重点发力的地方。Hologres在过去一年中引入了多副本、热升级、快速failover、资源隔离、读写分离、灾备等能力，实现了生产级高可用，并在今年的双11中得到了很好的应用。举几个例子：

1. 阿里巴巴客户体验事业部（Chief Customer Office，以下简称CCO）去年是业务上做了双链路写入和存储冗余来保证高可用。今年双11使用了Hologres原生高可用方案下掉手工双链路，省去备用数据链路上实时任务开发、数据比对的人力投入，减少链路切换时的数据不一致，整体开发人力成本减少200人日，环比去年降低50%以上；减少了100+用于实时重保的备份链路作业，减少计算资源2000CU。
2. 阿里巴巴数据技术及产品部（Data Technology，以下简称DT）使用Hologres读写分离方案，高吞吐写入和灵活查询互不干扰；分析查询QPS增长80%的同时，查询抖动明显减少。

我们认为实时数仓的生产系统化是一个必然的趋势，相信各个实时数仓产品都会逐步加码这方面的开发投入。

三 分析服务一体化（HSAP）

第三个趋势是分析服务的一体化（HSAP）。

Hologres是这方面的首倡者，源头是阿里集团内的业务对分析服务一体化有强诉求，分析服务一体化最佳实践首先在阿里内部落地，但我们在业界也看到越来越多的产品和企业在倡导和实践分析服务一体化。

分析服务一体化（HSAP）可以从几个层面上去理解：

最基础的是用户可以使用一套技术栈（Flink+Hologres）去解决Ad-hoc Query分析（对内）和线上服务（对内、to B、to C）两个任务，从而降低开发运维成本。传统上，实时数仓做的是Ad-hoc Query，而lambda架构实现的是线上服务。这两个在技术栈、数据链路、开发运维等都完全不同，但处理的数据来源往往是同一份数据，导致了大量的开发作业冗余，同时数据的一致性也是大难题。而通过使用统一技术栈同时满足这两方面的需求，开发、运维、治理变的简单。

以阿里CCO的场景为例，数据写入到Hologres行存表后（行存表写入吞吐高，主键查询快，更新场景Binlog开销低），会通过Hologres表的binlog被Flink二次消费加工后，存入Hologres的列存表提供分析（列存对于统计类查询速度快）。行存表提供线上服务/点查，列存表提供分析能力。

更高层次的HSAP是用户可以在一个平台上用一份数据去实现Ad-hoc Query和线上服务两个任务，同时实现良好的资源隔离和可用性。

例如，今年双11 DT部门上了Hologres读写分离方案（由两个Hologres实例分别负责实时写入和实时查询，但共享一份底层数据存储），同时有多个读实例分别负责不同类型的查询，这样就可以保证读写隔离、分析查询和服务查询隔离，且只有一份数据。也就是所谓的One Data，Multi Workload。

分析服务一体化除了上述的好处外，另外一个显著的优势是服务上线速度明显加快。因为一体化后，分析和服务的边界变的模糊，所以服务的开发和分析差异不大，可以认为服务就是一种简单、固定pattern的分析。这样，传统上服务上线的复杂流程就被大大简化了。当有紧急需求需要临时开发，也能马上就上线，无需繁琐的流程了。

我们相信分析服务一体化的理念随着像Hologres这样的产品的发展，会在更多的场景落地。而这也会反哺像Hologres这样的HSAP产品，将HSAP的理念、方法论、支持能力在产品中更好的沉淀下来，从而让更多的用户更容易的从HSAP中获益。

四 实时数据治理成为刚需

第四个趋势是实时数据治理变的越来越重要。

实时数据对于企业来说，有着致命的吸引力。因此，企业会自觉不自觉的逐步加大实时数仓上的投入。而各企业的实时数仓因为实时性的要求，往往没有实施离线数仓那么严密的方法论和管理体系。因为没有治理，数据大量冗余或者不合理，往往会导致成本急剧增大，数据可信度下降。在阿里这样的超大企业中，这块的成本就会突显出来，这已经成为实时数仓的一种刚需。

通过对实时数仓、离线数仓、流式计算、消息队列等全链路进行数据治理，可以实现数据没有“法外之地”，从而在节省成本的同时，提高数据的质量，真正将数据变为企业的资产。

五 实时数仓的类数据库化

第五个趋势是实时数仓的类数据库化。

大数据诞生于对传统数据库的扬弃，从NoSQL到NewSQL，大数据产品走出了一条独立于数据库的路。但就像从NoSQL到NewSQL一样，大数据产品中的实时数仓也在像数据库学习，提供了和数据库更好的兼容性，从而让用户能以更低的成本使用实时数仓产品。

这包含几个方面：

1. 操作SQL化以及和传统数据库在协议、语法上的兼容性，从而方便开发同学可以用习惯的工具（BI、开发工具等）去对接开发。大数据在这方面的积累还是及不上数据库几十年的积累的，相当多的业务同学对于数据库很熟练，但对于大数据（特别是实时数仓）就感觉不容易上手了。
2. 数据模型和语义向传统数据库靠拢。例如，主键（Primary Key）概念是传统数仓类产品所缺乏的，操作的原子性数仓产品往往也不能保证，这就限制了很多场景的应用。比方说，Clickhouse缺乏数据库意义上的主键（CK所说的主键是另外一个东西，非唯一性约束），所以就不合适处理数据库CDC同步场景。这两年，大数据业界可以明显看到对这块的增强。最典型的例子是DeltaLake、Iceberge和Hudi等为代表的近实时数仓增加了ACID能力。当然，受制于架构，这种近实时ACID在频繁更新场景下的性能和延时是有瓶颈的。

在阿里，大量场景需要这种基于主键的更新能力，以阿里巴巴内部场景为例：

1. 数据库的实时同步：通过将上游的分库分表和多个业务库实时同步（镜像）到一个大数据实时数仓中，可以提供对业务数据的强大分析能力，而这就需要很好的处理纯实时的高频UPDATE和DELETE操作。
2. Flink 计算产生的UPDATE和DELETE（RETRACTION）操作：例如统计GMV，Flink在结果更新时会生成UPDATE记录，而在有些场景下会生成RETRACTION记录（DELETE），这都要求下游系统能很好的处理这两类事件。
3. 风控等业务的计算是由多路作业共同完成的，这些作业共同实时更新一张大宽表（每个作业更新部分字段），这就要求下游系统能提供基于主键的部分更新能力。

传统上，这样的业务是由HBase、Redis这样的NoSQL系统或者MySQL、PostgreSQL等数据库RDS来承接的。但NoSQL的问题是分析能力普通偏弱，而数据库问题是写入性能和规模有限制。

这些业务在大数据处理中普遍存在。但在阿里的挑战是因为规模的巨大（特别是双11这样的场景），对基于主键的更新性能和延迟有苛刻的要求。

Hologres从设计之初就考虑了这两点。Hologres完全兼容了PostgreSQL 11的协议、语法、函数等，很多PostgreSQL扩展（例如PostGIS）可以直接使用。同时，Hologres提供了完整的主键概念和强大的更新能力，并提供了单SQL的ACID。今年双11，有业务测得了每秒350万+的实时写入更新性能。这些能力极大的放宽了实时数仓的应用场景，将传统由NoSQL和RDS承载的场景改由实时数仓来承载，为用户提供了更加强大的分析处理工具。

实时数仓的类数据库化并不就等价于HTAP数据库了。HSAP相比于HTAP，在事务能力上是削弱的。因为在服务（serving）场景，并不需要传统数据库完整的事务能力。而这种舍弃，带来的是在实时写入性能和查询性能上的极大提升，以及可扩展性上的提升（因为不需要全局事务管理器了）。因此，HSAP相比HTAP也就更加适合大数据场景。

六 实时数仓开发敏捷化

最后一个趋势是开发方法论上的变化，实时数仓的开发越来越敏捷，以适应分析场景的灵活多变。

过去数仓的开发往往按照经典的方法论，采用ODS->DWD->DWS->ADS逐层开发的方法，层与层之间采用事件驱动，或者微批次的方式调度。分层带来更好的语义层抽象和数据复用，但也增加了调度的依赖、降低数据的时效性、减少数据灵活分析的敏捷性。

实时数仓驱动了业务决策的实时化，在决策时通常需要丰富的上下文信息，因此传统的高度依据业务定制ADS的开发方法受到了较大挑战，成千上万的ADS表维护困难，利用率低，更多的业务方希望通过DWS甚至DWD进行多角度数据对比分析，这对查询引擎的计算效率、调度效率、IO效率都提出了更高的要求。

随着计算算子向量化重写、精细化索引、异步化执行、多级缓存等多种查询引擎优化技术，Hologres的计算力在每个版本都有较大改善。因此我们看到越来越多的用户采用了敏捷化的开发方式，在计算前置的阶段，只做数据质量清理、基本的大表关联拉宽，建模到DWD、DWS即可，减少建模层次，同时，将灵活查询在真正分析时在交互式查询引擎中执行，通过秒级的交互式分析体验，支撑了数据分析民主化的重要趋势。

七 总结

阿里巴巴在业界是较早应用实时数仓来处理海量数据的公司。实时数仓在阿里的发展也逐渐走入深水区。无论是生产系统化、分析服务一体化、实时数据治理（平台化）还是类数据库化、敏捷化，实时数仓正在随着业务需�