Steampipe Zero-ETL SQL 查询引擎

要解决的具体问题

在云与 SaaS 环境中，数据分散在 AWS、Azure、GCP、GitHub、Slack 等 API 后面。传统做法是写 SDK、维护凭证、做 ETL 把数据拉进仓库，再跑 SQL。这带来三类成本：工程复杂度（每个数据源都要写适配层）、运维负担（凭证轮换、限流、增量同步）、延迟（ETL 不是实时的）。当只想回答一个简单问题——比如「这个月 GCP 账单里 Top 10 服务」——这些流程显得过重。

技能如何工作

Steampipe 的思路是把云 API 映射成 PostgreSQL 表。它内置 150+ 数据源插件（AWS、Azure、GCP、GitHub、Slack 等），启动后会按 schema 暴露成可直接查询的表。你不需要写 ETL，直接用 psql 或标准 SQL 就能查。

关键步骤：

• 安装 Steampipe（本地或容器环境均可）
• 用 steampipe plugin install aws 这类命令装好对应数据源插件
• 执行 select * from aws_ec2_instance limit 10 即可返回结果
• 支持 where、join、聚合等标准 SQL 语法，跨数据源也能关联查询

适用边界与注意点

• 不是所有 API 都支持：150+ 插件覆盖主流云与 SaaS，但一些小众或内部 API 需要自己写 plugin
• 凭证管理：仍需配置各云厂商的认证信息，Steampipe 不自动处理 IAM
• 性能：首次查询可能较慢（需拉取元数据），高频查询建议结合缓存或 materialized view
• 数据新鲜度：取决于插件实现，部分数据源是准实时的，部分有延迟

适合的场景是临时查询、报表原型、数据探索，而非替代完整的数据仓库。