@clickzetta/cz-cli-darwin-arm64 0.3.87 → 0.3.88

package/bin/skills/clickzetta-dynamic-table/best-practices/non-partitioned-merge-into-warning.md

@@ -1,53 +1,53 @@
-# 非分区表 + 持续写入：DT 风险告警与 MERGE INTO 替代建议
+# Non-partitioned Table + Continuous Writes: DT Risk Alert and MERGE INTO Alternative
 
-## 触发条件
+## Trigger Conditions
 
-当用户要创建的 DT 同时满足以下条件时，**必须向用户发出告警**：
+When the DT the user is about to create simultaneously meets all of the following conditions, **an alert must be issued to the user**:
 
-1. DT 本身是非分区表（没有 `PARTITIONED BY`，也没有 `SESSION_CONFIGS()` 引用）
-2. 源表也是非分区表，且数据会持续写入（如 Kafka 消费落地表、CDC 明细表）
-3. SQL 中包含按主键去重的窗口函数模式：`ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts DESC) WHERE rn = 1`
+1. The DT itself is a non-partitioned table (no `PARTITIONED BY` and no `SESSION_CONFIGS()` references)
+2. The source table is also a non-partitioned table with continuous writes (e.g., a Kafka consumer landing table, a CDC detail table)
+3. The SQL contains a window function deduplication pattern by primary key: `ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts DESC) WHERE rn = 1`
 
-## 告警内容
+## Alert Content
 
-向用户说明以下三个风险：
+Explain the following three risks to the user:
 
-### 风险 1：存储无限膨胀
+### Risk 1: Unbounded Storage Growth
 
-非分区的 DT 和非分区的源表都没有自动的数据生命周期管理机制（`data_lifecycle` 仅对分区表生效）。随着数据持续写入：
-- 源表数据量无限增长
-- DT 的状态表全局维护，随数据量线性膨胀
-- 目标表数据量同步增长
-- 三者叠加，存储成本持续上升且不可控
+Non-partitioned DTs and non-partitioned source tables both lack automatic data lifecycle management (`data_lifecycle` only works for partitioned tables). As data continues to be written:
+- Source table data grows without bound
+- DT state tables are maintained globally and grow linearly with data volume
+- Target table data grows in sync
+- All three combined result in continuously rising and uncontrollable storage costs
 
-### 风险 2：源表归档引发性能灾难
+### Risk 2: Source Table Archiving Causes Performance Disaster
 
-当存储膨胀到一定程度，运维人员通常会对源表进行归档——将历史数据迁移到冷存储或归档表，然后从源表中删除以释放空间。此时：
+When storage grows to a certain point, operations teams typically archive the source table — migrating historical data to cold storage or an archive table, then deleting it from the source table to free space. At this point:
 
-- DT 会捕获源表的删除事件，并将其反映到增量计算结果中
-- `ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts DESC) WHERE rn = 1` 的删除处理代价极高：
-  - 窗口函数无法增量处理删除——需要回读该 key 下的所有历史数据重新排序
-  - 非分区表没有分区边界来限制回读范围，可能需要扫描整张表
-  - 大规模归档会产生海量删除变更，每个 key 都需要独立回算
-- 一次源表归档可能导致 DT REFRESH 耗时从秒级飙升到小时级甚至失败
+- The DT captures the source table's delete events and reflects them in incremental computation results
+- The `ROW_NUMBER() OVER (PARTITION BY key ORDER BY ts DESC) WHERE rn = 1` delete handling cost is extremely high:
+  - Window functions cannot handle deletes incrementally — they need to re-read all historical data for that key and re-sort
+  - Non-partitioned tables have no partition boundaries to limit the re-read scope; may need to scan the entire table
+  - Large-scale archiving produces massive delete changes; each key needs to be independently recomputed
+- A single source table archiving operation can cause DT REFRESH duration to spike from seconds to hours, or even fail
 
-### 风险 3：无法过滤归档产生的删除事件
+### Risk 3: Cannot Filter Archive-generated Delete Events
 
-DT 的增量引擎自动捕获源表的所有变更（INSERT / UPDATE / DELETE），用户无法干预这个过程。SQL 中的 `WHERE op <> 'DELETE'` 过滤的是业务层面的删除标记，而不是源表物理删除产生的删除变更。用户没有任何手段告诉 DT "这些删除是归档操作，请忽略"。
+The DT's incremental engine automatically captures all changes to the source table (INSERT / UPDATE / DELETE); users cannot intervene in this process. `WHERE op <> 'DELETE'` in the SQL filters business-level delete markers, not physical deletes from the source table. Users have no way to tell the DT "these deletes are archiving operations; please ignore them."
 
-## 推荐替代方案
+## Recommended Alternative
 
-建议用户使用 MERGE INTO + Table Stream 替代：
+Suggest the user use MERGE INTO + Table Stream instead:
 
 ```sql
--- Step 1: 源表开启变更跟踪
+-- Step 1: Enable change tracking on source table
 ALTER TABLE source_table SET PROPERTIES ('change_tracking' = 'true');
 
--- Step 2: 创建 Table Stream
+-- Step 2: Create Table Stream
 CREATE TABLE STREAM source_stream ON TABLE source_table
 WITH (TABLE_STREAM_MODE = 'STANDARD', SHOW_INITIAL_ROWS = TRUE);
 
--- Step 3: 创建目标表
+-- Step 3: Create target table
 CREATE TABLE target_table (
     id BIGINT,
     col1 STRING,
@@ -55,7 +55,7 @@ CREATE TABLE target_table (
     event_time TIMESTAMP
 );
 
--- Step 4: 定时调度 MERGE INTO 消费 Stream
+-- Step 4: Scheduled MERGE INTO to consume Stream
 MERGE INTO target_table t
 USING (
     SELECT id, col1, col2, event_time,
@@ -68,29 +68,29 @@ WHEN NOT MATCHED AND s.op = 'UPSERT' THEN INSERT
     (id, col1, col2, event_time) VALUES (s.id, s.col1, s.col2, s.event_time);
 ```
 
-MERGE INTO + Table Stream 的优势：
-- **每次计算独立**：只消费 Stream 中的增量数据，不依赖源表全量状态
-- **归档免疫**：源表归档时，可在 USING 子查询中通过 WHERE 条件过滤归档产生的删除事件
-- **目标表独立管理**：目标表的生命周期与源表解耦，可独立制定归档策略
-- **offset 自动推进**：MERGE INTO 消费 Stream 后 offset 自动推进，下次只处理新变更
+Advantages of MERGE INTO + Table Stream:
+- **Each computation is independent**: only consumes incremental data from the Stream; does not depend on the source table's full state
+- **Archive-immune**: when the source table is archived, archive-generated delete events can be filtered via WHERE conditions in the USING subquery
+- **Independent target table management**: the target table's lifecycle is decoupled from the source table; independent archiving strategies can be set
+- **Offset auto-advances**: after MERGE INTO consumes the Stream, the offset automatically advances; only new changes are processed next time
 
-## 告警话术模板
+## Alert Message Template
 
-当检测到用户的 DT 满足触发条件时，使用以下话术：
+When the user's DT is detected to meet the trigger conditions, use the following message:
 
-> ⚠️ **风险提示**：您正在创建一个非分区的 Dynamic Table，且源表也是非分区的持续写入表。这种组合存在以下长期运维风险：
+> ⚠️ **Risk Warning**: You are creating a non-partitioned Dynamic Table, and the source table is also a non-partitioned table with continuous writes. This combination has the following long-term operational risks:
 >
-> 1. **存储无限膨胀**：源表、DT 目标表、DT 状态表三者都会持续增长，且无法通过 `data_lifecycle` 自动清理
-> 2. **源表归档会引发性能灾难**：当您需要对源表进行归档（迁移历史数据后删除）时，DT 会捕获这些删除事件。由于 SQL 中包含 `ROW_NUMBER() ... WHERE rn = 1` 的去重逻辑，每个被删除的 key 都需要回读历史数据重新排序，非分区表没有边界限制，可能导致 REFRESH 性能严重回退
-> 3. **无法过滤归档删除**：DT 增量引擎自动捕获源表所有变更，您无法告诉 DT 忽略归档操作产生的删除
+> 1. **Unbounded storage growth**: the source table, DT target table, and DT state tables will all grow continuously and cannot be automatically cleaned up via `data_lifecycle`
+> 2. **Source table archiving will cause a performance disaster**: when you need to archive the source table (migrate historical data then delete), the DT will capture these delete events. Because the SQL contains `ROW_NUMBER() ... WHERE rn = 1` deduplication logic, each deleted key needs to re-read historical data and re-sort; non-partitioned tables have no boundary limits, which may cause serious REFRESH performance regression
+> 3. **Cannot filter archive deletes**: the DT incremental engine automatically captures all source table changes; you cannot tell the DT to ignore deletes generated by archiving operations
 >
-> **建议**：对于这类"非分区 CDC 明细表合并为结果表"的场景，推荐使用 MERGE INTO + Table Stream 方案。每次只消费增量数据，源表归档时可通过 WHERE 条件过滤删除事件，不会影响下游。
+> **Recommendation**: For this type of "merge non-partitioned CDC detail table into result table" scenario, the MERGE INTO + Table Stream approach is recommended. Each run only consumes incremental data; archive-generated delete events can be filtered via WHERE conditions, without affecting downstream.
 
-## 判断逻辑
+## Detection Logic
 
-在帮助用户创建 DT 时，按以下顺序检查：
+When helping users create a DT, check in the following order:
 
-1. DT 是否有 `PARTITIONED BY` 或 `SESSION_CONFIGS()` → 如果有，不触发告警
-2. 源表是否是持续写入的非分区表（如 Kafka 消费表、CDC 明细表）→ 如果不是，不触发告警
-3. SQL 是否包含 `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ... DESC) WHERE rn = 1` 模式 → 如果包含，风险最高，必须告警
-4. 即使没有 ROW_NUMBER，只要满足条件 1+2，也应提醒用户注意存储膨胀风险
+1. Does the DT have `PARTITIONED BY` or `SESSION_CONFIGS()`? → If yes, do not trigger alert
+2. Is the source table a non-partitioned table with continuous writes (e.g., Kafka consumer table, CDC detail table)? → If not, do not trigger alert
+3. Does the SQL contain the `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ... DESC) WHERE rn = 1` pattern? → If yes, highest risk; must alert
+4. Even without ROW_NUMBER, if conditions 1+2 are met, remind the user of the storage growth risk

package/bin/skills/clickzetta-dynamic-table/best-practices/performance-optimization.md

@@ -1,109 +1,109 @@
-# Dynamic Table 性能优化指南
+# Dynamic Table Performance Optimization Guide
 
-本文档从 SQL 写法、数据特征、管道设计三个维度，帮助用户写出增量刷新性能更好的 DT。
+This document helps users write DTs with better incremental refresh performance from three dimensions: SQL writing, data characteristics, and pipeline design.
 
-## 核心原则：增量刷新的代价模型
+## Core Principle: The Cost Model of Incremental Refresh
 
-增量刷新的性能取决于三个因素：
-1. **变更量占比**：每次刷新时，源表中有多少数据发生了变化。变更量越小，增量越划算
-2. **算子类型**：不同 SQL 算子的增量代价差异很大
-3. **数据局部性**：变更数据在 JOIN key / GROUP BY key / PARTITION BY key 上的分布是否集中
+Incremental refresh performance depends on three factors:
+1. **Change ratio**: how much data in the source table changed during each refresh. The smaller the change volume, the more worthwhile incremental is.
+2. **Operator type**: different SQL operators have very different incremental costs.
+3. **Data locality**: whether the changed data is concentrated on JOIN keys / GROUP BY keys / PARTITION BY keys.
 
-当变更量超过总数据量的较大比例时，增量刷新可能反而比全量刷新更慢，因为增量需要额外的变更数据计算、去重合并、状态表读写等开销。
+When the change volume exceeds a significant proportion of total data, incremental refresh may actually be slower than full refresh, because incremental has additional overhead for change data computation, deduplication merging, state table read/write, etc.
 
-## SQL 写法优化
+## SQL Writing Optimization
 
-### 1. 优先使用 INNER JOIN 而非 OUTER JOIN
+### 1. Prefer INNER JOIN over OUTER JOIN
 
-INNER JOIN 的增量计算比 OUTER JOIN 更高效：
-- INNER JOIN：只需要计算 A 的变更数据 JOIN B 的全量数据 + A 的全量数据 JOIN B 的变更数据
-- LEFT/RIGHT/FULL OUTER JOIN：还需要额外处理 NULL 填充、反向撤回等逻辑
+INNER JOIN incremental computation is more efficient than OUTER JOIN:
+- INNER JOIN: only needs to compute A's change data JOIN B's full data + A's full data JOIN B's change data
+- LEFT/RIGHT/FULL OUTER JOIN: also needs to handle NULL filling, reverse retraction, and other logic
 
-如果业务上可以保证参照完整性（即 JOIN key 一定能匹配），优先用 INNER JOIN。
+If business logic can guarantee referential integrity (i.e., JOIN keys will always match), prefer INNER JOIN.
 
 ```sql
--- ❌ 不必要的 LEFT JOIN（如果 product 一定存在）
+-- ❌ Unnecessary LEFT JOIN (if product is guaranteed to exist)
 SELECT o.*, p.name FROM orders o LEFT JOIN products p ON o.pid = p.id;
 
--- ✅ 改用 INNER JOIN
+-- ✅ Switch to INNER JOIN
 SELECT o.*, p.name FROM orders o INNER JOIN products p ON o.pid = p.id;
 ```
 
-### 2. 减少不必要的 DISTINCT
+### 2. Reduce Unnecessary DISTINCT
 
-每次增量刷新时，DISTINCT 需要对受影响的 key 做重算。如果上游数据已经去重，或者可以通过其他方式保证唯一性，去掉 DISTINCT。
+On every incremental refresh, DISTINCT needs to recompute affected keys. If upstream data is already deduplicated, or uniqueness can be guaranteed another way, remove DISTINCT.
 
 ```sql
--- ❌ 冗余的 DISTINCT
+-- ❌ Redundant DISTINCT
 SELECT DISTINCT user_id, user_name FROM user_events;
 ```
 
-### 3. 窗口函数必须有 PARTITION BY
+### 3. Window Functions Must Have PARTITION BY
 
-没有 PARTITION BY 的窗口函数会导致每次增量刷新都全量重算整个窗口。加上 PARTITION BY 后，只需要重算受影响的分区。
+Window functions without PARTITION BY cause every incremental refresh to fully recompute the entire window. With PARTITION BY, only affected partitions need to be recomputed.
 
 ```sql
--- ❌ 全局窗口，每次增量都全量重算
+-- ❌ Global window; every incremental refresh does a full recomputation
 SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM events;
 
--- ✅ 加上 PARTITION BY，只重算有变更的分区
+-- ✅ Add PARTITION BY; only recompute partitions with changes
 SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY created_at DESC) AS rn FROM events;
 ```
 
-### 4. 聚合 key 尽量使用简单列引用
+### 4. Use Simple Column References as Aggregation Keys
 
-复合表达式作为 GROUP BY key 会降低增量效率，因为引擎需要对表达式求值后才能判断哪些 key 受影响。
+Compound expressions as GROUP BY keys reduce incremental efficiency, because the engine needs to evaluate the expression before determining which keys are affected.
 
 ```sql
--- ❌ 复合表达式作为 GROUP BY key
+-- ❌ Compound expression as GROUP BY key
 SELECT DATE_TRUNC('hour', ts) AS hour, SUM(amount)
 FROM transactions
 GROUP BY DATE_TRUNC('hour', ts);
 
--- ✅ 如果可能，在上游预计算好 key 列
--- 或者拆分为两个 DT（见下文"管道拆分"）
+-- ✅ If possible, pre-compute the key column upstream
+-- Or split into two DTs (see "Pipeline Splitting" below)
 ```
 
-### 5. 尽可能使用分区条件限制数据范围
+### 5. Use Partition Conditions to Limit Data Range Where Possible
 
-在 DT 的 SQL 中对源表添加分区过滤条件，可以显著减少每次增量刷新需要扫描的数据量。
+Adding partition filter conditions on source tables in the DT's SQL can significantly reduce the amount of data that needs to be scanned on each incremental refresh.
 
 ```sql
--- ❌ 不加分区条件，每次扫描全表
+-- ❌ No partition condition; scans the full table every time
 SELECT o.*, p.name
 FROM orders o JOIN products p ON o.pid = p.id;
 
--- ✅ 通过分区条件限制数据范围
+-- ✅ Limit data range with partition condition
 SELECT o.*, p.name
 FROM orders o JOIN products p ON o.pid = p.id
 WHERE o.ds = SESSION_CONFIGS()['dt.args.ds'];
 ```
 
-## 管道拆分：复杂 DT 拆成多级
+## Pipeline Splitting: Break Complex DTs into Multiple Levels
 
-当一个 DT 的 SQL 包含多个 JOIN + 聚合 + 窗口函数时，考虑拆分为多个 DT，每个 DT 只做一件事。
+When a DT's SQL contains multiple JOINs + aggregations + window functions, consider splitting it into multiple DTs, each doing one thing.
 
-好处：
-- 每个 DT 的增量计算更简单、更快
-- 中间 DT 可以被多个下游 DT 复用
-- 出问题时更容易定位是哪一层的问题
-- 不同层可以使用不同的优化策略
+Benefits:
+- Each DT's incremental computation is simpler and faster
+- Intermediate DTs can be reused by multiple downstream DTs
+- Easier to pinpoint which layer has a problem when issues arise
+- Different layers can use different optimization strategies
 
-## 数据特征与增量效率
+## Data Characteristics and Incremental Efficiency
 
-### 变更量占比
+### Change Ratio
 
-增量刷新在变更量占总数据量比例较小时效果最好。经验值：
-- < 5%：增量刷新通常显著优于全量
-- 5% ~ 20%：取决于具体算子和数据分布
-- \> 20%：可能需要评估是否全量刷新更合适
+Incremental refresh works best when the change volume is a small proportion of total data. Rule of thumb:
+- < 5%: incremental refresh is usually significantly better than full
+- 5% ~ 20%: depends on specific operators and data distribution
+- \> 20%: may need to evaluate whether full refresh is more appropriate
 
-### Append-Only 源表
+### Append-Only Source Tables
 
-如果源表只有 INSERT 没有 UPDATE/DELETE 可以显著优化：
-- 增量引擎知道变更数据只有新增（无撤回），可以跳过去重合并等操作
-- 聚合可以直接累加，不需要维护完整的中间状态
+If the source table only has INSERT and no UPDATE/DELETE, significant optimization is possible:
+- The incremental engine knows change data only has additions (no retractions), and can skip deduplication merging and other operations
+- Aggregation can directly accumulate without maintaining complete intermediate state
 
-### 变更数据的分布
+### Distribution of Changed Data
 
-如果变更数据集中在少数 key 上（如最近时间段的数据），增量效率高。如果变更分散在大量 key 上，聚合和窗口函数需要重算大量分区，效率下降。
+If changed data is concentrated on a few keys (e.g., recent time periods), incremental efficiency is high. If changes are spread across many keys, aggregation and window functions need to recompute many partitions, reducing efficiency.

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

@@ -1,19 +1,19 @@
-# Dynamic Table 调度方式选择指南
+# Dynamic Table Scheduling Method Selection Guide
 
-## 两种调度方式对比
+## Comparison of Two Scheduling Methods
 
-| 方式 | 做法 | 优点 | 缺点 |
+| Method | Approach | Advantages | Disadvantages |
 |------|------|------|------|
-| **DDL 内置调度**（REFRESH INTERVAL） | 在 CREATE DYNAMIC TABLE 时写 `REFRESH INTERVAL` 子句，由 Lakehouse 自动触发 | 简单，无需额外配置 | 无告警、无依赖编排、刷新状态只能手动 SQL 查询 |
-| **Studio Task 调度**（推荐） | 在 Studio 创建定时任务，任务内容为 `REFRESH DYNAMIC TABLE` 命令 | 支持上下游依赖、统一告警、可视化监控 | 需要额外创建 Task |
+| **DDL built-in scheduling** (REFRESH INTERVAL) | Write a `REFRESH INTERVAL` clause in CREATE DYNAMIC TABLE; Lakehouse triggers automatically | Simple; no additional configuration needed | No alerts, no dependency orchestration; refresh status can only be checked via manual SQL |
+| **Studio Task scheduling** (recommended) | Create a scheduled task in Studio; task content is the `REFRESH DYNAMIC TABLE` command | Supports upstream/downstream dependencies, unified alerts, visual monitoring | Requires creating an additional Task |
 
-**生产环境推荐使用 Studio Task 调度。** DDL 内置调度适合快速验证和开发测试阶段。
+**Studio Task scheduling is recommended for production environments.** DDL built-in scheduling is suitable for quick validation and development/testing phases.
 
 ---
 
-## DDL 内置调度
+## DDL Built-in Scheduling
 
-在 CREATE 语句中通过 `REFRESH INTERVAL` 子句定义刷新频率，Lakehouse 自动周期性触发：
+Define the refresh frequency via the `REFRESH INTERVAL` clause in the CREATE statement; Lakehouse triggers periodically:
 
 ```sql
 CREATE DYNAMIC TABLE sales_daily
@@ -25,111 +25,111 @@ FROM orders
 GROUP BY 1;
 ```
 
-### 弊端
+### Drawbacks
 
-- **无告警**：刷新失败不会主动通知，只能手动执行 SQL 查询状态
-- **无依赖编排**：无法声明"等上游任务完成后再刷新"，只能靠时间间隔错开
-- **监控成本高**：需要定期手动执行以下命令检查刷新是否正常
+- **No alerts**: refresh failures are not proactively notified; status can only be checked by manually executing SQL
+- **No dependency orchestration**: cannot declare "refresh only after upstream task completes"; can only stagger by time interval
+- **High monitoring cost**: need to periodically manually execute the following command to check whether refresh is normal
 
 ```sql
--- 查看刷新历史，确认 state 是否为 SUCCEED
+-- View refresh history; confirm state is SUCCEED
 SHOW DYNAMIC TABLE REFRESH HISTORY WHERE name = 'your_dt_name';
 ```
 
-关键字段说明：
+Key field descriptions:
 
-| 字段 | 含义 |
+| Field | Meaning |
 |------|------|
 | `state` | SUCCEED / FAILED / RUNNING / QUEUED |
 | `refresh_mode` | INCREMENTAL / FULL / NO_DATA |
-| `error_message` | 失败时的错误信息 |
-| `duration` | 本次刷新耗时 |
-| `stats` | 增量行数（rows_inserted / rows_deleted） |
+| `error_message` | Error message on failure |
+| `duration` | Duration of this refresh |
+| `stats` | Incremental row count (rows_inserted / rows_deleted) |
 
 ---
 
-## Studio Task 调度（生产推荐）
+## Studio Task Scheduling (Recommended for Production)
 
-在 Studio 中创建 SQL 任务，任务内容为 REFRESH 命令，通过 Studio 的调度系统管理执行。
+Create a SQL task in Studio; task content is the REFRESH command; managed by Studio's scheduling system.
 
-### Task 内容
+### Task Content
 
-**非分区 DT：**
+**Non-partitioned DT:**
 
 ```sql
 REFRESH DYNAMIC TABLE schema_name.dt_name;
 ```
 
-**分区 DT（带参数）：**
+**Partitioned DT (with parameters):**
 
 ```sql
 SET dt.args.ds = '${bizdate}';
 REFRESH DYNAMIC TABLE schema_name.dt_name PARTITION (ds = '${bizdate}');
 ```
 
-`${bizdate}` 由 Studio 调度引擎在每次执行时自动替换为业务日期。
+`${bizdate}` is automatically replaced with the business date by the Studio scheduling engine at each execution.
 
-### 必须配置自依赖
+### Must Configure Self-dependency
 
-同一张 DT 禁止并发 REFRESH（会导致写冲突或数据不一致）。Task 必须开启**自依赖**，确保上一个实例完成后才启动下一个实例。
+Concurrent REFRESH on the same DT is prohibited (causes write conflicts or data inconsistency). The Task must enable **self-dependency** to ensure the next instance starts only after the previous one completes.
 
-### 上游依赖配置
+### Upstream Dependency Configuration
 
-- 如果 DT 的源表数据需要等上游任务产出后才能刷新 → 配置上游依赖
-- 如果源表数据不要求同步就绪（如实时写入表）→ 可以不配置上游依赖
+- If the DT's source table data needs to wait for an upstream task to produce before refreshing → configure upstream dependency
+- If source table data does not require synchronized readiness (e.g., real-time write table) → upstream dependency is optional
 
-### 告警配置
+### Alert Configuration
 
-Studio Task 支持以下告警规则，生产环境建议全部配置：
+Studio Tasks support the following alert rules; all are recommended for production environments:
 
-- **失败告警**：任务执行失败时通知
-- **超时告警**：刷新耗时超过阈值时通知（用于发现性能回退）
-- **未运行告警**：任务在预期时间内未启动时通知
+- **Failure alert**: notify when task execution fails
+- **Timeout alert**: notify when refresh duration exceeds a threshold (used to detect performance regression)
+- **Not-run alert**: notify when the task has not started within the expected time
 
 ---
 
-## 多级 DT 管道的调度编排
+## Scheduling Orchestration for Multi-level DT Pipelines
 
-当存在多张 DT 形成上下游依赖时（如 DT_A → DT_B → DT_C），每张 DT 对应一个 Studio Task，通过任务依赖关系保证执行顺序：
+When multiple DTs form upstream/downstream dependencies (e.g., DT_A → DT_B → DT_C), each DT corresponds to one Studio Task; task dependency relationships ensure execution order:
 
 ```
 Task_A (REFRESH DT_A)
-    └─ Task_B (REFRESH DT_B，依赖 Task_A)
-        └─ Task_C (REFRESH DT_C，依赖 Task_B)
+    └─ Task_B (REFRESH DT_B, depends on Task_A)
+        └─ Task_C (REFRESH DT_C, depends on Task_B)
 ```
 
-不同分区的 REFRESH 可以并行执行（分配到不同 Task 实例），同一分区/非分区 DT 禁止并发。
+REFRESHes for different partitions can run in parallel (assigned to different Task instances); concurrent refresh of the same partition/non-partitioned DT is prohibited.
 
 ---
 
-## 判断逻辑：向用户推荐调度方式
+## Decision Logic: Recommend Scheduling Method to Users
 
-在帮助用户创建或配置 DT 时，按以下逻辑推荐：
+When helping users create or configure a DT, recommend based on the following logic:
 
-1. **是否有 Studio？**
-   - 有 → 始终推荐 Studio Task 调度，无论是开发还是生产环境
-   - 无 → 使用 DDL 内置调度或第三方调度引擎
+1. **Is Studio available?**
+   - Yes → always recommend Studio Task scheduling, regardless of development or production environment
+   - No → use DDL built-in scheduling or a third-party scheduling engine
 
-2. **是否有上下游依赖？**
-   - 有（如源表由另一个任务产出）→ 必须用 Studio Task，配置上游依赖
-   - 无 → 仍推荐 Studio Task，获得告警能力
+2. **Are there upstream/downstream dependencies?**
+   - Yes (e.g., source table is produced by another task) → must use Studio Task; configure upstream dependency
+   - No → still recommend Studio Task to gain alert capability
 
-3. **用户已经写了 REFRESH INTERVAL 子句？**
-   - 提示：可以去掉 REFRESH INTERVAL 子句，改用 Studio Task 调度，获得告警和依赖管理能力
-   - REFRESH INTERVAL 和 Studio Task 可以共存，但会导致双重触发，建议二选一
+3. **User has already written a REFRESH INTERVAL clause?**
+   - Suggest: the REFRESH INTERVAL clause can be removed and replaced with Studio Task scheduling to gain alert and dependency management capability
+   - REFRESH INTERVAL and Studio Task can coexist, but will cause double triggering; choosing one is recommended
 
 ---
 
-## 告警话术模板
+## Alert Message Template
 
-当用户使用 DDL 内置调度时，使用以下话术提示：
+When the user is using DDL built-in scheduling, use the following message:
 
-> 💡 **建议**：您当前使用的是 DDL 内置调度（REFRESH INTERVAL），这种方式存在以下局限：
+> 💡 **Suggestion**: You are currently using DDL built-in scheduling (REFRESH INTERVAL), which has the following limitations:
 >
-> 1. **无告警**：刷新失败不会主动通知，需要手动执行 `SHOW DYNAMIC TABLE REFRESH HISTORY` 查看状态
-> 2. **无依赖编排**：无法声明上下游任务依赖关系，只能靠时间间隔错开
+> 1. **No alerts**: refresh failures are not proactively notified; you need to manually execute `SHOW DYNAMIC TABLE REFRESH HISTORY` to check status
+> 2. **No dependency orchestration**: upstream/downstream task dependencies cannot be declared; can only stagger by time interval
 >
-> **推荐**：在 Studio 中创建定时调度任务，任务内容为 `REFRESH DYNAMIC TABLE schema.dt_name`，并配置：
-> - 自依赖（防止并发刷新）
-> - 失败告警 + 超时告警
-> - 上游依赖（如果源表由其他任务产出）
+> **Recommendation**: Create a scheduled task in Studio with content `REFRESH DYNAMIC TABLE schema.dt_name`, and configure:
+> - Self-dependency (prevent concurrent refresh)
+> - Failure alert + timeout alert
+> - Upstream dependency (if source table is produced by other tasks)

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

@@ -1,15 +1,16 @@
 ---
 name: dt-creator
 description: |
-  创建 Dynamic Table 的参考资料索引。涵盖静态分区 DT 与动态分区 DT 的声明策略、
-  增量计算支持的 SQL 模式、增量刷新配置项说明、以及刷新历史的查询方式。
+  Reference index for creating Dynamic Tables. Covers declaration strategies for static partition DT
+  vs dynamic partition DT, SQL patterns supported by incremental computation, incremental refresh
+  configuration options, and how to query refresh history.
 ---
 
-# DT Creator — 参考资料索引
+# DT Creator — Reference Index
 
 ## references/
 
-- **dt-declaration-strategy.md** — DT 声明策略（静态分区 DT vs 动态分区 DT 的创建语法与选择）
-- **sql-limitations.md** — SQL 支持矩阵（JOIN、聚合、窗口函数、非确定性函数等的支持情况）
-- **incremental-config-reference.md** — 增量计算配置参考（刷新策略、源表特征声明、状态表管理等）
-- **refresh-history-guide.md** — 增量刷新历史查询（SHOW REFRESH HISTORY / DESC HISTORY / information_schema）
+- **dt-declaration-strategy.md** — DT declaration strategy (creation syntax and selection between static partition DT and dynamic partition DT)
+- **sql-limitations.md** — SQL support matrix (support status for JOIN, aggregation, window functions, non-deterministic functions, etc.)
+- **incremental-config-reference.md** — Incremental computation configuration reference (refresh strategy, source table characteristic declarations, state table management, etc.)
+- **refresh-history-guide.md** — Incremental refresh history queries (SHOW REFRESH HISTORY / DESC HISTORY / information_schema)