信创数仓分层建模｜国产数据库 ODS/DWD/DWS 分层落地规范（金仓 / 达梦 / 高斯适配）

摘要

信创数据中台建设中，很多团队直接照搬互联网数仓建模经验，用国产数据库却套 MySQL 建模思路，结果步步踩坑：分层过度复杂但性能低下、敏感数据裸奔不符合等保密评、国产数据库分区 / 列存 / 压缩特性完全没利用、指标口径混乱数据对不上。要么建了一堆表用不起来，要么合规验收反复打回。

本文基于政务、金融信创项目实战，输出ODS/DWD/DWS 三层标准分层建模规范，适配人大金仓 V9、达梦 DM9、GaussDB 三大主流国产数据库，覆盖每层定位、建模规范、存储策略、性能优化、数据流转、合规加固全流程，附命名规范、建表模板、国产库专属优化方案。照着做，既能发挥国产数据库性能，又能满足等保三级 + 密评合规要求，数据一致性 100% 可追溯。

政务选金仓，金融选达梦；开源自主选 openGauss，生态活跃成本低；政务云华为栈选 GaussDB，全栈信创一体化交付。全文无空泛理论，所有规范均经过生产项目验证，可直接落地。

一、痛点直击：信创数仓为什么不能直接搬互联网建模方案

📌 核心结论：信创数仓的核心矛盾不是数据量太大，而是合规要求高、业务场景严谨、国产数据库特性没吃透。照搬互联网四五层复杂架构，只会过度设计、性能低下、合规不达标。

1.1 四大普遍乱象

分层过度，冗余严重 搞五六层架构，ODS、DWD、DWS、ADS、DIM 层层叠加，数据冗余 3~5 倍，存储成本飙升，链路越长出错概率越高，排查问题要跨好几层。
国产库当 MySQL 用，性能低下 放着分区表、列存、压缩、向量化执行这些国产数据库特性不用，还是用 OLTP 那套范式建模、普通 B 树索引，大表查询全表扫描，数仓跑成 "慢查询仓库"。
合规缺失，验收卡壳 敏感字段不脱敏、数据没有审计、权限一锅粥，原始数据人人能看。等保、密评测评时，数据安全、权限分离、可追溯性项直接扣分。
口径混乱，指标对不上 同一指标不同层、不同主题口径不一致，业务部门对账对不上，数据可信度低，数仓变成 "数据废墟"。

1.2 信创数仓的核心原则

分层极简：ODS 贴源、DWD 明细、DWS 汇总，三层足够，避免过度设计
合规嵌入：脱敏、审计、权限、可追溯，从建模阶段就融入每层设计，不是事后补
特性利用：充分发挥国产数据库分区、列存、压缩、并行能力，性能优先
口径统一：指标、维度、编码全局统一，一个口径出数据

二、标准架构：ODS/DWD/DWS 三层分层模型（信创适配版）

2.1 整体架构图

复制代码

【业务源层】
  人大金仓 / 达梦 / GaussDB 业务系统
          ↓ SeaTunnel全量/增量同步
【ODS层 贴源层】
  保留原始数据、不做清洗、可追溯、可回滚
  → 按源系统分库、按时间分区、原始字段保留
          ↓ ETL清洗、标准化、脱敏
【DWD层 明细层】
  清洗标准化、维度关联、统一编码、敏感数据脱敏
  → 事实表+维度表、主题域划分、保留最细粒度
          ↓ 聚合、预计算
【DWS层 汇总层】
  面向主题、指标预聚合、公共维度统一
  → 按主题分、多粒度聚合、直接支撑报表/应用
          ↓
【应用层】 报表、大屏、查询、分析

2.2 三层定位对比表

层级	定位	数据粒度	保留周期	存储策略	访问权限	核心目标
ODS 贴源层	原始数据镜像，可追溯	和源库完全一致	30~90 天	低成本存储、按天分区	仅 ETL 账号可访问	保留原貌、可回溯、可核对
DWD 明细层	清洗标准化后的最细粒度数据	事务级最细粒度	6~12 个月	高性能存储、按主题分	开发、分析可访问脱敏后数据	统一口径、干净可用、支撑明细查询
DWS 汇总层	面向主题的指标预聚合	日 / 周 / 月多粒度	永久 / 按业务需求	高性能存储、宽表预聚合	业务、报表可访问	提升查询性能、统一指标输出

2.3 信创合规内置设计

权限分层：每层独立账号，ODS 原始数据最小权限，DWS 层开放业务权限，符合最小权限原则
脱敏分层：敏感字段在 ODS→DWD 过程中脱敏，DWD 及以下不出现明文敏感数据
审计全链路：每层数据读写都留痕，数据血缘可追溯，符合等保审计要求
存储分级：热数据高性能 SSD，冷数据低成本存储，符合成本与性能平衡

三、ODS 层：贴源层建模规范与国产数据库适配

ODS 层的核心是原汁原味保留源数据，不做业务清洗，只做格式对齐，目标是可追溯、可回滚、可对账。

3.1 建模核心规范

命名规范

复制代码

ods_源系统标识_表名
示例：
ods_kingbase_biz_apply    -- 金仓政务申报主表
ods_dm_biz_order        -- 达梦交易订单表

统一小写，下划线分隔，源系统前缀区分不同业务库
表名、字段名和源库保持一致，便于溯源和核对

字段规范

字段名称、类型、长度与源库完全对齐，不做转换

统一增加 3 个系统字段：

复制代码

etl_time      TIMESTAMP    -- ETL入库时间
etl_date      DATE         -- 数据日期，分区键
source_sys    VARCHAR(32)  -- 来源系统标识

不做任何清洗、转换、计算，保留原始数据面貌

分区策略

分区键 ：统一用etl_date按天分区，和同步周期对齐
分区粒度：按天分区，便于回溯、重跑、清理过期数据
保留周期：政务场景 30 天，金融场景 90 天，过期自动清理

数据同步

首次全量：SeaTunnel 全量初始化，一次性同步历史数据
日常增量：T+1 凌晨全量覆盖，或小时级增量同步
对账机制：每日同步后行数校验，和源库比对确保一致

3.2 国产数据库适配要点

数据库	ODS 层存储优化方案	核心命令 / 配置
人大金仓 V9	范围分区表 + 冷热分离 + 表空间	按天创建分区，超过 7 天迁入冷表空间，开启表级压缩
达梦 DM9	范围分区 + 表空间映射 + 批量插入优化	按天分区，ODS 独立表空间，关闭日志归档提升导入速度
GaussDB 5.x	范围分区 + 行存转列存 + 压缩	原始数据行存，超过 3 天转列存，开启高压缩比

3.3 建表模板（金仓示例）

复制代码

CREATE TABLE ods_kingbase_biz_apply (
    id BIGINT,
    dept_id INT,
    apply_content TEXT,
    status INT,
    create_time TIMESTAMP,
    -- 系统字段
    etl_time TIMESTAMP DEFAULT now(),
    etl_date DATE NOT NULL,
    source_sys VARCHAR(32) DEFAULT 'kingbase'
) PARTITION BY RANGE (etl_date)
TABLESPACE ts_ods_hot;

-- 创建分区示例
CREATE TABLE ods_kingbase_biz_apply_20260901
PARTITION OF ods_kingbase_biz_apply
FOR VALUES FROM ('2026-09-01') TO ('2026-09-02')
TABLESPACE ts_ods_hot;

四、DWD 层：明细层建模规范与维度退化策略

DWD 层是数仓的核心，完成清洗、标准化、脱敏、维度关联，输出最细粒度的干净数据，是所有汇总的基础。

4.1 建模核心规范

命名规范

复制代码

dwd_主题域_事实/维度_业务含义
示例：
dwd_government_fact_apply    -- 政务主题域 申报事实表
dwd_common_dim_dept         -- 公共维度 部门维度表

按主题域划分，政务、金融、公共维度等大主题分类
事实表加fact前缀，维度表加dim前缀，一目了然

清洗与标准化

空值处理：数值型空值补 0，字符串空值补 ''，明确空值语义
编码统一：字典码、状态值、单位统一，比如性别 0/1 统一为男 / 女，状态编码全局一致
格式统一 ：日期格式统一YYYY-MM-DD HH:MI:SS，金额统一保留 2 位小数，单位统一为元
数据脱敏 ：身份证、手机号、姓名、地址等敏感字段，ODS→DWD 过程中完成脱敏
- 不可逆脱敏：哈希、掩码，用于分析统计
- 可逆脱敏：国密算法加密，授权场景可解密
去重校验：主键去重，重复数据保留最新一条

事实表设计

保留最细粒度，一条记录对应一次业务事务
关联所有核心维度外键，比如部门、时间、状态、类型
保留所有可度量的数值字段，不提前聚合
按时间分区，按天分区，支持重跑和回溯

维度表设计

公共维度统一：时间、部门、地区、人员等公共维度全局唯一，全链路复用
缓慢变化维：用拉链表处理维度属性变化，保留历史快照
维度退化 ：低基数、变化少的维度，直接退化到事实表字段，减少关联，提升性能 💡 信创数仓数据量普遍不大，优先适度维度退化，少做雪花模型，宽表性能远优于多表关联

4.2 国产数据库适配要点

数据库	DWD 层优化方案	核心优势
人大金仓 V9	事实表分区 + 联合索引 + 并行查询	多维度查询走联合索引，并行计算提升分析速度
达梦 DM9	事实表分区 + 位图索引 + 优化器提示	低基数字段位图索引性能好，Oracle 兼容模式语法平滑迁移
GaussDB 5.x	列存引擎 + 向量化执行 + 分区裁剪	大宽表列存扫描速度是行存数倍，适合分析场景

4.3 建表模板（达梦示例）

复制代码

CREATE TABLE DWD_GOVERNMENT_FACT_APPLY (
    ID BIGINT PRIMARY KEY,
    DEPT_ID INT,
    DEPT_NAME VARCHAR(100),    -- 维度退化，部门名称直接落地
    APPLY_TYPE VARCHAR(32),
    STATUS INT,
    STATUS_NAME VARCHAR(32),  -- 状态名称退化
    CREATE_TIME DATE,
    AMOUNT NUMBER(18,2),
    ETL_TIME TIMESTAMP DEFAULT SYSDATE,
    ETL_DATE DATE NOT NULL
) PARTITION BY RANGE (ETL_DATE) (
    PARTITION P202609 VALUES LESS THAN ('2026-10-01')
) TABLESPACE TS_DWD;

-- 联合索引，覆盖常用查询维度
CREATE INDEX IDX_DWD_APPLY_DEPT_DATE ON DWD_GOVERNMENT_FACT_APPLY(DEPT_ID, ETL_DATE);

五、DWS 层：汇总层建模规范与指标体系

DWS 层面向业务主题，预聚合指标、构建宽表，直接支撑报表、大屏、查询，目标是快、准、统一。

5.1 建模核心规范

命名规范

复制代码

dws_主题域_粒度_业务含义
示例：
dws_government_day_apply_stat    -- 政务主题 日粒度 申报统计
dws_finance_month_order_sum     -- 金融主题 月粒度 订单汇总

明确标注聚合粒度：day/week/month/quarter/year
一个表对应一个主题一个粒度，避免大而全的万能表

聚合原则

按主题聚合：一个主题一个聚合模型，比如政务申报、金融交易
多粒度并存：日、周、月多粒度聚合，不同场景用不同粒度
指标统一：同一指标口径、公式、命名全局统一，比如 "申报量" 就是 count (id)，不能有的算总数有的算去重
公共维度对齐：所有聚合都按统一的维度切片，比如时间、部门、地区，便于横向对比

宽表优先策略

信创场景数据量普遍在千万级以内，优先做宽表聚合，把常用维度、指标都塞到一张宽表里，避免多表关联。查询性能比雪花模型高 3~10 倍，开发也更简单。

常用聚合方式

时间维度：日汇总、周汇总、月累计、同比环比
业务维度：按部门、按地区、按类型、按状态
组合聚合：多维度交叉汇总，支撑多维分析

5.2 国产数据库适配要点

数据库	DWS 层优化方案	适用场景
人大金仓 V9	物化视图 + 结果缓存 + 索引全覆盖	固定报表、定期刷新场景，自动刷新物化视图
达梦 DM9	实表预聚合 + 分区索引 + 并行插入	复杂聚合场景，提前计算好，查询直接读结果表
GaussDB 5.x	列存宽表 + 向量化聚合 + 分区裁剪	大宽表多维分析，向量化执行性能优势明显

5.3 指标口径管理

建立统一指标字典，每个指标明确：名称、口径、计算公式、粒度、更新频率
所有指标从 DWS 层输出，禁止业务直接查 DWD/ODS 自定义指标
指标变更走评审流程，更新后同步通知所有使用方，避免口径混乱

六、全链路流转：ETL 调度 + 质量管控 + 血缘审计

6.1 调度策略

环节	调度频率	时间窗口	依赖关系
ODS 层同步	每日凌晨 1 点	业务低峰期	源库业务日结完成
DWD 层清洗	每日凌晨 2 点	ODS 同步完成后	依赖对应 ODS 分区数据就绪
DWS 层聚合	每日凌晨 3 点	DWD 清洗完成后	依赖对应主题 DWD 数据就绪
数据校验	每日凌晨 4 点	所有任务完成后	全链路数据质量核查
报表输出	每日凌晨 5 点	校验通过后	生成日报、推送数据

💡 生产建议：统一调度平台编排，依赖驱动，不要定时卡死时间；失败自动重试 + 告警。

6.2 三级质量管控

入库校验：ODS 层行数校验、主键非空校验，和源库一致才能入库
清洗校验：DWD 层空值校验、格式校验、脱敏校验，脏数据拦截
聚合校验：DWS 层指标对账，和明细层聚合结果比对，误差为 0 才能发布

6.3 数据血缘与审计

血缘追踪：每层数据都有来源标识，字段级血缘可追溯，问题可定位到源系统
操作审计：所有 ETL 任务、数据读写、表结构变更全程留痕，可追溯到人
版本管理：模型变更保留历史版本，可回滚、可对比

七、国产数据库专属优化：金仓 / 达梦 / 高斯分层存储最佳实践

7.1 人大金仓 V9 分层优化方案

基于 PG 内核，充分发挥分区、表空间、并行、索引能力。

复制代码

-- 分层表空间规划
ts_ods_hot    -- ODS近7天数据，SSD高性能
ts_ods_cold   -- ODS历史数据，低成本存储
ts_dwd        -- DWD明细层，SAS高性能
ts_dws        -- DWS汇总层，SSD高性能

-- 核心优化参数
effective_cache_size = 24GB    -- 优化器缓存估算
work_mem = 64MB                -- 聚合排序内存
maintenance_work_mem = 2GB     -- 索引构建、VACUUM内存
random_page_cost = 1.1          -- SSD优化

ODS 层：按天分区，自动冷热迁移，7 天以上自动迁入冷表空间
DWD 层：事实表按天分区，常用查询维度建联合索引
DWS 层：高频报表用物化视图，定时自动刷新

7.2 达梦 DM9 分层优化方案

Oracle 兼容体系，发挥分区、位图索引、批量处理能力。

复制代码

-- 表空间规划
TS_ODS    -- ODS层
TS_DWD    -- DWD明细层
TS_DWS    -- DWS汇总层

-- 核心优化参数
BUFFER = 8GB
SORT_BUF_SIZE = 2097152
MAX_BUFFER = 16GB

ODS 层：批量导入关闭归档，提升导入速度，导入完成再开启
DWD 层：低基数字段建位图索引，多维度组合查询性能好
DWS 层：预聚合实表，按分区建索引，查询直接命中

7.3 GaussDB 5.x 分层优化方案

集中式发挥列存、向量化优势，分布式场景按需扩展。

ODS 层：行存保留原始数据，超过 3 天转列存压缩存储
DWD 层：明细宽表列存，向量化执行清洗、关联、聚合
DWS 层：多维度聚合宽表列存，分析查询性能是行存 3~5 倍
分布式场景：按主题分片，水平扩展支撑更大数据量

八、建模避坑：12 个信创数仓最容易踩的致命错误

⚠️ 坑 1：分层过度，搞四五层架构

后果：数据冗余、链路复杂、排查困难、存储成本高
整改：ODS/DWD/DWS 三层足够，别盲目照搬互联网大厂架构

⚠️ 坑 2：ODS 层做清洗，原始数据不可追溯

后果：数据错了没法对账，没法回溯源库，出问题找不到根因
整改：ODS 只贴源不清洗，所有转换都在 DWD 层做，保留原始数据可核对

⚠️ 坑 3：敏感字段不脱敏，裸奔到 DWS 层

后果：等保、密评数据安全项直接不通过，存在泄露风险
整改：ODS→DWD 必须脱敏，DWD 及以下不出现明文敏感数据

⚠️ 坑 4：雪花模型深度建模，大量关联查询慢

后果：层层维度关联，查询要 join 五六张表，性能极差
整改：适度维度退化，优先宽表，少做雪花模型，信创数据量不大，宽表性价比最高

⚠️ 坑 5：不做分区，全表扫描性能差

后果：千万级表查询全表扫，一次要几十秒
整改：所有事实表按时间分区，查询走分区裁剪，性能提升 10 倍以上

⚠️ 坑 6：国产数据库当 MySQL 用，特性全浪费

后果：放着列存、分区、压缩、向量化不用，性能还不如 MySQL
整改：针对每个数据库特性做分层优化，充分发挥国产数据库能力

⚠️ 坑 7：指标口径不统一，数出多门

后果：同一指标不同报表不一样，业务对账对不上
整改：统一指标字典，所有指标从 DWS 输出，一个口径对外

⚠️ 坑 8：权限一锅粥，人人都能看原始数据

后果：权限失控，合规不通过，数据安全风险高
整改：每层独立账号，最小权限原则，ODS 原始数据仅限 ETL 账号访问

⚠️ 坑 9：命名混乱，表不知道是干嘛的

后果：维护困难，新人看不懂，重复建设
整改：严格命名规范，前缀 + 主题 + 粒度 + 含义，见名知意

⚠️ 坑 10：不做数据校验，错了都不知道

后果：脏数据、丢数据、重复数据，报表错误
整改：三级校验机制，每层都做行数、主键、指标对账

⚠️ 坑 11：不考虑存储成本，全放高性能存储

后果：历史冷数据占着 SSD，存储成本飙升
整改：冷热分层，热数据 SSD，冷数据低成本存储，自动迁移

⚠️ 坑 12：没有数据血缘，出问题查不到

后果：数据错误找不到来源，排查全靠猜
整改：全链路血缘追踪，每个字段都能追溯到源系统源表

九、验收标准：分层建模落地 7 项必查

序号	检查项	达标标准
1	架构合理性	三层架构清晰，分层定位准确，无过度设计
2	模型规范性	命名统一、字段规范、分区合理、符合建模规范
3	数据一致性	各层数据行数对齐，指标口径统一，聚合结果可对账
4	性能达标	核心查询响应时间≤3 秒，报表出数≤10 秒
5	合规性	敏感数据脱敏、权限分层、操作审计，符合等保要求
6	可追溯性	数据血缘完整，可追溯到源系统，变更有记录
7	可维护性	文档齐全、调度清晰、异常可告警、问题可快速定位

总结

信创数仓分层建模，从来不是照搬互联网架构就行，核心是贴合信创合规要求、充分发挥国产数据库特性、极简分层、统一口径。三层架构足够支撑绝大多数政务、金融场景，过度设计只会带来成本和风险。

把模型做规范、把国产数据库特性用透、把合规嵌入每层、把质量管控跑通，就能建出性能好、合规强、数据准的生产级数仓，支撑业务分析与决策。

政务选金仓，金融选达梦；开源自主选 openGauss，生态活跃成本低；政务云华为栈选 GaussDB，全栈信创一体化交付。

📚 专栏推荐：专注 SpringBoot3 + 人大金仓 + 达梦 + GaussDB 信创实战，持续输出生产级部署、性能调优、数据中台、合规加固干货，关注不迷路。

觉得文章有用的话，欢迎点赞、收藏、关注三连，后续更新更多信创数据落地的硬核内容。