Table of Contents

• 每日一句正能量
• 摘要
• 一、引言：当交易与分析成为"鱼和熊掌"
• 二、DM9 HTAP引擎总体架构
• 2.1 架构设计哲学
• 2.2 核心组件架构
• 三、行列融合存储引擎
• 3.1 行存储：为OLTP而生
• 3.2 列存储：为OLAP而生
• 3.3 行列混存：HTAP的核心创新
• 3.4 影子副本：存储成本的破局者
• 四、智能资源隔离与调度
• 4.1 资源组的定义与使用
• 4.2 运行时资源监控
• 4.3 自适应资源调度
• 五、自适应查询优化与执行
• 5.1 查询特征识别
• 5.2 向量化执行引擎
• 5.3 智能物化视图
• 六、性能表现与实测数据
• 6.1 TPC基准测试
• 6.2 真实业务场景验证
• 6.3 资源隔离效果
• 七、最佳实践与调优建议
• 7.1 表设计建议
• 7.2 查询优化建议
• 7.3 资源调优建议
• 八、总结与展望

---

每日一句正能量

世界是一个巨大的收纳盒。
他们递来标签：
方形、圆形、可折叠的。
我的任务却是，
把自己折成一只鹤，
藏进盒盖的夹层。

摘要

摘要：在数字化转型深水区，企业同时面临高并发交易处理与实时数据分析的双重挑战。传统架构下TP（交易处理）与AP（分析处理）系统物理隔离，导致数据同步延迟、存储成本翻倍、运维复杂度激增。达梦DM9通过原生HTAP混合负载引擎，以行列融合存储、智能资源隔离、自适应查询优化三大核心技术，实现了一套系统同时支撑OLTP与OLAP负载，让"数据产生即分析"成为现实。本文将从架构设计、存储引擎、资源调度、查询优化四个维度，深入剖析DM9 HTAP引擎的实现原理。

---

一、引言：当交易与分析成为"鱼和熊掌"

在金融科技、电商零售、智能制造等领域，一个典型的业务场景是：白天系统需要处理数十万笔并发交易（OLTP），夜间又要对这些数据进行复杂的分析报表（OLAP）。传统方案通常采用两套独立系统：

• TP库（如Oracle/MySQL）：承载高并发短事务，擅长行级读写
• AP库（如Greenplum/Hive）：承载复杂分析查询，擅长批量扫描

这种"双库并行"架构带来了三大顽疾：

1. 数据延迟：通过ETL从TP库同步到AP库，延迟从分钟到小时不等，"T+1"报表已成为常态
2. 成本翻倍：两套硬件、两套软件许可、两套运维团队，IT投入成倍增长
3. 一致性难题：同步过程中数据不一致、丢失、重复等问题频发，影响决策准确性

达梦DM9给出的破局之道是：原生HTAP，一套引擎，双重能力。

---

二、DM9 HTAP引擎总体架构

2.1 架构设计哲学

DM9的HTAP引擎并非简单地在同一套系统中堆砌两套存储引擎，而是从内核层进行了深度重构，实现了**“逻辑双模、物理融合”**的设计：

• 逻辑双模：对上层应用暴露统一的SQL接口，内部根据查询特征自动选择行存或列存路径
• 物理融合：同一份数据可以同时以行格式和列格式存储，通过变更缓存（Delta Store）机制保持同步

2.2 核心组件架构

DM9 HTAP引擎由四个核心组件构成：

┌─────────────────────────────────────────────────────┐
│                    SQL 解析层                         │
│              (统一入口，智能路由)                       │
└───────────────────────┬─────────────────────────────┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│  行存引擎     │ │  列存引擎     │ │  混合查询     │
│  (Row Store) │ │ (Column Store)│ │   优化器      │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
       │                │                │
       └────────────────┼────────────────┘
                        ▼
┌─────────────────────────────────────────────────────┐
│              变更缓存与合并引擎                        │
│         (Delta Merge，保证行列数据一致性)              │
└─────────────────────────────────────────────────────┘

---

三、行列融合存储引擎

3.1 行存储：为OLTP而生

行存储是DM9的默认存储格式，数据按行组织，适合高并发的点查和短事务：

-- 创建行存储表（默认）
CREATE TABLE trade_orders (
    order_id BIGINT PRIMARY KEY, user_id INT NOT NULL,
    product_id INT, order_amount DECIMAL(18,2),
    order_status TINYINT, create_time TIMESTAMP
) STORAGE(ROW);

-- 高并发点查（行存优势场景）
SELECT * FROM trade_orders WHERE order_id = 100861001;
-- 执行计划：INDEX UNIQUE SCAN，单次I/O完成

行存储的核心优势在于：

• 局部性原理：一次I/O即可读取完整记录
• B+树索引：高效支持主键查询和范围扫描
• MVCC机制：多版本并发控制，读写互不阻塞

3.2 列存储：为OLAP而生

列存储将同一列的数据连续存放，适合大规模数据扫描和聚合分析：

-- 创建列存储表
CREATE TABLE trade_orders_col (
    order_id BIGINT, user_id INT, product_id INT,
    order_amount DECIMAL(18,2), order_status TINYINT,
    create_time TIMESTAMP
) STORAGE(COLUMN);

-- 复杂分析查询（列存优势场景）
SELECT product_id, COUNT(*) AS cnt,
       SUM(order_amount) AS total, AVG(order_amount) AS avg
FROM trade_orders_col
WHERE create_time >= '2024-09-01'
GROUP BY product_id ORDER BY total DESC;
-- 执行计划：COLUMN SCAN + VECTORIZED AGGREGATION

列存储的核心优势在于：

• 向量化执行：SIMD指令批量处理，CPU缓存友好
• 高效压缩：同一列数据类型相同，压缩率可达10:1
• 投影裁剪：只读取查询需要的列，大幅减少I/O

3.3 行列混存：HTAP的核心创新

DM9最具创新性的设计是行列混存表，同一份数据同时维护行格式和列格式：

-- 创建行列混存表
CREATE TABLE trade_orders_htap (
    order_id        BIGINT PRIMARY KEY,
    user_id         INT NOT NULL,
    product_id      INT,
    order_amount    DECIMAL(18,2),
    order_status    TINYINT,
    create_time     TIMESTAMP
) STORAGE(ON MAIN, ROWCOLUMN);

其内部实现机制如下：

1. 写入路径：数据首先写入行存储，确保OLTP性能不受影响
2. 变更缓存（Delta Store）：行存储的变更被记录到Delta Store中
3. 后台合并（Merge）：异步将Delta Store中的数据合并到列存储
4. 一致性保证：通过事务ID和版本链，确保行列两副本数据一致

-- 查看行列混存表的状态
SELECT TABLE_NAME, ROW_COUNT, COLUMN_ROW_COUNT, DELTA_COUNT
FROM V$HTAP_TABLE_STATUS WHERE TABLE_NAME = 'TRADE_ORDERS_HTAP';

-- 输出：TRADE_ORDERS_HTAP  10000000  9995000  5000

3.4 影子副本：存储成本的破局者

DM9在分布式场景下引入**影子副本（Shadow Replica）**技术，进一步降低存储成本：

传统方案：2副本 + 列存副本 = 4倍存储
DM9方案：  2副本 + 1影子副本(参与Raft但不承担读写) = 约2.3倍存储
节省比例：约70%

影子副本只存储列格式数据，不参与TP负载，但可以在AP查询中作为只读副本使用。

---

四、智能资源隔离与调度

4.1 资源组的定义与使用

DM9内置资源管理器（Resource Manager），通过资源组实现TP与AP负载的物理隔离：

-- 创建TP/AP资源组
CREATE RESOURCE GROUP tp_group CPU_LIMIT=60, MEMORY_LIMIT=8G, PRIORITY=HIGH;
CREATE RESOURCE GROUP ap_group CPU_LIMIT=30, MEMORY_LIMIT=4G, PRIORITY=LOW;

-- 将用户绑定到资源组
ALTER USER trading_app SET RESOURCE GROUP tp_group;
ALTER USER report_app SET RESOURCE GROUP ap_group;

4.2 运行时资源监控

-- 查看各资源组的实时负载
SELECT GROUP_NAME, ACTIVE_SESSIONS, CPU_USAGE_PCT, MEM_USAGE_PCT
FROM V$RESOURCE_GROUP_STATS ORDER BY CPU_USAGE_PCT DESC;

-- 输出：TP_GROUP  120  45.2%  62.3%
--       AP_GROUP   8   28.7%  35.8%

4.3 自适应资源调度

DM9支持自适应资源调度，根据业务负载动态调整资源分配：

-- 开启自适应调度
ALTER SYSTEM SET RESOURCE_AUTO_TUNE = TRUE;

-- 配置调度策略
ALTER SYSTEM SET TP_PRIORITY_HOURS = '08:00-20:00';
ALTER SYSTEM SET AP_PRIORITY_HOURS = '20:00-08:00';

在白天的交易高峰期，系统自动将更多资源分配给TP负载；夜间分析时段，则提升AP的资源配额。

---

五、自适应查询优化与执行

5.1 查询特征识别

DM9的查询优化器会自动识别查询特征，选择最优的存储路径：

-- 场景1：TP点查，优化器选择行存索引扫描
SELECT * FROM trade_orders_htap WHERE order_id = ?;

-- 场景2：AP聚合，优化器选择列存向量化扫描
SELECT product_id, SUM(order_amount) FROM trade_orders_htap GROUP BY product_id;

-- 场景3：混合查询，智能路由选择最优路径
SELECT o.*, p.product_name FROM trade_orders_htap o
JOIN products p ON o.product_id = p.product_id WHERE o.user_id = 12345;

5.2 向量化执行引擎

对于列存查询，DM9采用向量化执行引擎，以批处理方式提升性能：

-- 查看向量化执行计划
EXPLAIN SELECT product_id, AVG(order_amount)
FROM trade_orders_htap
WHERE create_time >= '2024-09-01'
GROUP BY product_id;

-- 输出：VECTORIZED AGGREGATION -> HASH GROUP BY -> COLUMN SCAN (BATCH 4096)

向量化执行的核心原理：

• 批处理：每次处理4096行数据，减少函数调用开销
• SIMD加速：利用AVX-512指令集，单条指令处理多组数据
• 流水线并行：算子之间形成流水线，数据逐批传递

5.3 智能物化视图

对于高频AP查询，DM9支持增量物化视图，在数据变更时自动刷新：

-- 创建增量物化视图
CREATE INCREMENTAL MATERIALIZED VIEW mv_daily_sales AS
SELECT product_id, DATE(create_time) AS dt,
       COUNT(*) AS cnt, SUM(order_amount) AS amt
FROM trade_orders_htap GROUP BY product_id, DATE(create_time);

-- 查看物化视图刷新状态
SELECT VIEW_NAME, LAST_REFRESH_TIME, STALE_ROWS
FROM V$MATERIALIZED_VIEW_STATUS;

---

六、性能表现与实测数据

6.1 TPC基准测试

DM9在HTAP场景下的性能表现：

测试项	DM9 HTAP	传统TP库	传统AP库	提升幅度
TPC-C (TpmC)	200万	100万	N/A	+100%
TPC-H (QphH)	12.6万	N/A	5.6万	+126%
混合负载并发	120+8	80(仅TP)	4(仅AP)	综合提升

6.2 真实业务场景验证

以某省级农商行的FTP（资金转移定价）系统为例：

改造前：传统数据仓库 + Oracle TP库

• 核心存储过程处理时间：3小时
• 定价计算：3.5小时
• 数据加工：9小时

改造后：DM9 HTAP分布式集群（12节点）

• 核心存储过程处理时间：1小时（-67%）
• 定价计算：1.5小时（-57%）
• 数据加工：2.5小时（-72%）
• 存储成本：降低约70%

6.3 资源隔离效果

在混合负载压力测试中：

测试配置：
- TP负载：1000并发，持续INSERT/UPDATE
- AP负载：10并发，复杂聚合查询

无资源隔离时：
- TP平均响应时间：从5ms飙升至800ms
- AP查询时间：120秒

开启DM9资源隔离后：
- TP平均响应时间：稳定在8ms
- AP查询时间：95秒
- 双方性能抖动降低90%以上

---

七、最佳实践与调优建议

7.1 表设计建议

-- 以TP为主的表：纯行存
CREATE TABLE tp_table (...) STORAGE(ROW);

-- 以AP为主的表：纯列存
CREATE TABLE ap_table (...) STORAGE(COLUMN);

-- 混合负载表：行列混存
CREATE TABLE htap_table (...) STORAGE(ROWCOLUMN);

-- 大表分区 + 行列混存
CREATE TABLE big_htap (...) STORAGE(ROWCOLUMN)
PARTITION BY RANGE(create_time) (
    PARTITION p202409 VALUES LESS THAN ('2024-10-01'),
    PARTITION p202410 VALUES LESS THAN ('2024-11-01')
);

7.2 查询优化建议

-- TP查询使用绑定变量，充分利用计划缓存
SELECT * FROM trade_orders_htap WHERE order_id = ?;

-- AP查询只取需要的列，大表关联优先列存
SELECT product_id, order_amount FROM trade_orders_htap;
SELECT /*+ USE_COLUMN_STORE */ * FROM large_table;

-- 监控慢查询，针对性优化
SELECT SQL_TEXT, EXEC_TIME FROM V$SLOW_SQL
WHERE EXEC_TIME > 5000 ORDER BY EXEC_TIME DESC;

7.3 资源调优建议

-- 根据业务峰谷动态调整资源
ALTER SYSTEM SET TP_CPU_LIMIT = 70;
ALTER SYSTEM SET AP_CPU_LIMIT = 20;

-- 设置AP查询超时，调整Delta Store合并频率
ALTER SYSTEM SET AP_QUERY_TIMEOUT = 3600;
ALTER SYSTEM SET DELTA_MERGE_INTERVAL = 300;

---

八、总结与展望

达梦DM9的TP+AP混合负载引擎，通过行列融合存储、智能资源隔离、自适应查询优化三大核心技术，从根本上解决了传统架构下交易与分析割裂的难题。其核心优势可以总结为：

1. 一份数据，双重能力：行列混存消除ETL，数据产生即分析
2. 资源隔离，互不干扰：资源管理器确保TP与AP负载和平共处
3. 弹性扩展，成本优化：影子副本技术节省70%存储资源
4. 统一运维，简化管理：一套系统、一套语法、一套运维体系

随着AI时代的到来，DM9的HTAP引擎还将与向量数据库、实时推理等能力深度融合，让企业不仅能"看清过去"，更能"预见未来"。

---

作者注：本文基于达梦DM9公开技术资料和实际项目经验撰写，深入解析了DM9 HTAP混合负载引擎的设计原理和实现机制。文中SQL示例基于DM9语法，实际使用时请参考官方文档。

标签：#达梦数据库 #达梦同行者征文 #DM9 #HTAP #混合负载 #数据库架构

---

欢迎 👍点赞✍评论⭐收藏，欢迎指正