企业官网建设流程全解析

OpenMetadata Data Insights 应用配置指南：DataInsightsAppConfig 全参数详解与源码实现解析

【免费下载链接】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 Insights（数据洞察）是 OpenMetadata 内置的本地应用（Native Application），负责周期性汇总元数据，生成数据资产快照、应用分析与成本分析三类洞察数据。本文围绕其配置模型DataInsightsAppConfig展开，逐项讲解batchSize、recreateDataAssetsIndex、backfillConfiguration与moduleConfiguration等全部参数的语义、默认值与实战场景，并结合仓库源码说明每个参数在应用执行链路中的真实作用，帮助读者在部署 OpenMetadata 后正确配置与排障 Data Insights 应用。

DataInsightsAppConfig 是什么

DataInsightsAppConfig是 OpenMetadata 中 Data Insights 应用的配置 Schema，完整定义位于 dataInsightsAppConfig.json。该 Schema 属于"内部应用配置"（configuration/internal），即配置逻辑由后端（Java 服务端）处理，前端仅负责提供可视化编辑表单。

在 OpenMetadata 中，Data Insights 应用通过应用市场（App Marketplace）定义注册，其内置定义见 DataInsightsApplication.json，应用实例的默认配置见 DataInsightsApplication.json（app 目录）。两份 JSON 给出了该应用的出厂默认配置：

{ "name": "DataInsightsApplication", "displayName": "Data Insights", "appConfiguration": { "batchSize": 100, "recreateDataAssetsIndex": false, "backfillConfiguration": { "enabled": false }, "moduleConfiguration": { "dataAssets": { "enabled": true, "entities": ["all"], "retention": 90 }, "appAnalytics": { "enabled": true }, "costAnalysis": { "enabled": true } } }, "appSchedule": { "scheduleTimeline": "Custom", "cronExpression": "0 3 * * *" } }

可见应用默认按 Cron 表达式0 3 * * *（每天凌晨 3 点）调度执行，三个分析模块默认全部开启。应用的实际执行入口是 DataInsightsApp.java，在init方法中通过JsonUtils.convertValue将前端保存的配置反序列化为DataInsightsAppConfig，再经JsonUtils.validateJsonSchema做 Schema 校验，随后把配置拆分给三个工作流模块使用。这意味着：只要配置不满足 Schema 约束（例如模块配置缺失必填项、出现未知属性），应用将无法完成初始化。

顶层参数详解

batchSize：单批处理的最大事件数

"batchSize": 100

batchSize定义应用每次处理的最大事件（实体）数量，Schema 中默认值为 100，最小值为 0。在 DataInsightsApp.java 中，该值被直接读取并赋值给成员变量batchSize：

batchSize = config.getBatchSize();

随后它被传入三个工作流（WebAnalyticsWorkflow、CostAnalysisWorkflow、DataAssetsWorkflow），作为PaginatedEntitiesSource分页读取数据库实体的每页大小，即每次从数据库取回一批实体、处理完再取下一批。调大该值可减少数据库往返次数、提升吞吐，但会增大单批内存占用；在实体量极大的环境中，需要结合服务端可用内存与数据库连接池大小权衡。

值得注意的源码细节：DataAssetsWorkflow在 computeConcurrencyBudget 中会根据 CPU 核数、数据库连接池大小（dataSourceFactory.getMaxSize()）以及AsyncOperationsConfiguration.dataInsightsMaxConcurrentDbTasks计算并发预算，并使用虚拟线程（virtual threads）配合Semaphore并行处理同一批实体，最后统一 flush 到搜索索引。因此batchSize与并发预算共同决定数据资产快照的处理速度。

recreateDataAssetsIndex：重建 DataAssets 数据流

"recreateDataAssetsIndex": false

recreateDataAssetsIndex（UI 中显示为 "Recreate DataInsights DataAssets Index"）用于强制重建Data Insights 的数据资产索引。文档明确警告：重建索引会删除已有的 DataAssets 数据，且重建后必须重新执行 Backfill（回填），否则历史数据将丢失。

其适用场景是：当你修改了自定义属性（Custom Property）的类型并因此遇到索引映射（mapping）错误时，可通过该开关重建索引以恢复可用。

从源码看，该开关仅在手动触发（on-demand）运行时生效。在 DataInsightsApp.java 中：

String runType = (String) jobExecutionContext.getJobDetail().getJobDataMap().get(TRIGGER_TYPE_KEY); if (!runType.equals(ON_DEMAND_JOB)) { backfill = Optional.empty(); recreateDataAssetsIndex = Optional.empty(); } if (recreateDataAssetsIndex.isPresent() && recreateDataAssetsIndex.get().equals(true)) { deleteDataAssetsDataStream(); createOrUpdateDataAssetsDataStream(); }

即：定时调度触发的运行会忽略该开关，只有通过 UI/API 手动触发运行时才执行"先删除全部 DataAssets 数据流、再按当前索引映射重建"的操作。重建逻辑由 deleteDataAssetsDataStream 与 createOrUpdateDataAssetsDataStream 实现，涉及对 Elasticsearch / OpenSearch 中di-data-assets-*前缀数据流（Data Stream）的删除与重建。

backfillConfiguration：历史数据回填

"backfillConfiguration": { "enabled": false }

backfillConfiguration用于配置数据回填（Backfill），即对过去某个日期区间重新计算并写入洞察数据，通常用于修复历史数据缺失或索引重建后的数据恢复。该对象包含三个子字段：

在 DataInsightsApp.java 中，仅当enabled为true时，startDate与endDate才会被封装为Backfill记录并传给工作流：

if (backfillConfig.isPresent() && backfillConfig.get().getEnabled()) { backfill = Optional.of(new Backfill(backfillConfig.get().getStartDate(), backfillConfig.get().getEndDate())); }

与recreateDataAssetsIndex一样，Backfill 同样只在手动触发运行时生效（定时运行时backfill会被置空）。底层时间处理可参考 TimestampUtils。

需要说明的实现边界：从源码看，回填能力目前主要作用于 Data Assets 模块。DataAssetsWorkflow会解析 Backfill 区间，并将开始日期钳制在"当前日期前 30 天"这一内部保留窗口内——若配置的起始日期早于该窗口，会打印告警日志且实际不回填更早的数据（见 DataAssetsWorkflow.java）。而CostAnalysisWorkflow中的 Backfill 逻辑目前仍以 TODO 注释形式存在（见 CostAnalysisWorkflow.java），从源码结构看尚未实现完整回填。配置前应结合当前版本实际行为评估。

moduleConfiguration：三大分析模块

moduleConfiguration是应用的核心配置区，包含dataAssets、appAnalytics、costAnalysis三个子模块，Schema 中三者均为必填（"required": ["dataAssets", "appAnalytics", "costAnalysis"]），且additionalProperties: false，不允许出现未知子模块。三个模块在运行时被分别解析为DataAssetsConfig、AppAnalyticsConfig、CostAnalysisConfig，并对应三条独立执行链：

• processWebAnalytics()→WebAnalyticsWorkflow
• processCostAnalysis()→CostAnalysisWorkflow
• processDataAssets()→DataAssetsWorkflow

三个工作流按顺序依次执行（先 Web Analytics，再 Cost Analysis，最后 Data Assets），任一模块失败会汇总错误信息并置任务为FAILED状态（见 DataInsightsApp.java）。

dataAssets：数据资产洞察模块

dataAssets是三个模块中配置项最丰富的一个，控制数据资产快照的生成。Schema 定义见 dataInsightsAppConfig.json，包含四个子配置：

Enabled：是否生成数据资产洞察

"enabled": true

布尔值，默认true。若为false，DataAssetsWorkflow.process()会直接返回，不执行任何快照逻辑（见 DataAssetsWorkflow.java）。

Entities：需要重建索引的实体列表

"entities": ["all"]

字符串数组，默认["all"]，且要求元素唯一（uniqueItems: true）。文档说明其含义为"需要重建索引（reindex）的实体列表"。从源码看，"all"是通配值：当列表等于Set.of("all")时，该应用支持的所有数据资产类型都会被处理；否则只处理列表中列出的实体类型（见 DataAssetsWorkflow.java）。

哪些实体类型可用？DataInsightsApp提供了 getDataAssetTypes 方法，它枚举DataAssetType的全部取值，并剔除那些通过索引别名（alias）映射到实时索引的>"retention": 90

整数，默认 90，最小 0。定义 Data Assets 洞察信息在搜索索引中的保留天数，超过该期限的记录会在每次运行时被删除。在DataAssetsWorkflow中，每次处理某个实体类型的数据流前，会调用 deleteBasedOnDataRetentionPolicy，通过deleteByRangeQuery删除@timestamp早于"当前时间 − retention 天"的旧记录：

long retentionLimitTimestamp = TimestampUtils.subtractDays(System.currentTimeMillis(), dataAssetsConfig.getRetention()); searchRepository.getSearchClient().deleteByRangeQuery(dataStreamName, "@timestamp", null, null, null, retentionLimitTimestamp);

同时，该保留天数也会在创建 Data Assets 数据流时写入索引生命周期配置（见DataInsightsApp.createOrUpdateDataAssetsDataStream中对dataAssetsConfig.getRetention()的使用）。

serviceFilter：按服务过滤

"serviceFilter": { "serviceType": "", "serviceName": "" }

serviceFilter用于将数据资产快照限定到特定类型的特定服务，包含serviceType（服务类型，如Mysql、Snowflake）与serviceName（服务名称）两个字段。配置逻辑上有两个重要约束：

1. 必须同时提供serviceType与serviceName。在 DataInsightsApp.parseDataAssetsConfig 中，若只填写了其中一个，整个serviceFilter会被置空（相当于不启用过滤）：

if (config.getServiceFilter() != null && (config.getServiceFilter().getServiceName() == null || config.getServiceFilter().getServiceType() == null)) { return config.withServiceFilter(null); }

2. 过滤生效的机制：在DataAssetsWorkflow中，serviceType用于推导该类型服务下可处理的实体类型集合（Entity.getEntityTypeInService(serviceType)，见 getEntityTypesToProcess），serviceName则作为查询参数过滤实体列表，并在写入前按service.name.keyword精确删除该服务在目标时间窗内的旧快照（见 getListFilter 与 deleteDataBeforeInserting）。

注意：dataProduct实体不支持软删除过滤，会使用Include.ALL单独处理。

appAnalytics：应用分析模块

"appAnalytics": { "enabled": true }

App Analytics模块配置，仅有enabled一个布尔字段，默认true。开启后，应用运行时会采集用户与数据资产交互行为（如浏览、搜索、使用等），生成应用分析洞察数据。对应的工作流为 WebAnalyticsWorkflow，在DataInsightsApp.startApp中作为第一个模块被调用。

costAnalysis：成本分析模块

"costAnalysis": { "enabled": true }

Cost Analysis模块配置，同样仅有enabled字段，默认true。开启后，应用会基于数据库服务下的表实体，结合生命周期（LifeCycle）与表大小等元数据生成成本分析报告。对应工作流为 CostAnalysisWorkflow。

从源码结构看，成本分析目前仅支持BigQuery、Redshift、Snowflake三种数据库服务类型（见 CostAnalysisWorkflow.databaseServiceSupportsProfilerAndUsage），其他类型的服务会被过滤跳过。处理结果分为两类写入报告数据（ReportData）时序表：

• RAW_COST_ANALYSIS_REPORT_DATA：原始成本分析数据，只保留最近一次快照（每次运行前先整体删除）；
• AGGREGATED_COST_ANALYSIS_REPORT_DATA：聚合成本分析数据，按天保留，每次运行前删除本次处理日期区间内的旧记录。

配置的加载与校验流程

完整的配置加载链路可归纳如下：

1. 前端表单保存：用户通过 UI 的 Applications 页面编辑 Data Insights 应用配置，保存为appConfigurationJSON。
2. 后端反序列化与校验：DataInsightsApp.init()将 JSON 转换为DataInsightsAppConfig，并执行 JSON Schema 校验（DataInsightsApp.java）。校验失败将直接阻断应用初始化。
3. 模块配置解析：分别解析costAnalysis、dataAssets、appAnalytics配置，其中dataAssets经过parseDataAssetsConfig的 serviceFilter 完整性校验（DataInsightsApp.java）。
4. 数据流就绪：createOrUpdateDataAssetsDataStream()确保每个数据资产类型对应的di-data-assets-*数据流存在且映射（mapping）最新（DataInsightsApp.java）。
5. 调度执行：Quartz 调度器按appSchedule触发startApp，依次执行三个模块工作流；支持手动触发（此时 Backfill 与索引重建开关生效）。

此外，Data Insights 应用支持多节点部署下的分布式互斥：startApp首先尝试获取数据库级别的任务锁（native-app:data-insights，TTL 5 分钟），获取失败则跳过本次运行；运行期间通过 60 秒一次的心跳续租（见 DataInsightsApp.java 与 startLockHeartbeat），确保同一时刻只有一个服务端实例在执行 Data Insights 任务。

常见配置场景与注意事项

场景一：修改自定义属性类型后索引报错

当你修改了某个自定义属性（Custom Property）的数据类型，导致 Data Assets 索引映射与实际数据不兼容、应用运行报错时：

1. 手动触发一次 Data Insights 应用运行；
2. 在运行前将recreateDataAssetsIndex置为true；
3. 运行完成后将其改回false，并配置 Backfill（enabled: true+ 起始/结束日期）重新回填历史数据。

务必注意：该开关会先删除全部di-data-assets-*数据流再重建，未配置回填将导致历史数据资产快照丢失。

场景二：缩小数据资产快照范围

如果只关心某个特定数据库服务的数据资产，可在moduleConfiguration.dataAssets中设置：

{ "enabled": true, "entities": ["all"], "retention": 90, "serviceFilter": { "serviceType": "Snowflake", "serviceName": "production_warehouse" } }

serviceType与serviceName必须成对出现，缺失任一字段会导致过滤整体失效（回退为处理全部服务）。

场景三：临时关闭某个分析模块

当成本分析或应用分析模块因数据量、权限等原因不需要运行时，将其enabled置为false即可；对应工作流会在process()入口直接短路返回，不影响其他模块（见 CostAnalysisWorkflow.java 与 DataAssetsWorkflow.java）。

注意事项汇总

• backfillConfiguration与recreateDataAssetsIndex只在手动触发运行时生效，定时调度会自动忽略，这是源码层面明确的行为；
• Backfill 存在约 30 天的内部保留窗口，早于该窗口的起始日期不会生效（Data Assets 模块）；
• 成本分析模块当前仅支持 BigQuery、Redshift、Snowflake 三种服务类型；
• Data Insights 结果写入搜索索引（Elasticsearch / OpenSearch）的di-data-assets-*数据流，以及数据库中的报告数据（ReportData）时序表，配置修改后通常需要等待下一次调度或手动触发才会生效。

相关源码索引

• 配置 Schema：dataInsightsAppConfig.json
• 应用实现：DataInsightsApp.java
• 应用市场定义：DataInsightsApplication.json
• 默认实例配置：DataInsightsApplication.json
• 数据资产工作流：DataAssetsWorkflow.java
• 成本分析工作流：CostAnalysisWorkflow.java
• 应用分析工作流：WebAnalyticsWorkflow.java
• 时间工具：TimestampUtils.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