关键词：
导读：大数据计算正从规模化走向实时化，实时大数据建设过程中开始面临很多的痛点和问题。本文内容整理于阿里资深技术专家姜伟华在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能力，支持向量检索，通过对知识库的向量检索来极大提升了知识的检索准确度，减少了架构的复杂度。
总结
通过阿里一站式实时数仓建设经验的分享，我们期望通过实时数仓Hologres能够减少大数据建设中的痛点，行业互通有无，更好的赋能业务增长。
作者：姜伟华（果贝） 阿里巴巴资深技术专家 ，实时数仓Hologres负责人
本文为阿里云原创内容，未经允许不得转载。
阿里云flink+hologres：构建企业级一站式实时数仓
作者｜徐榜江余文兵赵红梅随着大数据的迅猛发展，企业越来越重视数据的价值，这就意味着需要数据尽快到达企业分析决策人员，以最大化发挥数据价值。企业最常见的做法就是通过构建实时数仓来满足对数据的快速探索。在... 查看详情
数仓系列第11篇:实时数仓
...录导读：1.数据仓库简介2.数据仓库的发展3.数据仓库建设方法论4.数据仓库架构的演变5.实时数仓案例6.实时数仓与离线数仓的对比导读：本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以... 查看详情
实时数仓在有赞的实践(代码片段)
...展和商家实时应用场景的不断丰富，有赞在实时数仓建设方面做了大量的尝试和实践。本文主要分享有赞在建设实时数仓过程中所沉淀的经验，内容包括以下五个部分：建设背景应用场景方案设计项目应用未来展望1.... 查看详情
20000字详解大厂实时数仓建设（好文收藏）(代码片段)
一、实时数仓建设背景1.实时需求日趋迫切目前各大公司的产品需求和内部决策对于数据实时性的要求越来越迫切，需要实时数仓的能力来赋能。传统离线数仓的数据时效性是T+1，调度频率以天为单位，无法支撑实... 查看详情
美团实时数仓架构演进与建设实践
分享嘉宾：汤楚熙美团编辑整理：李瑶DataFun出品平台：DataFunTalk导读：大家好，我叫汤楚熙，来自美团数据平台中心的计算平台团队，当前主要工作内容是实时数仓平台的研发。今天和大家分享一下实时数据在美团的典型应用场... 查看详情
各厂实时数仓案例大全(代码片段)
目录前言：一、实时数仓建设目的二、实时数仓建设方案1.滴滴顺风车实时数仓案例2.快手实时数仓场景化案例3.腾讯看点实时数仓案例4.有赞实时数仓案例前言：实时需求日趋迫切目前各大公司的产品需求和内部决策对于... 查看详情
汤楚熙：美团实时数仓架构演进与建设实践
分享嘉宾：汤楚熙美团编辑整理：李瑶DataFun出品平台：DataFunTalk导读：大家好，我叫汤楚熙，来自美团数据平台中心的计算平台团队，当前主要工作内容是实时数仓平台的研发。今天和大家分享一下实时数据在美团的典型应用场... 查看详情
汤楚熙：美团实时数仓架构演进与建设实践
分享嘉宾：汤楚熙美团编辑整理：李瑶DataFun出品平台：DataFunTalk导读：大家好，我叫汤楚熙，来自美团数据平台中心的计算平台团队，当前主要工作内容是实时数仓平台的研发。今天和大家分享一下实时数据在美团的典型应用场... 查看详情
美团基于flink的实时数仓平台建设新进展
传送门：Flink系统性学习笔记1.平台建设现状美团于2018年首次引入Flink实时计算引擎，当时的实时数仓概念还不太普及，平台只提供了FlinkJar任务的生命周期管理和监控报警。2019年，我们注意到实时计算的主要应用... 查看详情
基于flink构建实时数仓实践
...的做出决策，更好的进行产品迭代，实时数仓的建设变得越发重要起来。本文主要介绍用户增长业务基于Flink构建实时数仓的实践之路。实时数仓1.0介绍如下图是早期的实时计算架构，实时数据需求较 查看详情
实时数仓在滴滴的实践和落地(代码片段)
图片1.实时数仓建设目的随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要，商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息，对企业的决策运营策略... 查看详情
数仓系列第11篇:实时数仓
...录导读：1.数据仓库简介2.数据仓库的发展3.数据仓库建设方法论4.数据仓库架构的演变5.实时数仓案例6.实时数仓与离线数仓的对比导读：本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以... 查看详情
flink在顺丰的应用实践
简介： 顺丰基于Flink建设实时数仓的思路，引入HudiOnFlink加速数仓宽表，以及实时数仓平台化建设的实践。本⽂由社区志愿者苗文婷整理，内容源⾃顺丰科技大数据平台研发工程师龙逸尘在FlinkForwardAsia2020分享的... 查看详情
10亿+/秒！看阿里如何搞定实时数仓高吞吐实时写入与更新(代码片段)
...读：Hologres（原交互式分析）是阿里云自研的一站式实时数仓，这个云原生系统融合了实时服务和分析大数据的场景，全面兼容PostgreSQL协议并与大数据生态无缝打通，能用同一套数据架构同时支持实时写入... 查看详情
技术分享：从双11看实时数仓hologres高可用设计与实践
...术人来说，更是一场年度大考。在这场大考中，一站式实时数仓Hologres以每秒11.2亿条的高速写入，和每秒1.1亿次的查询峰值（包含点查和OLAP查询），交出了满意的答卷，稳定高效地支撑了阿里巴巴双11... 查看详情
clickhouse在爱奇艺实时数仓的应用
...艺拥有海量视频，在视频生产过程中产生的上千QPS的实时数据、T级别的数据存储。要支持这样的数据进行即席查询和多个大表的JOIN，是爱奇艺视频生产团队大数据应用的难点。具体来说有以下几点：1)实时性的要求&#... 查看详情
clickhouse在爱奇艺实时数仓的应用
...艺拥有海量视频，在视频生产过程中产生的上千QPS的实时数据、T级别的数据存储。要支持这样的数据进行即席查询和多个大表的JOIN，是爱奇艺视频生产团队大数据应用的难点。具体来说有以下几点：1)实时性的要求&#... 查看详情
clickhouse在爱奇艺视频生产实时数仓的应用
...艺拥有海量视频，在视频生产过程中产生的上千QPS的实时数据、T级别的数据存储。要支持这样的数据进行即席查询和多个大表的JOIN，是爱奇艺视频生产团队大数据应用的难点。具体来说有以下几点：1)实时性的要求&#... 查看详情