@clickzetta/cz-cli-darwin-x64 0.3.1

package/bin/skills/lakehouse-doc/references/transformt-dt.md

@@ -0,0 +1,291 @@
+# 场景案例1：基于静态分区的ETL任务增量改造（无维度表或维度表不变）
+
+## 业务背景
+
+针对传统按天调度的全量批处理任务（T+1模式），通过动态分区表技术实现增量处理优化。改造后可达成：
+
+* 数据时效提升：支持小时级/分钟级调度间隔
+* 资源利用率优化：减少冗余计算约60%-80%
+* 运维效率提升：支持分区级数据修复与回溯
+
+## 场景特征
+
+适用对象需满足：
+
+1. 业务时间对齐自然日：如订单交易、日志采集等典型日切场景
+2. 固定调度时段：建议在数据就绪时段（如00:30-01:00）集中处理
+3. 分区字段标准化：源表需包含标准日期分区字段（如event_day/pt/ds等）
+
+## 改造方案：使用分区动态表
+
+#### 1. 创建分区动态表
+
+在创建分区动态表时，通过定义参数 `SESSION_CONFIGS()['dt.args.event_day']` 来指定源表要扫描的分区或者分区范围。此参数在 SQL 加工逻辑中使用，通过 `SESSION_CONFIGS()['dt.arg.xx']` 进行定义，表示查询源表的分区字段。
+
+* 参数格式：`SESSION_CONFIGS()['dt.args.xx']`，其中 `xx` 是自定义的参数名称，必须以 `dt.args.` 开头，以避免与系统内部字段冲突。
+* 等价表达：与传统调度中的 `SELECT * FROM source_table WHERE pt = ${bizdate}` 等价。例如，`SESSION_CONFIGS()['dt.args.pt']` 等价于 `pt = ${bizdate}`。
+
+#### 2. 动态表刷新
+
+在刷新动态表时，使用以下命令指定分区值：
+
+```SQL
+REFRESH DYNAMIC TABLE target_table PARTITION (pt = ${bizdate});
+```
+
+* 对应传统操作：等同于传统的 `INSERT OVERWRITE target_table PARTITION (pt = ${bizdate})`。
+
+## 改造实施步骤
+
+### 将离线任务转换为增量任务
+
+本节将指导用户如何将原有的离线任务转换为增量任务，以实现更高效的数据处理。以下是一个基于“传统数据库”的具体操作步骤，适用于业务逻辑按天对齐和按天调度刷新的场景。
+
+#### 步骤1：任务改造
+
+原始SQL
+
+```SQL
+CREATE TABLE target PARTITIONED BY (ds);
+
+-- 20250101 调度
+SQL :=
+INSERT OVERWRITE TABLE target (ds='20250101')
+SELECT * 
+FROM 
+    src_1 AS t1
+LEFT OUTER JOIN 
+    src_2 as t2 WHERE t2.ds = '2025/01/01' AND t2.category = 'A'
+ON t1.id = t2.id;
+
+-- 20250102 调度
+SQL :=
+INSERT OVERWRITE TABLE target (ds='20250102')
+SELECT * 
+FROM 
+    src_1 AS t1 
+LEFT OUTER JOIN 
+    src_2 as t2 WHERE t2.ds = '2025/01/02' AND t2.category = 'A'
+ON t1.id = t2.id;
+```
+
+首先，需要将原始SQL中的所有由调度引擎传入的参数`${bizdate}`替换为`SESSION_CONFIGS()['dt.args.bizdate']`。
+
+1. 找到连续的两个调度任务，如上文所示 20250101 调度 和 20250102 调度
+
+2. 找到其中变化的部分 如 上文两处标记为黄色的部分
+
+3. 将其替换为 SESSION\_CONFIG()\['dt.args.xx']
+
+   1. 值得重点注意的是，**SESSION_CONFIG()['dt.args.xx'] 返回的结果是string**，如果变量是int需要用SQL进行类型转换，例如 CAST(SESSION_CONFIG()['dt.args.xx'] AS BIGINT)
+   2. 并且设置上刷新的语句
+   3. ```sql
+      CREATE DYNAMIC TABLE target (columns...)
+      PARTITIONED BY (ds)
+      --INSERT OVERWRITE TABLE target (ds='20250101')
+      AS
+      --SELECT *
+      -- 分区列需要出现在最后的schema里，才能保证列的个数是对齐的
+      SELECT t1.id, t1.col1, t2.col1, format(t1.ds) -- YYYY-MM-DD ==> YYYYMMDD
+      FROM 
+          src_1 AS t1 
+      LEFT OUTER JOIN 
+       --   src_2 as t2 WHERE t2.ds = '2025/01/02' AND t2.category = 'A'
+          src_2 as t2 WHERE t2.ds = SESSION_CONFIG()['dt.args.date2'] AND t2.category = 'A'
+      ON t1.id = t2.id;
+      ```
+
+#### 步骤2：调度刷新命令
+
+```SQL
+set dt.args.date1 = {$date1};
+set dt.args.date2 = {$date2};
+REFRESH DYNAMIC TABLE target partition(ds = {$date1});
+```
+
+### 增量任务数据补数和运维
+
+在某些情况下，用户可能需要向已有的分区中补充数据。
+
+#### 方法1：向源表补充数据
+
+用户可以直接向源表中补充数据。这些补充的数据将通过相应的REFRESH任务自动反映到Dynamic Table（DT）中。
+
+**操作步骤**：
+
+1. 直接向源表插入或更新数据。
+2. 执行REFRESH任务，以将更改同步到DT中。
+
+#### 方法2：使用DML语句直接向DT补充数据
+
+用户可直接运用DML语句向DT的指定分区插入数据。**但需注意，若上游数据未发生变动，下一次刷新操作将执行全量刷新，此时数据会恢复至未修改前的状态。**
+
+**操作步骤**：
+
+1. 使用DML语句向DT的特定分区插入数据。
+2. 请注意，直接修改DT将导致下一次该分区的全量刷新。如果用户不希望出现全量刷新的结果，应避免调度该分区的REFRESH任务。
+
+**示例代码**：
+
+```SQL
+set cz.sql.dt.allow.dml=true;
+INSERT INTO DYNAMIC TABLE incremental_dt  VALUES (...);
+```
+
+**注意事项**：
+
+* 直接向DT插入的数据将参与DT的下游计算。如果下游的老分区不需要这些数据，请不要调度涉及这些数据的分区的REFRESH任务。
+* 其他未受影响的分区仍然可以进行增量刷新。
+
+# 场景案例2：基于动态分区的ETL任务优化方案（无维度表或维度表不变）
+
+## 场景特征
+
+1. 动态数据特征：源数据存在历史分区更新可能性
+2. 时间窗口要求：业务需要持续处理N天内可能变更的数据
+3. 维度表情况：维度表不变、无需保留历史维度，或不存在维度表。
+
+## 将离线任务转换为增量任务
+
+```sql
+CREATE TABLE target PARTITIONED BY (ds);
+
+-- 20250101 调度
+SQL :=
+INSERT OVERWRITE TABLE target (ds)
+SELECT * 
+FROM 
+    src_1 AS t1 WHERE t1.ds = '2025-01-01'
+LEFT OUTER JOIN 
+    src_2 as t2 WHERE t2.ds = '2025/01/01' AND t2.category = 'A'
+ON t1.id = t2.id;
+
+-- 20250102 调度
+SQL :=
+INSERT OVERWRITE TABLE target (ds)
+SELECT * 
+FROM 
+    src_1 AS t1 WHERE t1.ds = '2025-01-02'
+LEFT OUTER JOIN 
+    src_2 as t2 WHERE t2.ds = '2025/01/02' AND t2.category = 'A'
+ON t1.id = t2.id;
+```
+
+1. 如果用户原本就是一个依赖调度系统填参数的静态分区调度的作业，不建议改写为动态分区
+2. 如果用户希望 老分区的数据在某个阶段后便不再改变 了，也不建议改写为动态分区
+3. 动态分区改写时，主要遵循的原则是：一切计算都由数据驱动。即每一条数据都应该按照定义好的计算逻辑，和其他数据发生交互，并且写入对应的目标分区中。
+4. 过滤条件中需要根据实际业务需求加个窗口过滤，比如1周/1个月/3个月/一年，防止DT数据持续增加，时间长了之后可能会影响性能。
+
+接下来我们来尝试把上述的静态分区的SQL改写为动态分区
+
+```SQL
+CREATE DYNAMIC TABLE target (COLUMNS...)
+PARTITIONED BY (ds)
+--INSERT OVERWRITE TABLE target (ds)
+SELECT *, DATE_FORMAT(STR_TO_DATE(t1.ds, '%Y-%m-%d'), '%Y%m%d')
+FROM 
+ --   src_1 AS t1 WHERE t1.ds = '2025-01-02'
+    src_1 AS t1
+LEFT OUTER JOIN 
+ --   src_2 as t2 WHERE t2.ds = '2025/01/02' AND t2.category = 'A'
+    src_2 as t2
+ON t1.id = t2.id 
+AND t1.ds = DATE_FORMAT(STR_TO_DATE(t2.ds, '%Y/%m/%d'), '%Y-%m-%d')
+WHERE t2.category = 'A';
+```
+
+## 增量任务数据补数和运维
+
+1. 需要先对源表数据进行补数，如果表是来自于外部数据需要使用数据集成工具重新同步，
+
+2. 历史数据补数：
+
+   1. 影响：补进来的数据会作为增量数据进行加工，这一批次加工会变慢，影响最新数据加工的新鲜度。
+
+   2. 建议：
+
+      1. 建议提前扩大计算资源保证加工性能，补数进行分批操作，减少一次计算的量；
+      2. 另外就是可以补数完，触发一次全量加工
+
+3. 维度表修改：
+
+   1. 影响：维度表修改会直接影响增量计算，如果修改的内容影响加工的范围过大，可能会影响加工性能
+
+   2. 建议：
+
+      1. 如果影响范围小，直接修改即可，增量计算自动识别加工
+      2. 如果影响范围大，可修改完进行一次全量加工
+      3. 如果影响代码逻辑（比如增加列，要加计算逻辑），则需要修改dt逻辑，重新全量计算
+
+# 场景案例3：按天分区任务（需要保留历史维度）
+
+## 业务背景
+
+针对维度表持续变化的按天分区ETL场景，通过构建维度表实时同步体系与动态加工链路，实现事实表与维度表的增量协同计算。改造后可达成：
+
+* 维度数据时效性提升：维度变更延迟从T+1缩短至分钟级
+* 跨表数据一致性保障：建立维度-事实表的版本对齐机制
+* 资源消耗降低：避免维度表全量同步带来的冗余计算
+
+## 场景特征
+
+适用对象需满足：
+
+1. 混合数据处理模式：维度表需支持实时更新+历史版本保留
+2. 版本对齐要求：事实表处理需绑定对应时间点的维度快照
+
+## 将离线任务转换为增量任务
+
+![](.topwrite/assets/image_1747648578327.png)
+
+## 改造实施步骤
+
+### 一、维度表实时化改造
+
+#### 1. 多源同步架构
+
+* **实时同步层**：如果数据来源是外部系统（如MySQL），通过StudioCDC捕获工具实现源库多表实时同步。实时同步要求和源端字段必须保持一致，因此如果维度表含有分区，需要新建一张维度表存储每日维度分区快照。
+
+### 二、加工任务增量改造
+
+* **版本绑定**：事实表的事件时间自动关联对应日的维度分区。
+
+加工任务增量改造示例如下，假设t1是日维度分区表，t2是事实表：
+
+```sql
+CREATE DYNAMIC TABLE target (columns...)
+PARTITIONED BY (ds)
+--INSERT OVERWRITE TABLE target (ds='20250101')
+AS
+SELECT *
+-- 分区列需要出现在最后的schema里，才能保证列的个数是对齐的
+SELECT t1.id, t1.col1, t2.col1, format(t1.ds) -- YYYY-MM-DD ==> YYYYMMDD
+FROM 
+--    src_1 AS t1 WHERE t1.ds = '2025-01-02'
+    src_1 AS t1 WHERE t1.ds = SESSION_CONFIG()['dt.args.date2']
+LEFT OUTER JOIN 
+ --   src_2 as t2 WHERE t2.ds = '2025/01/02' AND t2.category = 'A'
+    src_2 as t2 WHERE t2.ds = SESSION_CONFIG()['dt.args.date3'] AND t2.category = 'A'
+ON t1.id = t2.id;
+```
+
+## 增量任务数据补数和运维
+
+1. **历史数据补数**：通过补数功能按天修改输入表数据，之后按天刷新Dynamic Table即可。增量计算分区表可以按天刷新，不影响当天最新数据的计算。
+
+2. **修改维度表**：
+
+   1. 如果影响范围小，直接修改即可，增量计算自动识别加工
+   2. 如果影响范围大，可修改完进行一次全量加工
+   3. 如果影响代码逻辑（比如增加列，要加计算逻辑），则需要修改dt逻辑，重新全量计算
+
+# 特殊场景下的增量计算效果说明
+
+在以下场景中，增量计算仍然可以正常执行，但性能优化效果可能有限。在最坏情况下，计算性能可能与全量计算相当。建议在这些场景下进行实际测试，评估增量计算的收益后再决定是否采用。
+
+1. **Outer Join 右表频繁变更**：数据查询中包含大量的 Outer Join，且参与 Outer Join 的右表数据处于频繁变更状态，每次变化数据量大于5%。
+2. **大量排序操作**：查询操作里存在大量数据排序需求，例如使用了 Order by 子句。
+3. **Window 函数排序与大分区**：Window 函数需要对数据进行排序（RowNumber=1 的情况除外），并且增量数据中包含多个数据量特别大的 Partition。
+4. **数据聚集性较差**：数据缺乏良好的聚集性，无法通过 Join key、Aggregate key、Window partition key 等清晰地将冷数据和热数据区分开来。
+
+^

package/bin/skills/lakehouse-doc/references/trial-account-quotas-and-limits.md

@@ -0,0 +1,81 @@
+# 试用账号配额与限制说明
+
+## 试用账户简介
+
+试用账户是云器 Lakehouse 为用户提供的免费体验形式，帮助新用户在零成本的前提下，对平台的功能与性能进行体验。
+
+每个账户新创建后，均会先成为“试用”状态用户。您可在管理中心左侧看到“试用”状态的标识。在创建服务实例后，账户内会获得总金额为 200 元、有效期为 30 天的代金券，用于产品体验。
+
+![](.topwrite/assets/image_1736856111009.png =189)
+
+为保证平台整体运行效率与资源的公平分配，试用版用户在使用过程中会受到一定的限制，具体限制说明如下。
+
+## 配额、使用限制概览
+
+| **功能点** | **限制说明**                          | **限制数值 / 规则**                                                                                  | **提升配额方式** |
+| ------- | --------------------------------- | ---------------------------------------------------------------------------------------------- | ---------- |
+| 全局      | 单租户下可创建的用户最大数量限制                  | 最大 500 个                                                                                       | 不可变更       |
+|         | 单租户可创建的实例数量限制                     | 可在任意 region 开通实例，总数不超过 1 个                                                                     | 转为正式账户     |
+|         | 单实例下可创建的工作空间数量限制                  | 不超过 100                                                                                        | 不可变更       |
+| 数据集成    | 离线同步任务：                           | 单个任务可配置的并发数上限为 10；同时运行的任务数量不超过 2 个。任务执行时长不超过 6 小时。                                               | 转为正式账户     |
+|         | 实时集成任务                            | 同时运行的任务数量不超过 2 个。任务运行时长不超过 6 小时。                                                                   | 转为正式账户     |
+|         | 多表实时同步任务                          | 多表实时同步任务过程中会分别使用离线同步任务和实时集成任务，分别占用离线任务和实时集成任务的配额。                                              | 转为正式账户     |
+| 数据开发    | SQL/Python/Shell/JDBC 任务文件的最大行数限制 | 最大 5000 行代码                                                                                    | 不可变更       |
+|         | SQL 查询结果返回行数限制                    | 默认 1000 行，用户可调最大至 10000 行                                                                       | 不可变更       |
+|         | SQL 查询结果下载的限制                     | 最大支持下载 4GiB 数据                                                                                 | 不可变更       |
+|         | 临时查询的运行历史保存时长                     | 最多保存 7 天                                                                                       | 不可变更       |
+|         | 历史版本和提交版本的历史保存时长                  | 永久保存                                                                                           | 不可变更       |
+| 任务调度    | 单租户并发启动的任务实例数量限制                  | 离线同步任务实例：20 个；SQL任务实例：无限制；Python任务实例：5 个；Shell任务实例：5 个；JDBC任务实例：20 个                               | 转为正式账户     |
+|         | 单任务实例系统兜底最大运行超时时长                 | 最小：1 分钟；最大：168 小时（7天）                                                                           | 不可变更       |
+|         | 实例自动重跑间隔                          | 最小：1 分钟；最大：1 天                                                                                  | 不可变更       |
+|         | 调度等待时长                            | 最小：1 分钟；最大：168 小时（7天）                                                                           | 不可变更       |
+| 运维中心    | 任务实例的历史保存时长                       | 周期实例：32 天；补数实例：32 天；临时实例：8 天                                                                     | 不可变更       |
+|         | 查询任务实例列表的限制                       | 展示结果受实例保存时长限制，最长6个月                                                                            | 不可变更       |
+|         | 任务操作日志的查询时间范围限制                   | 6个月                                                                                            | 不可变更       |
+|         | 任务操作日志的历史保存时长限制                   | 6个月                                                                                            | 不可变更       |
+| 计算集群    | 单个实例下最大可创建计算集群实例的总规格              | 所有计算集群的总规格不超过 28 CRU：其中 sys 工作空间默认占用 9 CRU 配额，服务实例下所有其他工作空间剩余总规格不超过 19 CRU。                         | 转为正式账户     |
+|         | 并发编译作业                            | 不超过2个                                                                                          | 联系云器商务调整   |
+| 数据对象    | 单实例下可创建数据对象(如表、视图等)数量上限           | 1000                                                                                           | 转为正式账户     |
+| 流式写入    | 单实例下可创建的Stream对象数量上限              | 10                                                                                             | 转为正式账户     |
+|         | 单实例下数据写入QPS                       | 5                                                                                              | 转为正式账户     |
+| 作业历史    | 查询作业列表的限制                         | 时间范围：最大7 天；返回作业历史数量：最多10000 条；超过上述配额的作业历史记录可在sys.information\_schema.job\_history视图中使用SQL进行查询。 | 不可变更       |
+|         | 日发送短信数量限制                         | \*\*验证码：\*\*每分钟内上限1条；每小时内上限20条；每个自然日内上限40条。\*\*报警通知等：\*\*每个自然日内上限50条。                          | 不可变更       |
+| 监控告警    | 监控规则数量限制                          | 同时开启的监控规则不超过 5 条                                                                               | 联系云器商务调整   |
+|         | 告警事件的查询时间范围                       | 最大7 天                                                                                          | 不可变更       |
+|         | 通知策略配置中最大发送次数限制                   | 最多 12 次                                                                                        | 不可变更       |
+| 数据目录    | 上传文件大小限制                          | 最大 2 GiB                                                                                       | 不可变更       |
+| 数据质量    | 校验结果时间查询限制                        | 校验结果保留 3 个月                                                                                    | 不可变更       |
+| 安全中心    | 单个实例下可创建的网络策略数量限制                 | 最多 20 个                                                                                        | 不可变更       |
+|         | 单个网络策略下可录入的白名单和黑名单数量限制            | 最多 100000（10 万）个 IP                                                                            | 不可变更       |
+
+## 试用周期与数据处理
+
+**限制说明**：
+
+新开账户的试用期截至服务实例开通后的 30 个自然日或 200 元代金券使用完毕。
+
+**到期后处理**：
+
+试用期间可随时申请升级为正式账户，也可在试用期结束后申请升级为正式账户。试用期结束后，您将无法访问或继续使用试用创建的服务实例。服务实例内的资源配置和数据将为您保留 7 个自然日，7 个自然日后将清理服务实例内的资源配置和数据，且不可恢复。
+
+如需持续使用，请于试用期结束的 7 个自然日内联系云器商务申请转为正式账户后继续使用。
+
+***
+
+## 超出配额的处理方式
+
+当您的使用超出配额限制时，您的操作会收到系统报错信息，提示所超过的配额限制。请清理不必要的资源，或根据第二节“配额、使用限制概览”中对应的提升配额方式进行处理。
+
+***
+
+## 临时禁用或暂停
+
+如果您以非正常使用方式占用过多系统资源，云器 Lakehouse 可能会对您的试用账号进行临时禁用或限制部分功能的使用权限，以保障其他用户的正常使用。如采取上述限制，我们会通过您预留的账户电话联系您告知。
+
+***
+
+## 联系方式
+
+*   **电话**：400-6767-862
+*   **邮箱**：<service@yunqi.tech>
+*   **企业微信**：![](.topwrite/assets/image_1736856313196.png =116)

package/bin/skills/lakehouse-doc/references/tutorial_DataGPT.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorial_connect_to_lakehouse.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorial_data_transformation.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorial_migration.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorial_virtual_cluster.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorial_work_with_workspace.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorial_zettapark.md

@@ -0,0 +1 @@
+^

package/bin/skills/lakehouse-doc/references/tutorials-streaming-data-pipeline-with_dynamic-table.md

@@ -0,0 +1,124 @@
+# 使用DynamicTable开展实时ETL
+
+## 教程概述
+
+通过本教程，您将了解如何使用 Lakehouse 动态表（Dynamic Table）对流式数据进行实时 ETL。
+
+本教程包含以下步骤：
+
+* 环境准备：通过样例数据集获取系统预置的实时数据表
+* 创建 ETL 任务：通过 Dynamic Table 分别构造数据清洗、数据聚合的加工流程
+* 验证加工结果：查看消费层数据表的变化情况，验证实时数据加工结果
+
+## Step 1. 准备工作
+
+本教程将利用 Lakehouse 样例数据集中具备实时数据的表作为数据源表（阿里云上海区域可用），同时创建一个用于测试的计算集群和一个测试用的 schema，用于保存 ETL 过程中产生的数据表。
+
+```sql
+--  1.计算资源和DEMO环境准备
+create vcluster if not exists dt_refresh_vc vcluster_size='XSMALL' vcluster_type='GENERAL';
+
+USE vcluster dt_refresh_vc;
+
+CREATE SCHEMA cz_tutourials;
+use cz_tutourials;
+
+-- 2.查看原始数据：样例数据集ecommerce_events_multicategorystore_live提供实时电商行为样例数据
+select * from clickzetta_sample_data.ecommerce_events_history.ecommerce_events_multicategorystore_live
+where event_time between current_timestamp() - INTERVAL 5 minutes and current_timestamp() limit 20;
+```
+
+查看原始数据明细，可以看到表 `ecommerce_events_multicategorystore_live` 持续有实时数据插入。
+![](.topwrite/assets/image_1716287777109.png)
+
+## Step 2.通过定义动态表实现数据清洗
+
+参考如下语句创建动态表 `ecommerce_events_multicategorystore_enriched`。该动态表将每分钟刷新一次，对每分钟的增量数据进行数据清洗转换。为了减少加工数据规模，对历史数据进行过滤，仅处理指定时间之后的新增数据。
+
+刷新任务将根据 DDL 中定义的刷新间隔自动运行，并使用 `refresh_vc` 指定的计算资源执行。
+
+```sql
+
+-- 以当前时间（以当前时间替换下方时间过滤条件，过滤规则可选）作为原始表过滤条件，创建包含数据清洗逻辑的物化视图,配置分钟级别调度
+CREATE DYNAMIC TABLE IF NOT EXISTS ecommerce_events_multicategorystore_enriched
+REFRESH
+    interval '1' minute
+    vcluster dt_refresh_vc
+AS
+SELECT
+event_time,
+CAST(SUBSTRING(event_time,0,19) AS TIMESTAMP) AS event_timestamp, 
+SUBSTRING(event_time,12,2) AS event_hour, 
+SUBSTRING(event_time,15,2) AS event_minute, 
+SUBSTRING(event_time,18,2) AS event_second, 
+event_type,
+product_id, 
+category_id,
+category_code,
+brand,
+CAST(price AS DECIMAL(10,2)) AS price, 
+user_id, 
+user_session,
+CAST(SUBSTRING(event_time,0,19)AS date) AS event_date 
+FROM clickzetta_sample_data.ecommerce_events_history.ecommerce_events_multicategorystore_live
+where event_time > TIMESTAMP '2024-05-21 18:18:35.117561';
+refresh DYNAMIC TABLE ecommerce_events_multicategorystore_enriched;
+```
+
+## Step 3.通过定义动态表实现数据聚合分析
+
+根据业务需求，这里模拟对表 `ecommerce_events_multicategorystore_enriched` 进行产品收入、转化率、DAU 等主题的数据聚合加工。
+
+```sql
+-- 分析指标加工
+-- 产品收入分析,配置分钟级别调度
+CREATE DYNAMIC TABLE IF NOT EXISTS Product_Grossing
+REFRESH
+    interval '1' minute
+    vcluster dt_refresh_vc
+AS 
+select event_date,product_id,sum(price) sum_price from ecommerce_events_multicategorystore_enriched
+group by event_date,product_id;
+refresh DYNAMIC TABLE Product_Grossing;
+
+--产品的转化率  Conversion Rates Per Product,配置分钟级别调度
+CREATE DYNAMIC TABLE IF NOT EXISTS Conversion_Rates_Per_Product
+REFRESH
+    interval '1' minute
+    vcluster dt_refresh_vc
+AS
+select event_date,product_id,
+count(case when event_type='purchase' then 1 else null end) num_of_sales,
+count(case when event_type='view' then 1 else null end) num_of_views,
+count(case when event_type='purchase' then 1 else null end)/count(case when event_type='view' then 1 else null end) cvr
+from ecommerce_events_multicategorystore_enriched
+GROUP BY event_date,product_id;
+refresh DYNAMIC TABLE Conversion_Rates_Per_Product;
+--日活跃用户(DAU),配置分钟级别调度
+CREATE DYNAMIC TABLE IF NOT EXISTS DAU
+REFRESH
+    interval '1' minute
+    vcluster dt_refresh_vc
+AS
+select event_date,count(distinct user_id) as DAU from ecommerce_events_multicategorystore_enriched  
+group by event_date;
+refresh DYNAMIC TABLE DAU;
+```
+
+## Step 4.验证实时ETL加工结果
+
+上述动态表在创建后，平台将自动进行调度刷新。当源头表有新数据写入时，最终加工出的聚合表将自动按照聚合逻辑进行更新。
+
+```sql
+-- 查询分析
+-- 当日收入前10产品分析
+select product_id,sum_price as revenue from Product_Grossing where event_date=CURRENT_DATE() order by sum_price desc limit 10;
+-- 当日转化率前10产品分析
+SELECT product_id,cvr FROM Conversion_Rates_Per_Product WHERE event_date=CURRENT_DATE() order by cvr desc limit 10;
+-- 当日DAU
+SELECT EVENT_DATE,DAU FROM DAU WHERE event_date=CURRENT_DATE();
+```
+
+
+
+

package/bin/skills/lakehouse-doc/references/undrop-dynamic-table.md

@@ -0,0 +1,79 @@
+# UNDROP TABLE 语句
+
+使用 UNDROP TABLE 语句可以恢复被删除的表、动态表和物化视图。是否可以恢复被删除的对象依赖于数据的[保留周期](<TIMETRAVEL.md>)。
+**数据保留周期**：
+对象的历史恢复能力取决于数据的保留周期。当前默认保留周期为1天。您可以通过执行[ALTER命令](TIMETRAVEL.md)来调整保留周期。请注意，修改保留周期可能会增加存储成本。支持表（TABLE）和动态表（DYNAMIC TABLE）不支持物化视图
+
+## 语法
+
+```sql
+UNDROP TABLE tablename;
+```
+
+## 参数说明
+
+- **tablename**：指定被删除的表的名字。支持动态表、内部表、物化视图。
+
+## 示例
+### 示例 1：恢复动态表
+
+```sql
+-- 创建一个基表
+DROP TABLE IF EXISTS dy_base_a;
+CREATE TABLE dy_base_a (i int, j int);
+INSERT INTO dy_base_a VALUES
+(1, 10),
+(2, 20),
+(3, 30),
+(4, 40);
+-- 使用dynamic table进行加工
+DROP DYNAMIC TABLE IF EXISTS change_table;
+CREATE DYNAMIC TABLE change_table
+(i, j)
+AS SELECT * FROM dy_base_a;
+-- 刷新dynamic table
+REFRESH DYNAMIC TABLE change_table;
+-- 查询数据
+SELECT * FROM change_table;
++---+----+
+| i | j  |
++---+----+
+| 1 | 10 |
+| 2 | 20 |
+| 3 | 30 |
+| 4 | 40 |
++---+----+
+DROP DYNAMIC TABLE IF EXISTS change_table;
+UNDROP TABLE change_table;
+SELECT * FROM change_table;
+```
+### 示例 2：删除表后创建同名的表恢复
+
+```sql
+-- 创建表
+CREATE TABLE mytable(id int, name string);
+INSERT INTO mytable VALUES(1, 'aaa');
+-- 删除表
+DROP TABLE mytable;
+-- 查看表删除记录
+SHOW TABLES HISTORY;
+-- 重复建表
+CREATE TABLE mytable(col1 int, col2 string);
+-- 查看表删除记录，未删除的表delete_time是null
+SHOW TABLES HISTORY;
++---------------+------------+-------------------------+----------+------+-------+---------+----------------+-------------------------+
+| schema_name  | table_name | create_time            | creator  | rows | bytes | comment | retention_time | delete_time             |
++---------------+------------+-------------------------+----------+------+-------+---------+----------------+-------------------------+
+| undrop_schema | mytable    | 2023-07-18 17:51:25.978 | UAT_TEST | 0    | 0     |         | 1              |                          |
+| undrop_schema | mytable    | 2023-06-06 12:22:57.642 | UAT_TEST | 1    | 1348  |         | 1              | 2023-07-18 17:49:26.374 |
++---------------+------------+-------------------------+----------+------+-------+---------+----------------+-------------------------+
+-- 重命名未删除的表
+ALTER TABLE mytable RENAME TO mytable_back;
+-- 恢复表
+UNDROP TABLE mytable;
+```
+
+## 注意事项
+
+- 请确保在数据保留周期内进行恢复操作，否则无法恢复被删除的表。
+- 在恢复表之前，请确保没有同名的表存在。如有同名表，请先重命名或删除同名表。