点击下载论文原文：【 《AnalyticDB-PG: A Cloud-native High-performance Data Warehouse in Alibaba Cloud》】
背景
在数据驱动与人工智能深度融合的时代，企业对数据仓库的需求早已超越“查得快”这一基础能力。实时写入、弹性扩展、混合负载处理、AI原生支持……这些不再是“加分项”，而是支撑智能决策、精准营销、实时风控等关键业务场景的“刚需”。
然而，传统数据仓库面临结构性困境：共享存储架构虽弹性灵活但性能受限；共享内存架构虽高性能却难以伸缩；实时分析依赖T+1 ETL导致数据滞后；多系统并存造成运维复杂、成本高昂。
面对挑战，阿里云瑶池数据库团队提出下一代云原生高性能数据仓库——AnalyticDB for PostgreSQL（简称ADB-PG）。其创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系，并自主研发Beam混合存储引擎与Laser向量化执行引擎，全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。
近日，相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025，标志着中国自研云数仓技术再次登上国际舞台。
从“割裂”到“统一”：一次架构革命的诞生
九年前，阿里云启动ADB-PG项目时，目标明确：打造一个面向公有云和政企客户的分布式MPP数据仓库。最初采用Shared-Nothing架构，部署于物理机本地磁盘，在电商大促、金融风控等高并发场景中表现出色。
但随着客户规模扩大，尤其是大型金融机构、跨国企业开始上云，新的问题浮现：
- 数据量动辄百TB甚至PB级，扩容成本极高；
- 多租户环境下资源利用率低下，闲置严重；
- 一些客户需要私有化部署保障合规，部分客户又希望享受云端弹性。
为此，团队尝试开发一套基于对象存储的Shared-Storage版本。然而，对象存储不支持随机写、追加写，导致主键约束、二级索引、高频更新等功能无法实现，严重影响事务一致性与用户体验。
更棘手的是：维护两套独立代码库带来了巨大的工程负担。功能同步难、Bug修复慢、版本迭代周期长。
于是，一个大胆的想法诞生了：能否用同一套核心架构，同时支撑Shared-Nothing和Shared-Storage两种模式？
这就是ADB-PG“统一架构”的起点。
统一架构：一套系统，两种世界
ADB-PG首次实现了单代码基线（single codebase）支持双部署模式，真正做到了“因地制宜”。
模式 |
适用场景 |
技术优势 |
Shared-Nothing (SNM) |
高性能、私有化部署、合规敏感、中小规模数据量 |
高缓存命中率、低延迟扫描、强隔离 |
Shared-Storage (SSM) |
高性价比、公有云、大数据量、动态负载 |
极致弹性、按需付费、跨实例资源共享 |
系统控制面基于Kubernetes与安全容器，实现多租户隔离、自动扩缩容、Serverless化调度。每个租户拥有独立网络空间与存储路径，确保安全性与SLA保障。
更重要的是，这种统一不是妥协，而是协同优化的结果——底层三大核心子系统为此而生。
Beam引擎：让写入如流水，查询如闪电
在真实业务中，企业往往面临双重压力：
- 实时性要求高：订单秒级入仓、用户行为即时可查；
- 分析复杂度高：报表聚合、趋势预测、关联挖掘。
传统的行存适合写入但分析慢，列存适合分析但写入代价大。ADB-PG的答案是：都不要舍弃，而是融合。由此，Beam混合存储引擎应运而生。
分层设计，动静分离
- 增量数据 → 行存（NSM）：以追加写方式高效处理流式写入、Upsert、Delete，满足OLTP类操作；
- 历史数据 → PAX混合格式：兼顾列式压缩与局部性，支持Z-order clustering提升过滤效率；
- 异步合并机制：后台自动将热数据归档为冷数据，避免手动Compaction带来的性能抖动。
实时索引，全局一致
Beam支持PostgreSQL全部主流二级索引（B-tree, Hash, GiST, GIN），并在写入时进行主键唯一性校验。通过可见性Bitmap + 行级锁 + Upsert并发控制，保障高并发下的事务正确性。
字典编码，降本增效
针对低基数字符串字段（如省份、商品分类），Beam采用全局字典编码，将字符串映射为整数ID，大幅降低存储开销，并在计算阶段使用整数运算加速Group By、Join等操作。
在某头部电商平台的实际测试中，启用字典编码后，SSB Q2查询耗时从38.87秒降至0.95秒，性能提升超40倍！
Laser引擎：榨干CPU每一滴算力
如果说Beam解决了“怎么存”，那Laser则回答了“怎么算”。
现代CPU拥有强大的SIMD指令集、多核并行能力，但传统数据库仍停留在“逐行解释执行”的时代。Laser引擎彻底改变这一局面。
向量化执行 + JIT编译
- 所有算子以batch-at-a-time方式处理，充分利用AVX-512等SIMD指令；
- 复杂表达式按需触发LLVM JIT编译，动态切换解释/编译模式，平衡启动延迟与运行效率；
- 自适应选择最优执行路径：顺序访问用列式布局（DSM），随机访问用行式布局（NSM），最大化缓存命中率。
运行时优化，越跑越快
- Bloom Filter下推：在Hash Join前过滤无效数据，减少shuffle流量；
- 计划重写：运行时感知实际数据分布，动态调整Join顺序与基数估计；
- 延迟解码：扫描时不立即展开字典，直到聚合阶段才解码，节省中间结果传输开销。
在TPC-DS Q24/Q64等复杂查询中，运行时过滤使耗时下降近50%，结合Join Reorder最高提速40%。
不止于分析：In-Database AI，开启Data+AI融合新篇章
今天的数据仓库，不能只做“数据搬运工”。越来越多客户提出：能不能直接在库里训练模型、生成向量、召回文档？
为此，ADB-PG率先引入In-Database AI/ML能力，构建一体化的多模融合平台：
功能 |
应用场景 |
内置向量搜索 |
图像相似匹配、语义检索 |
全文检索引擎 |
日志分析、内容推荐 |
模型微调与推理 |
基于业务数据fine-tune LLM，用于RAG问答 |
特征工程与训练 |
直接调用XGBoost、逻辑回归等算法 |
典型案例如某大型银行构建智能客服系统：
- 用户提问 → 文本向量化 → 向量搜索召回相关知识片段；
- 结合结构化客户画像 → 全文检索补充上下文；
- 调用微调后的BERT模型 → 输出个性化回复。
过去需打通5个系统，现在仅需一条SQL即可完成全流程。端到端延迟缩短60%，开发效率提升80%。
实测验证：性能、成本、弹性全面领先
1. 查询性能 vs 成本
在TPC-H 1TB测试中，SSM与SNM模式整体性能几何均值基本持平。尤其Q1、Q18等大表扫描场景，SSM因多节点并行反而略胜一筹。
而在百TB级以上场景，SSM的月度成本仅为SNM的40%-60%，得益于弹性计算与对象存储的低成本优势。
2. 写入与混合负载
在CH-BenCHmark混合负载测试中，16个事务线程 + 2个分析线程并发运行，彼此吞吐互不影响，资源分配公平。若物理隔离，总吞吐接近两者独立运行之和。
3. 弹性与容错
支持SSM/SNM模式下在线扩容云盘或EBS，故障时自动切换至备份节点，服务无中断。Serverless模式下可根据负载自动伸缩计算节点，业务零感知。
🆚 对比行业：为什么ADB-PG能脱颖而出？
能力维度 |
ADB-PG |
实时写入支持 |
强（支持UPSERT/Delete） |
二级索引能力 |
完整支持PG所有索引类型 |
存储架构灵活性 |
双模统一架构 |
向量化执行 |
更深度优化（JIT+自适应） |
In-Database AI |
支持模型训练、向量搜索、RAG |
更重要的是，ADB-PG不仅是一个技术产品，更是为业务而生的设计哲学：
- 金融客户要合规 → 提供SNM私有化方案；
- 互联网客户要弹性 → 提供SSM Serverless体验；
- AI团队要集成 → 提供In-Database AI一站式平台。
未来已来：迈向AI原生数据仓库
ADB-PG的愿景不止于“更快的查询”或“更低的成本”。我们正朝着三个方向持续演进：
- AI驱动的智能优化：利用机器学习预测查询模式，自动创建物化视图、索引；
- 自动弹性：基于负载预测提前扩缩容，消除冷启动延迟；
- 多模融合深化：整合图、时空、JSON等新型数据类型，打造真正的“全模态数据底座”。
正如我们在VLDB论文中所言：“未来的数据仓库，将是Data与AI无缝融合的智能中枢。”
而今天，它已经到来。
了解更多
- 点击下载论文原文：《AnalyticDB-PG: A Cloud-native High-performance Data Warehouse in Alibaba Cloud》
- 欢迎钉钉搜索群号： 11700737，或扫码加入钉群交流：
