一、先搞懂我们要解决什么问题
做数据相关工作的人，大多都遇到过这种糟心事：业务部门说报表数字不对，查了半天才发现是上周新上的数据源脏了，或者是某张表的关键字段有了空值、重复值，更气人的是，这种问题往往是业务方发现了才来通知，我们再紧急排查，整个过程既费时间又丢信任。
以前解决这类问题，要么是写一堆零散的SQL脚本去查数据，要么是靠人工定期核对，不仅效率低，还容易漏查。后来我们接触到了OpenMetadata（后面简称OM）这个工具，它自带数据质量测试的功能，能从规则定义到告警联动全流程覆盖，不用再东拼西凑做解决方案。但真正落地的时候，踩了不少坑，这篇就把这些坑和解决办法整理出来，帮大家少走弯路。
二、落地前的准备：先搭好基础环境
要做OM的数据质量测试，首先得把OM的基础环境搭起来，不然连数据都接不上，更别说做测试了。这里我们统一用Docker来部署，简单快速，适合大多数场景。
2.1 部署OpenMetadata基础环境
技术栈：Docker（含Docker Compose） 部署步骤很简单，先从OM的官方仓库拉取最新的Docker Compose配置文件，然后直接启动就行。这里给一个完整的启动命令，里面加了注释说明每个部分的作用：
# 先拉取OM官方的Docker Compose配置文件，指定最新稳定版（这里用1.3.0为例）
wget https://raw.githubusercontent.com/open-metadata/openmetadata-docker/main/docker-compose.yaml -O openmetadata-docker-compose.yaml
# 启动所有服务，-d表示后台运行，--build表示如果有镜像更新就重新构建
docker-compose -f openmetadata-docker-compose.yaml up -d --build
启动完成后，等个10分钟左右，等所有服务都启动成功，就可以通过http://localhost:8585访问OM的管理界面了，默认账号是admin，密码是admin。
2.2 接入要做质量测试的数据源
OM支持接入几乎所有常见的数据源，比如MySQL、PostgreSQL、ClickHouse、MongoDB等等，这里我们以接入MySQL为例，演示怎么把数据源接进来。 技术栈：Docker（含Docker Compose）、MySQL 8.0 接入步骤分两步，第一步是在OM界面里添加数据源，第二步是配置元数据同步，确保OM能拿到数据源的表结构、字段信息等。
先看界面操作的核心步骤：登录OM后，点击左侧菜单的“Services”，然后点击“Add Service”，选择“Database”，然后选择“MySQL”，按照提示填写MySQL的连接信息，包括主机地址、端口、用户名、密码、要同步的数据库名等。
如果要通过命令行配置（适合自动化场景），可以用OM的CLI工具，命令如下：
# 进入OM的CLI容器，这里假设容器名是openmetadata-server
docker exec -it openmetadata-server /bin/bash
# 配置MySQL数据源，替换成自己的连接信息
omcli services database create --name mysql-demo-service --service-type MySQL --connection '{"hostPort":"localhost:3306","username":"root","password":"123456","database":"demo_db"}'
接入成功后，OM就能同步到这个MySQL里的所有表和字段了，这是做数据质量测试的基础。
三、核心环节：规则定义怎么写才实用
很多人刚接触OM的数据质量测试，上来就把所有字段都加一堆规则，结果要么规则太严导致误报太多，要么规则太松起不到作用。这里要记住，规则定义要贴合业务场景，不能瞎加。
3.1 先搞懂OM支持的常见规则类型
OM的规则分很多种，覆盖了数据质量的常见场景，比如空值检查、重复值检查、数值范围检查、字符串格式检查、一致性检查等等。举几个常用的例子：
- 空值检查：比如用户表的手机号字段，不能有空值；
- 重复值检查：比如订单表的订单号字段，不能有重复；
- 数值范围检查：比如年龄字段，必须在0到120之间；
- 字符串格式检查：比如邮箱字段，必须符合邮箱格式。
3.2 规则定义的两种方式：界面操作和YAML配置
规则定义有两种方式，界面操作适合小范围、临时的规则，YAML配置适合批量、自动化的规则。这里重点说YAML配置，因为批量操作的时候效率高很多。
技术栈：YAML、OpenMetadata 1.3.0 举个完整的规则定义示例，比如我们要给MySQL里的用户表（user）定义几个规则，YAML配置如下：
# 规则所属的数据源服务名，和之前配置的MySQL服务名对应
service: mysql-demo-service
# 规则所属的数据库名
database: demo_db
# 规则所属的表名
table: user
# 规则列表
rules:
# 1. 空值检查：手机号字段不能有空值
- name: phone_not_null
type: column_value_not_null
column: phone
# 规则的描述，方便后续排查
description: 用户手机号不能为空
# 2. 重复值检查：订单号字段不能有重复（这里假设user表有order_no字段）
- name: order_no_not_duplicate
type: column_value_unique
column: order_no
description: 用户订单号不能重复
# 3. 数值范围检查：年龄字段必须在0到120之间
- name: age_range_check
type: column_value_in_range
column: age
# 范围的最小值和最大值
min_value: 0
max_value: 120
description: 用户年龄必须在0到120之间
# 4. 字符串格式检查：邮箱字段必须符合邮箱格式
- name: email_format_check
type: column_value_regex_match
column: email
# 正则表达式，匹配邮箱格式
regex: ^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\.[a-zA-Z0-9_-]+)+$
description: 用户邮箱必须符合标准格式
配置好YAML后，用OM的CLI工具把规则导入进去，命令如下：
# 进入OM的CLI容器
docker exec -it openmetadata-server /bin/bash
# 导入规则，替换成自己的YAML文件路径
omcli tests test_suite create --file /path/to/rules.yaml
3.3 规则定义的避坑要点
这里要注意几个坑，很多人容易踩： 第一，规则不要加太多，尤其是一开始，先加核心业务规则，比如订单号、手机号这种关键字段的规则，其他非核心字段可以后续慢慢加，不然误报太多会让人对告警失去信心； 第二，规则的阈值要合理，比如空值检查，是完全不能有空值，还是允许1%以内的空值？如果是允许少量空值，要在规则里配置阈值，比如把空值检查的阈值设为1%，超过这个比例才告警； 第三，规则要定期维护，比如业务调整了，年龄的范围从0-120改成0-150，要及时修改规则，不然会一直误报。
四、测试执行：怎么跑才稳定高效
规则定义好后，就要跑测试了，OM的测试执行有两种方式，手动执行和定时执行，定时执行适合日常监控，手动执行适合临时排查。
4.1 手动执行测试的两种方式
手动执行很简单，界面操作的话，找到对应的表，点击“Tests”标签，然后点击“Run Tests”就行。命令行的话，用OM的CLI工具，命令如下：
# 执行指定表的所有测试
omcli tests run --service mysql-demo-service --database demo_db --table user
执行完成后，就能看到测试结果，哪些规则通过了，哪些没通过，没通过的话有多少条数据不符合规则。
4.2 定时执行测试的配置
定时执行适合日常监控，比如每天凌晨跑一次，检查前一天的数据质量。定时执行的配置也有两种方式，界面操作和YAML配置。
技术栈：YAML、OpenMetadata 1.3.0 举个定时执行的YAML配置示例，比如我们要每天凌晨1点执行user表的测试，配置如下：
# 测试所属的测试套件名
test_suite: user_test_suite
# 定时规则，每天凌晨1点执行，用Cron表达式
schedule: "0 0 1 * * ?"
# 要执行的测试列表，和之前定义的规则名对应
tests:
- phone_not_null
- order_no_not_duplicate
- age_range_check
- email_format_check
配置好后，用CLI工具导入定时任务，命令如下：
# 导入定时任务
omcli tests schedule create --file /path/to/schedule.yaml
4.3 测试执行的避坑要点
测试执行也有几个坑要注意： 第一，测试执行的时间要避开业务高峰，比如业务高峰是白天9点到18点，那定时执行就设在凌晨，不然测试会占用数据源的资源，影响业务； 第二，测试执行的范围不要太大，比如不要一次性执行所有表的测试，而是分批次执行，比如按业务线分，或者按表的大小分，大表的测试单独安排时间； 第三，测试执行的结果要及时清理，OM会保存所有的测试结果，如果时间长了，测试结果会占用大量的存储空间，所以要定期清理过期的测试结果，比如只保留最近30天的结果。
五、告警联动：怎么让告警有用
测试执行完后，如果有问题，就要告警，OM的告警联动可以对接很多渠道，比如邮件、Slack、企业微信、钉钉等等，这里我们以对接邮件为例，演示怎么配置告警。
5.1 告警配置的两种方式
告警配置也有界面操作和YAML配置两种方式，这里重点说YAML配置，因为批量配置的时候更方便。
技术栈：YAML、OpenMetadata 1.3.0 举个告警配置的YAML示例，比如我们要给user表的测试配置邮件告警，配置如下：
# 告警所属的测试套件名
test_suite: user_test_suite
# 告警触发条件，只要有一个测试不通过就告警
trigger: any_test_failed
# 告警渠道，这里用邮件
channel:
type: email
# 邮件服务器配置，用QQ邮箱为例
smtp_host: smtp.qq.com
smtp_port: 465
smtp_username: your_email@qq.com
# 这里填的是QQ邮箱的授权码，不是邮箱密码
smtp_password: your_authorization_code
# 告警接收人列表
receivers:
- receiver1@example.com
- receiver2@example.com
配置好后，用CLI工具导入告警配置，命令如下：
# 导入告警配置
omcli alerts create --file /path/to/alert.yaml
5.2 告警联动的避坑要点
告警联动最容易踩的坑就是误报太多，导致大家对告警麻木，所以要注意几个点： 第一，告警要分级，比如核心业务规则不通过，发紧急告警，非核心规则不通过，发普通告警，不要所有告警都用一样的级别； 第二，告警要加上下文，比如告警里要说明哪个表、哪个规则、有多少条数据不符合，方便排查问题，不要只说“测试不通过”； 第三，告警要加静音机制，比如同一个规则短时间内多次不通过，只发一次告警，不要重复发，不然会打扰人； 第四，告警渠道要选对，比如紧急告警用企业微信或者钉钉，普通告警用邮件，这样重要的信息能及时收到。
六、应用场景、优缺点与注意事项
6.1 核心应用场景
OM的数据质量测试框架适合很多场景，比如：
- 数据仓库的日常监控：每天检查数据仓库的核心表，确保数据的准确性；
- 新数据源接入的验证：新数据源接入后，先跑一遍质量测试，确保数据没问题再上线；
- 业务报表的前置检查：报表上线前，先检查报表依赖的表，确保报表数字准确；
- 数据合规检查：比如检查敏感字段的空值、格式，确保符合合规要求。
6.2 技术优缺点
优点：
- 一站式解决方案：从规则定义、测试执行到告警联动，全流程覆盖，不用再东拼西凑；
- 支持多数据源：几乎所有常见的数据源都支持，不用为不同的数据源写不同的规则；
- 可扩展性强：可以自定义规则，满足特殊的业务需求；
- 可视化好：界面操作简单，测试结果一目了然。
缺点：
- 规则类型有限：虽然支持很多常见的规则，但特殊的复杂规则（比如跨表的复杂一致性检查）需要自定义，门槛比较高；
- 性能问题：大表的测试执行比较慢，尤其是全表扫描的规则，比如重复值检查，大表跑一次要很久；
- 告警配置复杂：告警的分级、静音等功能配置起来比较麻烦，界面操作不够友好。
6.3 落地注意事项
- 先试点再推广：不要一开始就全公司推广，先选一个业务线试点，跑通流程后再推广；
- 规则要贴合业务：规则不是越多越好，要贴合业务需求，核心规则优先；
- 定期优化：定期检查规则的有效性，测试执行的效率，告警的准确率，不断优化；
- 培训相关人员：数据质量不是某一个人的事，要培训业务人员、开发人员，让大家都重视数据质量。
七、经验总结
落地OM的数据质量测试框架，核心是“先简后繁，先核心后全面”，不要一开始就追求完美，要先跑通流程，再慢慢优化。
首先，基础环境要搭稳，数据源要接对，这是一切的基础；然后，规则定义要贴合业务，核心规则优先，不要加太多规则；测试执行要避开业务高峰，分批次执行；告警联动要避免误报，分级分类，加上下文。
另外，要重视持续优化，数据质量是一个长期的过程，不是一劳永逸的，要定期检查规则的有效性，测试执行的效率，告警的准确率，不断调整和优化。
最后，要建立数据质量的文化，让大家都重视数据质量，从源头上减少脏数据的产生，这样才能从根本上解决数据质量问题。
Comments