DataHub Metadata Tests 完整指南用无代码规则驱动数据资产自动化治理与合规监控【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubMetadata Tests 是 DataHub 中一个高度可配置的无代码no-code框架它允许你在整个企业元数据图Metadata Graph之上定义跨资产的监控规则与持续自动化动作。本文围绕该框架的完整生命周期展开从两大核心用例、前置权限要求到创建测试的四步操作流程选择条件、规则、动作、元信息再到结果查看、编辑删除、GraphQL 编程接口与批量评估的性能调优并结合作者仓库中的源码实现GraphQL Schema、Resolver、PDL 模型深入佐证其底层原理。读完本文你将能够独立设计并落地一套由元数据驱动的数据治理与合规监控方案。什么是 Metadata TestsDataHub 包含一个高度可配置、无需编写代码的框架允许你针对构成企业元数据图的各类数据资产——数据集Dataset、仪表盘Dashboard、图表Chart、数据管道Pipeline等——配置覆盖面广泛的监控器与持续动作。这个框架的核心就是Metadata Test元数据测试。每一个 Metadata Test 本质上由三部分构成Selection Criteria选择条件—— 界定哪些资产处于该测试的作用域内Rules规则—— 定义被选中资产必须满足的通过条件Actions动作可选—— 为通过或失败的资产自动执行的元数据变更。Metadata Tests 框架唯一支撑着两大极具价值的用例数据资产的自动化动作Automated Actions on Assets自动化元数据完成度监控Automated Metadata Completion Monitoring用例一自动化资产动作Metadata Tests 允许你定义一组用于筛选数据资产子集如数据集、仪表盘等的条件同时为被选中的实体指定一组动作。测试定义完成后这些动作会随着选择集的不断演化与数据生态的变化持续被应用。在定义选择条件时你可以从一系列由 DataHub 自动提取的有用技术信号如使用频率 usage、存储大小 size 等具体信号随集成方式而异中进行选择。这使得自动为企业中重要的资产应用业务元数据变得非常容易而这正是规模化推进数据治理Data Governance计划的关键。例如我们可以定义一个 Metadata Test选择过去 30 天处于查询最频繁前 10%的所有 Snowflake 表然后使用 DataHub 的 Tags、Glossary Terms 或 Domains为这些表自动打上特殊的Tier 1分组标记。用例二自动化数据治理监控Metadata Tests 允许你定义并监控一组适用于数据生态中资产数据集、仪表盘等的规则。在治理数据时这尤其有用因为它支持定义集中的元数据标准度量这些标准的合规情况。这两点对于引导bootstrapping和持续维护一个治理良好的数据生态都至关重要。例如我们可以定义一个 Metadata Test要求所有 Tier 1 数据资产即被打上特殊 Tag 或 Glossary Term 的资产必须具备以下元数据至少1 个明确的负责人owner且有高级别、人工撰写的文档且至少包含1 个来自 Classification 术语组Term Group的 Glossary Term然后我们可以在推进改进的过程中密切监控哪些资产通过、哪些资产未通过这些规则轻松识别出相对于一组集中定义的标准而言合规与不合规的资产。通过引入自动化Metadata Tests 能够支撑复杂数据治理计划的完整生命周期——从范围界定scoping到执行execution再到监控monitoring。设置前提、前置条件与权限要在 DataHub 上管理 Metadata Tests你需要Manage Tests管理测试平台权限Privilege该平台权限允许用户创建、编辑和移除 DataHub 上的所有Metadata Tests。因此它只应授予那些将充当平台元数据管理员metadata Admin的用户。默认的Admin角色自带此权限。从源码层面看这一权限校验在 TestUtils.java 中体现为两个工具方法canViewTests与canManageTests分别基于PoliciesConfig.VIEW_TESTS_PRIVILEGE和PoliciesConfig.MANAGE_TESTS_PRIVILEGE进行授权判断。创建、更新、删除等变更类操作都要求具备canManageTests权限而读取类操作如查看测试结果则依赖查看权限。注意Metadata Tests 功能目前对以下 DataHub 资产类型提供支持Dataset数据集Dashboard仪表盘Chart图表Data Flow数据流例如 PipelineData Job数据任务例如 TaskContainer容器例如 Database、Schema、Project如果你希望 Metadata Tests 支持其他资产类型请联系你的 DataHub Cloud 客户成功CustomerSuccess伙伴。使用 Metadata TestsMetadata Tests 可以通过导航到Govern Tests来创建。要开始构建一个新的 Metadata Test点击Create new Test按钮。在 Metadata Test 构建器中我们需要依次构造一个测试的三个组成部分Selection Criteria选择条件—— 选择测试作用域内的资产Rules规则—— 定义被选中资产通过或失败的条件Actions动作可选—— 定义为通过或失败测试的资产执行的自动化动作Step 1定义选择条件作用域第一步我们定义一组条件用于从元数据图中选出将进入该测试作用域的资产子集。匹配选择条件的资产被视为在作用域内in scope不匹配的则对该测试不适用not applicable。测试创建后对于任何处于作用域内的资产测试将持续被评估——既可以在资产在 DataHub 上发生变化时触发也可以每天执行一次。选择资产类型你必须从数据集Datasets、仪表盘Dashboards、图表Charts、数据流Data Flows / Pipelines、数据任务Data Jobs / Tasks和容器Containers这一集合中至少选择一种资产类型。被选中类型的实体将被视为在作用域内其他类型的实体则被排除在测试评估之外。构建条件Conditions属性Property条件是用于筛选数据资产的基本比较单元。每个Property条件由三部分组成目标property属性、operator操作符和一个可选的value值。Property属性是数据资产的一个特征。它既可以是技术信号如 usage 使用量、存储大小等metric 指标也可以是元数据信号如 owners、domain、glossary terms、tags 等具体取决于资产类型与该信号的适用性。Operator操作符是评估测试时应用于所选属性的谓词类型。可用的操作符类型取决于所选属性常见示例包括Equals等于、Exists存在、Matches Regex正则匹配和Contains包含。Value值定义条件的右侧即用于与属性和操作符比对的预配置值。值的类型取决于所选的属性和操作符例如当操作符为Matches Regex时值的类型就是字符串。通过组合属性、操作符和值我们可以创建单个用于筛选数据资产的条件谓词。例如可以构建出匹配以下情况的属性条件过去 30 天查询使用率位于前 25% 的所有数据集所有带有 Tier 1 Glossary Term 的资产所有位于 Marketing Domain 的资产所有没有负责人的资产所有没有描述的资产要创建Property条件只需点击Add Condition添加条件然后选择Property条件即可。我们还可以通过创建逻辑Logical条件使用包括AND、OR、NOT在内的布尔操作符来组合Property条件。要创建Logical条件只需点击Add Condition然后选择And、Or或Not条件。逻辑条件让我们能够适配复杂的真实世界选择需求例如所有 Snowflake 表位于查询最频繁前 25%且没有 Domain所有 Looker 仪表盘在 Looker 中或在 DataHub 中都没有撰写描述Step 2定义规则Rules第二步我们定义一组条件被选中的资产必须匹配这些条件才算通过该测试。为此我们可以像上面描述的那样再构造一组Property条件。专业提示Pro-Tip如果不提供任何规则那么所有被 Step 1 中条件选中的资产都将被视为通过。如果你需要对选中的资产应用自动化动作Action可以留空规则并直接进入下一步。规则与选择条件相结合使我们能够定义复杂、高度定制化的数据治理策略例如过去 30 天查询使用率位于前 25% 的所有数据集必须有一个负责人Marketing Domain 中的所有资产必须有描述查询最频繁前 25% 且没有 Domain 的所有 Snowflake 表必须带有来自 Classification 术语组的 Glossary Term验证测试条件在 Step 2 期间我们可以通过将它们与 DataHub 已索引的一些现有资产进行比对快速验证已编写的选择条件与规则是否符合预期。要验证测试条件只需点击Try it out试一试通过搜索与过滤缩小范围找到要测试的资产最后点击Run Test运行测试即可看到该资产是通过还是未通过所提供的条件。Step 3定义动作可选如果你不希望为通过或失败测试的资产采取任何动作直接点击 Skip跳过即可。第三步我们可以定义一组动作Actions这些动作将被自动应用于每个通过或未通过规则条件的被选中资产。例如我们可能希望为通过的资产标记特殊的 DataHub Tag 或 Glossary Term如 Tier 1并为未通过的资产移除这些特殊标记。这让我们能够在数据资产进出 Step 2 定义的规则合规状态时自动控制其分类标记。支持的部分动作类型包括添加或移除特定的 Tags标签添加或移除特定的 Glossary Terms术语添加或移除特定的 Owners负责人添加或移除到特定的 Domain域Step 4名称、类别与描述最后一步我们可以为新的 Metadata Test 添加一个自由文本的名称name、类别category和描述description。底层模型Test 实体与 testInfo / testResults 两个 AspectMetadata Tests 并不是一个黑盒功能。从源码结构看它由标准的 DataHub 实体与 Aspect 模型承载这一点在 metadata-models 目录下可以直接印证。testInfoAspect定义于 TestInfo.pdl承载测试自身的元信息包括name可搜索字段TEXT_PARTIAL类型支持部分匹配、categoryKEYWORD类型、description可选TEXT类型以及definition测试定义其type目前为JSON枚举json字段存放具体配置。testResultsAspect定义于 TestResults.pdl承载测试运行结果包含passing与failing两个TestResult数组每个结果关联对应的 TestIsPassing/IsFailing关系并且passingTests/failingTests均可作为搜索字段参与过滤——这正是 UI 上查看某个测试下通过/失败资产列表能力的数据基础。在 GraphQL 层tests.graphql 定义了Test、TestDefinition、TestResultTypeSUCCESS/FAILURE、TestResults、TestResult等类型并为Dataset扩展了testResults字段。对应的查询/变更 resolver 集中在 resolvers/test 目录下ListTestsResolver列表、CreateTestResolver创建、UpdateTestResolver更新、DeleteTestResolver删除、TestResultsResolver读取某实体的测试结果。其中 TestResultsResolver.java 的实现清晰地展示了结果的读取链路通过EntityClient.getV2按实体 URN 获取TEST_RESULTS_ASPECT_NAME即testResultsaspect再将其中的passing/failing列表映射为 GraphQL 的TestResult对象返回。也就是说资产页面上展示的测试通过/失败结果本质上是该资产testResultsaspect 的实时呈现。查看测试结果Metadata Test 的结果可以在两个地方查看资产详情页例如 Dataset 详情页内的Validation验证选项卡中Metadata Tests 管理页面上。要查看某个测试通过或失败的所有资产只需点击显示通过/失败资产数量的标签即可。更新一个已有测试要更新已有测试只需点击要更改测试上的Edit编辑按钮然后进行修改并点击Save保存。保存测试后变更可能需要最多2 分钟才会在整个 DataHub 中生效。移除一个测试要移除测试点击 Tests 列表中对应的垃圾桶图标即可。这将移除该测试并将其停用使其不再被评估。删除测试后变更同样可能需要最多2 分钟才会生效。通过 GraphQL 编程式管理测试除了 UIMetadata Tests 还暴露了完整的 GraphQL 编程接口schema 见 tests.graphql便于集成到自动化工作流中操作GraphQL 端点说明查询test(urn: String!): Test按 URN 获取单个测试查询listTests(input: ListTestsInput!): ListTestsResult分页列出所有测试支持start、count与query关键字过滤变更createTest(input: CreateTestInput!): String创建测试CreateTestInput支持可选自定义id必填name、category可选description与definition变更updateTest(urn: String!, input: UpdateTestInput!): String更新已有测试变更deleteTest(urn: String!): Boolean删除测试。注意删除不会清理悬空指针直到测试下次执行其中CreateTestInput与UpdateTestInput的定义在 tests.graphql 中TestDefinitionInput目前只支持json字段注释中已标注该字段已废弃JSON 表示方式不再被支持。创建时的定义映射逻辑位于 TestUtils.javamapDefinition方法始终将TestDefinitionType设置为JSON并将传入的json字符串写入定义。提示开启 Metadata Tests 需要显式启用。根据 Environment Variables 文档GMS 组件中的METADATA_TESTS_ENABLED环境变量默认值为false用于控制是否启用 metadata tests。批量评估的性能调优本节介绍定时批量评估 Metadata Tests 时的性能考量。批量处理架构批量评估任务运行在datahub-upgrade容器中可以直接本地访问EntityService与EntitySearchService。测试结果与动作以异步方式写入Kafka随后由MCE Consumer默认内嵌于 GMS 中消费并写入数据库。何时使用 ElasticSearch 执行器默认启用METADATA_TESTS_ELASTICSEARCH_EXECUTOR_ENABLEDtrue当测试的选择条件与规则可以被表达为 ElasticSearch 查询时使用在大规模实体数量下提供更快的评估速度对于不支持的谓词会回退到通过本地EntityService执行 SQL 查询关键配置变量主要的性能调优参数是METADATA_TESTS_ACTIONS_CONCURRENCY默认值2它控制用于生成动作 MCPMetadata Change Proposal的线程数。增大该值可以让更多动作被并行产出在处理大量测试结果时提高吞吐量。扩展建议由于测试评估使用本地服务瓶颈通常在于MCE Consumer 处理 Kafka 异步写入的吞吐量。要有效扩展需要关注MetadataChangeProposal_v1topic 上有足够的分区数Kafka partition count充足的 MCE consumer 容量内嵌或独立部署均可独立部署 MCE/MAE Consumer 及 Kafka 配置请参考 Configuring Kafka完整的环境变量参考见 Environment Variables。FAQ 与故障排查Metadata Tests 何时被评估Metadata Tests 在两种场景下被评估实时评估Real-time evaluation当 DataHub 中某个个体资产发生变化时所有将其纳入作用域的测试都会被评估。该特性通常默认关闭可按需启用需与 DataHub 团队讨论。定时评估Scheduled evaluation专用的 Metadata Test 评估器按固定计划通常每 24 小时运行对整个元数据图评估所有测试。节奏可以调整在元数据量较小的有限场景下可以更频繁同样需要与 DataHub 团队讨论。两种场景都会带来服务器负载上升的担忧可能需要额外的服务器资源并应咨询你的 DataHub 代表了解相关成本。能否为我的 Metadata Test 配置自定义评估计划不能。目前内部评估器会确保测试对每个资产持续运行无论该资产是否在 DataHub 上发生变更。Metadata Test 与 Assertion 有何区别Assertion断言是针对单个数据资产定义的特定测试类似于单元测试。它通常包含关于该资产的领域特定知识并针对其物理属性进行验证。例如一个 Assertion 可能会验证 Snowflake 中某张表的行数是否落在某个明确定义的范围内。Metadata Test是作用于元数据图子集例如跨多个数据资产的广泛谓词。它通常针对元数据属性进行定义而非物理数据本身。例如一个 Metadata Test 可能验证 Snowflake 中所有表都至少有 1 个指定的负责人和一份人工撰写的描述。简言之Assertion 关注单条数据的物理正确性而 Metadata Test 关注跨资产、由元数据驱动的治理策略——两者可以组合使用以支撑更大规模的数据治理计划。小结Metadata Tests 为 DataHub 提供了一套完整的定义—度量—执行闭环用无代码条件选择资产作用域用规则定义合规标准用动作自动落实治理标记并通过持续评估实时 定时与 GraphQL 接口让治理策略真正活起来。结合 TestInfo.pdl、TestResults.pdl 与 resolvers/test 目录下的源码你可以深入理解其数据模型与执行链路从而将这一框架灵活运用于自身的数据治理体系建设中。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DataHub Metadata Tests 完整指南：用无代码规则驱动数据资产自动化治理与合规监控
DataHub Metadata Tests 完整指南用无代码规则驱动数据资产自动化治理与合规监控【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahubMetadata Tests 是 DataHub 中一个高度可配置的无代码no-code框架它允许你在整个企业元数据图Metadata Graph之上定义跨资产的监控规则与持续自动化动作。本文围绕该框架的完整生命周期展开从两大核心用例、前置权限要求到创建测试的四步操作流程选择条件、规则、动作、元信息再到结果查看、编辑删除、GraphQL 编程接口与批量评估的性能调优并结合作者仓库中的源码实现GraphQL Schema、Resolver、PDL 模型深入佐证其底层原理。读完本文你将能够独立设计并落地一套由元数据驱动的数据治理与合规监控方案。什么是 Metadata TestsDataHub 包含一个高度可配置、无需编写代码的框架允许你针对构成企业元数据图的各类数据资产——数据集Dataset、仪表盘Dashboard、图表Chart、数据管道Pipeline等——配置覆盖面广泛的监控器与持续动作。这个框架的核心就是Metadata Test元数据测试。每一个 Metadata Test 本质上由三部分构成Selection Criteria选择条件—— 界定哪些资产处于该测试的作用域内Rules规则—— 定义被选中资产必须满足的通过条件Actions动作可选—— 为通过或失败的资产自动执行的元数据变更。Metadata Tests 框架唯一支撑着两大极具价值的用例数据资产的自动化动作Automated Actions on Assets自动化元数据完成度监控Automated Metadata Completion Monitoring用例一自动化资产动作Metadata Tests 允许你定义一组用于筛选数据资产子集如数据集、仪表盘等的条件同时为被选中的实体指定一组动作。测试定义完成后这些动作会随着选择集的不断演化与数据生态的变化持续被应用。在定义选择条件时你可以从一系列由 DataHub 自动提取的有用技术信号如使用频率 usage、存储大小 size 等具体信号随集成方式而异中进行选择。这使得自动为企业中重要的资产应用业务元数据变得非常容易而这正是规模化推进数据治理Data Governance计划的关键。例如我们可以定义一个 Metadata Test选择过去 30 天处于查询最频繁前 10%的所有 Snowflake 表然后使用 DataHub 的 Tags、Glossary Terms 或 Domains为这些表自动打上特殊的Tier 1分组标记。用例二自动化数据治理监控Metadata Tests 允许你定义并监控一组适用于数据生态中资产数据集、仪表盘等的规则。在治理数据时这尤其有用因为它支持定义集中的元数据标准度量这些标准的合规情况。这两点对于引导bootstrapping和持续维护一个治理良好的数据生态都至关重要。例如我们可以定义一个 Metadata Test要求所有 Tier 1 数据资产即被打上特殊 Tag 或 Glossary Term 的资产必须具备以下元数据至少1 个明确的负责人owner且有高级别、人工撰写的文档且至少包含1 个来自 Classification 术语组Term Group的 Glossary Term然后我们可以在推进改进的过程中密切监控哪些资产通过、哪些资产未通过这些规则轻松识别出相对于一组集中定义的标准而言合规与不合规的资产。通过引入自动化Metadata Tests 能够支撑复杂数据治理计划的完整生命周期——从范围界定scoping到执行execution再到监控monitoring。设置前提、前置条件与权限要在 DataHub 上管理 Metadata Tests你需要Manage Tests管理测试平台权限Privilege该平台权限允许用户创建、编辑和移除 DataHub 上的所有Metadata Tests。因此它只应授予那些将充当平台元数据管理员metadata Admin的用户。默认的Admin角色自带此权限。从源码层面看这一权限校验在 TestUtils.java 中体现为两个工具方法canViewTests与canManageTests分别基于PoliciesConfig.VIEW_TESTS_PRIVILEGE和PoliciesConfig.MANAGE_TESTS_PRIVILEGE进行授权判断。创建、更新、删除等变更类操作都要求具备canManageTests权限而读取类操作如查看测试结果则依赖查看权限。注意Metadata Tests 功能目前对以下 DataHub 资产类型提供支持Dataset数据集Dashboard仪表盘Chart图表Data Flow数据流例如 PipelineData Job数据任务例如 TaskContainer容器例如 Database、Schema、Project如果你希望 Metadata Tests 支持其他资产类型请联系你的 DataHub Cloud 客户成功CustomerSuccess伙伴。使用 Metadata TestsMetadata Tests 可以通过导航到Govern Tests来创建。要开始构建一个新的 Metadata Test点击Create new Test按钮。在 Metadata Test 构建器中我们需要依次构造一个测试的三个组成部分Selection Criteria选择条件—— 选择测试作用域内的资产Rules规则—— 定义被选中资产通过或失败的条件Actions动作可选—— 定义为通过或失败测试的资产执行的自动化动作Step 1定义选择条件作用域第一步我们定义一组条件用于从元数据图中选出将进入该测试作用域的资产子集。匹配选择条件的资产被视为在作用域内in scope不匹配的则对该测试不适用not applicable。测试创建后对于任何处于作用域内的资产测试将持续被评估——既可以在资产在 DataHub 上发生变化时触发也可以每天执行一次。选择资产类型你必须从数据集Datasets、仪表盘Dashboards、图表Charts、数据流Data Flows / Pipelines、数据任务Data Jobs / Tasks和容器Containers这一集合中至少选择一种资产类型。被选中类型的实体将被视为在作用域内其他类型的实体则被排除在测试评估之外。构建条件Conditions属性Property条件是用于筛选数据资产的基本比较单元。每个Property条件由三部分组成目标property属性、operator操作符和一个可选的value值。Property属性是数据资产的一个特征。它既可以是技术信号如 usage 使用量、存储大小等metric 指标也可以是元数据信号如 owners、domain、glossary terms、tags 等具体取决于资产类型与该信号的适用性。Operator操作符是评估测试时应用于所选属性的谓词类型。可用的操作符类型取决于所选属性常见示例包括Equals等于、Exists存在、Matches Regex正则匹配和Contains包含。Value值定义条件的右侧即用于与属性和操作符比对的预配置值。值的类型取决于所选的属性和操作符例如当操作符为Matches Regex时值的类型就是字符串。通过组合属性、操作符和值我们可以创建单个用于筛选数据资产的条件谓词。例如可以构建出匹配以下情况的属性条件过去 30 天查询使用率位于前 25% 的所有数据集所有带有 Tier 1 Glossary Term 的资产所有位于 Marketing Domain 的资产所有没有负责人的资产所有没有描述的资产要创建Property条件只需点击Add Condition添加条件然后选择Property条件即可。我们还可以通过创建逻辑Logical条件使用包括AND、OR、NOT在内的布尔操作符来组合Property条件。要创建Logical条件只需点击Add Condition然后选择And、Or或Not条件。逻辑条件让我们能够适配复杂的真实世界选择需求例如所有 Snowflake 表位于查询最频繁前 25%且没有 Domain所有 Looker 仪表盘在 Looker 中或在 DataHub 中都没有撰写描述Step 2定义规则Rules第二步我们定义一组条件被选中的资产必须匹配这些条件才算通过该测试。为此我们可以像上面描述的那样再构造一组Property条件。专业提示Pro-Tip如果不提供任何规则那么所有被 Step 1 中条件选中的资产都将被视为通过。如果你需要对选中的资产应用自动化动作Action可以留空规则并直接进入下一步。规则与选择条件相结合使我们能够定义复杂、高度定制化的数据治理策略例如过去 30 天查询使用率位于前 25% 的所有数据集必须有一个负责人Marketing Domain 中的所有资产必须有描述查询最频繁前 25% 且没有 Domain 的所有 Snowflake 表必须带有来自 Classification 术语组的 Glossary Term验证测试条件在 Step 2 期间我们可以通过将它们与 DataHub 已索引的一些现有资产进行比对快速验证已编写的选择条件与规则是否符合预期。要验证测试条件只需点击Try it out试一试通过搜索与过滤缩小范围找到要测试的资产最后点击Run Test运行测试即可看到该资产是通过还是未通过所提供的条件。Step 3定义动作可选如果你不希望为通过或失败测试的资产采取任何动作直接点击 Skip跳过即可。第三步我们可以定义一组动作Actions这些动作将被自动应用于每个通过或未通过规则条件的被选中资产。例如我们可能希望为通过的资产标记特殊的 DataHub Tag 或 Glossary Term如 Tier 1并为未通过的资产移除这些特殊标记。这让我们能够在数据资产进出 Step 2 定义的规则合规状态时自动控制其分类标记。支持的部分动作类型包括添加或移除特定的 Tags标签添加或移除特定的 Glossary Terms术语添加或移除特定的 Owners负责人添加或移除到特定的 Domain域Step 4名称、类别与描述最后一步我们可以为新的 Metadata Test 添加一个自由文本的名称name、类别category和描述description。底层模型Test 实体与 testInfo / testResults 两个 AspectMetadata Tests 并不是一个黑盒功能。从源码结构看它由标准的 DataHub 实体与 Aspect 模型承载这一点在 metadata-models 目录下可以直接印证。testInfoAspect定义于 TestInfo.pdl承载测试自身的元信息包括name可搜索字段TEXT_PARTIAL类型支持部分匹配、categoryKEYWORD类型、description可选TEXT类型以及definition测试定义其type目前为JSON枚举json字段存放具体配置。testResultsAspect定义于 TestResults.pdl承载测试运行结果包含passing与failing两个TestResult数组每个结果关联对应的 TestIsPassing/IsFailing关系并且passingTests/failingTests均可作为搜索字段参与过滤——这正是 UI 上查看某个测试下通过/失败资产列表能力的数据基础。在 GraphQL 层tests.graphql 定义了Test、TestDefinition、TestResultTypeSUCCESS/FAILURE、TestResults、TestResult等类型并为Dataset扩展了testResults字段。对应的查询/变更 resolver 集中在 resolvers/test 目录下ListTestsResolver列表、CreateTestResolver创建、UpdateTestResolver更新、DeleteTestResolver删除、TestResultsResolver读取某实体的测试结果。其中 TestResultsResolver.java 的实现清晰地展示了结果的读取链路通过EntityClient.getV2按实体 URN 获取TEST_RESULTS_ASPECT_NAME即testResultsaspect再将其中的passing/failing列表映射为 GraphQL 的TestResult对象返回。也就是说资产页面上展示的测试通过/失败结果本质上是该资产testResultsaspect 的实时呈现。查看测试结果Metadata Test 的结果可以在两个地方查看资产详情页例如 Dataset 详情页内的Validation验证选项卡中Metadata Tests 管理页面上。要查看某个测试通过或失败的所有资产只需点击显示通过/失败资产数量的标签即可。更新一个已有测试要更新已有测试只需点击要更改测试上的Edit编辑按钮然后进行修改并点击Save保存。保存测试后变更可能需要最多2 分钟才会在整个 DataHub 中生效。移除一个测试要移除测试点击 Tests 列表中对应的垃圾桶图标即可。这将移除该测试并将其停用使其不再被评估。删除测试后变更同样可能需要最多2 分钟才会生效。通过 GraphQL 编程式管理测试除了 UIMetadata Tests 还暴露了完整的 GraphQL 编程接口schema 见 tests.graphql便于集成到自动化工作流中操作GraphQL 端点说明查询test(urn: String!): Test按 URN 获取单个测试查询listTests(input: ListTestsInput!): ListTestsResult分页列出所有测试支持start、count与query关键字过滤变更createTest(input: CreateTestInput!): String创建测试CreateTestInput支持可选自定义id必填name、category可选description与definition变更updateTest(urn: String!, input: UpdateTestInput!): String更新已有测试变更deleteTest(urn: String!): Boolean删除测试。注意删除不会清理悬空指针直到测试下次执行其中CreateTestInput与UpdateTestInput的定义在 tests.graphql 中TestDefinitionInput目前只支持json字段注释中已标注该字段已废弃JSON 表示方式不再被支持。创建时的定义映射逻辑位于 TestUtils.javamapDefinition方法始终将TestDefinitionType设置为JSON并将传入的json字符串写入定义。提示开启 Metadata Tests 需要显式启用。根据 Environment Variables 文档GMS 组件中的METADATA_TESTS_ENABLED环境变量默认值为false用于控制是否启用 metadata tests。批量评估的性能调优本节介绍定时批量评估 Metadata Tests 时的性能考量。批量处理架构批量评估任务运行在datahub-upgrade容器中可以直接本地访问EntityService与EntitySearchService。测试结果与动作以异步方式写入Kafka随后由MCE Consumer默认内嵌于 GMS 中消费并写入数据库。何时使用 ElasticSearch 执行器默认启用METADATA_TESTS_ELASTICSEARCH_EXECUTOR_ENABLEDtrue当测试的选择条件与规则可以被表达为 ElasticSearch 查询时使用在大规模实体数量下提供更快的评估速度对于不支持的谓词会回退到通过本地EntityService执行 SQL 查询关键配置变量主要的性能调优参数是METADATA_TESTS_ACTIONS_CONCURRENCY默认值2它控制用于生成动作 MCPMetadata Change Proposal的线程数。增大该值可以让更多动作被并行产出在处理大量测试结果时提高吞吐量。扩展建议由于测试评估使用本地服务瓶颈通常在于MCE Consumer 处理 Kafka 异步写入的吞吐量。要有效扩展需要关注MetadataChangeProposal_v1topic 上有足够的分区数Kafka partition count充足的 MCE consumer 容量内嵌或独立部署均可独立部署 MCE/MAE Consumer 及 Kafka 配置请参考 Configuring Kafka完整的环境变量参考见 Environment Variables。FAQ 与故障排查Metadata Tests 何时被评估Metadata Tests 在两种场景下被评估实时评估Real-time evaluation当 DataHub 中某个个体资产发生变化时所有将其纳入作用域的测试都会被评估。该特性通常默认关闭可按需启用需与 DataHub 团队讨论。定时评估Scheduled evaluation专用的 Metadata Test 评估器按固定计划通常每 24 小时运行对整个元数据图评估所有测试。节奏可以调整在元数据量较小的有限场景下可以更频繁同样需要与 DataHub 团队讨论。两种场景都会带来服务器负载上升的担忧可能需要额外的服务器资源并应咨询你的 DataHub 代表了解相关成本。能否为我的 Metadata Test 配置自定义评估计划不能。目前内部评估器会确保测试对每个资产持续运行无论该资产是否在 DataHub 上发生变更。Metadata Test 与 Assertion 有何区别Assertion断言是针对单个数据资产定义的特定测试类似于单元测试。它通常包含关于该资产的领域特定知识并针对其物理属性进行验证。例如一个 Assertion 可能会验证 Snowflake 中某张表的行数是否落在某个明确定义的范围内。Metadata Test是作用于元数据图子集例如跨多个数据资产的广泛谓词。它通常针对元数据属性进行定义而非物理数据本身。例如一个 Metadata Test 可能验证 Snowflake 中所有表都至少有 1 个指定的负责人和一份人工撰写的描述。简言之Assertion 关注单条数据的物理正确性而 Metadata Test 关注跨资产、由元数据驱动的治理策略——两者可以组合使用以支撑更大规模的数据治理计划。小结Metadata Tests 为 DataHub 提供了一套完整的定义—度量—执行闭环用无代码条件选择资产作用域用规则定义合规标准用动作自动落实治理标记并通过持续评估实时 定时与 GraphQL 接口让治理策略真正活起来。结合 TestInfo.pdl、TestResults.pdl 与 resolvers/test 目录下的源码你可以深入理解其数据模型与执行链路从而将这一框架灵活运用于自身的数据治理体系建设中。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考