迁移至Cloud Composer 2：如何查询Airflow DAG的临时存储与内存使用？

一、查询现有DAG所需的临时存储量 #

Airflow本身不会直接存储KubernetesPodOperator启动的Spark Pod的临时存储使用数据，但可以通过以下两种方式获取实际需求：

• 查看原K8s集群的监控数据：
  • 执行kubectl top pod --containers命令，找到对应Spark作业的Pod，查看ephemeral-storage的使用峰值；
  • 若集群有监控工具（如Prometheus+Grafana），可筛选该Pod的存储相关指标（如kube_pod_container_resource_usage_ephemeral_storage_bytes），获取运行期间的最大使用量，以此作为limit_resources中ephemeral-storage的参考值。
• 分析Spark作业日志：
  Spark作业运行时会在日志中输出临时存储相关的统计（比如shuffle数据量、临时文件生成大小），可从Airflow的任务日志中提取这些信息，估算所需的临时存储容量。

二、在Airflow 2中查询DAG的内存使用量 #

Airflow 2本身不会自动记录DAG的内存消耗，但可以通过以下途径获取：

• 针对Spark Pod的内存使用：
  这是最关键的部分，因为实际内存消耗发生在Spark Pod中，而非Airflow调度组件。同样可以通过原K8s集群的kubectl top pod查看Pod的内存使用峰值，或监控工具的内存指标（如kube_pod_container_resource_usage_memory_bytes）获取准确数据。
• Airflow自身组件的内存使用：
  若需要查看Airflow调度器/worker运行该DAG任务时的内存占用，可通过Airflow的监控指标（如Prometheus采集的airflow_worker_process_memory_rss），或在worker节点上查看对应进程的内存使用情况，但这部分通常远小于Spark作业的内存需求。
• 从任务日志提取数据：
  部分场景下，Airflow的任务实例日志会包含资源使用统计，可从中提取内存相关数据作为参考。

额外建议（针对CC2 Autopilot迁移） #

除了设置limit_resources指定存储和内存限制，还可以考虑将Spark作业的临时数据（如shuffle文件、临时输出）挂载到Cloud Storage（GCS），彻底减少对Pod临时存储的依赖，这更适配GCP Cloud Composer的生态，也能从根源避免Pod因临时存储不足被驱逐的问题。

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