OpenMetadata Data Retention 应用配置指南为每种实体精细化设置数据库保留策略【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata导读Data Retention数据保留是 OpenMetadata 内置的自动化应用负责按管理员定义的保留期限定期清理服务端内部数据库中的过期记录防止变更事件、活动线程、测试结果、Profile 数据、审计日志等随时间持续膨胀拖垮数据库性能。本文以 DataRetentionApplication.md 中定义的 8 个配置字段为主线结合 JSON Schema、应用注册配置与 Java 实现源码完整讲解每个保留参数的语义、默认值、取值范围及其在底层清理流程中的实际作用并给出可直接落地的配置建议。Data Retention 应用在 OpenMetadata 中扮演什么角色OpenMetadata 的服务端会持续产生大量过程性数据每次元数据变更产生的 change event、用户对话产生的活动线程与评论、数据质量测试的运行结果、profiler 采集的 Profile 时间序列、审计日志以及测试连接、查询运行器、反向摄取等自动化工作流留下的短期记录。这些数据若不清理会随运行时间线性增长拖慢查询、增加备份体积。Data Retention 应用正是为此而生它作为一个原生internal应用注册在 OpenMetadata 中按固定调度周期运行依据管理员配置的保留期限批量删除过期记录。其市场定义在 DataRetentionApplication.json 中明确说明The Data Retention App automates the cleanup of OpenMetadatas internal database to maintain performance and efficiency... prevents data bloat by removing outdated records.自动清理内部数据库以维持性能与效率通过删除过期记录防止数据膨胀。应用的实际执行入口是org.openmetadata.service.apps.bundles.dataRetention.DataRetention类见 DataRetention.java它继承AbstractNativeApplication在startApp中调用executeCleanup依次执行各类清理任务。配置入口在哪里填写保留期限Data Retention 应用通过 OpenMetadata UI 的Settings → Applications应用市场安装/启用。在应用的配置面板中表单的每个输入字段对应的就是本文档描述的各个保留参数。DataRetentionApplication.md正是这一配置表单的字段说明locale 文案每个字段以$$section包裹并通过$(id...)绑定到对应的 JSON 配置键名。这些字段对应的配置结构体定义在 dataRetentionConfiguration.json应用启动时由 DataRetention.java 通过JsonUtils.convertValue将 UI 提交的配置反序列化为DataRetentionConfiguration对象。若配置为空应用会记录警告No retention policy configuration provided. Cleanup tasks will not run.并跳过清理。八个保留参数逐一详解下表汇总了全部配置字段的键名、含义、Schema 默认值与取值范围随后逐个展开。配置键id控制的数据Schema 默认值取值范围约束changeEventRetentionPeriod变更事件记录含成功发送的事件、消费者 DLQ7 天整数最小 1必填activityThreadsRetentionPeriod类型为Conversation的活动线程60 天整数最小 0必填activityCommentsRetentionPeriod活动事件上的评论0 天永久保留整数最小 0必填testCaseResultsRetentionPeriod测试用例结果时间序列1440 天整数必填profileDataRetentionPeriodProfiler 采集的 Profile 数据时间序列1440 天整数必填auditLogRetentionPeriod审计日志条目90 天整数最小 1必填workflowRetentionPeriod自动化工作流记录测试连接、查询运行器、反向摄取30 天整数最小 0非必填extensions基于 OpenMetadata 构建的分发版贡献的扩展清理保留期{}空 Map键为扩展名值为天数1. Change Event Retention Period (days)$(idchangeEventRetentionPeriod)控制变更事件记录的保留天数例如 7 代表保留一周、30 代表一个月。Schema 默认值为 7最小值为 1不允许设置为 0。在底层这个参数一次驱动三类表的清理见 DataRetention.javasuccessful_sent_change_events已成功发送给订阅消费者的变更事件change_events通用的变更事件记录consumers_dlq投递失败进入死信队列DLQ的事件。三者都通过eventSubscriptionDAO的delete*InBatches(cutoffMillis, BATCH_SIZE)以批量方式删除。2. Activity Threads Retention Period (days)$(idactivityThreadsRetentionPeriod)控制类型为Conversation的活动线程记录保留天数如 30 对应一个月、60 对应两个月。Schema 默认值 60最小 0。底层由 cleanActivityThreads 调用ConversationRepository.deleteExpiredUserConversations实现事务内批量执行。3. Activity Comments Retention Period (days)$(idactivityCommentsRetentionPeriod)控制活动事件上评论的保留天数。设置为 0 表示永久保留评论。Schema 默认值即为 0。底层由cleanActivityComments调用ConversationRepository.deleteExpiredActivityConversations实现见 DataRetention.java。4. Test Case Results Retention Period (days)$(idtestCaseResultsRetentionPeriod)控制数据质量测试用例结果Test Case Results的保留天数默认值 1440约 4 年。底层由cleanTestCaseResults调用testCaseResultsDAO.deleteRecordsBeforeCutOff按时间序列时间戳批量清理见 DataRetention.java。该 DAO 在构造函数中通过collectionDAO.testCaseResultTimeSeriesDao()注入。5. Profile Data Retention Period (days)$(idprofileDataRetentionPeriod)控制 profiler 采集的列/表 Profile 数据时间序列的保留天数默认值同样为 1440。底层由cleanProfileData调用profileDataDAO.deleteRecordsBeforeCutOff清理见 DataRetention.java。注意它与测试结果共用 1440 天的默认值若你的 profiler 调度频繁、采集量很大可适当调低以控制存储。6. Audit Log Retention Period (days)$(idauditLogRetentionPeriod)控制审计日志条目的保留天数默认 90约一个季度最小 1。底层由cleanAuditLogs调用auditLogDAO.deleteInBatches清理见 DataRetention.java。审计日志用于安全合规追溯设置过短可能导致无法回溯历史操作。7. Automation Workflow Retention Period (days)$(idworkflowRetentionPeriod)控制自动化工作流记录的保留天数。这些是测试连接test connection、查询运行器query runner和反向摄取reverse ingestion运行后留下的短期记录默认保留 30 天设置为 0 表示永久保留。这是实现上最特殊的一个参数工作流对象持有其运行所针对的服务连接信息如果仅用批量 SQL 删除行连接密钥会残留在外部密钥管理器中、所有者关系行也会遗留。因此底层不使用批量 SQL而是逐个通过仓库层Entity.deleteEntity删除见 DataRetention.java。每次删除都是一次仓库往返外加一次deleteSecretsFromWorkflow调用在 AWS/Azure 环境下会走网络访问外部密钥管理器因此单次运行设置了 10 万条MAX_WORKFLOW_DELETES_PER_RUN的上限首次运行积累的大量积压会被分摊到后续多次周任务中避免长时间运行触发密钥服务商的限流。8. Extension Retention Periods (days)$(idextensions)为基于 OpenMetadata 构建的分发版如商业发行版、下游 fork通过扩展机制贡献的清理任务设置保留期键为扩展名。Schema 中明确指出OpenMetadata never reads these values; it hands them to the registered DataRetentionExtension, which decides what a missing key means.—— OpenMetadata 本身不读取这些值而是将它们交给注册的扩展由扩展自行决定缺失某个键时的行为通常回退到扩展自带的默认值。应用的默认配置与调度方式应用的注册数据定义在 DataRetentionApplication.json它同时给出了开箱即用的默认保留策略{ name: DataRetentionApplication, displayName: Data Retention, appConfiguration: { changeEventRetentionPeriod: 7, activityThreadsRetentionPeriod: 60, activityCommentsRetentionPeriod: 0, profileDataRetentionPeriod: 1440, testCaseResultsRetentionPeriod: 1440, auditLogRetentionPeriod: 90, workflowRetentionPeriod: 30 }, appSchedule: { scheduleTimeline: Custom, cronExpression: 0 0 * * 0 } }调度上应用使用Custom时间线cron 表达式为0 0 * * 0即每周日零点执行一次全量清理。市场定义DataRetentionApplication.json中scheduleType为ScheduledOrManualpermission为Allruntime.enabled为trueclassName指向org.openmetadata.service.apps.bundles.dataRetention.DataRetention—— 也就是说除了按计划自动运行管理员也可以在 UI 中手动触发一次清理。保留语义的两个关键细节0 或缺失 永久保留activityThreadsRetentionPeriod、activityCommentsRetentionPeriod、workflowRetentionPeriod三个字段的值为 0 或未配置null时不执行对应清理数据永久保留。实现中的判定函数位于 DataRetention.javastatic boolean isRetentionEnabled(Integer retentionPeriod) { return retentionPeriod ! null retentionPeriod 0; }这一语义在 DataRetentionTest.java 中被测试锁定null和0均判定为不启用1及以上才启用。而changeEventRetentionPeriod、auditLogRetentionPeriod在 Schema 中最小值为 1因此不允许用 0 关闭清理。字段的必填与向后兼容Schema 的required列表包含除workflowRetentionPeriod和extensions外的全部字段。workflowRetentionPeriod故意不作为必填项这样在它被引入之前保存的应用配置在反序列化时会回退到 Schema 默认值 30 而不是 null。对应的测试workflowRetentionFallsBackToDefaultForConfigsSavedWithoutIt见 DataRetentionTest.java验证了仅配置{changeEventRetentionPeriod: 7}时getWorkflowRetentionPeriod()返回 30。底层执行流程一次运行做了什么executeCleanup见 DataRetention.java定义了单次运行的完整清理顺序分为两大部分第一阶段数据一致性清理与保留天数无关每次必跑孤立关系与损坏的服务层级通过EntityRelationshipCleanupUtil清理entity_relationship表中的孤立关系并删除指向已删除服务的损坏实体database、dashboard、api、messaging、pipeline、storage、mlmodel、search 等类型删除数按服务类型分别统计孤立标签使用TagUsageCleanup孤立测试用例清理entityLink指向已删除实体的测试用例缺少关系的测试用例清理缺少 testDefinition 关系会破坏搜索索引或缺少可执行测试套件的测试用例孤立的摄取管道清理容器服务/测试套件CONTAINS 关系已消失、永远无法运行且会破坏搜索索引的摄取管道孤立的时序行清理测试用例解析状态、Agent 执行记录、MCP 执行记录、孤立 Profile 数据与查询成本时序等孤儿行。第二阶段按保留期限的定时清理按顺序执行变更事件、活动线程、活动评论、测试用例结果、Profile 数据、审计日志、自动化工作流最后运行扩展清理。所有清理都以 10,000 行BATCH_SIZE为一批次循环排空drain每批删除数不足一个批次即认为排空完成自动化工作流清理则采用零进度即停止的判定防止某条永远删不掉的数据阻塞整个排空相关行为被aPoisonRowDoesNotStopTheWorkflowDrain测试固化见 DataRetentionTest.java。每次清理的成功/失败行数都会通过updateStats记录到Stats结构jobStats汇总 entityStats按实体分类运行结束后通过AppRunRecord持久化并通过 WebSocket 向data_retention_app_channel广播便于 UI 实时展示运行统计。扩展机制为自有表接入同一套清理管道extensions参数配合DataRetentionExtensionSPI 使用。该接口定义在 DataRetentionExtension.java基于 OpenMetadata 构建的分发版可注册实现通过META-INF/services/...DataRetentionExtension使其自有数据表也能被同一个调度任务、以同样的批处理、统计与失败上报方式清理而 OpenMetadata 无需知道这些表的存在。name()扩展的稳定标识同时作为extensionsMap 的键与日志标识要求跨 provider 唯一且不可随意变更steps(configuration)返回该扩展贡献的清理步骤RetentionStep每个步骤含统计键与批量删除函数按顺序执行retentionPeriodDays(configuration, defaultDays)读取管理员在extensions.name下配置的天数未配置时回退到扩展自带默认值 —— 这正是文档中Leave a key out to use whatever default that extension defines省略某个键即使用该扩展定义的默认值的实现依据。DataRetentionExtensionRegistry见 DataRetentionExtensionRegistry.java通过ServiceLoader发现 classpath 上的扩展并对发现、实例化、贡献步骤三个阶段做了全面防御单个损坏的注册/扩展会被跳过内置清理与其余扩展照常运行运行状态标记为ACTIVE_ERROR并记录首个失败详情。扩展清理始终在全部内置清理之后执行因此即使某次运行中途失败OpenMetadata 自身数据表的清理结果也已得到保证。配置建议与注意事项结合 Schema 约束与实现行为给出以下实践要点变更事件建议保持较短周期默认 7 天即适合多数场景变更事件仅用于通知与审计追溯长期积累收益有限测试结果与 Profile 数据按需裁剪两者默认 1440 天约 4 年如果数据质量与 profiler 任务高频运行且存储紧张可调低到 180365 天审计日志兼顾合规默认 90 天若组织有更长的审计追溯要求应调大注意最小值为 1不可设为 0 关闭0 值语义只对线程、评论、工作流三类生效这三个字段为 0 时数据永久保留其余字段最小值为 1首次启用注意工作流积压自动化工作流清理单次有 10 万条上限历史积压会跨多个周任务逐步消化属预期行为可在应用的运行统计automation_workflows等实体统计键中观察进度修改保留期限立即生效配置在每次运行时读取init阶段反序列化调整参数后下一次调度即按新值执行也可在 UI 中手动触发一次运行验证效果。相关资源配置字段说明本文档DataRetentionApplication.md配置 JSON Schema默认值与约束dataRetentionConfiguration.json应用注册与默认配置/调度DataRetentionApplication.json应用市场定义DataRetentionApplication.json核心实现DataRetention.java扩展 SPIDataRetentionExtension.java扩展注册与防御式发现DataRetentionExtensionRegistry.java清理步骤模型RetentionStep.java保留语义与排空行为测试DataRetentionTest.java【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenMetadata Data Retention 应用配置指南：为每种实体精细化设置数据库保留策略
OpenMetadata Data Retention 应用配置指南为每种实体精细化设置数据库保留策略【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata导读Data Retention数据保留是 OpenMetadata 内置的自动化应用负责按管理员定义的保留期限定期清理服务端内部数据库中的过期记录防止变更事件、活动线程、测试结果、Profile 数据、审计日志等随时间持续膨胀拖垮数据库性能。本文以 DataRetentionApplication.md 中定义的 8 个配置字段为主线结合 JSON Schema、应用注册配置与 Java 实现源码完整讲解每个保留参数的语义、默认值、取值范围及其在底层清理流程中的实际作用并给出可直接落地的配置建议。Data Retention 应用在 OpenMetadata 中扮演什么角色OpenMetadata 的服务端会持续产生大量过程性数据每次元数据变更产生的 change event、用户对话产生的活动线程与评论、数据质量测试的运行结果、profiler 采集的 Profile 时间序列、审计日志以及测试连接、查询运行器、反向摄取等自动化工作流留下的短期记录。这些数据若不清理会随运行时间线性增长拖慢查询、增加备份体积。Data Retention 应用正是为此而生它作为一个原生internal应用注册在 OpenMetadata 中按固定调度周期运行依据管理员配置的保留期限批量删除过期记录。其市场定义在 DataRetentionApplication.json 中明确说明The Data Retention App automates the cleanup of OpenMetadatas internal database to maintain performance and efficiency... prevents data bloat by removing outdated records.自动清理内部数据库以维持性能与效率通过删除过期记录防止数据膨胀。应用的实际执行入口是org.openmetadata.service.apps.bundles.dataRetention.DataRetention类见 DataRetention.java它继承AbstractNativeApplication在startApp中调用executeCleanup依次执行各类清理任务。配置入口在哪里填写保留期限Data Retention 应用通过 OpenMetadata UI 的Settings → Applications应用市场安装/启用。在应用的配置面板中表单的每个输入字段对应的就是本文档描述的各个保留参数。DataRetentionApplication.md正是这一配置表单的字段说明locale 文案每个字段以$$section包裹并通过$(id...)绑定到对应的 JSON 配置键名。这些字段对应的配置结构体定义在 dataRetentionConfiguration.json应用启动时由 DataRetention.java 通过JsonUtils.convertValue将 UI 提交的配置反序列化为DataRetentionConfiguration对象。若配置为空应用会记录警告No retention policy configuration provided. Cleanup tasks will not run.并跳过清理。八个保留参数逐一详解下表汇总了全部配置字段的键名、含义、Schema 默认值与取值范围随后逐个展开。配置键id控制的数据Schema 默认值取值范围约束changeEventRetentionPeriod变更事件记录含成功发送的事件、消费者 DLQ7 天整数最小 1必填activityThreadsRetentionPeriod类型为Conversation的活动线程60 天整数最小 0必填activityCommentsRetentionPeriod活动事件上的评论0 天永久保留整数最小 0必填testCaseResultsRetentionPeriod测试用例结果时间序列1440 天整数必填profileDataRetentionPeriodProfiler 采集的 Profile 数据时间序列1440 天整数必填auditLogRetentionPeriod审计日志条目90 天整数最小 1必填workflowRetentionPeriod自动化工作流记录测试连接、查询运行器、反向摄取30 天整数最小 0非必填extensions基于 OpenMetadata 构建的分发版贡献的扩展清理保留期{}空 Map键为扩展名值为天数1. Change Event Retention Period (days)$(idchangeEventRetentionPeriod)控制变更事件记录的保留天数例如 7 代表保留一周、30 代表一个月。Schema 默认值为 7最小值为 1不允许设置为 0。在底层这个参数一次驱动三类表的清理见 DataRetention.javasuccessful_sent_change_events已成功发送给订阅消费者的变更事件change_events通用的变更事件记录consumers_dlq投递失败进入死信队列DLQ的事件。三者都通过eventSubscriptionDAO的delete*InBatches(cutoffMillis, BATCH_SIZE)以批量方式删除。2. Activity Threads Retention Period (days)$(idactivityThreadsRetentionPeriod)控制类型为Conversation的活动线程记录保留天数如 30 对应一个月、60 对应两个月。Schema 默认值 60最小 0。底层由 cleanActivityThreads 调用ConversationRepository.deleteExpiredUserConversations实现事务内批量执行。3. Activity Comments Retention Period (days)$(idactivityCommentsRetentionPeriod)控制活动事件上评论的保留天数。设置为 0 表示永久保留评论。Schema 默认值即为 0。底层由cleanActivityComments调用ConversationRepository.deleteExpiredActivityConversations实现见 DataRetention.java。4. Test Case Results Retention Period (days)$(idtestCaseResultsRetentionPeriod)控制数据质量测试用例结果Test Case Results的保留天数默认值 1440约 4 年。底层由cleanTestCaseResults调用testCaseResultsDAO.deleteRecordsBeforeCutOff按时间序列时间戳批量清理见 DataRetention.java。该 DAO 在构造函数中通过collectionDAO.testCaseResultTimeSeriesDao()注入。5. Profile Data Retention Period (days)$(idprofileDataRetentionPeriod)控制 profiler 采集的列/表 Profile 数据时间序列的保留天数默认值同样为 1440。底层由cleanProfileData调用profileDataDAO.deleteRecordsBeforeCutOff清理见 DataRetention.java。注意它与测试结果共用 1440 天的默认值若你的 profiler 调度频繁、采集量很大可适当调低以控制存储。6. Audit Log Retention Period (days)$(idauditLogRetentionPeriod)控制审计日志条目的保留天数默认 90约一个季度最小 1。底层由cleanAuditLogs调用auditLogDAO.deleteInBatches清理见 DataRetention.java。审计日志用于安全合规追溯设置过短可能导致无法回溯历史操作。7. Automation Workflow Retention Period (days)$(idworkflowRetentionPeriod)控制自动化工作流记录的保留天数。这些是测试连接test connection、查询运行器query runner和反向摄取reverse ingestion运行后留下的短期记录默认保留 30 天设置为 0 表示永久保留。这是实现上最特殊的一个参数工作流对象持有其运行所针对的服务连接信息如果仅用批量 SQL 删除行连接密钥会残留在外部密钥管理器中、所有者关系行也会遗留。因此底层不使用批量 SQL而是逐个通过仓库层Entity.deleteEntity删除见 DataRetention.java。每次删除都是一次仓库往返外加一次deleteSecretsFromWorkflow调用在 AWS/Azure 环境下会走网络访问外部密钥管理器因此单次运行设置了 10 万条MAX_WORKFLOW_DELETES_PER_RUN的上限首次运行积累的大量积压会被分摊到后续多次周任务中避免长时间运行触发密钥服务商的限流。8. Extension Retention Periods (days)$(idextensions)为基于 OpenMetadata 构建的分发版如商业发行版、下游 fork通过扩展机制贡献的清理任务设置保留期键为扩展名。Schema 中明确指出OpenMetadata never reads these values; it hands them to the registered DataRetentionExtension, which decides what a missing key means.—— OpenMetadata 本身不读取这些值而是将它们交给注册的扩展由扩展自行决定缺失某个键时的行为通常回退到扩展自带的默认值。应用的默认配置与调度方式应用的注册数据定义在 DataRetentionApplication.json它同时给出了开箱即用的默认保留策略{ name: DataRetentionApplication, displayName: Data Retention, appConfiguration: { changeEventRetentionPeriod: 7, activityThreadsRetentionPeriod: 60, activityCommentsRetentionPeriod: 0, profileDataRetentionPeriod: 1440, testCaseResultsRetentionPeriod: 1440, auditLogRetentionPeriod: 90, workflowRetentionPeriod: 30 }, appSchedule: { scheduleTimeline: Custom, cronExpression: 0 0 * * 0 } }调度上应用使用Custom时间线cron 表达式为0 0 * * 0即每周日零点执行一次全量清理。市场定义DataRetentionApplication.json中scheduleType为ScheduledOrManualpermission为Allruntime.enabled为trueclassName指向org.openmetadata.service.apps.bundles.dataRetention.DataRetention—— 也就是说除了按计划自动运行管理员也可以在 UI 中手动触发一次清理。保留语义的两个关键细节0 或缺失 永久保留activityThreadsRetentionPeriod、activityCommentsRetentionPeriod、workflowRetentionPeriod三个字段的值为 0 或未配置null时不执行对应清理数据永久保留。实现中的判定函数位于 DataRetention.javastatic boolean isRetentionEnabled(Integer retentionPeriod) { return retentionPeriod ! null retentionPeriod 0; }这一语义在 DataRetentionTest.java 中被测试锁定null和0均判定为不启用1及以上才启用。而changeEventRetentionPeriod、auditLogRetentionPeriod在 Schema 中最小值为 1因此不允许用 0 关闭清理。字段的必填与向后兼容Schema 的required列表包含除workflowRetentionPeriod和extensions外的全部字段。workflowRetentionPeriod故意不作为必填项这样在它被引入之前保存的应用配置在反序列化时会回退到 Schema 默认值 30 而不是 null。对应的测试workflowRetentionFallsBackToDefaultForConfigsSavedWithoutIt见 DataRetentionTest.java验证了仅配置{changeEventRetentionPeriod: 7}时getWorkflowRetentionPeriod()返回 30。底层执行流程一次运行做了什么executeCleanup见 DataRetention.java定义了单次运行的完整清理顺序分为两大部分第一阶段数据一致性清理与保留天数无关每次必跑孤立关系与损坏的服务层级通过EntityRelationshipCleanupUtil清理entity_relationship表中的孤立关系并删除指向已删除服务的损坏实体database、dashboard、api、messaging、pipeline、storage、mlmodel、search 等类型删除数按服务类型分别统计孤立标签使用TagUsageCleanup孤立测试用例清理entityLink指向已删除实体的测试用例缺少关系的测试用例清理缺少 testDefinition 关系会破坏搜索索引或缺少可执行测试套件的测试用例孤立的摄取管道清理容器服务/测试套件CONTAINS 关系已消失、永远无法运行且会破坏搜索索引的摄取管道孤立的时序行清理测试用例解析状态、Agent 执行记录、MCP 执行记录、孤立 Profile 数据与查询成本时序等孤儿行。第二阶段按保留期限的定时清理按顺序执行变更事件、活动线程、活动评论、测试用例结果、Profile 数据、审计日志、自动化工作流最后运行扩展清理。所有清理都以 10,000 行BATCH_SIZE为一批次循环排空drain每批删除数不足一个批次即认为排空完成自动化工作流清理则采用零进度即停止的判定防止某条永远删不掉的数据阻塞整个排空相关行为被aPoisonRowDoesNotStopTheWorkflowDrain测试固化见 DataRetentionTest.java。每次清理的成功/失败行数都会通过updateStats记录到Stats结构jobStats汇总 entityStats按实体分类运行结束后通过AppRunRecord持久化并通过 WebSocket 向data_retention_app_channel广播便于 UI 实时展示运行统计。扩展机制为自有表接入同一套清理管道extensions参数配合DataRetentionExtensionSPI 使用。该接口定义在 DataRetentionExtension.java基于 OpenMetadata 构建的分发版可注册实现通过META-INF/services/...DataRetentionExtension使其自有数据表也能被同一个调度任务、以同样的批处理、统计与失败上报方式清理而 OpenMetadata 无需知道这些表的存在。name()扩展的稳定标识同时作为extensionsMap 的键与日志标识要求跨 provider 唯一且不可随意变更steps(configuration)返回该扩展贡献的清理步骤RetentionStep每个步骤含统计键与批量删除函数按顺序执行retentionPeriodDays(configuration, defaultDays)读取管理员在extensions.name下配置的天数未配置时回退到扩展自带默认值 —— 这正是文档中Leave a key out to use whatever default that extension defines省略某个键即使用该扩展定义的默认值的实现依据。DataRetentionExtensionRegistry见 DataRetentionExtensionRegistry.java通过ServiceLoader发现 classpath 上的扩展并对发现、实例化、贡献步骤三个阶段做了全面防御单个损坏的注册/扩展会被跳过内置清理与其余扩展照常运行运行状态标记为ACTIVE_ERROR并记录首个失败详情。扩展清理始终在全部内置清理之后执行因此即使某次运行中途失败OpenMetadata 自身数据表的清理结果也已得到保证。配置建议与注意事项结合 Schema 约束与实现行为给出以下实践要点变更事件建议保持较短周期默认 7 天即适合多数场景变更事件仅用于通知与审计追溯长期积累收益有限测试结果与 Profile 数据按需裁剪两者默认 1440 天约 4 年如果数据质量与 profiler 任务高频运行且存储紧张可调低到 180365 天审计日志兼顾合规默认 90 天若组织有更长的审计追溯要求应调大注意最小值为 1不可设为 0 关闭0 值语义只对线程、评论、工作流三类生效这三个字段为 0 时数据永久保留其余字段最小值为 1首次启用注意工作流积压自动化工作流清理单次有 10 万条上限历史积压会跨多个周任务逐步消化属预期行为可在应用的运行统计automation_workflows等实体统计键中观察进度修改保留期限立即生效配置在每次运行时读取init阶段反序列化调整参数后下一次调度即按新值执行也可在 UI 中手动触发一次运行验证效果。相关资源配置字段说明本文档DataRetentionApplication.md配置 JSON Schema默认值与约束dataRetentionConfiguration.json应用注册与默认配置/调度DataRetentionApplication.json应用市场定义DataRetentionApplication.json核心实现DataRetention.java扩展 SPIDataRetentionExtension.java扩展注册与防御式发现DataRetentionExtensionRegistry.java清理步骤模型RetentionStep.java保留语义与排空行为测试DataRetentionTest.java【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考