@clickzetta/cz-cli-darwin-x64 0.3.75 → 0.3.78

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

@@ -1,291 +0,0 @@
-# 场景案例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

@@ -1,81 +0,0 @@
-# 试用账号配额与限制说明
-
-## 试用账户简介
-
-试用账户是云器 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,124 +0,0 @@
-# 使用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

@@ -1,79 +0,0 @@
-# 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;
-```
-
-## 注意事项
-
-- 请确保在数据保留周期内进行恢复操作，否则无法恢复被删除的表。
-- 在恢复表之前，请确保没有同名的表存在。如有同名表，请先重命名或删除同名表。