一场22周年技术云享会，我却更看重一张架构图

胖头鱼的技术专栏-434 一场22周年技术云享会，我却更看重一张架构图（20260627）

914fcc7ad57defa7868c3be1ca7fb4f5.jpg

本周四，即6月25日，很荣幸收到南大通用的邀请，来到了美丽的天津，和众多技术大佬一道参加『2026GBASE技术云享会』，2026年也是南大通用走过的第22个年头。

9fdd6f434e3b2e251fd04a8e54d5bc68.png

在会议开始之前，我们也参观了南大通用的总部。

633b2343008f41ea509f2b702ec27fdf.jpg

作为国内老牌数据库厂商，南大通用很早就有所了解，包括现任董事长老丁与多位技术核心也是老熟人了。但是在以前我对GBase的理解是，在每个细分的业务场景赛道上都有拳头产品：

• GBase 8a，全称GBase 8a MPP Cluster，无共享（Shared-Nothing）MPP分布式分析型数据库，主打列式存储，面向海量数据统计分析场景。
• Gbase 8c，多模多态分布式HTAP数据库，一套库同时支持OLTP+OLAP混合负载（HTAP），支持行存、列存、内存、时序、向量多存储引擎；支持单机主备、分布式分片、存算分离多种部署形态；高度兼容Oracle、MySQL、PostgreSQL；支持分布式事务、弹性横向扩缩容，同时具备全密态数据安全能力，原生支持AI向量检索，兼顾交易与分析混合业务。
• GBase 8s，共享存储架构的集中式企业级事务数据库，对标Oracle RAC，面向核心交易系统，支撑关键业务7×24不间断运行。

但我认为的问题就是，三条相对独立产品线，面向不同场景，但却很难协同工作。以AI时代的最方便赋能的海量数据与报表分析场景为例，即便GBase 8c已经拥有一定的混合负载能力，但是数据量一旦过大，8c依然会力不从心。

传统的解决方案是通过ETL等方式将生产数据抽取传输到大数据分析型数据库中，然后进行报表开发，这种方式在高时效需求场景下往往会出现得到结果时，结果已经过时，无法及时产生有效的价值。

在本次技术云享会来自GBase 8c的产品经营部总经理 张益老师演讲中的一张图让我看到了南大通用两个产品之间的协作。

image.png

在这张架构图中我们看到了，生产业务由GBase 8c全面支撑，通过实时镜像能力，将数据实时同步到GBase 8a中，8a则可以支撑实时的海量数据分析场景需求。GBase 8c+8a的组合架构，可以很好的同时支持HTAP和海量数据分析场景，在AI应用场景下也是有用的，Agent无需额外的执行数据抽取传输操作，即可在不同数据库快速得到需要的数据。

我很好奇这个功能的实现方式，因此会后找到了张益老师想了解技术细节，张益老师说，由于这个功能还没有正式公开，只能给我有限信息，其中的关键就是Iceberg。

Iceberg是开源的开放表格式（Open Table Format），专门面向PB级海量分析数据集，给对象存储/HDFS上的文件赋予数据库“数据表”能力，让 Spark、Flink、Trino (Presto)、Hive多引擎共用同一张表，实现湖仓一体Iceberg。简单一句话：Iceberg不是数据库，不是存储，而是数据湖的表管理层，用来替代传统Hive表，解决数据湖无事务、元数据混乱、多引擎不互通的痛点。

在GBase 8a中，数据流向：行存OLTP → 逻辑复制 → Parquet → Iceberg，然后提供给GBase 8a使用。松耦合架构，不影响8c性能；本地WAL回放保证事务原子性；Deletion Vector机制高效处理变更；标准开放格式，零锁定。

更多的技术细节需要将来南大通用披露。

这是南大通用使用先进技术结合自身产品的一次创新，有效应对了HTAP+海量数据分析场景需求，同时实现了高性能与低成本的架构融合。

老规矩，知道写了些啥。