@clickzetta/cz-cli-darwin-arm64 0.3.78 → 0.3.81

package/bin/skills/clickzetta-dynamic-table/SKILL.md

@@ -1,230 +0,0 @@
----
-name: clickzetta-dynamic-table
-description: |
-  ClickZetta Dynamic Table（动态表）使用指南与路由中心。
-
-  【触发场景】
-  - 通用咨询：动态表介绍、使用方式、最佳实践、性能优化、增量配置
-  - 创建指导：DT 声明策略、SQL 支持矩阵、刷新历史查询
-  - 修改操作：检测到后自动委托给 dynamic-table-alter 子技能
-  - SQL 转换：检测到后自动委托给 sql-to-dt 子技能
-
-  【触发关键词】
-  "动态表怎么用"、"DT 介绍"、"动态表最佳实践"、"动态表性能优化"、
-  "增量计算配置"、"维度表 JOIN"、"动态表刷新历史"、"静态分区 DT"、
-  "动态分区 DT"、"状态表管理"、"非分区表风险"、"创建动态表"、
-  "动态表调度"、"REFRESH INTERVAL"、"动态表告警"
-
-  【不触发场景】
-  修改操作（"修改动态表"、"加列"、"改间隔"等）→ 使用 dynamic-table-alter
-  SQL转换（"转换DT"、"INSERT OVERWRITE转DT"等）→ 使用 sql-to-dt
----
-
-# Dynamic Table 使用指南 — 路由与索引
-
-本技能是 ClickZetta 动态表的**知识中心和路由器**，根据用户意图提供参考文档或自动委托到专门的操作型子技能。
-
----
-
-## 使用场景分类
-
-### 1. 通用咨询与学习（本技能处理）
-
-**适用场景：**
-- 需要查询最佳实践和性能优化建议
-- 寻找特定配置项的说明文档
-- 学习如何创建动态表
-
-**触发关键词：**
-- "动态表怎么用"、"DT 介绍"、"Dynamic Table 是什么"
-- "动态表最佳实践"、"DT 性能优化"、"动态表性能调优"
-- "增量计算配置"、"刷新策略"、"状态表管理"
-- "维度表 JOIN 怎么配置"、"非分区表风险"
-- "动态表刷新历史怎么查"、"REFRESH HISTORY"
-- "静态分区 DT"、"动态分区 DT"、"DT 声明策略"
-- "动态表支持哪些 SQL"、"动态表 SQL 限制"
-- "创建动态表"、"新建动态表"、"CREATE DYNAMIC TABLE"
-
-**处理方式：** 提供相关参考文档的内容和指引。
-
----
-
-### 2. 修改现有动态表（自动委托给 dynamic-table-alter 子技能）
-
-**适用场景：**
-- 需要修改已存在的动态表结构或属性
-- 暂停/恢复动态表刷新
-- 添加/删除列、修改刷新间隔、修改查询定义
-
-**触发关键词：**
-- "修改动态表"、"动态表加列"、"动态表删列"
-- "改刷新间隔"、"修改 REFRESH_INTERVAL"
-- "暂停动态表"、"恢复动态表"、"SUSPEND"、"RESUME"
-- "重命名列"、"修改列注释"、"修改表注释"
-- "ALTER DYNAMIC TABLE"、"CREATE OR REPLACE DYNAMIC TABLE"
-- "修改 DT 查询定义"、"修改 AS SELECT"
-
-**处理方式：**
-> ⚠️ 检测到修改操作意图，应立即加载 dynamic-table-alter 子技能。
-> 该子技能提供完整的 10 种修改操作工作流：
-> - 5种直接 ALTER：suspend、resume、set_comment、rename_column、set_column_comment
-> - 5种 CREATE OR REPLACE：add_column、drop_column、alter_column、set_refresh_interval、set_select
-
----
-
-### 3. SQL 转换为动态表（自动委托给 sql-to-dt 子技能）
-
-**适用场景：**
-- 将 Hive/Spark 等任意批处理系统的 CREATE TABLE + INSERT OVERWRITE 转换为 DT
-- 批量迁移传统 ETL 到动态表
-- 自动生成 refresh、backfill 等配套文件
-
-**触发关键词：**
-- "转换 DT"、"sql to dt"、"convert to dynamic table"
-- "INSERT OVERWRITE 转 DT"、"DDL 转换"
-- "Hive SQL 转 ClickZetta"、"Spark SQL 转动态表"
-- "批量转换 ETL"、"迁移到动态表"
-- "创建动态表"、"新建动态表"、"CREATE DYNAMIC TABLE"
-
-**处理方式：**
-> ⚠️ 检测到 SQL 转换意图，应立即加载 sql-to-dt 子技能。
-> 如果用户说"创建动态表"但未提供 DDL 和 INSERT OVERWRITE，应主动提示：
-> "请提供原始的 CREATE TABLE DDL 和 INSERT OVERWRITE 语句，我可以全自动生成对应的 Dynamic Table DDL 及配套的 refresh、backfill 文件。"
-> 该子技能提供 6 步自动转换工作流：
-> 1. 预处理输入（移除 ALTER、ANALYZE、注释）
-> 2. 占位符替换（转换为 SESSION_CONFIGS）
-> 3. 自引用检测
-> 4. 核心转换（合并 DDL + INSERT 为 CREATE OR REPLACE）
-> 5. 列校验
-> 6. 生成配套文件（refresh、prev_refresh、backfill）
-
----
-
-## 知识库目录
-
-### dt-creator/ — 创建动态表参考资料
-
-**包含内容：**
-- **dt-declaration-strategy.md** — 静态分区 DT vs 动态分区 DT 的声明策略与选择
-  - 静态分区 DT：使用 SESSION_CONFIGS() 传递分区参数，每个分区独立刷新
-  - 动态分区 DT：不传递分区参数，一次性处理所有增量数据
-  - 决策树：根据数据模式选择合适的分区策略
-
-- **sql-limitations.md** — 增量计算支持的 SQL 模式（JOIN、聚合、窗口函数等的支持情况，以及 VIEW/外部表不支持增量的限制）
-
-- **incremental-config-reference.md** — 增量刷新配置项完整参考
-  - 刷新策略：强制全量、尝试增量并回退
-  - 源表特征声明：维度表、仅追加表
-  - 全量回退触发条件：基于表变更或变更量
-  - 状态表管理：启用/禁用、生命周期、重建、schema 指定
-  - DT 定义变更：CREATE OR REPLACE 的兼容性检查
-  - Backfill：历史分区数据修正
-  - 分区表写入行为：覆盖 vs 追加模式
-
-- **refresh-history-guide.md** — 刷新历史查询的 3 种方式
-  - SHOW DYNAMIC TABLE REFRESH HISTORY：作业级信息，含 refresh_mode（INCREMENTAL/FULL/NO_DATA）
-  - DESC HISTORY：版本级历史，含行数、字节数、操作类型
-  - information_schema.materialized_view_refresh_history：批量分析、监控、CRU 统计
-
-**适用问题：**
-- "静态分区 DT 和动态分区 DT 有什么区别？ "
-- "动态表支持哪些 SQL 语法？"
-- "增量计算的配置项有哪些？"
-- "怎么查看动态表的刷新历史？"
-- "什么时候会触发全量刷新？"
-
----
-
-### dynamic-table-alter/ — 修改动态表操作指南
-
-**包含内容：**
-- 完整的动态表修改工作流（10 种操作）
-- 5 种直接 ALTER 操作：suspend、resume、set_comment、rename_column、set_column_comment
-- 5 种 CREATE OR REPLACE 操作：add_column、drop_column、alter_column、set_refresh_interval、set_select
-- 平台特有语法和限制说明（CHANGE COLUMN、RENAME COLUMN、DML 限制等）
-- 详细示例和故障排除
-
-> ⚠️ 此目录对应独立的 **dynamic-table-alter 子技能**。当用户有明确的修改操作意图时，应直接加载该子技能而非本指南。
-
----
-
-### sql-to-dt/ — SQL 转 DT 自动转换
-
-将 Hive/Spark 等任意批处理系统的 CREATE TABLE DDL + INSERT OVERWRITE 全自动转换为 Dynamic Table DDL 及配套文件（refresh、prev_refresh、backfill）。
-
-详细转换规则参见 sql-to-dt 子技能。
-
----
-
-### best-practices/ — 最佳实践与避坑指南
-
-**包含内容：**
-
-- **performance-optimization.md** — 性能优化策略
-  - 核心原则：变更量占比（< 5% 适合增量）、算子类型（INNER JOIN 快于 OUTER JOIN）、数据局部性
-  - SQL 优化技巧：优先 INNER JOIN、减少 DISTINCT、窗口函数必须有 PARTITION BY、使用分区条件限制数据范围
-  - 管道拆分：将复杂 DT 拆分为多个阶段
-
-- **dimension-table-join-guide.md** — 维度表 JOIN 场景详解
-  - 核心机制：维度表变更被忽略，仅事实表变更触发增量计算
-  - 配置方式：TBLPROPERTIES('mv_const_tables'='dim1,dim2') 或 Session 配置
-  - 推荐场景：码表/字典表、T+1 维度 + 实时事实表、大事实 JOIN 小维度
-  - 不推荐场景：频繁更新的维度且需要实时一致性
-  - 数据修正：维度表变更后必须使用全量刷新
-
-- **non-partitioned-merge-into-warning.md** — 非分区 DT + 连续写入风险告警
-  - 触发条件：DT 是非分区表 + 源表连续写入 + SQL 含 ROW_NUMBER() 去重
-  - 三大风险：存储无限增长、归档引发性能灾难、无法过滤归档删除
-  - 推荐替代方案：MERGE INTO + Table Stream（归档免疫、独立生命周期管理）
-
-- **scheduling-guide.md** — 调度方式选择指南
-  - 两种方式对比：DDL 内置调度（REFRESH INTERVAL）vs Studio Task 调度
-  - 有 Studio 时始终推荐 Studio Task：支持上下游依赖、统一告警、可视化监控
-  - DDL 内置调度的弊端：无告警、无依赖编排、只能手动 SQL 查询刷新状态
-  - Studio Task 配置要点：必须开启自依赖、配置失败/超时告警、按需配置上游依赖
-  - 多级 DT 管道的调度编排方式
-
-**适用问题：**
-- "动态表性能怎么优化？"
-- "维度表 JOIN 怎么配置？"
-- "非分区动态表有什么风险？"
-- "什么时候不应该用动态表？"
-- "动态表调度用 REFRESH INTERVAL 还是 Studio Task？"
-- "动态表刷新失败怎么收到告警？"
-
----
-
-## 路由决策树
-
-```
-用户提问
-    │
-    ├─ 包含修改操作关键词？
-    │   （"修改动态表"、"加列"、"改间隔"、"暂停"、"ALTER DYNAMIC TABLE"）
-    │   └─ 是 → 立即加载 dynamic-table-alter 子技能
-    │
-    ├─ 包含 SQL 转换关键词？
-    │   （"转换DT"、"sql to dt"、"INSERT OVERWRITE转DT"、"DDL转换"、"创建动态表"）
-    │   └─ 是 → 立即加载 sql-to-dt 子技能
-    │
-    └─ 通用咨询/学习？
-        （"动态表怎么用"、"最佳实践"、"性能优化"、"增量配置"）
-        └─ 是 → 提供本指南的参考文档
-```
-
----
-
-## 使用建议
-
-1. **首次学习**：从 dt-creator/ 开始，了解 DT 的声明策略和配置项
-2. **迁移场景**：使用 sql-to-dt 子技能批量转换现有 ETL
-3. **日常运维**：使用 dynamic-table-alter 子技能修改 DT 结构
-4. **性能调优**：参考 best-practices/ 中的优化建议和避坑指南
-5. **调度配置**：有 Studio 时始终使用 Studio Task 调度，参考 best-practices/scheduling-guide.md
-
----
-
-## 相关技能
-
-- **dynamic-table-alter** — 修改动态表的操作型子技能（10 种修改操作）
-- **sql-to-dt** — SQL 转 DT 的转换型子技能（6 步自动转换工作流）

package/bin/skills/clickzetta-dynamic-table/best-practices/dimension-table-join-guide.md

@@ -1,253 +0,0 @@
-# 维度表 JOIN 场景详解
-
-## 核心机制
-
-将某张表标记为维度表（dimension table）后，增量引擎会将该表的变更数据视为**空**。即：
-- 维度表的任何数据变更（INSERT/UPDATE/DELETE）都**不会触发增量计算**
-- 增量计算时，维度表始终读取**最新全量数据**
-- 只有非维度表（事实表）的变更才会驱动增量刷新
-
-## 配置方式
-
-```sql
--- 方式1：DT 表属性（推荐，跟随 DT 定义）
-CREATE DYNAMIC TABLE my_dt
-TBLPROPERTIES('mv_const_tables'='dim_table1,dim_table2')
-AS SELECT ...;
-
--- 方式2：Session 配置（在 REFRESH 前设置，灵活可动态调整）
-set CZ_OPTIMIZER_INCREMENTAL_DIMENSION_TABLES=dim_table1:dim_table2
-```
-
-## 各 JOIN 类型下的增量行为
-
-### A LEFT JOIN B（B 为维度表）
-
-这是最常见的维度表 JOIN 场景。
-
-**Case 1：A 有增量数据，B 无变化**
-```
-增量计划：A 的变更数据 LEFT JOIN B 的全量数据
-```
-- 新增的 A 行与 B 的最新数据做 LEFT JOIN
-- 如果 JOIN 上 → 输出完整行
-- 如果没 JOIN 上 → B 侧输出 NULL
-- ✅ 结果正确
-
-**Case 2：B 有数据变更，A 无变化**
-```
-增量计划：不触发计算（变更数据为空）
-```
-- B 的变更被完全忽略
-- 之前 A 行没 JOIN 上 B 输出的 `(xxx, NULL)` 不会被修正为 `(xxx, yyy)`
-- 之前 A 行 JOIN 上的旧 B 数据不会被更新为新值
-- ⚠️ 结果与全量重算不一致，但这是**预期行为**
-
-**Case 3：A 和 B 同时有变化**
-```
-增量计划：A 的变更数据 LEFT JOIN B 的全量数据
-```
-- 只处理 A 的增量，B 的变更被忽略
-- 新增的 A 行会 JOIN 到 B 的最新数据
-- 但已有的 A 行不会因 B 的变更而更新
-- ⚠️ 新旧数据可能存在不一致
-
-### A INNER JOIN B（B 为维度表）
-
-**Case 1：A 有增量数据，B 无变化**
-```
-增量计划：A 的变更数据 INNER JOIN B 的全量数据
-```
-- 新增的 A 行与 B 做 INNER JOIN
-- JOIN 不上的 A 行被丢弃
-- ✅ 结果正确
-
-**Case 2：B 有数据变更，A 无变化**
-```
-增量计划：不触发计算
-```
-- B 新增了能匹配已有 A 行的数据 → 不会产出新结果
-- B 删除了匹配已有 A 行的数据 → 已输出的结果不会被撤回
-- ⚠️ 结果与全量重算不一致
-
-### 多表 JOIN 中的维度表
-
-```sql
--- t2, t3 都是维度表
-CREATE DYNAMIC TABLE dt
-TBLPROPERTIES('mv_const_tables'='t2,t3')
-AS
-SELECT t1.*, t2.v1, t3.v1
-FROM t1
-LEFT JOIN t2 ON t1.id = t2.id
-LEFT JOIN t3 ON t1.id = t3.id;
-```
-
-- 只有 t1 的变更会触发增量计算
-- t2、t3 的变更都被忽略
-- 增量计划：t1 的变更数据 LEFT JOIN t2 的全量数据 LEFT JOIN t3 的全量数据
-
-## 适合使用维度表的场景
-
-### ✅ 推荐场景
-
-1. **码表/字典表 JOIN**
-   - 如：地区码表、产品分类表、状态码映射表
-   - 特点：数据量小、极少变更、即使变更也不影响历史分析
-   ```sql
-   -- 地区码表几乎不变
-   TBLPROPERTIES('mv_const_tables'='dim_region')
-   ```
-
-2. **T+1 维度表 + 实时事实表**
-   - 维度表每天批量更新一次，事实表持续写入
-   - 在两次维度表更新之间，维度表可视为不变
-   ```sql
-   -- 用户画像表每天更新，订单表实时写入
-   TBLPROPERTIES('mv_const_tables'='dim_user_profile')
-   ```
-
-3. **配置表 JOIN**
-   - 如：业务规则配置、阈值配置、权重配置
-   - 变更频率极低，且变更后可以手动触发全量刷新
-   ```sql
-   TBLPROPERTIES('mv_const_tables'='config_rules')
-   ```
-
-4. **大事实表 JOIN 小维度表，且对维度表变更的实时性要求低**
-   - 核心诉求是事实表的增量计算性能
-   - 维度表偶尔变更后，可以接受短暂的数据不一致
-   ```sql
-   -- 商品信息表偶尔更新，订单表持续写入
-   TBLPROPERTIES('mv_const_tables'='dim_product')
-   ```
-
-5. **不支持 time travel 的外部表作为 JOIN 右表**
-   - 外部表无法提供变更数据，标记为维度表后可以正常进行增量计算
-   - 增量引擎会读取外部表的最新快照
-   ```sql
-   -- 外部 MySQL 表不支持 time travel
-   TBLPROPERTIES('mv_const_tables'='external_mysql_table')
-   ```
-
-### ❌ 不推荐场景
-
-1. **维度表频繁更新且要求结果实时一致**
-   - 如：用户状态表每分钟更新，且下游报表要求实时反映最新状态
-   - 此时不应标记为维度表，应让两侧都参与增量计算
-
-2. **维度表变更会影响聚合结果的正确性**
-   - 如：价格表更新后，历史订单的金额计算应该用旧价格
-   - 但维度表标记后，新的事实行会 JOIN 到新价格，旧事实行保持旧价格
-   - 如果业务要求所有行统一使用最新价格，不应使用维度表
-
-3. **维度表数据量大且变更频繁**
-   - 维度表标记的优化收益来自跳过变更数据的计算
-   - 如果维度表本身很大且频繁变更，应该考虑让它正常参与增量
-
-## 维度表变更后的数据订正
-
-由于维度表的变更不会触发增量计算，当维度表发生了重要变更（如修正了错误数据、更新了映射关系），DT 中已有的结果不会自动更新。**如果需要订正数据，必须执行全量刷新。**
-
-```sql
--- 强制全量刷新（推荐）
-set cz.optimizer.incremental.force.full.refresh=true
-REFRESH DYNAMIC TABLE my_dt;
--- 刷新完成后记得关闭，否则后续每次都是全量
-set cz.optimizer.incremental.force.full.refresh=false
-
--- 如果是分区表，也可以只全量刷新指定分区
-set cz.optimizer.incremental.force.full.refresh=true
-set dt.args.ds=2025-01-01
-REFRESH DYNAMIC TABLE my_dt PARTITION(ds = '2025-01-01');
-set cz.optimizer.incremental.force.full.refresh=false
-```
-
-配置说明：
-- `cz.optimizer.incremental.force.full.refresh`：默认 `false`。设为 `true` 后，下一次 REFRESH 会忽略增量逻辑，对所有源表做全量扫描重算
-- 该配置是 session 级别的，刷新完成后需要手动设回 `false`，否则后续所有 REFRESH 都会走全量
-- backfill 模式（`cz.optimizer.incremental.backfill.enabled=TRUE`）也会自动开启全量刷新
-
-## 性能收益
-
-标记维度表后的优化效果：
-- **跳过维度表的变更数据扫描**：不需要读取维度表的变更日志
-- **简化增量计划**：只需要用事实表的变更数据 JOIN 维度表的全量数据，不需要反向计算
-
-## ⚠️ 开启维度表后可能出现的数据不一致与重复
-
-标记维度表是一种**用一致性换性能**的权衡。以下是具体会出现问题的场景，使用前务必评估业务是否可以接受。
-
-### 场景 1：LEFT JOIN 维度表更新导致 NULL 不被修正
-
-```sql
--- DT 定义
-SELECT order.*, product.name
-FROM order LEFT JOIN product ON order.pid = product.id;
--- product 标记为维度表
-```
-
-| 时间 | 事件 | DT 中的结果 | 全量重算应有的结果 |
-|------|------|------------|------------------|
-| T1 | order 插入 (pid=100)，product 中无 id=100 | (pid=100, name=NULL) | (pid=100, name=NULL) |
-| T2 | product 插入 id=100, name='手机' | (pid=100, name=NULL) **不变** | (pid=100, name='手机') |
-
-**原因**：product 的变更不触发增量计算，T1 输出的 NULL 行永远不会被修正。
-
-### 场景 2：INNER JOIN 维度表新增数据导致结果缺失
-
-```sql
-SELECT order.*, product.name
-FROM order INNER JOIN product ON order.pid = product.id;
--- product 标记为维度表
-```
-
-| 时间 | 事件 | DT 中的结果 | 全量重算应有的结果 |
-|------|------|------------|------------------|
-| T1 | order 插入 (pid=200)，product 中无 id=200 | 无输出（INNER JOIN 不匹配） | 无输出 |
-| T2 | product 插入 id=200, name='电脑' | **仍然无输出** | (pid=200, name='电脑') |
-
-**原因**：product 的新增不触发增量，已有的 order 行不会被重新 JOIN。
-
-### 场景 3：维度表删除/更新导致过期数据残留
-
-```sql
-SELECT order.*, product.name, product.price
-FROM order LEFT JOIN product ON order.pid = product.id;
--- product 标记为维度表
-```
-
-| 时间 | 事件 | DT 中的结果 | 全量重算应有的结果 |
-|------|------|------------|------------------|
-| T1 | order 插入 (pid=100)，product id=100 price=99 | (pid=100, price=99) | (pid=100, price=99) |
-| T2 | product 更新 id=100 price=**199** | (pid=100, price=**99**) 旧值残留 | (pid=100, price=199) |
-| T3 | product 删除 id=100 | (pid=100, price=**99**) 仍然残留 | (pid=100, name=NULL) |
-
-**原因**：维度表的 UPDATE/DELETE 都被忽略，已输出的行保持旧值。
-
-### 场景 4：维度表 + 聚合导致聚合结果不一致
-
-```sql
-SELECT product.category, SUM(order.amount) as total
-FROM order LEFT JOIN product ON order.pid = product.id
-GROUP BY product.category;
--- product 标记为维度表
-```
-
-| 时间 | 事件 | DT 中的结果 | 全量重算应有的结果 |
-|------|------|------------|------------------|
-| T1 | order (pid=1, amount=100)，product (id=1, category='A') | category='A', total=100 | 同左 |
-| T2 | product 更新 id=1 的 category 从 'A' 改为 'B' | category='A', total=100 **不变** | category='B', total=100 |
-| T3 | order 新增 (pid=1, amount=200) | category='B', total=200（新行 JOIN 到新 category）| category='B', total=300 |
-
-**原因**：T2 的 category 变更不触发重算，T1 的旧数据仍按旧 category 聚合。T3 的新数据按新 category 聚合。最终结果中同一个 pid 的数据被分到了不同 category，聚合结果错乱。
-
-### 总结：什么时候结果会不一致
-
-| 维度表变更类型 | LEFT JOIN | INNER JOIN |
-|--------------|-----------|------------|
-| 新增匹配行 | 旧 fact 行的 NULL 不被修正 | 旧 fact 行不会产出新结果 |
-| 更新已有行 | 旧 fact 行保持旧值 | 旧 fact 行保持旧值 |
-| 删除已有行 | 旧 fact 行保持旧值（不会变 NULL） | 旧 fact 行不会被撤回 |
-
-**核心原则**：维度表的任何变更都不会影响已经输出的结果行。只有新的事实表增量才会 JOIN 到维度表的最新快照。

package/bin/skills/clickzetta-dynamic-table/best-practices/medallion-and-stream-patterns.md

@@ -1,124 +0,0 @@
-# Medallion 架构与 Table Stream 组合模式
-
-## Medallion 三层管道
-
-```
-Bronze（原始数据）
-    ↓ Dynamic Table（清洗，INCREMENTAL）
-Silver（清洗数据）
-    ↓ Dynamic Table（聚合，FULL）
-Gold（指标数据）
-    ↓ BI 工具直接查询
-```
-
-### Bronze → Silver（增量清洗）
-
-```sql
--- 前提：源表开启变更跟踪
-ALTER TABLE bronze.raw_orders SET PROPERTIES ('change_tracking' = 'true');
-
-CREATE DYNAMIC TABLE IF NOT EXISTS silver.orders_cleaned
-REFRESH INTERVAL 15 MINUTE vcluster default
-AS
-SELECT
-  order_id,
-  customer_id,
-  CAST(amount AS DECIMAL(18,2))  AS amount,
-  CAST(created_at AS TIMESTAMP)  AS created_at,
-  COALESCE(region, 'unknown')    AS region
-FROM bronze.raw_orders
-WHERE order_id IS NOT NULL AND amount > 0;
-```
-
-### Silver → Gold（聚合指标，通常 FULL）
-
-```sql
-CREATE DYNAMIC TABLE IF NOT EXISTS gold.orders_daily_summary
-REFRESH INTERVAL 60 MINUTE vcluster default
-AS
-SELECT
-  DATE(created_at)              AS stat_date,
-  region,
-  COUNT(*)                      AS order_count,
-  SUM(amount)                   AS total_revenue,
-  COUNT(DISTINCT customer_id)   AS unique_customers
-FROM silver.orders_cleaned
-GROUP BY 1, 2;
-```
-
----
-
-## 与 Table Stream 组合（事件驱动）
-
-Table Stream 捕获源表变更，Dynamic Table 消费 Stream 做增量处理。
-
-### 基本模式
-
-```sql
--- 1. 源表开启变更跟踪
-ALTER TABLE bronze.raw_orders SET PROPERTIES ('change_tracking' = 'true');
-
--- 2. 创建 Table Stream
-CREATE TABLE STREAM bronze.orders_stream
-  ON TABLE bronze.raw_orders
-  WITH PROPERTIES ('TABLE_STREAM_MODE' = 'STANDARD');
-
--- 3. Dynamic Table 消费 Stream
--- 注意：Stream 作为 DT 源时，每次刷新会消费 offset
-CREATE DYNAMIC TABLE IF NOT EXISTS silver.orders_incremental
-REFRESH INTERVAL 5 MINUTE vcluster default
-AS
-SELECT order_id, customer_id, amount, status
-FROM bronze.orders_stream
-WHERE __change_type IN ('INSERT', 'UPDATE_AFTER');
-```
-
-### MERGE INTO + Table Stream（替代非分区 DT 的去重场景）
-
-当需要按主键去重且源表持续写入时，推荐用 MERGE INTO 替代 Dynamic Table：
-
-```sql
--- 1. 创建 Table Stream
-CREATE TABLE STREAM source_stream ON TABLE source_table
-WITH PROPERTIES ('TABLE_STREAM_MODE' = 'STANDARD', 'SHOW_INITIAL_ROWS' = 'TRUE');
-
--- 2. 创建目标表
-CREATE TABLE target_table (
-    id BIGINT,
-    col1 STRING,
-    col2 INT,
-    event_time TIMESTAMP
-);
-
--- 3. 定时调度 MERGE INTO 消费 Stream
-MERGE INTO target_table t
-USING (
-    SELECT id, col1, col2, event_time,
-        CASE WHEN `value` IS NULL OR `value` = '' THEN 'DELETE' ELSE 'UPSERT' END AS op
-    FROM source_stream
-) s ON t.id = s.id
-WHEN MATCHED AND s.op = 'UPSERT' THEN UPDATE SET
-    t.col1 = s.col1, t.col2 = s.col2, t.event_time = s.event_time
-WHEN NOT MATCHED AND s.op = 'UPSERT' THEN INSERT
-    (id, col1, col2, event_time) VALUES (s.id, s.col1, s.col2, s.event_time);
-```
-
----
-
-## 实时报表物化
-
-```sql
--- 每小时刷新销售汇总，供 BI 工具直接查询
-CREATE DYNAMIC TABLE IF NOT EXISTS rpt.sales_hourly
-REFRESH INTERVAL 60 MINUTE vcluster default
-AS
-SELECT
-  DATE_TRUNC('hour', order_time) AS hour_bucket,
-  product_category,
-  SUM(amount)                    AS revenue,
-  COUNT(*)                       AS order_cnt,
-  AVG(amount)                    AS avg_order_value
-FROM silver.orders_cleaned
-WHERE order_time >= DATEADD(day, -30, CURRENT_DATE)
-GROUP BY 1, 2;
-```