导读：大数据计算正从规模化走向实时化，实时大数据建设过程中开始面临很多的痛点和问题。本文内容整理于阿里资深技术专家姜伟华在DataFunTalk上的演讲，为大家介绍阿里巴巴基于一站式实时数仓Hologres建设实时数仓的经验和解决方案。

分享的内容从以下三点展开：

实时数仓的演进：一站式实时数仓
Hologres：阿里经过大规模验证的实时数仓
阿里CCO部门基于Hologres的一站式实时数仓建设过程与经验

点击查看视频回放：
https://www.bilibili.com/video/BV1jY411A73P

实时数仓的演进：一站式实时数仓

1、大数据正从规模化走向实时化

大数据计算正从规模化走向实时化。

随着业务的发展，不管是实时大屏，还是智能交通、银行金融风控、或者是实时推荐都迫切的需要更实时的数据助力业务增长。

常见的实时数仓有两种场景：

面向BI或者内部人员的OLAP分析：主要通过OLAP引擎做明细+自由分析
面向B/C端的线上服务（Serving）：通过Lambda架构预计算后写入KV系统，通过KV系统线上服务。

两个场景用了两套架构，导致实际使用时痛点也非常明显，包括：结构复杂维护难、同步数据困难、数据孤岛、开发成本高等，同时也需要维护很多套系统，无法快速响应业务敏捷需求。业务团队上手成本高，必须大数据团队支撑。

上面是我们看到的在大数据发展过程中的普遍现状。下面，我们也来看看由业务催生的大数据技术发展趋势。

2、实时大数据需要敏捷化

首先第一个趋势就是大数据开发需要敏捷化。包括：

使用普惠化

业务能自助开发：业务团队希望自己能够来做业务开发，而不是把需求提给大数据团队排期开发。
低代码：业务团队相较大数据团队的开发能力更弱，不一定都会Java或Scala这样的语言，有的只会SQL，有的甚至SQL都不会，只会各种BI工具，所以要实现业务团队低代码开发，只需要可视化配置就能得到想要的数据。
数据治理成为刚需：当把开发能力下沉到业务团队时，需要保证比较高的数据质量，所以数据治理成为刚需，否则业务团队开发出来的结果与原始数据无法对齐，会造成非常多的麻烦。

无学习成本

像数据库一样使用大数据：大数据组件上手成本远比数据库要高，业务团队希望自助开发，降低学习成本，最好能像数据库一样开发。
标准SQL，容易上手：业务团队希望开发方式是标准SQL，这样上手门槛更低。
适配常用工具（如Tableau)：同时，业务团队希望开发结果可以和常用工具方便对接，减少开发量和工具学习成本。

开发敏捷化

写入即分析：对业务团队来说，不希望维护复杂的链路体系，最好能写入即分析，减少ETL层次，减少预聚合。
存储明细数据，而非预计算结果
灵活分析，快速上线：业务变化快速，而预计算灵活度太差，需要更改指标计算逻辑时，需要做非常多的改动。而业务侧有很强的快速分析、快速上线的诉求。

所有敏捷化的需求和趋势，都依赖一款强大的实时数仓引擎才能实现。

3、实时数仓走向在线化

传统上，数仓是线下系统，并非用于生产系统。但随着业务的发展，线上数据也需要更加灵活，所以越来越多的业务把实时数仓作为在线系统来使用。所以我们可以看到，实时数仓开始从传统的内部使用，逐渐走到台前，被越来越多的ToB、ToC在线业务使用。如下图的阿里淘宝的智能客服和达摩院的小蛮驴无人配送服务，背后都依赖实时数仓技术。

4、从阿里看实时数仓新趋势：一站式实时数仓

所以实时数仓的发展趋势，不再是把OLAP分析和线上服务两个场景完全割裂，而是希望通过一站式实时数仓去解决这个问题。业务更希望，无论是实时写入还是离线写入，都能统一写入至一个实时数仓，然后通过这个实时数仓来对外提供线上服务和OLAP分析两种能力。

基于此，阿里提出了一个新的理念：分析服务一体化（Hybrid Serving/Analytics Processing, HSAP），期望通过一个产品解决就能OLAP分析和线上服务两个问题。HSAP是比较技术化的概念，与之对应的业务概念就是“一站式实时数仓”。

一站式实时数仓的优势非常明显：实时数据和离线数据统一存储、线上服务和线下分析不割裂，同时因为存有明细数据，所以就能敏捷响应变化，可以快速构建数据服务……

而阿里云产品Hologres，则是HSAP理念下的最佳产物，经过了阿里多个核心场景的生产验证。下面我们将会对其进行进一步介绍。

Hologres：阿里一站式实时数仓

1、Hologres：经过阿里多个核心场景验证的一站式实时数仓

基于一站式实时数仓HSAP的理念，阿里内部完全自研了Hologres。Hologres从诞生至今已有5年多的时间，经历了阿里内部多个核心场景的生产验证，包括淘系数字化大屏、电商分析、阿里妈妈广告投放、智能客服、物流的菜鸟、达摩院、飞猪、饿了么等。并且也稳定支撑了历年的阿里大促场景，如双11、618等。在2021年的双11中，写入峰值达11亿+/秒，单个业务点查峰值达到上亿条/秒。OLAP分析场景，单业务峰值达到2000+QPS，同时支持了PB级数据存储。

2、Hologres与阿里自研大数据产品矩阵深度兼容

Hologres作为大数据OLAP分析与线上服务的统一出口，一套系统就能提供分析和服务2种能力。依托Hologres，再结合阿里大数据产品矩阵如DataWorks、MaxCompute、Flink、DLF等，能非常完美的支持实时离线一体、分析服务一体、湖仓一体、流批一体等场景。

3、一站式实时数仓Hologres的演进过程

对Hologres来说，最开始也并不是能完全支持各种场景，其能力是基于业务理解和技术发展趋势不断演进的。

2020年，Hologres支持通过一套技术栈，通过行存和列存两种存储格式来分别提供线上服务和OLAP分析两种能力。相比传统方式，最大的优势就是统一技术栈、统一模型、统一SQL。同时也比较方便做数据治理。但是数据需要行存列存各写一份，存在割裂，使用上还是有些不方便。

2021年，Hologres支持了行列共存的表，做到了One-Data ，Multi Workload。即一份数据供线上服务和OLAP分析两个Workload使用。其中的行存用来给线上服务用，列存用来给OLAP用，行存和列存的数据是强一致的不需要存储多份，减少冗余和重复导数。同时在企业级能力上提供高可用部署，支持读写分离，有效的隔离分析和服务两种场景，保证了线上服务的稳定性。这些能力也在2021年阿里双11生产级验证。

但我们认为这还不是一站式实时数仓的完全态。

2021年解决的问题是一份数据多个应用场景，而在之后要解决的问题是如何更加的简化数据加工链路，能在一个平台上把数据加工过程用SQL表达出来。比如实时物化视图。目前相关功能正在开发中。这样在横向（多种应用场景）和纵向（数据加工链路）两个维度上都实现了“一站式”。

阿里CCO一站式实时数仓建设经验

Hologres支持了阿里集团内非常多的核心业务场景，比如阿里妈妈、淘宝、菜鸟等。下面我们将会以阿里CCO为例，介绍其实时数仓建设过程中的经验和思考，以帮助大家在建设实时数仓这条道路上走得更加便捷。

1、 CCO应用场景介绍

阿里巴巴CCO全称Chief Customer Office，主要负责阿里全链路的客户体验。其主要的场景有：

客服现场调度：人工分配客服坐席，快速响应线上问题
购物链路预警：在淘系的购物链路中（曝光、点击、加购、下单、物流、售后）发现潜在问题并对客服做出预警，这样客服就能快速响应客户的相关问题并及时处理，避免信息滞后。
AI智能服务：通过AI智能客服承接淘系的在线客服答疑问题，，避免消耗过多的人力成本。

目前CCO业务背后的实时数仓，承载着上千个Flink实时任务，消耗几万CU，写入峰值4000万+条/秒，产生2000万+条/秒Binlog，有超过上千张的行存表和4000张+的列存表。虽然CCO的数据量在阿里不是最大的，但是业务链路却是最复杂之一。

2、CCO实时数仓的三代发展历程

CCO的实时数仓建设也经历了传统数仓-流批一体数仓-新一代高可用数仓的3代发展过程，且目前第三代还在不断的迭代中。

传统数仓1.0：在2016至2017年，通过Flink实时数据加工，把预计算结果写到HBase或MySQL等KV存储中，然后对外提供查询。强调的是重加工和预计算，并且整个链路都是端到端，作业和作业之间不共享数据，就是端到端的烟囱开发。

流批一体数仓2.0：但是业务发展太快，到2018年烟囱开发式的数仓无法更好的承载业务需求。于是用Flink构建了实时数仓的分层（DWD/DWS/ADS)，通过消息队列Datahub来承载。这样，不同的Flink作业之间就可以共享DWD和DWS层的实时数据。计算结果根据业务需求写入OLAP和KV两个引擎。其中OLAP引擎承载的是对内的明细查询分析; KV引擎对外提供点查服务。

这个架构也是目前市面上比较流行的架构，同时也有了数仓分层，能更好的为业务服务。但是在实际业务应用中，也很快遇到了问题。

于是来到了新一代高可用数仓3.0的建设： 2020年CCO开始和Hologres一起构建实时数仓3.0。实时数据通过Flink实时写入Hologres，离线数据在MaxCompute加工后也写入Hologres，在Hologres中统一存储了实时和离线数据。再通过Hologres承载OLAP分析和线上服务两个能力。如果需要二次加工，直接通过Flink订阅Hologres Binlog。

3.0实时数仓架构相比于2.0架构，主要有以下几个优势：

流批一体和实时离线一体。
与Flink有非常好的配合，减少了重复开发。
可用性和隔离型高。
与阿里内部的元数据管理体系有很好地衔接。

3、技术架构升级的挑战和解法

下面我们来具体剖析CCO实时数仓升级换代过程中遇见的挑战和解法。

实时数仓2.0虽然做到了流批一体，但是本质上还是一个Lambda架构，在实际使用中有很多问题：

首先看业务表象：

任务增速快，成本高：2.0时代也是淘系快速爆发的时候，业务增长特别快，导致作业增速快，而开发成本非常高，运维压力非常大。
实时数据产研效率低。每到大促，实时研发就会成为瓶颈，任务和表无统一元数据管理，灾备通过双联路完成，开发和压测成本都非常高。

再来看问题背后的原因：

实时任务烟囱化。实时任务虽然做了很多中间层，但是整个烟囱化还是非常明显，KV引擎和OLAP引擎并不通，形成数据孤岛。数据需要多份冗余存储，形成很多数据同步任务，统计下来大概有30%的作业在做数据同步，浪费很多资源。

• 实时架构瓶颈。元数据的缺失与引擎的单一功能，无法有效的治理数据和任务。

通过架构3.0的升级，这些问题都得到了很好的解决。

以CCO典型的用户画像场景为例来补充说明实时数仓3.0如何解决相关痛点。

典型的画像类场景做法是将多个数据源的数据构建成一个实时大宽表，并实时更新。CCO也不例外，基于主题构建实时大宽表时，把不同来源的数据放在大宽表的不同字段，数据来源于多个上游系统，并且任何字段的更新都能在大宽表中体现出来。传统方案是Flink多流Join，但Flink多流Join的问题在于，上游如果只是一两个流还比较简便，但如果上游是很多个流，那Flink多流Join就非常麻烦。这个痛点在很多公司在做画像类产品的时候都很常见。

CCO还有更重要的诉求是希望上游任何一个字段的变化都要去触发整行数据更新，同时能吐出完整的整行数据被Flink去做二次加工。这也是画像类任务的非常常见诉求。

在实时架构3.0中，实时大宽表利用了Hologres的主键更新能力，多个上游流作业各自更新同一主键的不同字段，完美解决画像类大宽表数据更新的问题。

同时，CCO和Hologres一起共建了Hologres Binlog。这样，画像大宽表的任一字段更新都会透出Hologres Binlog，Flink再基于Binlog做二次加工构建DWS层。

2021年，在实时数仓3.0中，Hologres与CCO共建“一份数据、多种负载”的高可用能力，并在2021年双11中生产级落地：

标注1：行存提供高性能的写入、多副本、Flink读取Binlog二次加工的能力。
标注2：列存提供内外服务，通过共享存储高可用部署，多个实例共享一份存储但是计算资源完全隔离，数据只需要存储一份就能实现分析服务隔离、读写分离、高可用等
标注3：灾备方案。在2.0实时数仓中，灾备方案是双链路。而3.0架构中数据实时写入2后会自动实时同步到3去。简单高效的实现灾备

4、CCO典型应用场景实践

下面我们将结合CCO的3个典型业务场景介绍Hologres在实时数仓3.0中的作用。

场景一：客服资源管理

客服资源管理场景主要是通过数据分析快速的管理客服资源。这个场景并没有非常强的线上属性，更多的是一个内部分析系统。

在这个场景中，离线MaxCompute数据直接通过Hologres查询加速，将外表和实时数据做关联查询得到分析结果；对于实时比较敏感的数据，会通过Flink做轻度汇总，再写入Hologres实时查询。元数据由通过DataWorks数据地图进行查询。这样业务方都可以非常简单高效的自助构建实时监控大屏，比如说某部门人力资源分配情况、接单情况等等。通过BI工具接入Hologres，半小时就可以搭建实时监控大屏出来，非常方便，实现数据敏捷化。

场景二：用户声音洞察

用户声音洞察场景主要是用于实时聆用户的诉求，并及时为用户解决问题。

系统会实时采集用户在淘系购物体验的全链路数据，实时写入Hologres，并通过Binlog订阅二次计算，提供QPS实时分析的能力，支持超过20个BU的用户声音洞察。

场景三：智能客服服务

智能客服场景是是淘宝App上的一个to C能力，比如为88VIP的智能客服服务旨在通过智能化的服务降低人工服务成本。

这个场景就是非常典型的在线服务场景，当用户发起服务请求时，智能服务需要快速响应并提供相应的帮助。在该场景中，充分利用了Hologres的在线服务能力，并使用了Hologres内置的达摩院向量检索Proxima能力，支持向量检索，通过对知识库的向量检索来极大提升了知识的检索准确度，减少了架构的复杂度。