加载失败
这是一篇 Show HN，介绍 Rocky——一个用 Rust 实现的 SQL engine，主打 branches、replay 和 column lineage。作者在评论里承认开发和文案都用了不少 LLM 工具，引发了对项目成熟度与表达方式的质疑。讨论里反复拿 dbt（数据转换框架）、SQLMesh（SQL 变更管理工具）、Databricks（数据平台）和 Snowflake（云数据仓库）来对比，因为它们都牵涉模型 DAG、调度和成本统计。Rocky 想把“列从哪来、改了会坏哪里、AI 生成 SQL 是否语义正确”这些问题提前放到编译期解决，并通过 branch/replay 做隔离实验。
有人对标题和引导文案里的 LLM 痕迹很敏感，认为连介绍都带着未经筛选的夸张说法，会让人怀疑底层代码是否同样草率。回应里承认营销文案确实是 AI 辅助，但也明确说项目是用大约一个月、借助大量 LLM 工具做出来的，并没有回避这一点。为了把注意力拉回工程质量，还列出了测试与交付证据：workspace 级测试覆盖 19 个 crates，CI 跑在 5 个平台上，JSON schema 也在 CI 里做代码生成校验。讨论里还提到，与其纠结“像不像 AI 写的”，不如直接看代码和具体 PR。
关于“当前 stack 不拥有 DAG”的说法，评论指出把 Databricks 当例子不太准确，因为 Databricks 的 Workflows 和 DLT 本身就管理调度 DAG。随后又澄清 Rocky 所说的 DAG 不是任务先后顺序，而是编译器构建的语义依赖图。这里关注的是模型到模型、列到列的传递关系，例如 `dim_customer.email` 如何从 `raw_users.email_address` 经多个 CTE 传下来。也就是说，争论焦点在于同一个 DAG 词汇在不同层级上的含义不同。
最受关注的技术点是编译期 column lineage。评论认为，很多 lineage 工具是执行后解析 query log 才重建图，所以只能看到“已经发生了什么”；而编译器在推导阶段就能回答“改了某列会坏掉哪些下游模型”。这对 AI 生成 SQL 尤其关键，因为现在的 LLM 往往能拼出语法正确的 SQL，却可能连错键、错聚合粒度，语义上完全跑偏。把生成结果先送进 type checker，再对照真实 DAG 校验，可以拦住这类“能运行但不对”的查询。
另一条线是产品路线和落地细节：有人希望增加 model versioning，并支持 ClickHouse SQL。回应把 versioning 拆成三种不同问题——语义层版本、schema migration history，以及基于 branch 的版本管理——说明不同诉求对应不同设计。关于 branch/replay，当前对 incremental model 的隔离已经做了 schema prefix 和独立 key，但 snapshot model 还没有继承主分支历史，未来计划靠 Delta SHALLOW CLONE 或 Snowflake zero-copy 在建分支时做点时快照。成本方面目前记录了 `bytes_scanned` 和 duration，但预算门控只支持 USD 和时间，不支持按扫描字节直接 fail CI。
column lineage: 列级数据血缘，追踪字段从源表到下游模型的传递路径。
DAG: Directed Acyclic Graph，有向无环图；这里指模型或列依赖图，不是单纯的任务调度图。
replay: 重放历史运行或变更，用来在分支上复现结果并验证影响。
zero-copy clone / SHALLOW CLONE: 创建分支时只复制元数据、不复制实际数据的克隆方式，常用于快照分支。