电商数仓初期数据治理策略（附案例说明）

前言：之前一版内容感觉理解起来容易，但是落地有难度；特意对一些关键知识点附加了部分代码或案例说明，这样理解和实践就容易多了。

一、数据治理框架搭建

1. 治理组织

• 数据治理委员会：由业务、技术、数据团队组成，负责制定治理策略和决策
• 数据 stewards：每个业务域指定数据负责人，负责域内数据治理
• 技术支持团队：负责治理工具和平台的建设和维护

2. 治理流程

• 需求阶段：数据需求评审，确保数据定义清晰
• 设计阶段：数据模型评审，确保模型符合标准
• 开发阶段：代码审查，确保 ETL 流程符合规范
• 测试阶段：数据质量测试，确保数据质量符合要求
• 上线阶段：上线评审，确保系统稳定运行
• 运维阶段：持续监控，确保数据质量和系统性能

3. 治理工具

• 元数据管理：使用 DataWorks 元数据管理功能，记录数据血缘和定义
• 数据质量：使用 DataWorks 数据质量功能，监控数据质量指标
• 数据标准：建立数据标准管理系统，确保标准执行
• 数据安全：使用 MaxCompute 权限管理和数据脱敏功能
• 监控告警：配置统一的监控和告警系统

二、数据标准体系建设

1. 业务术语标准

• 统一术语：建立电商业务统一术语表，明确每个术语的定义
• 术语映射：不同系统中的术语映射关系，确保语义一致
• 维护机制：定期更新术语表，适应业务变化

案例：电商业务术语表示例

2. 数据模型标准

• 模型设计规范：星型模型设计标准，维度和事实表设计规则
• 表结构标准：表命名、字段命名、数据类型、分区策略等
• 主键外键规则：主键唯一性，外键关系处理

SQL 代码示例：创建符合标准的订单事实表

— 创建订单事实表
CREATE TABLE fact_orders (
order_id STRING COMMENT '订单ID',
user_id STRING COMMENT '用户ID',
order_date_id STRING COMMENT '订单日期ID',
product_id STRING COMMENT '商品ID',
channel_id STRING COMMENT '渠道ID',
region_id STRING COMMENT '地域ID',
order_amount DOUBLE COMMENT '订单金额',
payment_amount DOUBLE COMMENT '支付金额',
refund_amount DOUBLE COMMENT '退款金额',
order_status STRING COMMENT '订单状态',
payment_status STRING COMMENT '支付状态',
create_time STRING COMMENT '创建时间',
payment_time STRING COMMENT '支付时间',
shipping_time STRING COMMENT '发货时间',
finish_time STRING COMMENT '完成时间'
) COMMENT '订单事实表'
PARTITIONED BY (ds STRING COMMENT '分区日期');

3. 数据编码标准

• 统一编码：商品、用户、订单等核心实体的编码规则
• 编码映射：不同系统间编码的映射关系
• 编码校验：编码格式和有效性校验规则

案例：订单编码规则

• 编码格式：ORD + 年月日 + 6 位序号
• 示例：ORD20231201000001
• 校验规则：长度固定为 17 位，前 3 位为 ORD，中间 8 位为日期，后 6 位为数字

SQL 代码示例：订单编码校验

— 检查订单编码格式是否正确
SELECT
order_id,
CASE
WHEN LENGTH(order_id) != 17 THEN '编码长度错误'
WHEN SUBSTR(order_id, 1, 3) != 'ORD' THEN '编码前缀错误'
WHEN NOT (SUBSTR(order_id, 4, 8) REGEXP '^[0-9]{8}$') THEN '日期格式错误'
WHEN NOT (SUBSTR(order_id, 12, 6) REGEXP '^[0-9]{6}$') THEN '序号格式错误'
ELSE '编码格式正确'
END AS check_result
FROM
ods_orders
WHERE
ds = '${bizdate}';

4. 指标定义标准

• 指标体系：建立统一的指标体系，明确指标定义和计算方法
• 指标维度：指标的维度分解和聚合规则
• 指标口径：确保指标口径一致，避免歧义

案例：电商核心指标体系

SQL 代码示例：计算销售额指标

— 计算日销售额
SELECT
ds,
SUM(order_amount) AS sales_amount
FROM
dws_sales_summary
GROUP BY
ds
ORDER BY
ds;

三、数据质量保障体系

1. 质量指标体系

• 核心指标：完整性、准确性、一致性、及时性、可靠性
• 指标定义：每个指标的具体定义和计算方法
• 质量目标：各指标的目标值和阈值

案例：数据质量指标阈值

SQL 代码示例：数据完整性检查

— 检查订单表关键字段空值率
SELECT
'order_id' AS field_name,
COUNT(*) AS total_count,
COUNT(CASE WHEN order_id IS NULL THEN 1 END) AS null_count,
(COUNT(CASE WHEN order_id IS NULL THEN 1 END) / COUNT(*)) * 100 AS null_rate
FROM
ods_orders
WHERE
ds = '${bizdate}'
UNION ALL
SELECT
'user_id' AS field_name,
COUNT(*) AS total_count,
COUNT(CASE WHEN user_id IS NULL THEN 1 END) AS null_count,
(COUNT(CASE WHEN user_id IS NULL THEN 1 END) / COUNT(*)) * 100 AS null_rate
FROM
ods_orders
WHERE
ds = '${bizdate}'
UNION ALL
SELECT
'order_amount' AS field_name,
COUNT(*) AS total_count,
COUNT(CASE WHEN order_amount IS NULL OR order_amount <= 0 THEN 1 END) AS null_count,
(COUNT(CASE WHEN order_amount IS NULL OR order_amount <= 0 THEN 1 END) / COUNT(*)) * 100 AS null_rate
FROM
ods_orders
WHERE
ds = '${bizdate}';

2. 质量检查点

• 数据源端：源系统数据质量检查
• ETL 过程：ETL 各环节的数据质量检查
• 数据仓库端：数仓各层级的数据质量检查
• 应用端：BI 和 AI 应用的数据质量检查

SQL 代码示例：ETL 过程数据质量检查

— 检查ETL过程中订单数据的一致性
SELECT
o.order_id,
o.order_amount AS source_amount,
SUM(oi.item_amount) AS item_total_amount,
ABS(o.order_amount – SUM(oi.item_amount)) AS diff
FROM
ods_orders o
JOIN
ods_order_items oi ON o.order_id = oi.order_id
WHERE
o.ds = '${bizdate}'
GROUP BY
o.order_id, o.order_amount
HAVING
ABS(o.order_amount – SUM(oi.item_amount)) > 0.01;

3. 质量监控机制

• 实时监控：关键数据的实时质量监控
• 离线监控：批量数据的离线质量评估
• 告警处理：质量异常的告警和处理流程
• 质量报告：定期生成数据质量报告

SQL 代码示例：生成数据质量报告

— 生成每日数据质量报告
INSERT OVERWRITE TABLE dq_daily_report PARTITION (ds = '${bizdate}')
SELECT
'ods_orders' AS table_name,
COUNT(*) AS total_count,
COUNT(CASE WHEN order_id IS NULL THEN 1 END) AS null_count,
(COUNT(CASE WHEN order_id IS NULL THEN 1 END) / COUNT(*)) * 100 AS null_rate,
COUNT(CASE WHEN order_amount IS NULL OR order_amount <= 0 THEN 1 END) AS invalid_count,
(COUNT(CASE WHEN order_amount IS NULL OR order_amount <= 0 THEN 1 END) / COUNT(*)) * 100 AS invalid_rate,
COUNT(DISTINCT order_id) AS distinct_count,
(COUNT(DISTINCT order_id) / COUNT(*)) * 100 AS unique_rate
FROM
ods_orders
WHERE
ds = '${bizdate}';

4. 质量改进机制

• 根因分析：质量问题的根因分析流程
• 整改措施：针对质量问题的整改方案
• 效果验证：整改效果的验证和评估
• 持续优化：基于质量数据的持续优化

案例：数据质量问题整改流程

四、元数据管理体系

1. 技术元数据

• 数据源元数据：数据源连接信息、表结构、字段定义
• ETL 元数据：ETL 任务定义、依赖关系、执行日志
• 数据仓库元数据：数仓表结构、分区信息、存储统计
• BI 元数据：看板定义、图表配置、数据映射

SQL 代码示例：元数据采集脚本

— 采集表结构元数据
INSERT OVERWRITE TABLE metadata_table_columns
SELECT
CURRENT_DATE() AS collect_date,
'ods_orders' AS table_name,
col.column_name,
col.data_type,
col.comment,
col.position
FROM
information_schema.columns col
WHERE
col.table_schema = 'ecommerce_dw'
AND col.table_name = 'ods_orders';

2. 业务元数据

• 业务实体：商品、用户、订单等业务实体的定义
• 业务规则：促销规则、价格规则、库存规则等
• 指标定义：KPI 指标的定义、计算方法、口径
• 数据字典：核心业务术语和数据元素的字典

案例：业务规则定义

SQL 代码示例：业务规则验证

— 验证订单金额规则
SELECT
order_id,
order_amount,
CASE
WHEN order_amount <= 0 THEN '违反订单金额规则'
ELSE '符合订单金额规则'
END AS rule_check
FROM
ods_orders
WHERE
ds = '${bizdate}';

3. 操作元数据

• 数据 lineage：数据的来源和流向，支持端到端追踪
• 数据使用情况：数据的访问频率、使用部门、使用场景
• 数据变更历史：数据结构和内容的变更记录
• 性能指标：查询性能、ETL 执行时间等

SQL 代码示例：数据血缘分析

— 分析订单数据的血缘关系
SELECT
'dws_sales_summary' AS target_table,
'order_amount' AS target_column,
'dwd_orders_detail' AS source_table,
'order_amount' AS source_column,
'SUM' AS transform_type
UNION ALL
SELECT
'dwd_orders_detail' AS target_table,
'order_amount' AS target_column,
'ods_orders' AS source_table,
'order_amount' AS source_column,
'DIRECT' AS transform_type;

4. 元数据应用

• 影响分析：数据变更的影响范围分析
• 血缘分析：数据问题的根因追溯
• 数据地图：数仓数据资产的可视化展示
• 智能推荐：基于元数据的数据分析推荐

SQL 代码示例：影响分析

— 分析订单表结构变更的影响范围
SELECT
t.table_name,
t.column_name,
d.dependency_type,
d.dependent_table,
d.dependent_column
FROM
metadata_table_columns t
JOIN
metadata_dependencies d ON t.table_name = d.source_table AND t.column_name = d.source_column
WHERE
t.table_name = 'ods_orders';

五、数据安全与隐私保护

1. 安全策略

• 分级分类：数据分级分类标准，如敏感数据、一般数据
• 访问控制：基于角色的访问控制 (RBAC)，最小权限原则
• 数据脱敏：敏感数据的脱敏规则和实现方式
• 加密策略：数据传输和存储的加密方案

案例：数据分级分类

SQL 代码示例：数据脱敏处理

— 对用户手机号进行脱敏处理
SELECT
user_id,
CONCAT(SUBSTR(phone, 1, 3), '****', SUBSTR(phone, 8, 4)) AS masked_phone
FROM
dim_user;

2. 合规要求

• 法规遵循：符合 GDPR、CCPA 等数据隐私法规
• 内部规范：公司内部数据使用规范和流程
• 审计追踪：数据访问和操作的审计日志
• 合规检查：定期进行合规性检查和评估

SQL 代码示例：审计日志查询

— 查询用户数据访问审计日志
SELECT
event_time,
user_name,
operation_type,
table_name,
affected_rows,
ip_address
FROM
audit_logs
WHERE
table_name = 'dim_user'
AND event_time >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
ORDER BY
event_time DESC;

3. 安全技术

• 数据脱敏工具：使用 MaxCompute 数据脱敏功能
• 访问控制：配置 MaxCompute 和 DataWorks 的权限
• 加密传输：确保数据传输过程的加密
• 安全监控：监控异常数据访问和操作

SQL 代码示例：权限管理

— 为销售部门授予销售数据的只读权限
GRANT SELECT ON TABLE dws_sales_summary TO ROLE sales_dept;

六、数据生命周期管理

1. 存储策略

• 热数据：最近 7 天的数据，使用 MaxCompute 标准存储
• 温数据：7-30 天的数据，使用 MaxCompute 标准存储
• 冷数据：30 天以上的数据，迁移到 MaxCompute 归档存储

SQL 代码示例：数据生命周期管理

— 将30天以上的数据迁移到归档存储
ALTER TABLE ods_orders PARTITION (ds < DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)) SET TBLPROPERTIES ('lifecycle'='30');

2. 保留策略

• 业务数据：根据业务需求和法规要求设置保留期限
• 日志数据：根据审计需求设置保留期限
• 备份数据：设置合理的备份策略和保留期限
• 测试数据：明确测试数据的使用和销毁规则

案例：数据保留期限

SQL 代码示例：数据备份

— 备份订单表数据
INSERT OVERWRITE TABLE ods_orders_backup PARTITION (backup_date = CURRENT_DATE())
SELECT * FROM ods_orders WHERE ds = CURRENT_DATE();

3. 清理策略

• 数据清理：定期清理过期和无用的数据
• 存储优化：优化数据存储结构，减少存储空间
• 性能优化：基于数据生命周期优化查询性能
• 成本控制：通过生命周期管理控制存储成本

SQL 代码示例：数据清理

— 清理6个月以上的日志数据
DELETE FROM ods_user_logs WHERE ds < DATE_SUB(CURRENT_DATE(), INTERVAL 6 MONTH);

七、AI 能力接入的专项治理

1. 数据准备

• 数据标准化：确保 AI 训练数据的格式和结构标准化
• 数据标注：建立数据标注规范和流程，确保标注质量
• 数据增强：制定数据增强策略，丰富训练数据
• 数据平衡：确保训练数据的类别平衡，避免模型偏差

SQL 代码示例：数据标准化处理

— 标准化用户行为数据
SELECT
user_id,
product_id,
CASE
WHEN behavior_type = 'pv' THEN '浏览'
WHEN behavior_type = 'cart' THEN '加购'
WHEN behavior_type = 'buy' THEN '购买'
ELSE '其他'
END AS standardized_behavior,
behavior_time,
duration
FROM
ods_user_logs
WHERE
ds = '${bizdate}';

2. 数据质量要求

• 完整性：AI 训练数据必须完整，无缺失值
• 准确性：数据必须准确，无错误或异常
• 一致性：数据必须一致，无矛盾或冲突
• 时效性：使用最新的数据，确保模型的时效性
• 可解释性：数据必须可解释，便于 AI 模型的理解和调试

SQL 代码示例：AI 训练数据质量检查

— 检查AI训练数据的质量
SELECT
'train_data' AS data_type,
COUNT(*) AS total_count,
COUNT(CASE WHEN user_id IS NULL THEN 1 END) AS null_user_id,
COUNT(CASE WHEN product_id IS NULL THEN 1 END) AS null_product_id,
COUNT(CASE WHEN behavior_type IS NULL THEN 1 END) AS null_behavior,
COUNT(CASE WHEN behavior_time IS NULL THEN 1 END) AS null_time,
COUNT(DISTINCT user_id) AS unique_users,
COUNT(DISTINCT product_id) AS unique_products
FROM
ai_train_data;

3. 特征工程支持

• 特征定义：统一特征定义和计算方法
• 特征存储：建立特征库，存储和管理特征
• 特征选择：基于业务需求和模型性能选择特征
• 特征监控：监控特征分布的变化，及时调整模型

SQL 代码示例：特征工程

— 生成用户特征
INSERT OVERWRITE TABLE ai_user_features
SELECT
user_id,
COUNT(DISTINCT order_id) AS order_count,
SUM(order_amount) AS total_amount,
AVG(order_amount) AS avg_amount,
MAX(order_date) AS last_order_date,
DATEDIFF(CURRENT_DATE(), MIN(registration_date)) AS user_age_days,
COUNT(DISTINCT CASE WHEN behavior_type = 'buy' THEN product_id END) AS purchased_products
FROM
dwd_user_behaviors
GROUP BY
user_id;

4. 模型数据管理

• 训练数据版本：管理训练数据的版本，支持模型回溯
• 模型数据血缘：追踪模型使用的数据来源和版本
• 模型性能监控：监控模型在新数据上的性能
• 模型更新策略：基于数据变化的模型更新机制

SQL 代码示例：模型数据版本管理

— 记录模型训练数据版本
INSERT INTO ai_model_versions (
model_id,
model_version,
training_data_version,
training_start_time,
training_end_time,
accuracy,
precision,
recall,
f1_score
) VALUES (
'recommendation_model',
'v1.0',
'data_v20231201',
CURRENT_TIMESTAMP(),
CURRENT_TIMESTAMP() + INTERVAL 2 HOUR,
0.85,
0.82,
0.88,
0.85
);

八、实施路径

1. 阶段一：基础建设（0-1 个月）

• 成立数据治理委员会
• 制定数据治理框架和策略
• 建立数据标准体系
• 配置基础治理工具

2. 阶段二：核心实施（1-3 个月）

• 实施数据模型标准
• 建立数据质量监控体系
• 部署元数据管理系统
• 实施数据安全策略

3. 阶段三：深化应用（3-6 个月）

• 完善数据治理流程
• 扩展治理覆盖范围
• 集成 AI 数据治理功能
• 建立治理效果评估机制

4. 阶段四：持续优化（6 个月 +）

• 持续监控和改进数据质量
• 定期更新数据标准和规则
• 优化治理流程和工具
• 评估治理效果和 ROI

九、关键成功因素

1. 高层支持

• 获得管理层的支持和资源投入
• 明确数据治理的战略地位

2. 跨团队协作

• 业务、技术、数据团队密切协作
• 建立有效的沟通和协作机制

3. 工具支持

• 选择适合的治理工具和平台
• 确保工具的易用性和有效性

4. 持续改进

• 建立治理效果的评估机制
• 基于反馈持续优化治理策略

5. 人才培养

• 培养数据治理专业人才
• 提高团队的治理意识和能力

十、总结

在电商数仓建设初期就做好数据治理，不仅可以避免后续的治理成本，还能为 AI 能力接入奠定坚实的基础。通过建立完善的数据治理体系，包括数据标准、数据质量、元数据管理、数据安全和数据生命周期管理等方面，可以确保数据的质量、一致性和可靠性，使 AI 模型能够更准确地学习和预测。

同时，通过提供具体的案例和 SQL 代码示例，大家可以更直观地理解数据治理的实施方法，直接参照这些示例进行实践，减少落地难度。

再次说一句：数据治理是一个持续的过程，需要在数仓建设和运营的各个阶段不断优化和完善，以适应业务的发展和技术的进步。