Apache Airflow在GKE环境下DagRun历史过多致性能下降的优化咨询

dag_run.updated_at
FROM
dag_run
WHERE
dag_run.dag_id = $1
AND dag_run.execution_date < $2::timestamptz
AND dag_run.state = $3
ORDER BY
dag_run.execution_date DESC

我认为清理DagRun历史会有帮助，但需保留执行历史访问权限，且未来可能每天需处理5000行数据。请问：
1. 该查询的用途是什么？
2. 如何禁用它？
3. 如何在不影响性能的前提下管理DagRun历史？

---

# 该查询的用途
这条查询是Airflow核心组件的周期性扫描逻辑，大概率是**调度器（Scheduler）**发起的：
- 用于扫描特定DAG中、早于某个时间点的特定状态（比如`success`/`failed`）的DagRun，目的是处理任务重试、DAG回溯（backfill），或清理标记为过期的运行实例；
- 也可能是Webserver加载DAG历史页面时的查询，但从每秒1次的频率来看，Scheduler的周期性检查是主要原因——它需要确认已完成的DagRun是否触发了后续依赖，或执行自动清理逻辑。

# 如何禁用该查询
直接"禁用"核心查询会破坏Airflow的正常运行，优先优化而非强制禁用：
- 调整Scheduler配置：修改`airflow.cfg`中的`max_active_runs_per_dag`，限制每个DAG的并发运行数，减少需要扫描的DagRun总量；
- 关闭不必要的自动逻辑：在DAG定义中设置`catchup=False`，禁用未执行的历史DAG自动回溯；调整`dag_run_cleanup_interval`参数，延长清理检查的间隔时间，降低查询频率；
- 优化Webserver查询：如果是前端页面导致的高频查询，可增加Webserver的历史页面缓存时间，减少重复查询触发。

# 不影响性能的DagRun历史管理方案
结合你的需求（保留历史访问、未来扩容到每日5000行），可从以下维度入手：

## 1. 分阶段清理+归档
- 使用Airflow内置的`DagRunCleanupOperator`，定期清理超过保留期的DagRun，但将核心元数据（执行状态、时间、关键参数）同步到归档存储：
  - 自定义清理逻辑，把需要保留的历史数据同步到独立的CloudSQL实例或BigQuery归档库，原`dag_run`表只保留最近30天的活跃数据；
  - 配置`airflow.cfg`中的`max_num_runs_to_keep`参数，限制每个DAG保留的DagRun数量，超过阈值自动清理。

## 2. 数据库性能优化
- 添加复合索引：针对查询的过滤条件创建联合索引，大幅降低查询耗时：
  ```sql
  CREATE INDEX idx_dag_run_dag_state_execution ON dag_run (dag_id, state, execution_date DESC);

• 扩容CloudSQL：升级实例CPU/内存配置，开启只读副本，将Webserver的历史查询流量分流到副本，减轻主库压力。

3. DAG架构重构（从根源减少DagRun） #

• 改用动态任务映射（Airflow 2.x+支持）或TaskGroup，将单条数据的处理从独立DagRun改为同一DagRun下的并行Task：
  • 把ApiToExport和Export改为ListToApi的子任务，用expand()方法生成500个并行Task，而非500个独立DagRun；
  • 这样每日DagRun数量从1001降到1个，从根源上避免数据量爆炸。

4. 历史数据替代访问方式 #

• 将归档的DagRun数据同步到BigQuery，搭建BI仪表板供团队查询历史执行情况，无需通过Airflow Webserver访问旧数据；
• 配置Airflow Webserver只展示最近30天的DagRun，历史数据通过归档系统查询。

内容的提问来源于stack exchange，提问作者Daniele Ravizza