语义层
dbt
受治理指标、MCP 工具边界、开发与生产隔离、查询成本，以及分析结果回溯到模型代码。
21 条已收录资料 · 0 个设计案例。下列日期对应各篇材料，不代表产品当前能力清单。
近 30 天重点 12 条资料中优先展示，按原文日期
- Fivetran 发布 Agent 上下文层 Context Layer原文 2026-09-17 · 收录 2026-09-19
- Fivetran与dbt Labs发布dbt v2及上下文层原文 2026-09-17 · 收录 2026-09-19
- Looker 26.14 更新：验证查询 GA，dbt CI 集成与 Dashboard Agent 预览原文 2026-08-28 · 收录 2026-08-29
精选参考 3 条
dbt State让Fivetran单个模型运行时间从40分钟降到40秒
dbt State会结合metadata和模型SQL判断上游数据或代码是否变化，只构建需要更新的节点，其余节点复用、克隆或自动延迟到生产状态。Fivetran案例中，一个模型的运行时间从约40分钟降至40秒，体现状态感知执行对成本与迭代速度的价值。
IAS：从看板异常追到 dbt SQL，再用只读查询验证
结合 Looker 入口、dbt 模型与血缘、Databricks 只读 SQL；Agent 调查指标逻辑，按业务用户或分析师输出不同细节。
dbt MCP 的生产模式与大表查询成本陷阱
总结受治理指标问答、文档初稿、CI 测试和跨工具编排；明确指出大表全扫描容易引发超时和仓库费用，应预物化或设置查询限制。
产品动态 18 条
Looker 26.14 更新：验证查询 GA，dbt CI 集成与 Dashboard Agent 预览
Looker 宣布从 2026年8月24日至26日，面向运行 Looker 26.14 的实例自动启用多项功能。其中，Conversational Analytics 的 verified queries（golden queries）正式可用，并支持在 Looker (Google Cloud core) 中定义。新增的 CI 集成可在 dbt Cloud CI 作业完成后自动运行 CI 套件，以在 dbt 变更部署前检查 Looker Explores 是否会因模型变更产生 SQL 错误。此外，预览功能包括在 LookML 仪表板上定义并对话 data agents，以及从 LookML Explores 派生数据库内分析模型。
Fivetran 发布 Agent 上下文层 Context Layer
Fivetran 发布 Fivetran Context Layer，目前处于 Limited Public Preview，这是一个托管服务，用于帮助企业构建受治理的上下文层。它可让团队在自有数据仓库或 Fivetran Managed Data Lake Service 中构建和维护上下文，并向任意 Agent 提供所需上下文。Fivetran 称该服务运行在其已迁移的数据和 dbt 已建模的元数据之上，目标是让 Agent 输出更可信，同时降低 token 成本。文中提到仅 22% 组织成功在多个业务部门规模化 AI，72% 企业仍缺乏 Agent 所需的统一、可访问数据。
Fivetran与dbt Labs发布dbt v2及上下文层
Fivetran + dbt Labs 宣布 dbt v2 与 dbt State 正式 GA，并推出 Fivetran Context Layer、dbt Wizard 新体验、dbt Charts 以及开放湖仓愿景。dbt v2 是 dbt 引擎的 Rust 重写，称解析 10,000 模型项目比 v1 快最多 10 倍，并提供实时错误、列检查与血缘反馈。公司称 Core/Fusion 双引擎时代结束，dbt 变为一个引擎两个版本：dbt Core v1（Python）与 dbt v2（Rust）。其 Open Data Infrastructure 愿景强调厂商中立、可互操作，让企业自主选择存储、计算、数据移动、转换和可视化层，使 AI Agent 可使用企业拥有的数据与上下文。
dbt Summit发布dbt v2、State、Wizard与Charts
dbt Summit 在拉斯维加斯举行，dbt Labs 面向 2,000 名数据从业者（线上另有数千人）发布 dbt 与 Fivetran 产品组合更新。dbt v2 已 GA，作为统一的 Rust 引擎结束双引擎维护，并继续保留 dbt Core，同时提供 superset dbt 与 Apache 2 许可的 dbt-oss 两个发行版。大会还宣布 dbt State、dbt Wizard 和 dbt Charts，核心叙事是让数据基础与 AI 所需的可信上下文、业务理解型 agent 对齐。文章逐项解释这些发布为何重要，并讨论 AI 时代分析工程实践如何升级。
dbt State 正式发布：按变更运行 dbt，最高省 59% 成本
dbt State 已全面 GA，可在 Airflow、Dagster、GitHub Actions 或本地等任意运行 dbt 的环境使用，并已支持 Snowflake 的 dbt projects；兼容 Snowflake、BigQuery、Databricks 和 Redshift。它通过读取模型 SQL 与仓库元数据，判断模型结果是否变化，进而决定构建、跳过、克隆或延迟节点，无需手写 selection syntax 或维护自定义编排。早期采用者平均节省 15-30% 计算，RxBenefits 称在 Snowflake adaptive warehouse 上计划任务成本降低 59%，60 天复用超 70 万模型、减少两周查询运行时间。dbt 每天平均构建超 2200 万个模型，而多数上游未刷新导致重复构建。
ClickHouse 登陆 dbt 平台，dbt v2 适配器公测
dbt 在 dbt Summit 上宣布，ClickHouse 的 dbt v2 适配器进入公开 beta，由 Rust 引擎驱动；ClickHouse 也作为原生支持数仓加入 dbt Platform 的私有 beta，支持开源 ClickHouse 与 ClickHouse Cloud。它是 dbt Platform 上首个由合作伙伴构建的 v2 适配器，通过 ADBC 驱动和 Apache Arrow 连接 ClickHouse。dbt v1 适配器自 2021 年 GA 并继续维护；v2 适配器与平台集成都于 2026 年 9 月 16 日开放 beta。
超越集中化：亚太零售与CPG团队为何需要dbt
Fivetran博客指出，集中化数据只是基础，零售和CPG团队需通过dbt测试、治理和血缘追踪来获得可信数据。亚太市场数据来源混杂，自动化补货、促销和库存决策依赖底层数据质量。dbt通过自动运行的not_null、unique等测试，在数据驱动关键决策前暴露坏数据，避免错误补货和缺货损失。
为什么AI试点会卡在上下文鸿沟——dbt的解法
仅16%的企业已规模化部署agentic AI；近80%的公司称AI项目受数据访问限制，70%的受访者表示无法充分信任和治理agent。dbt认为，AI试点停滞的主因并非模型，而是缺乏可信、受治理的上下文，导致agent可能臆造指标或随意选择口径。dbt平台通过提供受治理的语义上下文，帮助企业构建可规模化、可信任的AI agent。
AI规模化易，信任它难
文章指出组织正将AI嵌入日常业务运营，但规模化成功远不止部署强大模型。调查显示92%的公司计划增加AI投资，仅1%认为自身AI部署成熟。缺乏可信数据、治理和业务上下文时，AI系统难以产出可靠可解释的结果。作者分析了数据质量、治理、所有权、成本和信任等挑战。
Snowflake Summit 2026：Whatnot如何将超高速增长数据转化为业务洞察
Whatnot 在 Snowflake Summit 2026 展示了支撑数十亿实时事件的数据平台实践，从集中式 dbt 管理转向基础设施即代码的去中心化架构，让各业务单元自建 Snowflake warehouse 和 pipelines。为缓解数据科学家瓶颈，Whatnot 先后尝试 Slackbot 自动生成 SQL、将 Snowflake semantic views 接入 Sigma 和 Glean，内部测试 text-to-SQL 准确率超 90%，并迈向 agentic analytics 阶段。该案例展示了高增长压力下数据平台的可观测性、成本控制与 AI 分析嵌入运维闭环的落地方式。
Suprema Gaming借助ClickHouse Cloud打造Agent-ready数据平台
Suprema Gaming从Snowflake迁移至ClickHouse Cloud，以支撑公司向Agent优先运营转型。此前数据延迟达4小时，查询耗时数分钟，dbt管道每天只能全量重建一次，且成本随并发增长。迁移后，团队获得实时交互分析能力，可支持AI Agent问答与行动。
dbt on Snowflake实践：把编排搬进数仓后真正的问题
作者回顾了一次在400行DAG定义中手动追踪依赖的下午，指出代码优先的DAG缺乏可视化反馈，调试如同考古。他将真实项目迁移到dbt Projects on Snowflake，结合Workspaces、Task Graphs和Horizon Catalog，评估其承诺是否兑现。文章也列出了迁移后依然耗时的地方，以及编排移入数仓带来的实际体验。
Fivetran谈数据目的地：决定数据架构成败的5个要点
Fivetran 认为数据目的地决定了数据在分析、AI和业务运营中被治理、查询、激活和复用的难易程度，是数据架构中最关键的决策之一。其目的地设计强调跨仓库一致的 schema 语义、表级同步模式选择、对开放湖格式的原生支持与自动目录注册，以及反向 ETL 层以避免数据死胡同。文中还指出，借助一致的 schema，dbt 模型和 Quickstart 包可跨 Snowflake、Databricks、BigQuery、Redshift 等平台移植。
Databricks处理数据，dbt定义数据含义
Databricks是优秀的数据平台，dbt与Databricks保持合作，数千团队在两者上运行生产工作负载。但选择Databricks作为计算平台与选择它来承载转换逻辑是两个不同的决策，多数公司往往一并批准。将转换逻辑完全置于Databricks会带来可移植性和可审计性风险，退出成本可能在日后成为数月的工程项目。
为Token建模而非表：dbt仓储上下文节省20倍成本
Gong通话记录是AI重要上下文，但直接调用API每次账户查询消耗约24万token且触及速率上限。团队用Fivetran将Gong数据同步至Snowflake，通过dbt建模并经dbt MCP server提供结构化上下文。最终token成本降低20倍，还能与账户其他数据关联形成更丰富的上下文层。