使用 SQL Alerts 自动化数据和 KPI 监控

标题：使用 SQL 警报自动化数据和 KPI 监控

URL 来源：https://www.databricks.com/blog/automate-data-kpi-monitoring-sql-alerts

发布时间：2026-05-19T21:04:41+0000

Markdown 内容： 在许多组织中，数据监控仍然是一项手动、重复的日常工作：每天早上打开同一个仪表板，重新运行相同的查询，扫描异常情况。当有人问"为什么这个指标下降了？"时，错误往往已经持续了数小时甚至数天，通常是被利益相关者发现的，或者下游报告已经发送了错误数据。修复方法是另一个手动流程。这在出问题之前是有效的：它无法跨团队、环境或生产工作负载扩展，而且监控成本持续上升。

今天我们宣布 Databricks SQL 警报 正式发布 (GA)，已有超过 4,000 个客户在生产环境中使用警报。SQL 警报将手动流程转变为可靠、自动化监控：在 SQL 中定义一次指标或条件，按计划评估（或在与生成数据的 Jobs 管道内联评估），当指标超出您的警戒线时通知正确的负责人。无论是跟踪收入等业务 KPI，还是管道新鲜度等运营健康状况，或数据质量问题，SQL 警报都能帮助您尽早发现问题，减少人工抽查，并随着使用量增长保持监控的一致性。

"为我们的异常检测服务实施 SQL 警报使可观测性变得更加简单。现在我们可以依赖警报来扫描问题并通知用户，而不是维护监控基础设施。其简化的界面和可定制的体验减少了我们团队的手工工作量，并帮助我们更快地识别问题。"——Enrique Olivares，Zillow 大数据软件开发工程师

**SQL 警报概述**

**什么是 SQL 警报？**

SQL 警报将 SQL 查询、评估条件、计划和一组通知目标捆绑在一起。当查询结果在其计划运行中超出条件时，Databricks 会通过您配置的渠道通知正确的负责人。

团队可以使用 SQL 警报做什么：

• 尽早发现业务指标偏差。 当收入环比下降超过 5% 时、当日转化率低于目标时，或关键地区的日活跃用户下降时发出警报。
• 保持管道可信度。 当表在过去一小时内未刷新时、当行数低于预期基线时，或当作业加载部分数据时发出警报。
• 在仪表板损坏之前检测自定义数据质量问题。 当空值率超过阈值时、当出现重复键时，或当分布超出预期范围时发出警报。

**GA 版本中有什么？**

SQL 警报 GA 版本包含了在生产环境中创作、操作和扩展警报所需的一切：

• 在 SQL 编辑器中创作警报。 在一个流程中定义查询、评估条件、计划和通知。您可以使用 Databricks SQL 的全部功能以及 Genie Code 来帮助您编写查询。
• 在需要的地方运行警报。 使用独立的 SQL 警报按自己的计划运行，或将 SQL 警报任务添加到 Lakeflow Job 中，以在与生成数据的管道内联评估条件。
• 以正确的方式联系正确的人。 发送通知到电子邮件、Slack、PagerDuty、Microsoft Teams 或 Webhooks，使用包含警报评估历史的丰富模板，以便接收者更快地进行分类处理。
• 将警报作为生产代码管理。 在 Git 中对警报定义进行版本控制，通过声明式自动化包部署它们，并通过 API、Terraform 和 SDK 自动化创建和更新。
• 大规模观察警报。 新的警报系统表（处于私有预览阶段）——system.alert.alerts 和 system.alert.alert_evaluation_history——在整个工作区中显示配置和评估数据，以便团队可以审计警报、分析趋势并大规模管理工作负载。

"Databricks 的原生集成使警报简单易定义且可靠运营。警报逻辑、计划和通知在一个地方管理——并通过 Git 进行版本控制——帮助我们标准化监控，更快地发现问题，大大减少了手动工作量。"——Tom Potash，DoubleVerify 软件工程经理

**使用 SQL 警报的示例**

现在让我们通过一个示例来演示 SQL 警报的价值。一个常见的业务监控需求是检测收入相对于近期基线的意外下降。这个示例展示了如何创建一个警报，比较昨天的收入与七天平均值，并在下降超过 5% 时通知正确的人。

#### 第 1 步：在 SQL 编辑器中编写查询

此查询计算昨天的收入并与七天平均值进行比较。

输出： 一个单独的列 revenue_pct_change，用于警报评估。此警报会被触发，因为收入下降超过 5%。

#### 第 2 步：配置条件和通知

在编辑器中，设置条件为 revenue_pct_change < -5 并添加通知接收者。您还可以使用富 Markdown 编辑器自定义通知模板，在通知中添加更多上下文或后续步骤。

#### 第 3 步：设置计划

选择评估频率。例如，对于关键业务 KPI，每天评估可确保在 24 小时内捕获变化。

当警报触发时，接收者会收到包含警报评估状态、结果、警报链接和最近运行历史的通知。您可以立即开始调查。

SQL Alerts 还包含一个全面的警报详情页面，显示完整的运行历史，包括每次评估的运行时间、是否触发警报以及通知目标。这有助于团队确认监控是否按预期运行，并通过显示警报开始触发的时间来加快故障排查速度。

**使用 Genie Code 创建警报（即将推出）**

通过 Genie Code，上述流程将变成只需一个提示即可完成。用自然语言描述你想要的警报（"当每日收入环比下降超过 5% 时提醒我"），Genie Code 会端到端地为你构建警报。你可以随时要求 Genie 进行编辑，或直接打开警报 UI 进行修改。

**在 Lakeflow Jobs 中运行警报**

独立的 SQL Alerts 按照自己的计划运行，独立于任何管道。这适用于许多监控场景：任何不关心上游数据何时到达的监控需求。

但有些检查应该放在产生数据的管道内部：_这次加载是否完成了完整数据？在我们发布之前，这个指标是否正常？下一步是否应该运行？_ 将这些检查作为独立的计划警报运行意味着警报按照自己的计划运行，与产生数据的管道分开，其结果无法影响管道中后续发生的事件。

通过 Lakeflow Jobs 中的 SQL Alert 任务（公开预览中），你可以精确做到这一点。同一个警报对象现在可以作为任务在管道内部运行。它还将评估状态（OK、TRIGGERED 或 ERROR）作为任务输出值公开，供下游引用。

**示例：交易数据到达时立即检测欺诈峰值**

管道每小时加载信用卡交易数据。如果加载后欺诈率出现峰值，欺诈运营团队需要立即知道以便调查。

在加载步骤之后添加一个 SQL Alert 任务，检查欺诈标记率是否超过阈值。然后添加一个 If/Else 任务，条件为 {{tasks.Alert-FraudRateCheck.output.alert_state}} == "TRIGGERED"。如果警报返回 OK，管道继续进行常规 BI 报告。如果返回 TRIGGERED，则路由到一个诊断笔记本，生成按商家类别和地区的细分，并向欺诈运营团队发送电子邮件。同一个警报对象可以驱动你的管道流程！

**在生产环境中可靠地运行警报**

随着警报在团队和环境中的规模扩大，挑战从创建警报转向随时间可靠地管理它们。SQL Alerts 通过以下方式构建以处理生产工作流：

• Git 集成： 警报定义存储在 Git 中，与生产代码的其他部分一起进行版本控制和审查。
• **声明式自动化包**： 提供一种结构化的方式来定义和部署警报以及其他工作区资源，支持从开发到生产的可重复推广。
• **API**、**Terraform**和 SDK： 通过 API 和 Databricks SDK 以编程方式创建和管理警报。

加入已经使用 SQL Alerts 的 4000+ 客户行列。你的第一个警报只需五分钟即可设置完成。阅读 SQL Alerts 文档 并从你已经定期手动检查的监控查询开始！