本文根据2024云栖大会实录整理而成，演讲信息如下：
演讲人：
姜伟华 | 阿里云智能集团资深技术专家、Hologres 负责人
丁 烨 | 阿里云智能集团产品专家、Hologres 产品负责人
活动：
2024 云栖大会 - 商用大数据计算与分析平台论坛
2024年云栖大会，Hologres 3.0全新升级为一体化实时湖仓平台，通过统一数据平台实现湖仓存储一体、多模式计算一体、分析服务一体、Data+AI 一体，发布 Dynamic Table、External Database、分时弹性、Query Queue、NL2SQL 等众多新的产品能力，实现一份数据、一份计算、一份服务，极大提高数据开发及应用效率。同时，Hologres 的预付费实例年付折扣再降15%，仅需7折，不断帮助企业降低数据管理成本，赋能业务增长。
一、Hologres 3.0 全新升级：一体化实时湖仓平台
1. 构建一体化实时湖仓平台的挑战
- 技术架构之争
在几十年的大数据发展演进历史中，经历过多轮的技术迭代。随着 Hadoop 的普及，涌现出许多相关工具，如 Hive、Spark、HBase 等，形成了一个完整的技术生态系统，但是由于组件太多，业界开始了从 Lambda 到 Kappa 的探索。随着数据湖技术的发展，对于数仓、数据湖、湖仓等方案的讨论不断增多，然而到底什么数据放在仓、什么数据放在湖，如何提升湖仓使用的一致性与易用性等等还有很多问题要去解决。近两年的技术架构又出现了明显的 All in one 的趋势，企业不想再维护多套不同的组件，希望通过一个引擎可能满足大部分的需求，从而可以有更多的时间专注于业务的实现，并且希望这个引擎同时可以满足未来几年的技术架构演进，不管是对于湖的融合，还是对于数据成本与时效性，这也是 Hologres 3.0提出一体化实时湖仓平台的背景。
- 计算模式之争
在核心的计算层面，也一直同时存在着 MapReduce、流计算、MPP 等多种计算模式，而在一体化的背景下，业界尝试了很多流批一体的方案：例如 Flink、Spark 等在计算层实现了流批的统一，但是由于数据层不统一，还会出现数据的冗余，Hologres 等一些新兴的技术栈尝试从存储层实现流批一体，实时和离线可以对同一张表写入/更新，统一数据口径，但是由于计算层未统一，还是有两套任务，两套代码。当前最新的计算模式都在朝同时支持全量/增量/流式的多模式计算演进，这也是后面 Hologres 3.0会重点讲到的能力。
同时在计算层特别是实时场景，还有一个比较大的问题就是实时数仓的分层，因为有分层才有复用，有复用然后便能得提升性能，降低成本。这个在离线数仓里面问题不大，但是在实时数仓里怎么控制每一层的时效性？每次分层如果用全量去计算，那么每一层都需要花比较长的时间。最后整个实时链路端到端的时效性就非常差了，这个对于实时来说明显是不行的。
业界常用 Flink+Kafka 的分层方案，但是会有大量的同步任务，资源消耗非常大，处理链路也非常复杂，而且中间层的 Kafka 不便于排查，复用性比较差。同时也无法做到快速响应 schema 的动态变化，比如MySQL 原表又发生了加列改数据类型等等情况，整个数据链路都需要做改动。这个也是企业级实时数仓需要解决的核心问题。
- 性能成本之争
最后无法避免的是性能与成本的平衡，实时是非常消耗资源的。Hologres 是云原生的产品，天然具备存算分离的优势，存储和计算都可以做到弹性扩展，计算自动分时弹性，存储自动冷热分层。而且作为商用的平台，稳定性、可观测性、安全性等等具备明显的优势。近两年很多客户对我们都提出了降本的诉求，后面我们也会讲到在整个实时场景下的资源管理方案，通过 Serverless 来控制实时场景下的成本与稳定性。
2. Hologres 发展历程
2016年 Hologres 诞生于阿里巴巴集团内部，最开始是为了满足双11等大规模场景下实时性能的要求，作为 Flink 的新型 KV 存储引擎来保证数据实时写入、存储与查询，作为 MaxCompute 的交互式分析引擎进行离线数据的加速查询与分析，在支撑双11关键业务后合并为 Hologres。2020年 Hologres 发布1.0版本，开始在阿里云上商业化，以分析服务一体化（HSAP）的理念，将技术架构的论文发表自 VLDB2020，我们希望通过 HSAP 的架构，可以让一份数据同时满足交互式分析、Servering 等多种计算场景的需求，并提供极致的实时性能，数据写入即可见。2023年 Hologres 发布2.0版本，在原先满足性能要求的前提下，通过 Serverless 来解决实时场景的隔离与弹性，帮助客户降低成本，同时也开始了针对湖仓场景进行了技术升级，不仅以更快的速度查询 MaxCompute 与 OSS 数据，还原生支持 JSONB 的半结构化数据。
2024年 Hologres 在原先分析服务一体化的基础上发布全新的3.0版本，升级为一体化实时湖仓平台，通过统一数据平台实现湖仓存储一体、多模式计算一体、分析服务一体、Data+AI 一体，无缝对接主流BI工具，支持 OLAP 查询、即席分析、在线服务、向量计算多个场景。
3. Hologres 3.0 全新升级：一体化实时湖仓平台
全新的 Hologres 产品架构面向未来的大数据与 AI 一体化融合发展设计，主要包含四个方面：
- 湖仓存储一体
存储层，除了Hologres自带的高性能存储，带来极致的性能。Hologres 3.0同时支持 MaxCompute、Paimon、Delta Lake、Hive、Iceberg、Hudi 等开放的数据湖格式，并针对每种格式进行性能优化，达到最好的性能，例如当前对Paimon的查询速度已经达到了内表的60%。在使用体验方面，Hologres 3.0发布全新的 External Database 进行统一的元数据管理，支持对接阿里云 DLF、HiveMetastore、MaxCompute，实现元数据的双向自动映射。
- 多模式计算一体
计算层，Hologres 3.0新增 Dynamic Table 功能，同时支持全量、增量、流式（V3.1)三种计算模式，在流批一体，湖仓分层等场景实现一份数据、一份 SQL 、一份计算，同时统一了计算层与存储层。流和批都基于相同的数据模型进行操作，确保历史数据和实时数据的分析结果具备一致性和可比性，极大提高了数据开发和应用的效率。
- 分析服务一体
应用层，Hologres 从诞生之初就同时支持 OLAP 查询、即席分析、在线服务等场景，但是面向应用的性能、稳定性、成本等还有很多要求，Hologres 通过在 Serverless 场景上的不断地演进与迭代，发布了例如计算组（Virtual Warehouse）、Severless Computing 等功能保持分析服务的隔离与稳定性，Hologres 3.0发布分时弹性，Query Queue 等能力，形成了分析服务一体化场景下的完整 Severless 资源管理方案。
- Data+AI 一体
面向AI与大模型，Hologres 支持向量计算，通过和阿里云人工智能平台 PAI 等产品的结合，可以5分钟一键拉起基于大模型的 RAG 检索增强方案，构建企业级知识库。凭借 Hologres 自带的高性能与企业级易用性，提供高 QPS、低延时的向量计算服务。同时作为面向分析的大数据引擎，Hologres 3.0对接了DataWorks、百炼析言 GBI 等具备 NL2SQL 能力的产品，深度结合 Hologres 自带的高级函数，构建一站式 ChatBI 解决方案，提供低门槛，高性能、灵活易用的数据分析体验。
二、Hologres 3.0 深度解读
1. 湖仓存储一体
数据湖的技术的兴起，企业会有更多的结构化、半结构化数据放到数据湖里，这些都会围绕对象存储去展开。相比数据仓库，数据湖可以更灵活的，更方便的去存储这些数据。随着技术的发展，现在都往湖仓融合方向发展，Hologres 也在从传统的实时数仓向实时湖仓进行转型，支持 MaxCompute、Paimon、Delta Lake、Hive、Iceberg、Hudi 等开放的湖仓数据格式。
以 Hologres 和 Paimon 的结合为例，在 TPC-H 标准测试集上查询 Paimon 表，同等计算资源下，Hologres V3.0.5 相比 Trino 422有6倍以上的性能提升
数据湖生态有很多外表的概念，PG 生态也有 Foreign Data Wrapper (FDW)的外表概念。但是 FDW 其实在使用上其实有很多限制。因为它有两份元数据，源端湖里有一份元数据，在目的端这边也有一份元数据，然后做权限控制。使用起来难度比较高，比如还需要去刷新元数据等等。很多湖仓一体的架构都在做统一的元数据管理，Hologres 3.0发布了 External Database，在整个使用过程中，我们只需要创建 External Database，就可以将外部数据源 Catalog 级别下的 DB 和表全量映射至 Hologres，现在支持MaxCompute、DLF、Hive 的 HMS 等等。其次由于 PG 本身原生的就是三层的结构，所以 External Database 可以直接被传统的 Superset，Tableau、QuickBI 等 BI 工具读到，也不需要更改任何 SQL，可以直接使用。最后就是 ETL 场景，可以用 Paimon、Iceberg 等格式直接写到数据湖上，包括去消费 Paimon 的 Changelog。
至此，Hologres 3.0支持了多种开放的湖仓数据格式，并提升了 Paimon 等格式的查询性能，通过 External Database 统一管理元数据，提高湖仓的使用体验。后续将继续讲解结合 Dynamic Table 的实时湖仓架构的设计。
2. 多模式计算一体
在流批一体的发展过程中，有两种发展路径。
- 计算层流批一体
例如 Flink、Spark 等在计算层支持流（Streaming）和批（Batch）两种处理模式，这种方案可以统一 SQL 方言，降低开发门槛和成本，缺点是存储层并未统一，还是会有离线、实时两套存储，造成数据冗余。而且虽然使用同一种 SQL 方言，还是两个任务，会导致数据不一致的问题。
- 存储层流批一体
例如 Hologres 等新技术栈将存储层统一，实时和离线可以对同一张表写入/更新，同时存储离线历史数据和实时数据。在计算层，批计算用 Hologres，流计算借助 Flink，ADS 层数据依旧统一使用 Hologres 里的数据，通过分析服务一体化，这样数据可以一直在 Hologres，统一数据口径。但是这种方案在计算层面并未真正统一，还是需要维护两套任务，两套代码，并且这类产品是天生为实时与性能设计的，在做大批量离线计算时可能会 OOM，影响体验。
- Hologres Dynamic Table：多模式统一计算
Hologres 3.0发布了 Dynamic Table，将存储层和计算层均实现流批一体，通过一份 SQL，即可实现全量、增量、流式的数据更新，满足不同业务对于数据时效性和成本的要求。
Hologres 会保证3种模式的SQL语义一致，计算逻辑尽量复用，实现计算层统一，刚才提到 Hologres 本身就具备存储的流批一体，这样就实现了计算层、存储层均统一的架构。而且 Dynamic Table 是一种声明式数据处理架构，引擎会自动管理数据 pipeline，在资源层面也可以通过 Serverless Computing 资源执行计算，同时也实现资源层统一。在全量、增量、流式三种不同的模式上，Dynamic Table 在每个模式上都做了不同的优化，例如在全量刷新的场景上，优化多种算子，自适应 agg、join 等场景，这些技术优化可以充分发挥分布式计算算力，达到性能与成本的完美平衡。
在 Demo Case 上，可以看到我们在创建 Dynamic Table 的时候，只需要修改不同的 refresh mode，就可以控制不同的刷新模式和刷新间隔。一份数据、一份 SQL、一份计算，多种刷新模式，满足不同的业务时效性要求。
在我们展示的 demo 大屏示例上，可以看到上方是实时更新的数据，左下角是增量更新的每小时数据，右侧是全量刷新，支持历史数据回刷修订，并且可以使用不同的计算资源进行执行，例如全量这种资源消耗高的场景，可以单独使用 Serverless Computing 来执行，非常方便的隔离全量刷新任务，提升任务运行的稳定性。
3. 一体化实时湖仓架构设计
在有了 Dynamic Table、External Database 等众多能力更新之后，Hologres 3.0可以有更好的湖仓一体使用体验。面对传统时效性高的场景，通过全仓架构，可以实现极致的数据查询能力。面对湖仓融合的场景，也可以通过将 ODS 数据放在数据湖，使用 Dynamic Table 数仓分层，简化整体湖仓的架构，提升使用效率。
我们以 Hologres+Paimon 为例，简单介绍下一体化实时湖仓架构的设计：
- 首先在 DLF 建表，External Database 会自动映射元数据，我们可以直接通过 Flink 将实时数据写入Paimon。
- 数据存储在 Paimon 的时候，Hologres 一方面可以直接查询 Paimon 数据，也可以通过创建不同模式的 DWD 层 Dynamic Table 表，由于 Hologres 支持 Paimon 的 Change log，并且自带 Binlog 的能力，可以直接消费并实现 DWD、ADS 层的增量数据更新。
- 如果有时效性要求，也可以直接把增量模式直接改成流式模式，无需改动其他任何的代码。
- 在 Hologres 中二次加工的数据，同时可以回流 Paimon，后续供 Hologres、MaxCompute、EMR、Flink 引擎等做二次消费。这样整体一体化的实时湖仓架构可以在使用体验、时效性、成本上取的平衡。
一体化实时湖仓架构下，在性能上 Hologres 的外表查询对比 Trino 有6倍的性能提升，如果数据在 Hologres 内表，性能提升将会高达10倍。
Hologres 是当前唯一一款支持消费 Paimon 的 Changelog 的 OLAP 引擎，可以读取 Paimon 表中 Changelog 生成的数据。
易用性上，Hologres 只需简单修改刷新模式，无需改动其他代码，即可切换 Dynamic Table 刷新模式。流式或者增量往往还会有一些数据一致性的问题，Dynamic Table 的流式和增量模式还可以设置分区结束之后自动转全量刷新，业务可以使用全量刷新再回刷一次数据，保持数据的一致性，这样我们不用再去单独写流或者批的逻辑，逻辑在 Dynamic Table 一直只有一份，Hologres 自动管理。
在实际应用的时候，一体化实时湖仓架构不管是全仓的架构设计，还是湖仓的架构设计，均有性能和效率的提升和成本的降低。在2024年淘天集团618大促的案例中，淘宝直播这类对于直播时效性要求相对较高的业务，数据全部存储在 Hologres，采用全仓架构，通过 Hologres Dynamic Table 流式刷新+全量刷新两种模式设计数仓分层，实现了50%的成本降低，并提升了200%的开发效率。在淘天营销活动分析的场景，历史数据存储在 Paimon 上，业务时效性要求在分钟级，而且有更多全量回刷的场景，通过 Hologres Dynamic Table 增量刷新和全量刷新两种模式处理 Paimon 的数据，实现了70%的成本降低，减少了80%数据回刷延迟。
4. 分析服务一体
2020年 Hologres 商业化的时候，就提出了分析服务一体化的 HSAP 架构，在这个架构下，本质是希望通过一份数据，满足多种计算的要求，于是在架构上需要是存算分离的架构设计，使用同一份数据，不同的计算可以单独扩容。但是，在这个架构下面，对于资源管理的难度是非常大的。
- 隔离与稳定性问题。分析和服务不同业务资源如何保障，互相隔离不受影响？不同业务部门之间的查询如何隔离？故障如何快速恢复？
- 资源浪费问题。波峰波谷分时特征明显，需要预留限制资源
- 大任务难题针对全量数据同步，历史数据回刷等大 ETL、大查询跑不出来，容易 OOM，并影响其他查询。
- 运维难题。瞬间高并发打爆实例，未知来源大查询影响整体资源池稳定性。
针对以上问题，Hologres 在分析服务一体化架构下持续演进 Serverless 能力，解决各种资源管理难题。
2022年，Hologres 就发布了弹性计算组（Virtual Warehouse），采用 Shared Data 架构，存储共用一份，计算资源分解为不同的计算组（Warehouse），每个计算组可独立弹性扩展，计算组之间共享数据、元数据。
弹性计算组有多种使用方式，用户可以实现高可用、负载隔离与降本，并显著提升故障恢复速度及使用易用性。
- 隔离与高可用：计算组之间物理隔离，不同部门业务之间实现读读隔离、写写隔离、读写隔离，同时避免计算组之间的相互影响，减少业务抖动。
- 成本与弹性：存算分离，存储共享一份，计算组可动态热扩缩容，显著降低成本。
- 易用性：对应用只暴露一个 Endpoint，新增与销毁、故障实例切换等操作通过简单 SQL 即可快速实现，实现故障自动路由。
但是弹性计算组只是解决了稳定与隔离性问题，只能通过 API 来实现弹性扩缩容，使用起来不是很方便。Hologres 3.0发布了计算组实例的分时弹性，支持每个计算组单独设置弹性计划，支持每个弹性计划设置多个时间段，解决资源的波峰波谷的成本问题。
传统的 MPP 架构，往往针对的热数据进行极致的性能优化。但是对于大任务、大 ETL 的支持往往不够友好。例如争抢资源，给生产等其他查询带来抖动，需要预留资源，支付高昂的费用，任务需要跑失败、OOM、跑很久的问题。Hologres 作为一体化实时湖仓平台的设计，针对大任务、大 ETL 推出了 Serverless Computing，通过共享的大 Serverless Pool，按需分配任务需要的 Serverless 资源，稳定执行大规模 ETL 和大查询，执行完毕后即可释放资源。
在云上客户应用时，可以实现百亿数据 ETL 执行成功率100%，综合 CPU、内存水位下降50%以上，预留计算资源释放，总成本节约20%。
同时针对 Dynamic Table 的增量和全量刷新模式，是天然与 Serverless Computing 场景结合的。用户可以将 Dynamic Table 的刷新任务提交到 Serverless Computing 执行，任务间相互隔离。更加稳定、更高效率、更低成本，例如每日的全量刷新任务，使用 Serverless Computing 执行完后，资源自动释放。
资源层面完成 Serverless 的整体规划之后，还是会面对 Query 层面资源争抢的问题。Hive 和 Spark 都会有 Queue 的概念，本质上 SQL 进入某个 Queue，可以设定并发的执行数和排队数。Hologres 3.0发布的 Query Queue 有两个核心的区别。一方面很多业务方其实不太知道自己的 SQL 对于系统执行的影响， Hologres 提供 SQL 指纹，方便管理员对很多的 Query 进行自动的分类，同时也可以针对用户等维度等来做自定义的规则配置。另一方面，除了传统的 Kill 等方式来直接止血，Hologres 支持将一些大查询直接隔离，自动使用 Serverless Computing 资源来执行，避免它影响线上服务的稳定性。通过 Query Queue，可以在 Query 层面实现负载限流和大查询的隔离。
在刚才提到的分析服务一体化架构下面，Hologres 通过计算组、分时弹性、Serverless Computing、Query Queue 等功能，形成了整体资源管理的 Serverless 方案，后续我们将在弹性与 Serverless 方向持续迭代，支持根据负载自动弹性，Query Acceleration Service（大Query自动使用Serverless资源），支持更多场景使用 Serverless 资源，提升使用体验，降低整体成本。
5. Data+AI 一体
在 AI 时代，数据是 AI 的基础设施，Hologres 3.0融合 AI 与大模型各项能力，满足企业数据架构在 AI 时代的演进需求。Hologres 自带向量计算能力，与阿里云人工智能平台 PAI 结合，5分钟即可部署基于大模型的 RAG 检索增强方案，构建企业级知识库。
- 高性能
通过一体化实时湖仓平台，提供低延时、高吞吐的在线向量查询服务，支持向量数据实时写入与更新，写入即可查。
- 高易用性
统一 SQL 查询接口查询向量数据，兼容 PostgreSQL 生态，支持复杂过滤条件向量检索，5分钟即可完成一键部署。
- 企业级能力
向量计算与存储资源灵活水平扩展，支持主从实例架构、计算组实例架构，支持计算资源物理隔离，实现企业级高可用能力。
在与 AI 大模型结合的领域，作为分析引擎，Hologres 3.0与大数据开发治理平台 DataWorks 结合，提供更好的 NL2SQL，除了 SQL 生成，还具备 SQL 改写、SQL 续写、SQL 纠错、SQL 解释、SQL 注释等众多强大的能力，极大降低数仓开发与分析的门槛。
Hologres 3.0同时与阿里云百炼析言 GBI 联合发布 ChatBI 解决方案，深度结合 Hologres 强大的实时分析能力，以 Github 常见用户行为：新建分支、提交代码、遇到报错三个事件为转化路径为例，原始的模型 SQL 虽然可以理解漏斗含义，但 SQL 逻辑复杂，计算资源开销大延时大，通过析言 GBI 的修正，可以正确使用 Hologres 自带的高级漏斗函数，按正确的转化路径，层层聚合。
三、总结
Hologres 在商业化的4年时间内，不断通过产品迭代，不仅支撑阿里巴巴集团业务，同时满足各行各业对于实时大数据的需求，推动数据从规模化向实时化演进。
企业大数据平台正在面对湖仓融合、数据实时性、AI 结合等众多挑战，Hologres 3.0 面向企业的未来架构设计一体化实时湖仓平台，在湖仓一体、流批一体、大数据AI一体等场景深度融合，不断提升企业的数据实时性与数据使用效率。同时，Hologres 的预付费实例年付折扣再降15%，仅需7折，Hologres 将不断帮助企业降低数据管理成本，赋能业务增长。如果后续希望体验，可以在阿里云官网新购开通实例，新用户免费试用 Hologres 3.0。
