我不讨厌SQL。我讨厌元数据摩擦。

Source: Dev.to

我写 SQL 本身并不困难，但我在它周围的所有事情上都感到困扰。你一定很熟悉这种流程：

• 打开 BigQuery 控制台。
• 在 INFORMATION_SCHEMA 上写一个简单查询。
• 这时才发现忘记了分区列。
• 复制一段旧查询。
• 对其进行微调。
• 这时又发现需要另一列。
• 打开文档。
• 切换到 Airflow，看看能否更快得到答案。
• 回到 BigQuery 控制台。
• 忘记自己在查什么。

这些都不难。只是每隔一天就会重复出现的低层次、持续的摩擦。

于是我做了一个小工具来减少这种摩擦。

Source: …

问题

我经常会问类似的问题：

• 最近哪些表的模式发生了变化？
• 哪些作业消耗的槽位最多？
• 为什么昨天的 BigQuery 运行缓慢？
• 为什么 BigQuery 成本飙升？

BigQuery 通过 INFORMATION_SCHEMA 暴露了许多答案，但查询往往并不简单。它们很长，需要进行连接，而且你必须记住字段名称——所以我经常需要回到文档去查找细节。

我开始在 dbt 中对元数据进行建模，并为以下内容创建了一些汇总表：

• 作业
• 存储
• 模式更改
• 依赖关系
• 槽位使用

这并不是什么革命性的创新——只是把数据以我实际使用的方式进行结构化。这确实有所帮助，但我仍然在重复编写相同类型的查询。

所以我把 LLM 抛进去

一旦我拥有了干净的 dbt 模型并配有体面的描述，接下来的步骤显而易见：与其手写 SQL，何不直接提问？大多数 BI 工具都在为业务用户宣传 Text‑to‑SQL 解决方案；那它为什么不能同样适用于工程师呢？

当前设置

1. dbt 模型 汇总了 BigQuery 的元数据。
2. 将数据同步到 DuckDB（以避免每次都扫描 BigQuery，并且我不信任 LLM 在实时数据上的表现）。
3. 我把 schema + 列描述传递给 LLM。
4. LLM 生成 SQL。
5. SQL 在 DuckDB 上运行。
6. 结果在一个小型终端 UI 中展示。

它基本上是一个可以“聊天”我的元数据的 TUI。

一个真实的例子

一周前，BigQuery 运行异常缓慢。很可能是槽位竞争导致的，可能是因为当周早些时候部署的一个新转换引起的。

我没有手动排查，而是直接问：

why was bigquery slow this week?

系统分析了槽位使用情况和长时间运行的作业，识别出一个在运行六小时后超时的新转换模型。我联系了负责的团队，他们表示会进行修复。

几天后，我再次询问：

are the slot timeouts gone?

系统确认长时间运行的作业已经消失。那一刻，我意识到这实际上对首次调查非常有用。

这并不完美

一开始就出现了问题。

• 冗长的答案 – 即使是简单的问题也会触发过于详细的报告。我把 UI 拆分为两种模式：快速 和 分析。
• 幻觉 – BigQuery 作业 ID 看起来像 UUID。即使查询结果是正确的，LLM 有时也会在解释中捏造作业 ID，这是不可接受的。

我尝试添加验证步骤，但它们很快就因为消耗的 token 过多而变得成本高昂。目前我返回原始查询结果以及摘要。

我还遇到一个无限循环：LLM 查询数据、解释后再次查询，如此循环。幸好我只有 $5 的额度，所以随后我添加了严格的使用限制。

为什么选择 DuckDB？

主要是成本和速度。我不想出现意外的昂贵扫描和慢速迭代循环。所以我把相关的元数据同步到 DuckDB 并对其进行查询。

在这种规模下运行良好，虽然显然无法镜像无限的历史。

这个工具到底是什么

这 不是 一个 BI 或可观测性工具。它只是一个在不编写重复元数据查询的情况下，更快提出运维问题的方式。

它可用于：

• 一级调查
• 健全性检查
• 避免复制粘贴 SQL

就是这样。我在需要快速答案时使用它。

替代正式分析。但它降低了激活能。仅此一点就使它有用。

开源？

我在考虑将它开源。现在它可以配合 BigQuery 元数据使用，但从技术上讲，只要有合适的表定义，你完全可以接入任何 BigQuery 数据集。

在我投入更多时间去支持额外的数据工程操作元数据之前，我想先了解：

• 你会使用这样的工具吗？
• 它能解决你真实的烦恼吗？
• 有什么会让它立刻变得不可用？
• 有什么会让它变得不可或缺？

如果有兴趣，我会整理代码仓库并开源它。

我想验证这到底是我的个人需求，还是更广泛的需求。欢迎提供诚实（包括严厉）的反馈。