如何对Athena已保存查询进行版本控制？

我完全理解你的困扰——用Glue Notebook依赖Athena已保存查询跑数据管道，结果这些查询没有版本保护，谁都能改能删，哪天不小心被改坏或者删了，整个管道都要出问题。接下来给你几个实用的方案，结合你的使用场景来解决这个问题：

方案1：把查询移到Git等版本控制系统（最推荐） #

其实Athena的“已保存查询”本质就是存储在AWS里的一段SQL字符串，与其依赖这个无版本的存储，不如把这些SQL作为代码放到Git仓库里管理。这样所有修改都需要提交、审核，有完整的版本历史，还能随时回滚到之前的正确版本。

结合你的现有代码，调整起来很简单：

• 把每个Athena已保存查询的SQL内容，单独存成.sql文件放到Git仓库（比如用AWS CodeCommit或者你们团队常用的Git托管服务）
• 修改Glue Notebook里的逻辑，不再通过查询名称去Athena拉取内容，而是直接读取Git仓库里的SQL文件：

# 假设queries现在是包含查询名称和对应SQL文件路径的列表
for q in queries:
    print(f"\nRunning query: {q['query_name']}")
    # 读取Git仓库中的SQL文件（如果Glue挂载了Git仓库，直接读本地路径；否则可以从S3同步后读取）
    with open(q['sql_file_path'], 'r') as sql_file:
        query_string = sql_file.read()
    execute_query(query_string)

这样做的好处：彻底摆脱对Athena已保存查询的依赖，查询的变更完全受版本控制，团队协作也更规范，不会有人随便改坏查询。

方案2：用Lambda+CodeCommit自动同步Athena查询到版本库 #

如果不想完全放弃Athena已保存查询的便利（比如有些人习惯在Athena控制台编辑查询），可以做一个自动同步的机制：

• 用CloudWatch Events监听Athena的NamedQuery创建、修改事件
• 触发Lambda函数，把变更后的查询内容同步到CodeCommit仓库里
• 这样每次有人修改Athena已保存查询，都会自动生成一个Git提交，保留版本历史

如果查询不小心被删除了，你也可以从CodeCommit里找到历史版本，重新创建Athena查询。

方案3：用AWS Config做变更审计与版本回溯 #

开启AWS Config服务，配置跟踪AWS::Athena::NamedQuery这个资源类型。AWS Config会记录每个已保存查询的所有变更历史，包括修改前的SQL内容、修改时间、操作人等信息。

虽然它不像Git那样直接提供版本切换，但你可以通过Config的历史记录，找回被修改或删除的查询内容，也能审计是谁做了变更，起到事后追溯和恢复的作用。

内容来源于stack exchange