陶玉印的博客

企业数据治理、数据仓库、数据质量、AI应用实践与研究

0%

结合 OpenMetaData 的数据治理实践

发表于

如何你的企业使用的是 OpenMetadata 做数据治理，对企业来说，OpenMetadata 的价值并不止是“元数据目录”，它实际上可以承载一套比较完整的治理运行机制：资产识别 → 责任落实 → 语义统一 → 分类分级 → 质量控制 → 血缘追溯 → 权限策略 → 数据产品化 → 治理度量。

OpenMetadata 官方的数据治理能力本身也是围绕 Glossary、Classification、Domain/Data Product、Roles/Policies 等展开的，并通过 Profiler、Data Quality、Lineage 和 Data Insights 把治理从静态登记延伸到持续运行。

下面我按“企业真正怎么实施”的方式展开。

一、先建立一个数据治理实践框架

DAMA-DMBOK 讲的数据治理范围很大，包括数据架构、元数据、数据质量、主数据、安全、标准等。企业实际落地时，我更建议把复杂的方法论收敛为六个问题：

治理问题 要解决什么 OpenMetadata 对应能力
有什么数据 数据资产盘点 Service、Database、Schema、Table、Dashboard、Pipeline
数据属于谁 权责明确 Domain、Team、Owner、Expert
数据是什么意思 语义统一 Glossary、Metric、Description
数据有什么属性 分类分级 Classification、Tag、Tier、PII
数据可靠吗 数据质量 Profiler、Test、Incident、Alert
数据从哪里来、影响哪里 可追溯 Lineage、Column Lineage
谁能看、谁能改 数据安全 Role、Policy、Tag-based Policy
哪些数据应该被业务消费 数据供给管理 Data Product
治理有没有改善 治理度量 Data Insights、KPI

最终形成一个闭环：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
业务需求
   ↓
数据资产发现
   ↓
Domain / Owner
   ↓
Glossary / Metric
   ↓
Classification / Tier
   ↓
Lineage
   ↓
Data Quality
   ↓
Policy
   ↓
Data Product
   ↓
数据消费
   ↓
Data Insights / KPI
   ↓
治理改进

这才是一套能够长期运行的数据治理机制。

二、第一阶段：先解决“有什么数据”

这是所有治理工作的基础。

企业经常一开始就做：

  • 数据标准
  • 数据质量
  • 主数据
  • 数据安全

结果发现连：

  • 到底有多少数据库？
  • 有多少表？
  • 哪些表还在使用？
  • 谁创建的？
  • 从哪里来的？

都说不清楚。

所以第一阶段其实是：

Data Inventory + Metadata Foundation

在 OpenMetadata 里就是建立 Service，然后运行 Metadata Ingestion：

1
2
3
4
5
6
7
8
9
10
ERP MySQL
MES SQLServer
SRM MySQL
CRM
Hive
ClickHouse
BI
...
        ↓
OpenMetadata

最终把：

1
2
3
4
5
6
7
8
Database
Schema
Table
Column
View
Dashboard
Pipeline
Topic

统一收进来。

可以形成：

1
2
3
4
5
6
7
ERP ───────┐
MES ───────┤
CRM ───────┤
SRM ───────┼──→ OpenMetadata
BPM ───────┤
Hive ──────┤
BI ────────┘

这一步的治理目标不要定成“元数据采集完成”。

应该定成几个可以量化的指标，例如：

1
2
3
生产数据源接入率       ≥ 95%
核心数据库采集覆盖率   = 100%
核心表字段采集率       = 100%

OpenMetadata 后面的 Data Insights 正好可以继续衡量 Description、Ownership、Tier 等治理覆盖率。

三、第二阶段：建立业务责任体系

资产进来以后，第二件事情应该是：

谁负责？

这是数据治理最重要的一步之一。

很多治理失败的根本原因并不是缺工具，而是数据出现问题时，没有明确的人负责解释和处理。

这里可以建立三层责任结构：

1
2
3
4
5
Domain
  ↓
Owner Team
  ↓
Data Steward / Expert

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Finance
│
├── Owner
│   Finance Data Team
│
├── Experts
│   财务BP
│   ERP财务负责人
│
└── Assets
    应收
    应付
    收入
    成本
    发票

OpenMetadata 的 Domain 本身就是用于建立业务边界和分散式数据责任的，Domain 可以关联资产、Team、Glossary 等，并配置 Owner 和 Expert。

结合前面我们讨论的结构，可以先建立：

1
2
3
4
5
6
7
8
Sales
SupplyChain
Manufacturing
Quality
Finance
HumanResources
MasterData
EnterpriseAnalytics

OpenMetadata 支持 Source-aligned、Consumer-aligned、Aggregate 三种 Domain 类型，也支持父子 Domain。

比如：

1
2
3
4
5
6
7
Finance
├── Revenue
├── Receivable
├── Payable
├── Cost
└── Invoice

然后给真正重要的资产指定责任：

1
2
3
4
5
6
7
8
9
10
11
12
13
dwd_finance_receivable_da


Domain:
    Finance.Receivable


Owner:
    Finance Data Team


Expert:
    财务应收业务负责人

IT 团队可以负责技术维护，但“应收账款是什么意思、哪些规则正确、数据是否可以发布给业务使用”，最终需要业务 Owner 承担责任。

四、第三阶段：建立业务语义体系

这一阶段解决的是企业最常见的问题：

  • 销售收入到底怎么算？
  • 有效客户是什么？
  • 经销商和客户是不是同一个概念？
  • 毛利是一毛还是二毛？
  • 库存是账面库存还是可用库存？

这就是：

Business Glossary + Metric Governance

OpenMetadata Glossary 是受控词汇体系，可以定义：

1
2
3
4
5
6
7
8
定义
同义词
相关术语
父子关系
Owner
Reviewer
Reference
Tag

官方也明确把 Glossary 定义为建立企业共同业务语言和语义的重要治理工具。

比如：

1
2
3
4
5
6
7
8
销售
│
├── 销售收入
├── 含税销售收入
├── 不含税销售收入
├── 毛利
├── 经销商
└── 销售区域

“销售收入”可以定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
名称：
销售收入


业务定义：
企业在指定统计期间因商品销售确认的收入。


计算口径：
SUM(net_sales_amount)


时间口径：
会计期间


Owner：
财务中心


相关术语：
销售订单
客户
毛利

然后把这个 Glossary Term 绑定到：

1
2
3
4
5
6
7
8
9
10
Hive字段
    sales_revenue


BI指标
    销售收入


Dashboard
    集团经营分析

这样用户搜索：

销售收入

就不只是找到一个字段，而是能够看到：

1
2
3
4
5
6
7
8
9
业务定义
   ↓
相关表
   ↓
字段
   ↓
指标
   ↓
Dashboard

OpenMetadata 还有专门的 Metric 实体，可以保存指标名称、公式、粒度、类型、计算代码、Owner 等，并与 Glossary 和数据资产关联。

这意味着治理可以进一步从：

1
字段治理

走到：

1
指标语义治理

五、第四阶段：分类分级

资产有业务含义以后，就开始回答：

数据有什么治理属性？

这就是前面讨论过的 Classification / Tag / Tier。

这里建议第一版控制在几个真正有治理价值的维度。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
DataLayer
ODS / DWD / DWS / ADS


Lifecycle
Development / Active / Deprecated / Archived


SecurityLevel
Public / Internal / Confidential / Restricted


PII
Sensitive / NonSensitive


Tier
Tier1 ~ Tier5

OpenMetadata 的 Classification 本质上是受控标签体系，适合用于数据分类、检索以及策略控制；Classification 还支持互斥标签。

一张生产表可能最终是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
dwd_patient_order


Domain
    Sales


Tier
    Tier1


Tags
    DataLayer.DWD
    Lifecycle.Active
    SecurityLevel.Restricted


Columns


customer_name
    PII.Sensitive


mobile_phone
    PII.Sensitive

这时候治理规则就开始具备机器可执行性。

六、分类标签进一步驱动安全治理

这是 OpenMetadata 很值得使用的一部分。

传统数据治理里经常有：

1
2
3
4
5
6
7
8
《数据安全管理制度》


一级数据
二级数据
三级数据
四级数据

制度写完以后，系统并不知道哪些数据属于三级。

OpenMetadata 可以把：

1
2
3
4
5
6
7
8
9
制度定义
    ↓
Classification
    ↓
Tag
    ↓
Asset
    ↓
Policy

串起来。

例如：

1
SecurityLevel.Restricted

可以驱动 Policy：

1
2
3
4
5
Restricted
    +
当前用户不是 Owner
    ↓
拒绝访问

OpenMetadata Policy 同时支持 RBAC 和基于资源属性的 ABAC，并且官方用例里直接支持根据 PII.Sensitive Tag 和 Ownership 限制访问。

于是：

1
Tag

就从“元数据描述”升级成：

1
Governance Rule

这就是所谓：

Active Metadata

元数据开始参与治理执行。

七、第五阶段：重要性分级——Tier

这里要和安全等级区分。

比如：

1
SecurityLevel

回答：

数据敏感程度多高？

而：

1
Tier

回答：

数据对于企业有多重要？

OpenMetadata 自带：

  • Tier1
  • Tier2
  • Tier3
  • Tier4
  • Tier5

官方推荐 Tier1 用于收入、监管、声誉等高影响数据，而 Tier5 可以用于低价值或长期未使用的数据资产。

例如：

1
2
3
4
5
6
7
8
9
10
11
dwd_sales_order
Tier2


dws_group_operating_report
Tier1


tmp_test_sales
Tier5

这里可以进一步形成治理资源分配规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Tier1
    ↓
必须有 Owner
必须有 Description
必须有 Glossary
必须有 Lineage
必须有 Data Quality Test


Tier2
    ↓
必须有 Owner
必须有 Description


Tier5
    ↓
90/180 天无访问
进入清理候选

这非常重要。

因为治理不能要求：

1200 张表全部达到同样治理水平。

那样成本会迅速失控。

正确方式通常是：

1
2
20% 核心资产
→ 80% 治理投入

Tier 就可以承担这个优先级体系。

八、第六阶段：血缘治理

资产、语义、Owner 建完以后，下一个能力应该是：

数据是怎么来的？

OpenMetadata 支持：

1
2
3
4
5
6
Table → Table
Table → Dashboard
Pipeline → Table
Topic → Table
Table → ML Model

同时支持 Column-level Lineage、Pipeline Reference 和 SQL。

例如：

1
2
3
4
5
6
7
8
9
10
11
ERP.sales_order
      ↓
ods_sales_order
      ↓
dwd_sales_order
      ↓
dws_sales_daily
      ↓
ads_sales_management
      ↓
集团经营Dashboard

字段级：

1
2
3
4
5
6
7
ERP.amount
     ↓
dwd.sales_amount
     ↓
dws.sales_amount
     ↓
指标：销售收入

OpenMetadata 支持自动以及人工字段级 lineage。

这时候血缘真正能服务治理。

例如开发准备修改：

1
dwd_sales_order.sales_amount

通过 Lineage 可以判断：

1
2
3
4
5
6
7
8
9
修改字段
   ↓
哪些DWS受影响
   ↓
哪些ADS受影响
   ↓
哪些指标受影响
   ↓
哪些Dashboard受影响

这就是：

Impact Analysis

而发生问题以后反方向查询：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Dashboard数据错误
        ↓
指标
        ↓
ADS
        ↓
DWS
        ↓
DWD
        ↓
ODS
        ↓
源系统

就是：

Root Cause Analysis

所以血缘的治理价值远大于“画一张漂亮的数据流程图”。

九、第七阶段：数据质量治理

这里建议坚持一个原则：

数据质量规则从业务规则开始，不从工具支持哪些规则开始。

比如经销商应收数据：

业务要求：

1
2
3
4
经销商编码不能为空
应收金额 ≥ 0
账龄不能为负
会计日期不能为空

转换成数据质量规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
dealer_code
    NOT NULL


receivable_amount
    >= 0


aging_days
    >= 0


accounting_date
    NOT NULL

OpenMetadata 的 Data Quality 模型是：

1
2
3
4
5
6
7
Test Definition
      ↓
Test Case
      ↓
Test Suite
      ↓
Test Result

系统提供 25+ 内置测试定义，也支持 Custom Test。

常见规则包括：

1
2
3
4
5
6
7
8
9
10
Not Null
Unique
Regex
Value Set
Between
Row Count
Min / Max
Mean
Sum
Standard Deviation

再结合 Profiler：

1
2
3
4
5
6
Null %
Distinct %
Min
Max
Mean
Distribution

OpenMetadata Profiler 可以持续采集这些统计指标。

治理闭环就可以做到：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
规则
 ↓
Test
 ↓
Failed
 ↓
Alert
 ↓
Incident
 ↓
Owner
 ↓
修复
 ↓
Resolved

官方的数据质量体系也把 Tests、Alerts、Health Dashboard、Resolution Workflow 放在一个完整流程里。

十、数据质量规则不能平均铺开

这是实际实施非常关键的一点。

不要这样做：

1
2
3
4
5
1200张表
×
每张20条质量规则
=
24000条规则

后面基本没人维护。

推荐：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Tier1
    强质量控制


Tier2
    核心字段质量控制


Tier3
    基础完整性控制


Tier4 / Tier5
    原则上不主动建设大量规则

例如：

1
2
3
集团销售收入表
Tier1

必须：

1
2
3
4
5
6
7
8
Owner
Glossary
Description
Lineage
Freshness Test
RowCount Test
Revenue Rule Test
核心Column Test

而：

1
2
tmp_sales_analysis_2025
Tier5

可能只要求：

1
2
3
Lifecycle.Temporary
Owner
自动清理

这种治理模式才真正可持续。

十一、第八阶段：把数据治理延伸到 Data Product

治理做到这里以后，很多企业还是存在一个问题：

OpenMetadata 里有 1000 张治理得很好的表，但业务到底该用哪一个？

于是需要从：

1
Data Asset

进一步进入：

1
Data Product

OpenMetadata 的 Data Product 本身就是一个 Domain 内经过整理的数据资产集合，可以具有 Owner，并向数据消费者暴露明确的数据供给。

例如：

1
2
3
4
5
6
Domain
Finance


Data Product
经销商应收分析

内部包含：

1
2
3
4
5
6
7
8
9
10
11
12
13
dwd_dealer_receivable
dws_dealer_receivable_aging
ads_dealer_receivable_analysis


指标：
应收余额
逾期金额
平均账龄


Dashboard：
经销商应收分析

最终业务用户关注的是：

经销商应收分析

而不需要先理解：

1
2
3
4
5
ODS
DWD
DWS
ADS

这就是：

1
2
3
4
5
6
7
技术资产
    ↓
治理资产
    ↓
数据产品
    ↓
业务消费

十二、第九阶段：建立治理度量

数据治理最容易出现的问题之一，是做了一年以后只能汇报：

1
2
3
创建了600个术语
配置了900个Owner
建立了5000条质量规则

这些都是工作量指标。

治理真正应该关注：

  • 覆盖率
  • 质量
  • 使用率
  • 问题解决效率
  • 业务价值

OpenMetadata Data Insights 可以直接衡量：

  • Description Coverage
  • Ownership Coverage
  • Tier Coverage
  • 用户活跃度
  • 资产情况

并且允许设置治理 KPI 和目标。

比如第一年可以设置：

指标 初始 目标
核心资产 Owner 覆盖率 35% 100%
Tier1 Description 完整率 50% 100%
Tier1 Glossary 覆盖率 20% 90%
Tier1 Lineage 覆盖率 40% 95%
Tier1 DQ 覆盖率 10% 90%
PII 自动识别覆盖率 0 95%
无 Owner 核心表 180 0

这样每个月看的就是：

1
治理有没有改善？

而不是：

1
治理团队做了多少事情？

十三、最终一张成熟的数据资产应该是什么样

例如一张：

1
dws_dealer_receivable_aging_da

治理完成以后，在 OpenMetadata 里应该看到：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
Name
经销商应收账龄汇总


Description
按经销商统计当前应收余额及账龄区间，
用于信用风险及应收管理。


Domain
Finance.Receivable


Owner
Finance Data Team


Experts
应收会计
数据仓库开发负责人


Tier
Tier1


Glossary
经销商
应收账款
账龄
逾期金额


Tags
DataLayer.DWS
Lifecycle.Active
SecurityLevel.Confidential


Columns
dealer_code
    Glossary: 经销商编码


receivable_amount
    Glossary: 应收金额


aging_days
    Glossary: 账龄


Lineage


ERP
 ↓
ODS
 ↓
DWD
 ↓
DWS
 ↓
BI


Data Quality


dealer_code NOT NULL
receivable_amount >= 0
aging_days >= 0
row_count > 0
freshness < 24h


Data Product
经销商应收分析

到这一层，这张表才真正成为一个被管理的数据资产。

十四、组织机制要和 OpenMetadata 一起设计

OpenMetadata 能解决工具问题，但治理责任还需要组织配套。

比较实际的结构是：

1
2
3
4
5
6
7
8
9
10
11
12
数据治理委员会
        │
        ▼
数据治理 / 数据平台团队
        │
 ┌──────┼───────┐
 ▼      ▼       ▼
Finance Sales Manufacturing
Owner   Owner    Owner
 │       │        │
Steward Steward  Steward

OpenMetadata 中可以对应：

企业治理角色 OpenMetadata
数据治理委员会 Governance Admin
数据治理团队 Team + Steward Role
Domain Owner Domain Owner
Data Owner Asset Owner
Data Steward Team / Role
业务专家 Expert
普通消费者 Consumer Role

OpenMetadata 官方的 Roles / Policies 示例中也专门提供 Data Steward、Owner-only Access、PII Access 等模式。

十五、结合当前环境，可以采用“三阶段实施”

如果目前有数仓、ERP/MES/CRM/SRM/BPM 等业务系统，按这样的实施顺序控制得比较务实。

Phase 1：Data Catalog，先把底座做实

目标：

1
2
3
有什么数据
谁负责
属于什么业务

重点建设：

1
2
3
4
5
6
7
Metadata Ingestion
Domain
Team
Owner
Tier
Description
DataLayer Tag

第一阶段甚至不需要大量做 Glossary 和 DQ。

核心成果应该是：

1
2
3
4
核心资产全部能找到
核心资产全部有Owner
核心资产全部归Domain
Tier1资产识别完成

Phase 2：Governance

目标：

1
2
3
数据能理解
数据能信任
数据能追溯

开始建设：

1
2
3
4
5
6
7
Glossary
Metric
Classification
PII
Lineage
Profiler
Data Quality

重点做：

1
2
3
Tier1
+
Tier2

不要全量铺。

Phase 3：Active Governance

目标：

1
元数据真正参与企业数据运行

开始建设：

1
2
3
4
5
6
7
Policy
Tag-based Access
DQ Alert
Incident
Data Product
Data Insights KPI
自动资产治理

最终：

1
2
3
4
5
6
7
8
9
Metadata
   +
Rules
   +
Automation
   +
Workflow
   =
Active Data Governance

十六、一个很重要的实施原则

如果从企业治理成熟度来看，可以把 OpenMetadata 的实施优先级排成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1 资产
      ↓
2 Owner
      ↓
3 Domain
      ↓
4 Tier
      ↓
5 Description
      ↓
6 Glossary
      ↓
7 Lineage
      ↓
8 Data Quality
      ↓
9 Classification / Security
      ↓
10 Data Product
      ↓
11 Policy
      ↓
12 Governance KPI

不是所有能力第一天同时启用。

不要一开始就追求：

1
2
3
4
100%表有Glossary
100%字段有Tag
100%表有质量规则
100%表有字段级血缘

治理成本会非常高，而且大量低价值数据根本不值得做这样的治理。

更合理的机制是：

1
2
3
4
5
Tier1 → 深治理
Tier2 → 标准治理
Tier3 → 基础治理
Tier4 → 最小治理
Tier5 → 清理治理

按照这样的方法和步骤，企业的数据治理平台才能落地和提升业务价值。