当然可以！在 Elementary Data 中，新鲜度（Freshness）用于监控数据表是否按预期频率被更新。你可以通过配置 freshness 测试来实现这一点。下面是配置新鲜度的基本方法： ### 1. 在 dbt 模型中添加新鲜度测试 在你的

schema.yml

或模型配置文件中，添加如下内容：

yaml models:   - name: <模型名称>     tests:       - elementary.freshness_anomalies:           timestamp_column: <时间戳字段>  # 必填，指定用于判断新鲜度的时间戳字段           # 可选参数           where_expression: <SQL表达式>   # 只对部分数据做新鲜度检测           time_bucket:                  # 默认按天分桶             period: day             count: 1           anomaly_sensitivity: 3        # 敏感度，数值越低越敏感

- `timestamp_column`：指定用于判断数据更新时间的字段，通常是表中的时间戳字段。 - `time_bucket`：设置检测的时间粒度，比如按天（day）、小时（hour）等。 - `anomaly_sensitivity`：调整检测的灵敏度，数值越低越容易触发异常告警。 详细参数说明可以参考官方文档：[freshness_anomalies 配置说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) ### 2. 自动化新鲜度监控（Elementary Cloud） 如果你使用的是 Elementary Cloud，系统会自动为所有数据源创建新鲜度监控，无需手动配置。你可以在 UI 中选择自动（基于机器学习）或手动（自定义 SLA）两种检测方式，并可调整灵敏度或直接设置 SLA 阈值。例如： - **自动模式**：系统根据历史数据自动学习更新频率，智能检测异常。 - **手动模式**：你可以直接设置“多久没更新就告警”，适合有固定更新周期的表。 详细说明见：[自动新鲜度监控](https://docs.elementary-data.com/features/anomaly-detection/automated-freshness) ### 3. dbt Source Freshness 集成 如果你想集成 dbt 的 source freshness 检查，可以在 dbt 1.8 及以上版本的

dbt_project.yml

文件中添加：

yaml flags:   source_freshness_run_project_hooks: True

这样 Elementary 会自动收集 source freshness 结果并展示在 UI 和告警中。对于低于 1.8 的版本，需要手动运行命令上传结果，具体见：[Collect dbt source freshness results](https://docs.elementary-data.com/oss/guides/collect-dbt-source-freshness) --- 如果你有具体的场景或需求，也可以补充说明，我可以帮你写出更详细的配置示例！

好的，下面我根据官方文档为你详细介绍

freshness_anomalies

的所有主要参数，并解答你关于 dbt Source Freshness 集成的问题。 --- ## 1.

elementary.freshness_anomalies

主要参数说明 你可以在模型的

tests

配置中使用这些参数：

yaml - elementary.freshness_anomalies:     timestamp_column: <字段名>           # 必填，用于判断新鲜度的时间戳字段     where_expression: <SQL表达式>        # 可选，只对部分数据做新鲜度检测     anomaly_sensitivity: <int>           # 可选，灵敏度，数值越低越敏感     detection_period:                    # 可选，检测周期       period: [hour|day|week|month]       count: <int>     training_period:                     # 可选，训练周期       period: [hour|day|week|month]       count: <int>     time_bucket:                         # 可选，分桶粒度，默认按天       period: [hour|day|week|month]       count: <int>     detection_delay:                     # 可选，检测延迟       period: [hour|day|week|month]       count: <int>     ignore_small_changes:                # 可选，忽略小幅度变化       spike_failure_percent_threshold: <int>       drop_failure_percent_threshold: <int>     anomaly_exclude_metrics: <SQL表达式>  # 可选，排除某些指标

参数解释： - `timestamp_column`：必填。用于判断数据更新时间的字段。 - `where_expression`：可选。只对满足条件的数据做新鲜度检测。 - `anomaly_sensitivity`：可选。灵敏度，数值越低越敏感，越容易报警。 - `detection_period`：可选。检测的时间范围，比如最近2天、1周等。 - `training_period`：可选。用于模型学习的历史数据范围，默认14天。 - `time_bucket`：可选。分桶粒度，比如每天、每小时等，默认是每天。 - `detection_delay`：可选。检测延迟，比如只检测到前一天的数据。 - `ignore_small_changes`：可选。设置阈值，忽略小幅度的变化，避免误报。 - `anomaly_exclude_metrics`：可选。排除某些指标不参与异常检测。 详细配置和用法可以参考官方文档：[freshness_anomalies 配置说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 2. dbt Source Freshness 集成是 Cloud 专属吗？ 不是，**dbt Source Freshness 集成并不是 Elementary Cloud 专属功能**，开源版（OSS）同样支持，只是集成方式略有不同： - **dbt 1.8 及以上版本**：只需在

dbt_project.yml

里加上

yaml   flags:     source_freshness_run_project_hooks: True

Elementary 就会自动收集 source freshness 结果，和其他测试一样展示在 UI 和告警中。 - **dbt 1.8 以下版本**：需要手动运行命令上传 source freshness 结果：

shell   edr run-operation upload-source-freshness --project-dir <你的项目路径>

这个命令需要在

dbt source freshness

之后、`edr monitor` 之前执行。 - **dbt Cloud 用户**：目前 Elementary 无法直接从 dbt Cloud 收集 source freshness 结果，但有社区用户提供了[解决方案建议](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688113609829869)。 详细说明见：[Collect dbt source freshness results](https://docs.elementary-data.com/oss/guides/collect-dbt-source-freshness) 和 [Cloud 相关说明](https://docs.elementary-data.com/cloud/guides/collect-source-freshness)。 --- 如有更具体的配置需求，欢迎继续提问！

@kapa.ai 参数说明，你没讲清楚作用和应用场景

好的，以下是基于官方文档和社区问答，对

elementary.freshness_anomalies

主要参数的详细说明，包括它们的作用和适用场景： --- ## 1.

timestamp_column

**作用**：指定用于判断数据更新时间的字段（如 `updated_at`、`etl_import_date` 等）。 **场景**：必须配置。用于分桶和计算每个时间段内的最新更新时间，是新鲜度检测的核心依据。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 2.

where_expression

**作用**：只对满足条件的数据做新鲜度检测。 **场景**：如果你只关心表中某一部分数据（如某个地区、某个类型），可以用 SQL 表达式筛选。例如：

yaml where_expression: "region = 'APAC'"

[参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 3.

anomaly_sensitivity

**作用**：控制检测的灵敏度，数值越低越敏感，越容易报警。 **场景**： - 数据非常关键，哪怕轻微延迟都要报警 → 设置较低的值（如 1 或 2）。 - 数据偶尔延迟可以接受 → 设置较高的值（如 3 或 4）。 [参考](https://slack.com/archives/C02CTC89LAX/p1703157711512959) --- ## 4.

detection_period

**作用**：指定检测的时间范围（如最近2天、1周等），只在这个范围内查找异常。 **场景**： - 只关心最近几天是否有异常 → 设置 `period: day, count: 2`。 - 关心最近一周 → `period: week, count: 1`。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 5.

training_period

**作用**：指定用于模型学习的历史数据范围，默认14天。 **场景**： - 数据有明显周期性（如周末不更新）→ 建议设置为 21 天或更长，让模型更好地学习周期性。 - 数据量小或变化不大 → 可以适当缩短。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 6.

time_bucket

**作用**：设置分桶粒度，比如每天、每小时等。 **场景**： - 数据每天更新 → `period: day, count: 1`（默认）。 - 数据每小时更新 → `period: hour, count: 1`。 - 数据每月更新 → `period: month, count: 1`。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 7.

detection_delay

**作用**：设置检测延迟，比如只检测到前一天的数据，避免“当天还没到点就误报”。 **场景**： - 数据每天凌晨更新，但检测任务在白天跑 → 可以设置 `detection_delay`，只检测到前一天，避免误报。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 8.

ignore_small_changes

**作用**：设置阈值，忽略小幅度的变化，避免误报。 **场景**： - 数据偶尔有小延迟但不影响业务 → 设置

spike_failure_percent_threshold

或 `drop_failure_percent_threshold`，只有大幅变化才报警。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- ## 9.

anomaly_exclude_metrics

**作用**：排除某些指标不参与异常检测。 **场景**： - 某些特殊情况下不希望某些数据点影响整体异常判断时使用。 [参考](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) --- 如果你有具体的业务场景，可以告诉我，我可以帮你推荐更合适的参数组合！

anomaly_sensitivity

的设置直接影响 Elementary 检测新鲜度异常的灵敏度。它的原理是基于标准差（Z-score）：默认值为 3，表示只有当数据点偏离均值超过 3 个标准差时才会被判定为异常。你可以这样理解： - **数值越低（如 2 或 1.5）**：检测会更敏感，更容易触发异常报警（即只要数据点稍微偏离历史均值就会报警）。 - **数值越高（如 4 或 5）**：检测会更宽松，只有极端偏离才会报警。 Elementary 推荐的默认值是 3，因为在正态分布下，约 99.7% 的数据都在 3 个标准差以内，超过这个范围通常被认为是异常。如果你希望更频繁地捕捉到小的异常，可以把

anomaly_sensitivity

调低，比如设置为 2 或 1.5。 如何判断设置多少能触发？ 你可以通过 Elementary 的“模拟配置”功能（Simulate Configuration）来直观查看不同灵敏度下，哪些数据点会被判定为异常。这个功能会展示历史数据在不同灵敏度下的检测结果，帮助你选择合适的数值。如果你在本地配置，可以多次调整参数并观察 Elementary 报告中的异常触发情况，找到适合你业务的灵敏度。 官方说明原文如下： > A sensitivity of 3 means that the expected range is within 3 standard deviations from the average of the training set. Smaller sensitivity means this range will be reduced and more values will be potentially flagged as anomalies. Larger values will have the opposite effect and will reduce the number of anomalies as the expected range will be larger. > — [anomaly_sensitivity 参数说明](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-sensitivity) 如果你想更明确地知道某个具体值会不会触发，可以先用默认值运行一次，然后根据 Elementary 的报告结果，逐步调整 `anomaly_sensitivity`，直到达到你期望的报警频率。[数据异常检测方法说明](https://docs.elementary-data.com/data-tests/data-anomaly-detection) 也有详细介绍。 目前，Elementary 没有提供“百分之百明确”的阈值表，因为每个数据集的分布不同，但你可以通过模拟和历史数据回测来找到最适合你的灵敏度设置。

在 Elementary Data（以及 dbt 项目）中，配置 test 的 yml 文件**通常写在每个模型（model）或数据源（source）对应的 yml 文件里**，比如

schema.yml

或 `sources.yml`。这些文件一般放在你的 dbt 项目的

models/

目录下，和模型 SQL 文件同级或同目录。 **命名方式**没有强制要求，常见的命名有： - `schema.yml`（最常见，适用于模型） - `sources.yml`（适用于 source 配置） - 也可以根据实际情况自定义，比如 `my_model_schema.yml`，只要是有效的 yml 文件名即可。 官方和社区说明： - “Elementary tests are implemented as dbt tests, so the configuration is on the same YML files where you defined native tests like

not_null

for example.” [Slack 官方答复](https://slack.com/archives/C02CTC89LAX/p1670241799990399) - 你可以在

models/example/schema.yml

这样的文件里配置 elementary 的 test。 [Slack 官方答复](https://slack.com/archives/C02CTC89LAX/p1649048906578539) 示例：

yaml version: 2  models:   - name: my_model     tests:       - elementary.freshness_anomalies:           timestamp_column: created_at

**总结**： - 推荐将 test 配置写在

schema.yml

或

sources.yml

文件中，放在对应模型或 source 的目录下。 - 文件名可以自定义，但

schema.yml

是最常见的命名方式。 如需进一步了解，可以参考 [dbt 官方文档关于 YML 配置](https://docs.getdbt.com/reference/resource-properties/tests)。

timestamp_column

字段**不一定非要是时间戳类型**，日期（date）类型的字段也是可以的。官方文档明确说明： > The best column for this would be an `updated_at`/`created_at`/`loaded_at` timestamp for each row (date type also works). > > — [timestamp_column 配置说明](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/timestamp-column) 也就是说，只要这个字段能代表每行数据的生成或更新时间，无论是

timestamp

还是

date

类型，都可以用来做

timestamp_column

配置。

根据你的需求（数据超过一天不更新就 error），Elementary 的

freshness_anomalies

测试本身是基于异常检测模型，不支持像 dbt source freshness 那样直接设置“超过一天就 error”的静态阈值。 官方和社区明确说明：如果你需要严格的 SLA（比如超过 24 小时就 error），建议用 dbt 的原生 freshness 检查，而不是 elementary 的 anomaly 检查[Slack 官方说明](https://slack.com/archives/C02CTC89LAX/p1687159731219839)。 但如果你还是希望用 elementary 的方式尽量接近你的需求，可以通过设置

time_bucket

为天，并将

anomaly_sensitivity

调低，让检测更敏感。示例配置如下：

yaml version: 2  models:   - name: dwd_daily_aditem_report_walmart     tests:       - elementary.freshness_anomalies:           timestamp_column: <你的时间字段>           time_bucket:             period: day             count: 1           anomaly_sensitivity: 1  # 越低越敏感，尽量接近“只要一天没更新就报错”           config:             severity: error

注意： -

<你的时间字段>

请替换为你表中实际用于判断更新时间的字段名（如 `updated_at`）。 - 这种方式不能保证和 dbt source freshness 一样“超过一天必定 error”，但会让检测尽量敏感，接近你的需求[参数说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies)。 如果你需要100%严格的“超过一天就 error”，建议直接用 dbt 的 source freshness 功能[Slack 官方说明](https://slack.com/archives/C02CTC89LAX/p1687159731219839)。

你说得对，elementary 的

freshness_anomalies

虽然不是严格的 SLA 阈值检测，但确实可以通过配置 `timestamp_column`，让它在数据不更新时自动检测并报错。官方和社区的说法是： 你只需要配置

freshness_anomalies

并指定 `timestamp_column`，如果数据没有按历史频率更新，测试就会 fail。它的机制是基于历史数据的分布自动判断“异常”，而不是你手动设定一个具体的时间阈值（比如 24 小时）[Slack 官方说明](https://slack.com/archives/C02CTC89LAX/p1687159731219839)。 配置示例：

yaml version: 2  models:   - name: dwd_daily_aditem_report_walmart     tests:       - elementary.freshness_anomalies:           timestamp_column: <你的时间字段>           time_bucket:             period: day             count: 1           anomaly_sensitivity: 1           config:             severity: error

-

<你的时间字段>

替换为你表中的实际更新时间字段。 - 这种配置会让 elementary 检测到只要数据没有像历史一样每天更新，就会 fail。 注意： elementary 的新鲜度检测不是绝对的“超过一天必定 error”，而是基于历史数据的更新频率自动判断异常。如果你的表本来就是每天更新，且突然有一天没更新，这个测试会 fail，达到你想要的效果。如果你的表本身更新频率不规律，建议用 dbt 的 source freshness 功能来实现严格的 SLA 检查[Slack 官方说明](https://slack.com/archives/C02CTC89LAX/p1687159731219839)。 如需进一步调整灵敏度，可以通过

anomaly_sensitivity

参数来实现，数值越低越敏感。

Elementary 通过分析你表的历史数据更新情况来“学习”模型的更新频率。具体来说： - 在你配置并运行

freshness_anomalies

测试时，Elementary 会根据你指定的

timestamp_column

字段，把数据按 `time_bucket`（如每天）分桶。 - 它会收集一段时间（比如默认14天或21天，取决于配置和产品版本）的历史数据，统计每个时间桶内的最大更新时间，然后计算这些时间间隔的分布。 - Elementary 的检测模型会基于这些历史间隔，自动推断出“正常”的更新频率和范围。如果后续某个时间桶的更新时间间隔明显偏离历史分布（比如比以往都长），就会被判定为异常，从而触发告警或失败。 这种方式不需要你手动指定“多久更新一次”，而是让系统自动根据历史数据推断出合理的更新频率和阈值。这也是为什么 Elementary 的新鲜度检测属于“异常检测”而不是严格的 SLA 检查。[官方文档说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies) 和 [社区答复](https://slack.com/archives/C02CTC89LAX/p1713235387448399) 都有类似描述。 简而言之：**Elementary 通过分析历史数据的更新时间，自动学习和判断模型的更新频率。**

如果你使用 dbt 的新鲜度检测（dbt source freshness），**目前在 Elementary 的报告（UI/dashboard）中不会显示为异常**，只会在 Elementary 的告警（如 Slack alert）中体现。也就是说，dbt source freshness 的结果不会自动出现在 Elementary 的 Test Results 或 Test Runs 页面，只有通过 elementary 的 freshness_anomalies 测试才会在报告中展示。 官方和社区多次明确说明了这一点： - “Currently

dbt source freshness

tests are not revealed in elementary report (They are being used in elementary alerts).” [Slack 官方答复](https://slack.com/archives/C02CTC89LAX/p1682416734937579) - “The issue is that

source freshness

is not yet supported in the Elementary report, only in the alerts, and the Slack message is a report summary and not an alert.” [Slack 官方答复](https://slack.com/archives/C02CTC89LAX/p1689088826025229) - “The freshness tests at the UI are currently elementary freshness tests, and we have an open issue for adding dbt source freshness as well.” [Slack 官方答复](https://slack.com/archives/C02CTC89LAX/p1677715870599249) 不过，Elementary 团队已经在开发将 dbt source freshness 结果集成到报告中的功能，但截至目前，**只有 elementary 自己的 freshness_anomalies 测试结果会在报告中显示**，dbt 的新鲜度检测只会通过告警渠道通知你异常。 如果你希望在 Elementary 的报告中看到新鲜度异常，建议使用 elementary 的 freshness_anomalies 测试。[相关说明](https://slack.com/archives/C02CTC89LAX/p1684734955417799)

当然可以！Elementary 的空值检测主要通过

elementary.column_anomalies

或

elementary.all_columns_anomalies

测试来实现。下面是详细说明和参数解释： --- ## 1. 配置示例 单列空值检测：

yaml models:   - name: your_model_name     columns:       - name: your_column_name         tests:           - elementary.column_anomalies:               column_anomalies:                 - null_count                 - null_percent

全表所有列空值检测：

yaml models:   - name: your_model_name     tests:       - elementary.all_columns_anomalies:           column_anomalies:             - null_count             - null_percent

你可以只检测

null_count

或 `null_percent`，也可以同时检测。 --- ## 2. 主要参数说明 - column_anomalies 作用：指定要检测的指标。 常用值：`null_count`（空值数量），`null_percent`（空值百分比）。 适用场景：只想检测空值时，配置这两个即可。如果还想检测其他异常（如长度、数值等），可以添加更多指标。 [官方说明](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/column-anomalies) - where_expression 作用：只对满足条件的数据做检测。 适用场景：如只检测某一地区、某一类型的数据。 示例：`where_expression: "region = 'APAC'"` [官方说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/column-anomalies) - time_bucket 作用：设置检测的时间粒度（如每天、每小时）。 适用场景：数据按天更新时用默认即可，若按小时更新可设置为 hour。 示例：

yaml   time_bucket:     period: day     count: 1

[官方说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/column-anomalies) - anomaly_sensitivity 作用：控制检测灵敏度，数值越低越敏感。 适用场景：希望更早发现异常时调低，减少误报时调高。 示例：`anomaly_sensitivity: 2` [参数说明](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-sensitivity) - config.severity 作用：设置检测结果为 `warn`（警告）或 `error`（错误）。 适用场景：只想收到警告但不影响下游流程时用 `warn`，否则用 `error`。 示例：

yaml   config:     severity: warn

[社区说明](https://slack.com/archives/C02CTC89LAX/p1709141168413439) --- ## 3. 支持的空值相关指标 - `null_count`：空值数量 - `null_percent`：空值百分比 这两个指标适用于所有类型的列（any type）[官方说明](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/column-anomalies)。 --- 如需更复杂的配置（如分组、排除某些时间段等），Elementary 还支持 `dimensions`、`anomaly_exclude_metrics` 等参数，具体可参考[官方文档](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/column-anomalies)。

很抱歉，根据目前的知识库，Elementary 的空值检测（如

elementary.column_anomalies

或 `elementary.all_columns_anomalies`）**不支持直接配置“空值数量超过多少就 error”这种静态阈值**。Elementary 的异常检测机制是基于历史数据的分布自动判断异常（即“异常检测”），而不是像 dbt 原生 test 那样允许你直接设定一个具体的数值阈值。 官方和社区多次说明，Elementary 的 anomaly tests 是基于历史趋势自动判定异常，而不是用户自定义阈值。如果你需要这种“超过多少就 error”的功能，建议使用 dbt 的原生 test（如

not_null

或自定义 SQL test）来实现[相关说明](https://slack.com/archives/C02CTC89LAX/p1691677190472129)。 如果你有更复杂的需求，比如同时用 anomaly 检测和静态阈值，可以将两者结合： - 用 dbt 原生 test 检查“空值数量超过阈值”； - 用 Elementary 检测历史趋势异常。 如需 Elementary 的 anomaly 检测配置示例，请参考前述回答或[官方文档](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/column-anomalies)。

如果你想用 dbt 原生的方式检测“空值数量超过多少就 error”，可以使用 dbt 的自定义 SQL test 或 dbt-utils 包中的相关测试。 在 dbt 的 yml 文件中，你可以这样配置：

yaml models:   - name: your_model_name     columns:       - name: your_column_name         tests:           - not_null

如果你需要自定义“空值数量超过某个阈值就 error”，可以写一个自定义 SQL test。例如： 1. 在

tests/

目录下新建一个 SQL 文件，比如 `too_many_nulls.sql`：

sql -- tests/too_many_nulls.sql SELECT   COUNT(*) AS null_count FROM {{ model }} WHERE {{ column_name }} IS NULL HAVING COUNT(*) > {{ threshold }}

2. 在 yml 文件中这样引用：

yaml models:   - name: your_model_name     columns:       - name: your_column_name         tests:           - too_many_nulls:               threshold: 10  # 这里设置你的阈值

这种方式可以实现你想要的“空值数量超过多少就 error”的效果。 如果你需要更详细的 dbt 原生 test 配置方法，可以参考 dbt 官方文档或 dbt-utils 包的相关说明。 （知识库中未包含 dbt 原生 test 的详细官方文档链接，但社区答复和 Elementary 官方也推荐这种做法）[相关社区说明](https://slack.com/archives/C02CTC89LAX/p1693901622870449)。

你遇到的 “Not enough data to calculate anomaly score.” 这个结果，是 Elementary 的异常检测机制导致的。根据官方文档和多条社区答复，出现这个提示通常有以下几种原因： 1. 训练数据不足 Elementary 的 anomaly 检测（包括 `null_count`）需要有足够的历史数据点来建立“正常”分布。默认情况下，至少需要 7 个时间桶（如 7 天）才会开始计算异常分数。如果你的表数据量太少、测试刚刚配置、或者只运行了几次 test，就会出现这个提示。 > This occurs when there are fewer than 7 training data points. To resolve: > - For timestamp-based tests: Check if your timestamp column has enough historical data > - For non-timestamp tests: Run your tests multiple times to build up training data. [官方异常检测排查指南](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/Anomaly-troubleshooting-guide) 2. timestamp_column 配置问题 如果

timestamp_column

字段的数据类型不对、值为空、或者分桶后没有足够的历史数据，也会导致无法收集到足够的训练数据点。 [相关社区答复](https://slack.com/archives/C02CTC89LAX/p1688298056468299) 3. 测试未运行足够多次 对于没有 timestamp 的表，Elementary 需要你多次运行 dbt test，每次运行都会生成一个新的数据点，只有累计到足够的数据点后才会开始检测异常。 [官方文档说明](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/Anomaly-troubleshooting-guide) **你的配置没有明显错误**，但如果是刚刚开始收集数据，或者历史数据不够多，就会出现这个提示。建议你： - 确认

fetch_unixtime

字段有足够的历史数据，且类型为时间戳或日期。 - 多运行几次 dbt test，积累更多的历史数据点。 - 检查

data_monitoring_metrics

表，确认是否已经有足够的历史记录。 如果满足这些条件后依然出现该提示，可以进一步排查 timestamp 字段的数据质量或 Elementary 版本问题（有些旧版本存在相关 bug）[相关社区答复](https://slack.com/archives/C02CTC89LAX/p1688298056468299)。 总结：**这是因为训练数据点不足，建议多运行几次 test 或检查 timestamp 字段的数据量和质量。**

你看到的页面上显示 `Anomaly Threshold: 3`，其实指的是**异常检测的灵敏度阈值（anomaly_sensitivity 或 anomaly_score_threshold）**，而不是“空值超过3个才报 error”。 具体来说，这里的 3 代表的是**标准差（Z-score）阈值**，也就是 Elementary 用来判断某个数据点是否为异常的统计学标准。只有当本次的 `null_count`（空值数量）与历史平均值相比，偏离超过 3 个标准差时，才会被判定为异常并报 error。这和“空值数量大于3”没有直接关系，而是和历史数据的分布有关。 举例说明： - 如果历史上

null_count

一直是 0，这次突然变成 10，且这个变化超过了 3 个标准差，就会报 error。 - 如果历史上

null_count

有波动，这次的值没有超过 3 个标准差，就不会报 error。 结论： 页面上的

Anomaly Threshold: 3

并不是“空值超过3个就 error”，而是“空值数量偏离历史均值超过3个标准差才 error”——这是 Elementary 的异常检测原理[官方说明](https://docs.elementary-data.com/data-tests/data-anomaly-detection)。 如果你需要“空值数量超过3就 error”，建议用 dbt 原生的自定义 test，而不是 Elementary 的 anomaly 检测。

标准差（Standard Deviation）是衡量一组数据分布离均值有多远的统计学指标。在 Elementary 的异常检测中，标准差用于判断某个数据点（如某天的空值数量）与历史平均水平相比，是否“异常”地偏离。 在 Elementary 中，什么时候会报 error？ Elementary 使用“Z-score”方法： - 首先收集一段历史数据（比如过去14天的空值数量），计算出平均值和标准差。 - 每次检测时，将最新的数据点与历史平均值进行比较，计算它的 Z-score（即“当前值与均值的差距，除以标准差”）。 - 如果这个 Z-score 的绝对值大于你设置的阈值（比如默认是3），就会被判定为异常，测试报 error。 举例说明： - 假设过去14天

null_count

都是0，标准差也是0。如果今天突然有10个空值，这个变化就会被判定为异常，报 error。 - 如果历史数据本身波动很大，标准差也大，那么只有当新数据点偏离均值非常多时才会报 error。 Elementary 默认的阈值是3，意思是“只有当数据点偏离历史均值超过3个标准差时，才会报 error”[数据异常检测方法说明](https://docs.elementary-data.com/data-tests/data-anomaly-detection)。 如果你需要更详细的标准差和异常检测原理，可以参考 Elementary 的[官方说明](https://docs.elementary-data.com/data-tests/data-anomaly-detection)。

在 Elementary 中，**标准差本身不需要你直接配置**，而是通过配置

anomaly_sensitivity

参数来间接控制异常检测的“标准差阈值”。 也就是说，你只需要设置 `anomaly_sensitivity`，Elementary 会自动用历史数据计算均值和标准差，并用你设置的灵敏度（即多少个标准差）作为异常判定的阈值。 配置方法示例：

yaml models:   - name: your_model_name     columns:       - name: your_column_name         tests:           - elementary.column_anomalies:               column_anomalies:                 - null_count               anomaly_sensitivity: 2  # 这里设置为2，表示超过2个标准差就判定为异常

-

anomaly_sensitivity

的默认值是 3，表示超过 3 个标准差才算异常。你可以根据需要调整为 2、2.5 等其他数值，数值越低越敏感，越容易报警[anomaly_sensitivity 参数说明](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-sensitivity)。 总结： 你无需直接配置“标准差”，只需通过

anomaly_sensitivity

参数来控制 Elementary 检测异常时所用的标准差阈值。

在 Elementary 的新鲜度曲线中： - **freshness**：表示在该时间区间（比如 29/07/2025 08:00 - 30/07/2025 08:00）内，数据的“新鲜度”数值。具体来说，这个数值是指在该时间桶内，**最大的一次“距离上次数据更新时间的秒数”**。也就是说，freshness 是该时间段内最长一次没有数据更新的时间间隔（单位为秒）[Slack 说明](https://slack.com/archives/C02CTC89LAX/p1676632895348579) [Slack 说明2](https://slack.com/archives/C02CTC89LAX/p1718731076544139)。 - **expected**：这是基于历史数据计算出来的“正常范围”，通常是一个区间（比如 0 - 768968.74）。这个区间表示在历史数据分布下，模型认为新鲜度应该落在这个范围内。如果 freshness 超出了 expected 区间，就会被判定为异常[Slack 说明](https://slack.com/archives/C02CTC89LAX/p1688122955509649)。 举例说明： - 29/07/2025 08:00 - 30/07/2025 08:00 freshness: 677221 expected: 0 - 768968.74 这表示在这一天内，最大一次没有数据更新的时间间隔是 677221 秒，模型认为只要在 0 到 768968.74 秒之间都算正常。 - 30/07/2025 08:00 - 31/07/2025 08:00 freshness: 86392 expected: 0 - 749848.04 这一天最大未更新间隔是 86392 秒，模型认为 0 到 749848.04 秒都正常。 总结： - freshness 是实际观测到的最大未更新间隔（秒）。 - expected 是模型根据历史数据推断的“正常”新鲜度区间（秒）。 - 如果 freshness 超出 expected 区间，就会被判定为异常。 这些定义和原理可以在 Elementary 官方文档和社区答复中找到详细说明：[Slack 说明](https://slack.com/archives/C02CTC89LAX/p1676632895348579) [Slack 说明2](https://slack.com/archives/C02CTC89LAX/p1718731076544139) [官方文档](https://docs.elementary-data.com/data-tests/anomaly-detection-tests/freshness-anomalies)。

edr_target

文件夹是 Elementary CLI 运行时用于存放输出和日志的目录。根据官方和社区说明，这四个文件的作用如下： - **dbt.log**：记录 Elementary 内部 dbt 项目的运行日志，主要用于调试和排查问题。这个日志文件和你自己 dbt 项目的日志不同，是 Elementary CLI 在执行内部 dbt 操作时生成的日志文件[社区说明](https://slack.com/archives/C02CTC89LAX/p1686758880460839)。 - **edr.log**：记录 Elementary CLI 的运行日志，包括命令执行、错误信息等。主要用于调试和问题定位。删除这个文件不会影响 Elementary 的功能，仅用于排查问题[社区说明](https://slack.com/archives/C02CTC89LAX/p1679307638705379)。 - **elementary_output.json**：这是 Elementary 生成报告时的中间数据文件，包含了报告所需的所有原始数据。该文件主要用于报告生成过程的内部使用，通常不需要手动查看或处理[社区说明](https://slack.com/archives/C02CTC89LAX/p1679918193888649)。 - **elementary_report.html**：这是最终生成的数据观测报告（HTML 格式），用于可视化和浏览数据质量、异常检测等结果。你可以将这个文件发布到 Web 服务器或直接用浏览器打开查看[官方文档说明](https://docs.elementary-data.com/oss/guides/generate-report-ui)。 这些文件都属于 Elementary 的临时输出或调试文件，可以安全地删除，不会影响后续的功能使用[社区说明](https://slack.com/archives/C02CTC89LAX/p1684345883187609)。

elementary_report.html 在生成过程中会用到 elementary_output.json 作为中间数据文件，但**生成后的 elementary_report.html 是一个完全独立的静态 HTML 文件，不再依赖 elementary_output.json**。你可以单独拷贝或部署 HTML 文件，用户在浏览报告时不需要 elementary_output.json 的存在。 社区官方答复明确指出： > the html file includes the json file (it’s encoded) > > — [Slack 官方答复](https://slack.com/archives/C02CTC89LAX/p1698696536636559) 也就是说，elementary_output.json 的内容在生成 HTML 时已经被嵌入到 elementary_report.html 里，后续查看报告时无需再依赖 json 文件。