@clickzetta/cz-cli-darwin-arm64 0.5.15 → 0.5.17

package/bin/skills/lakehouse-doc-en/references/pipe-overview.md

@@ -1,10 +1,10 @@
-# Data Pipelines and Change Capture
+# Data Pipelines and Change Data Capture
 
-This chapter covers two types of objects: **Pipe** (continuous data ingestion) and **Table Stream** (change data capture). A Pipe automatically writes data from external files or message streams into a table; a Table Stream records incremental changes on a table for downstream incremental processing.
+This chapter covers two types of objects: **Pipe** (continuous data ingestion) and **Table Stream** (change data capture). Pipe automatically writes data from external files or message streams into tables; Table Stream records incremental changes on a table for downstream incremental computation.
 
-A Pipe is a **continuous data ingestion object** in Lakehouse. Once created, it runs automatically, continuously reading data from object storage (OSS/COS/S3) or Kafka and writing it to a target table — no manual triggering required.
+Pipe is the **continuous data ingestion object** in Singdata Lakehouse. Once created, it runs automatically, continuously reading data from object storage (OSS/COS/S3) or Kafka and writing it to a target table — no manual triggering required.
 
-Think of a Pipe as a continuously running conveyor belt. After a file is uploaded to an OSS subdirectory, the Pipe detects it and loads it within approximately 30 seconds. Kafka messages are consumed and written in batches at a configured interval. Unlike scheduled jobs, a Pipe runs persistently and processes new data as it arrives.
+Analogy: Pipe is like a continuously running conveyor belt. Once files are uploaded to an OSS subdirectory, Pipe automatically detects and loads them within about 30 seconds. When Kafka messages are written, Pipe continuously consumes and writes them in batch intervals. Unlike scheduled tasks, Pipe runs persistently and processes new data as it arrives.
 
 ![](/.topwrite/assets/14-pipe.png)
 
@@ -13,22 +13,22 @@ Think of a Pipe as a continuously running conveyor belt. After a file is uploade
 ## Pipe Types
 
 | Type | Data Source | Detection Latency | Typical Use Case |
-|------|--------|---------|---------|
-| **Object Storage Pipe** | OSS / COS / S3 | ~30 seconds | Automatically ingest periodically uploaded CSV/Parquet/JSON files |
+|------|-------------|-------------------|-----------------|
+| **Object Storage Pipe** | OSS / COS / S3 | ~30 seconds | Automatic ingestion of periodically uploaded CSV/Parquet/JSON files |
 | **Kafka Pipe** | Kafka Topic | Per batch interval (default 60 seconds) | Real-time ingestion of logs and business events |
 
-A Pipe is functionally equivalent to a Studio sync task. The difference is that a Pipe is created and managed via SQL DDL, making it suitable for code-driven pipeline management, while Studio sync tasks are configured through a visual interface and support more data sources (including relational databases).
+Pipe and Studio sync tasks are functionally equivalent. The difference is: Pipe is created and managed via SQL DDL, suitable for code-based pipeline management; Studio sync tasks are configured through a visual interface and support more data sources (including relational databases).
 
 ---
 
 ## Continuous Ingestion from Object Storage
 
-**Prerequisites**: Create a Storage Connection → Create an External Volume (must point to a specific subdirectory, not the bucket root path) → Create the target table → Create the Pipe.
+**Prerequisites**: Create a Storage Connection → Create an External Volume (must point to a specific subdirectory, not the bucket root) → Create the target table → Create the Pipe.
 
-> ⚠️ **Note**: The Volume's `LOCATION` must point to an OSS subdirectory (e.g., `oss://bucket/pipe_data/`), not the bucket root path (`oss://bucket/`). Using the root path will cause an error when creating the Pipe.
+> ⚠️ The Volume's `LOCATION` must point to an OSS subdirectory (e.g., `oss://bucket/pipe_data/`), not the bucket root (`oss://bucket/`). Otherwise, Pipe creation will fail.
 
 ```sql
--- Step 1: Create a Storage Connection
+-- Step 1: Create a storage connection
 CREATE STORAGE CONNECTION my_oss_conn
     TYPE OSS
     ENDPOINT = 'oss-cn-hangzhou.aliyuncs.com'
@@ -51,7 +51,7 @@ CREATE TABLE IF NOT EXISTS orders (
 
 -- Step 4: Create the Pipe
 CREATE PIPE orders_oss_pipe
-    VIRTUAL_CLUSTER = 'default'
+    VIRTUAL_CLUSTER = 'DEFAULT'
     INGEST_MODE = 'LIST_PURGE'
 AS
 COPY INTO orders
@@ -65,31 +65,31 @@ Once created, the Pipe starts running immediately and checks the Volume for new
 ### Two Ingestion Modes
 
 | Mode | Trigger | Source File Handling | Use Case |
-|------|---------|-----------|---------|
-| `LIST_PURGE` | Periodic polling scan (~30 seconds) | **Source file deleted after ingestion** | Simple setup, suitable for most scenarios |
-| `EVENT_NOTIFICATION` | Object storage event notification (near real-time) | Source file retained | When you need to keep the original files; OSS and S3 only |
+|------|---------|---------------------|---------|
+| `LIST_PURGE` | Periodic polling scan (~30 seconds) | **Deletes source files after ingestion** | Simple configuration, suitable for most scenarios |
+| `EVENT_NOTIFICATION` | Object storage event notification (near real-time) | Keeps source files | When source files need to be retained; OSS and S3 only |
 
-> ⚠️ **Note**: In `LIST_PURGE` mode, source files in OSS are **permanently deleted** after a successful ingestion and cannot be recovered. Use `EVENT_NOTIFICATION` mode if you need to retain the files.
+> ⚠️ `LIST_PURGE` mode **permanently deletes** source files from OSS after a successful import. This is irreversible. Use `EVENT_NOTIFICATION` mode if you need to retain the files.
 
-### Deduplication
+### Deduplication Mechanism
 
-A Pipe uses `load_history` to record the paths of already-ingested files. Each unique file path is only ingested once — re-uploading the same file will not trigger a duplicate ingestion. Records in `load_history` are retained for 7 days.
+Pipe records ingested file paths in `load_history`. The same file path is only imported once — re-uploading the same file will not trigger a duplicate import. `load_history` records are retained for 7 days.
 
 ```sql
 -- View ingested file records
 SELECT * FROM load_history('orders');
--- Result includes: file_path, last_copy_time, file_size, status, first_error_message
+-- Results include: file_path, last_copy_time, file_size, status, first_error_message
 ```
 
 ---
 
 ## Continuous Consumption from Kafka
 
-A Pipe creates a persistent consumer group that pulls data from a Kafka Topic at a configured batch interval and writes it to a table.
+Pipe creates a persistent consumer group, pulling data from a Kafka Topic in batches and writing it to a table.
 
 ```sql
 CREATE PIPE kafka_orders_pipe
-    VIRTUAL_CLUSTER = 'default'
+    VIRTUAL_CLUSTER = 'DEFAULT'
     BATCH_INTERVAL_IN_SECONDS = '60'
 AS
 COPY INTO orders_raw
@@ -98,23 +98,23 @@ FROM (
     FROM TABLE(READ_KAFKA(
         'kafka-host:9092',    -- bootstrap.servers
         'orders_topic',       -- topic
-        '',                   -- topic pattern (not supported yet, leave empty)
-        'pipe_orders_group',  -- group_id (must be unique per Pipe for the same Topic)
-        '', '', '', '',       -- start/end offsets and timestamps, managed by Pipe automatically
+        '',                   -- topic pattern (not yet supported, leave empty)
+        'pipe_orders_group',  -- group_id (must be unique per topic per Pipe)
+        '', '', '', '',       -- start/end offsets and timestamps, managed by Pipe
         'raw', 'raw',         -- key/value format
-        0, map()              -- max error count, additional Kafka config
+        0, map()              -- max errors, extra Kafka config
     ))
 );
 ```
 
-> ⚠️ **Note**: Each Pipe can only consume one Kafka Topic. Multiple Topics require multiple Pipes, and each Pipe's `group_id` must be unique.
+> ⚠️ A single Pipe can only consume one Kafka Topic. Multiple Topics require multiple Pipes, and each Pipe must have a unique `group_id`.
 
 ---
 
 ## Monitoring and Management
 
 ```sql
--- View all Pipes (including status, type, VCluster)
+-- View all Pipes (with status, type, VCluster)
 SHOW PIPES;
 
 -- View Pipe details
@@ -136,32 +136,32 @@ DROP PIPE orders_oss_pipe;
 Key fields in `DESC PIPE` output:
 
 | Field | Description |
-|------|------|
+|-------|-------------|
 | `pipe_status` | `RUNNING` / `PAUSED` |
 | `pipe_kind` | `VOLUME` (object storage) or `KAFKA` |
-| `properties` | Configuration such as ingest_mode and vcluster |
+| `properties` | Configuration such as ingest_mode, vcluster |
 | `input_name` | Data source (Volume or Kafka Topic) |
 | `output_name` | Full path of the target table |
-| `invalid_reason` | Error reason when the Pipe is in an abnormal state |
+| `invalid_reason` | Error reason when Pipe is in an error state |
 
-To view Pipe execution history, filter job history by `query_tag` in the format `pipe.workspace_name.schema_name.pipe_name`.
+To view Pipe execution history: filter job history by `query_tag`, in the format `pipe.workspace_name.schema_name.pipe_name`.
 
 ---
 
-## Important Notes
+## Notes
 
-- **Volume must point to a subdirectory**: `LOCATION` cannot be the bucket root path, or Pipe creation will fail.
-- **Each Pipe requires its own Volume**: Different Pipes cannot share the same Volume.
-- **The COPY statement cannot be modified**: To change the ingestion logic, drop the Pipe and recreate it.
-- **Data loading order is not strictly guaranteed.**
-- **Recommended file sizes**: gzip-compressed files should be under 50 MB; uncompressed CSV/Parquet files should be 128 MB–256 MB.
-- **`EVENT_NOTIFICATION` mode** requires additional MNS message queue configuration, supports only Alibaba Cloud OSS and AWS S3, and requires RoleARN-based authorization.
+- **Volume must point to a subdirectory**: `LOCATION` cannot be the bucket root, otherwise Pipe creation will fail
+- **Each Pipe requires its own Volume**: Different Pipes cannot share the same Volume
+- **COPY statement cannot be modified**: To change the ingestion logic, drop and recreate the Pipe
+- **Data loading order is not guaranteed**
+- **Recommended file sizes**: gzip compressed files should be under 50MB; uncompressed CSV/Parquet files should be 128MB–256MB
+- **EVENT_NOTIFICATION mode** requires additional MNS message queue configuration, supports only Alibaba Cloud OSS and AWS S3, and must use RoleARN authorization
 
 ---
 
 ## Related Documentation
 
-- [Object Storage Pipe](pipe-storage-object.md) — Complete configuration for LIST_PURGE and EVENT_NOTIFICATION
-- [Kafka Pipe](pipe-kafka.md) — READ_KAFKA parameter reference and consumer offset management
+- [Object Storage Pipe](pipe-storage-object.md) — Full configuration for LIST_PURGE and EVENT_NOTIFICATION
+- [Kafka Pipe](pipe-kafka.md) — READ_KAFKA parameter reference, consumer offset management
 - [Pipe Syntax Reference](pipe-syntax.md) — Complete DDL syntax
-- [Table Stream](om-table-stream.md) — Change data capture for CDC-driven incremental processing
+- [Table Stream](om-table-stream.md) — Change data capture, CDC-driven incremental computation

package/bin/skills/lakehouse-doc-en/references/pipe-storage-object.md

@@ -1,6 +1,6 @@
 # Continuous Data Import from Object Storage Using Pipe
 
-Pipe is a powerful data import feature in the Singdata Lakehouse platform. It allows you to read data directly from object storage at a fixed frequency and import it into the Lakehouse. By implementing a file detection mechanism, Pipe supports micro-batch file loading, enabling you to quickly access the latest data. It is particularly suitable for scenarios requiring real-time or near-real-time data processing.
+Pipe is a powerful data import feature in the Singdata Lakehouse platform. It allows users to read data directly from object storage at a fixed frequency and import it into the Lakehouse. By implementing a file detection mechanism, Pipe supports micro-batch file loading, enabling quick access to the latest data. It is particularly suitable for scenarios requiring real-time or near-real-time data processing.
 
 Think of an object storage Pipe as a program that continuously scans an inbox — you simply upload files to OSS/S3/COS, and it automatically detects and imports them without any manual trigger.
 
@@ -8,34 +8,35 @@ Think of an object storage Pipe as a program that continuously scans an inbox
 
 1. **File Detection**:
 
-   1. **EVENT\_NOTIFICATION\_MODE**: Requires enabling a message service. It uses Alibaba Cloud Message Service to notify Lakehouse of new file uploads. Currently only Alibaba Cloud OSS and AWS S3 are supported.
-   2. **LIST\_PURGE mode**: Periodically scans directories, synchronizes unrecorded files, and deletes the source files after synchronization.
+   1. **EVENT\_NOTIFICATION\_MODE**: Requires enabling a message service. Uses Alibaba Cloud Message Service to notify the Lakehouse of new file uploads. Currently only Alibaba Cloud OSS and AWS S3 are supported.
+   2. **LIST\_PURGE mode**: Periodically scans directories, synchronizes unrecorded files, and deletes source files after synchronization.
 
 2. **COPY Statement**: Defines the source location of data files and the target table, supporting multiple file formats.
 
 3. **Automated Loading**: Automatically detects new files and executes the COPY statement.
 
-4. **Duplicate Import Prevention**: To avoid duplicate imports, the `load_history` function records the copy import history for the current table. When Pipe executes, it deduplicates based on the `load_history` table name and import file name, ensuring already-imported files are not imported again. If you need to re-import a recorded file, you can manually execute the copy command. `load_history` records are currently retained for 7 days.
+4. **Duplicate Import Prevention**: To avoid duplicate imports, the `load_history` function records the COPY import history for the current table. When Pipe executes, it deduplicates based on the `load_history` table name and import file name, ensuring already-imported files are not re-imported. If you need to re-import a recorded file, manually execute a COPY command. Records in `load_history` are retained for 7 days.
 
-5. **Pipe Import Job History**: Since each execution is a Pipe-issued copy, you can view all operations in the job history. Filter by `query_tag` in the job history — all copy jobs executed by a Pipe are tagged with the format `pipe.``workspace_name``.schema_name.pipe_name`, making it easy to track and manage.
+5. **Pipe Import Job History**: Since each execution is a Pipe-issued COPY, you can view all operations in the job history. Filter by `query_tag` in the job history — all COPY jobs executed by a Pipe are tagged with the format `pipe.``workspace_name``.schema_name.pipe_name`, making it easy to track and manage.
 
 ## Use Cases
 
-* **Real-time Data Synchronization**: When your data is stored in object storage and needs to be frequently synchronized to access the latest data in a timely manner.
-* **Cost Optimization**: Importing and exporting data via object storage avoids public network traffic costs. Within the same region, you can specify intranet transfer for object storage, further reducing costs.
+* **Real-time Data Synchronization**: When data is stored in object storage and needs frequent synchronization to access the latest data.
+* **Cost Optimization**: Importing and exporting data via object storage avoids public network traffic costs. Within the same region, you can specify intranet transfer for object storage to further reduce costs.
 
 ## Notes
 
 * When using EVENT\_NOTIFICATION\_MODE, you must use the role ARN authorization method to create the storage connection.
-* LIST\_PURGE mode supports both access key and role ARN authorization methods.
+* LIST\_PURGE mode supports both access key and role ARN authorization.
 * **Recommended File Size**: gzip compressed files should be around 50 MB. Uncompressed CSV and Parquet files should be between 128 MB and 256 MB.
 * **Data Loading Order**: **Data loading cannot guarantee strict ordering**.
 * **Pipe Latency**: Pipe loading time is affected by various factors, including file format, size, and the complexity of the COPY statement.
-* **Pipe and Volume Mapping**: Each Pipe must correspond to a dedicated Volume and cannot be shared.
+* **Pipe and Volume Mapping**: Each Pipe requires a dedicated Volume and cannot be shared.
 * Modifying the COPY statement logic is not supported. If you need to change it, delete the Pipe and recreate it.
-* When you modify a Pipe's `COPY_JOB_HINT`, the new setting overwrites the existing hints. If your Pipe already has hints such as `{"cz.sql.split.kafka.strategy":"size"}`, you must include all required hints together when setting new ones, otherwise the existing hints will be overwritten. Separate multiple parameters with commas.
+* When modifying a Pipe's `COPY_JOB_HINT`, the new settings overwrite existing hints. If your Pipe already has hints such as `{"cz.sql.split.kafka.strategy":"size"}`, you must include all required hints together when setting new ones; otherwise existing hints will be overwritten. Separate multiple parameters with commas.
 * The COPY statement inside a PIPE does not support the `files`, `regexp`, or `subdirectory` parameters.
 
+
 ## Cost
 
 Charged based on the computing resources used when loading files.
@@ -51,27 +52,24 @@ CREATE PIPE [ IF NOT EXISTS ] <pipe_name>
 AS <copy_statement>;
 ```
 
-* `<pipe_name>`: The name of the Pipe object you want to create.
-
-* `VIRTUAL_CLUSTER`: Specify the name of the virtual cluster.
-
-* `INGEST_MODE`: Determines the data import mode — choose one:
-  * `LIST_PURGE`: Periodically polls and scans the directory — simple to configure, suitable for most scenarios; **deletes source files after a successful import (irreversible**).
+- `<pipe_name>`: The name of the Pipe object to create.
+- `VIRTUAL_CLUSTER`: Specifies the Virtual Cluster name.
+- `INGEST_MODE`: Determines the data ingestion mode — choose one:
+  - `LIST_PURGE`: Periodically polls and scans the directory — simple to configure, suitable for most scenarios; **deletes source files after a successful import (irreversible)**
+  - `EVENT_NOTIFICATION`: Triggers immediately upon receiving an object storage event notification — suitable for near-real-time ingestion where source files must be retained; requires additional MNS queue configuration
 
-  * `EVENT_NOTIFICATION`: Triggers immediately upon receiving an object storage event notification — suitable for near-real-time ingestion where source files must be retained; requires additional MNS queue configuration.
-  > ⚠️ **Note**: `LIST_PURGE` mode **permanently deletes** source files from object storage after a successful import. If you need to retain the original files, use `EVENT_NOTIFICATION` mode.
+  > ⚠️ **Warning**: `LIST_PURGE` mode **permanently deletes** source files from object storage after a successful import. If you need to retain the original files, use `EVENT_NOTIFICATION` mode.
+- `COPY_JOB_HINT`: Optional, reserved parameter for Lakehouse.
+- `copy_statement`: `<copy_statement>` supports all file parameters. When the `ON_ERROR=CONTINUE|ABORT` parameter is set, it controls error handling during data loading, and the list of imported files is returned:
+    * `CONTINUE`: Skips error rows and continues loading subsequent data. Suitable for tolerating partial errors while maximizing data loading completion. Currently, ignorable errors are limited to file format mismatches — for example, the command specifies zip compression but the file uses zstd.
+    * `ABORT`: Immediately terminates the entire `COPY` operation. Suitable for strict data quality requirements where any error requires manual inspection.
 
-* `COPY_JOB_HINT`: Optional, reserved parameter for Lakehouse.
-
-* `copy_statement`: `<copy_statement>` supports all file parameters. When the `ON_ERROR=CONTINUE|ABORT` parameter is set, it controls how errors are handled during data loading, and the list of imported files is returned:
-  * `CONTINUE`: Skips error rows and continues loading subsequent data. Suitable for scenarios that tolerate partial errors and require maximum data loading completion. Currently, ignorable errors are limited to file format mismatches — for example, the command specifies zip compression but the file uses zstd compression.
-  * `ABORT`: Immediately terminates the entire `COPY` operation. Suitable for scenarios with strict data quality requirements where any error requires manual inspection.
 
 ## Supported File Formats
 
 Refer to [COPY INTO import](copy-into-table.md).
 
-## Using PIPE Load Examples
+## PIPE Load Examples
 
 ### Using Scan File Mode (LIST\_PURGE)
 
@@ -100,7 +98,7 @@ CREATE EXTERNAL VOLUME pipe_volume
     
 ```
 
-Step 2: Run the copy command standalone to verify it imports successfully
+Step 2: Run the COPY command standalone to verify it imports successfully
 
 ```SQL
 copy into pipe_purge_mode from volume pipe_volume(id int,col string) 
@@ -113,26 +111,26 @@ Step 3: Use the above statement to build the Pipe object
 
 ```SQL
 create pipe volume_pipe_list_purge
-  VIRTUAL_CLUSTER = 'default'
-  --Execute to get the latest file using scan file mode
+  VIRTUAL_CLUSTER = 'DEFAULT'
+  -- Use scan file mode to get the latest files
   INGEST_MODE = 'LIST_PURGE'
   as
 copy into pipe_purge_mode from volume pipe_volume(id int,col string) 
 using csv OPTIONS(
   'header'='false'
 )
---Must add purge parameter to delete data after successful import 
+-- Must add purge parameter to delete data after successful import 
 purge=true
 ;
 ```
 
 Step 4: View Pipe execution history and imported files
 
-* View the execution status of Pipe copy jobs
+* View the execution status of Pipe COPY jobs
 
-Filter by `query_tag` in the job history. All copy jobs executed by the Pipe are tagged with the format: `pipe.workspace_name.schema_name.pipe_name`
+Filter by `query_tag` in the job history. All COPY jobs executed by the Pipe are tagged with the format: `pipe.workspace_name.schema_name.pipe_name`
 
-* View the history of files imported by copy jobs
+* View the history of files imported by COPY jobs
 
 ```SQL
 select * from load_history('schema_name.table_name');
@@ -143,7 +141,7 @@ select * from load_history('schema_name.table_name');
 Step 1: Enable Alibaba Cloud Message Service (MNS)
 
 1. Enable Message Service MNS in the Alibaba Cloud console.
-2. Configure MNS to listen to the OSS folder you want to synchronize. [See the documentation for details](https://help.aliyun.com/zh/mns/user-guide/create-a-rule-to-generate-oss-event-notifications?spm=a2c4g.11186623.0.i14)
+2. Configure MNS to listen to the OSS folder you want to synchronize. [See the documentation](https://help.aliyun.com/zh/mns/user-guide/create-a-rule-to-generate-oss-event-notifications?spm=a2c4g.11186623.0.i14)
 
 Step 2: Authorize Lakehouse to read OSS
 
@@ -164,14 +162,14 @@ CREATE STORAGE CONNECTION my_connection_exnet_role
     TYPE oss
     REGION = 'cn-hangzhou'  -- Select according to the region where OSS is located
     ROLE_ARN = 'acs:ram::...:role/czudfrole'  -- Replace with your Role ARN
-    ENDPOINT = 'oss-cn-hangzhou.aliyuncs.com';  -- Select Endpoint according to the region where OSS is located
+    ENDPOINT = 'oss-cn-hangzhou.aliyuncs.com';  -- Select Endpoint based on the OSS region
 ```
 
 Step 5: Create a Volume
 
 ```SQL
 CREATE EXTERNAL VOLUME my_volume_exnet_role
-    LOCATION 'oss://function-compute-my1/autoloader'  -- Replace with the path of the OSS Bucket
+    LOCATION 'oss://function-compute-my1/autoloader'  -- Replace with your OSS Bucket path
     USING connection my_connection_exnet_role
     DIRECTORY = (
         enable = TRUE,
@@ -197,7 +195,8 @@ COPY INTO pipe_log_json FROM (
 
 ## Status Monitoring and Management
 
-### Viewing Pipe Status
+### View Pipe Status
+
 
 ````
 DESC PIPE EXTENDED kafka_pipe_stream
@@ -217,29 +216,27 @@ DESC PIPE EXTENDED kafka_pipe_stream
 | invalid_reason     |                                                                                                                                                                                     |
 | pipe_latency       | {"kafka":{"lags":{"0":0,"1":0,"2":0,"3":0},"lastConsumeTimestamp":-1,"offsetLag":0,"timeLag":-1}}                                                                                   |
 +--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-````
 
-### Viewing Pipe Run History
+````
 
-Since each execution is a Pipe-issued copy, you can view all operations in the job history. Filter by `query_tag` in the [job history](web-job-history.md) — all copy jobs executed by the Pipe are tagged with the format `pipe.``workspace_name``.schema_name.pipe_name`, making it easy to track and manage.
+### View Pipe Execution History
 
-### Stopping and Starting a Pipe
+Since each execution is a Pipe-issued COPY, you can view all operations in the job history. Filter by `query_tag` in the [job history](<web-job-history.md>). All COPY jobs executed by a Pipe are tagged with the format `pipe.``workspace_name``.schema_name.pipe_name` for easy tracking.
 
-* Pause a Pipe
+### Stop and Start a Pipe
 
+- Pause a Pipe:
 ```
 ALTER PIPE pipe_name SET PIPE_EXECUTION_PAUSED = true;
 ```
-
-* Resume a Pipe
-
+- Resume a Pipe:
 ```
 ALTER PIPE pipe_name SET PIPE_EXECUTION_PAUSED = false
 ```
 
-### Modifying Pipe Properties
+### Modify Pipe Properties
 
-You can modify a Pipe's properties, but only one property at a time. If you need to modify multiple properties, run the `ALTER` command multiple times. The following properties can be modified:
+You can modify Pipe properties one at a time. If multiple properties need to be changed, run the `ALTER` command multiple times. Below are the modifiable properties and their syntax:
 
 ```SQL
 ALTER PIPE pipe_name SET 
@@ -255,9 +252,7 @@ Examples:
 
 ```
 -- Change the compute cluster
-ALTER PIPE pipe_name SET VIRTUAL_CLUSTER = 'default'
+ALTER PIPE pipe_name SET VIRTUAL_CLUSTER = 'DEFAULT'
 -- Set COPY_JOB_HINT
 ALTER PIPE pipe_name SET COPY_JOB_HINT='{"cz.mapper.kafka.message.size": "2000000"}'
 ```
-
-^

package/bin/skills/lakehouse-doc-en/references/pipe-summary.md

@@ -1,6 +1,5 @@
 # Using Pipe for Continuous Data Import
 
-> \[Preview Release] This feature is currently in public preview.
 
 ## Overview
 
@@ -79,13 +78,24 @@ Parameter Description:
 
 Currently, you can use SQL commands to view the Pipe list and object details.
 
-* Use the SHOW PIPES command to view the PIPE object list
+* Use the `SHOW PIPES` command to view the Pipe object list
 
-```SQL
+```
+-- List all Pipes in the current Schema
 SHOW PIPES;
+-- List all Pipes in a specified Schema
+SHOW PIPES IN SCHEMA schema_name;
+-- List all Pipes in a specified Workspace
+SHOW PIPES IN WORKSPACE workspace_name;
 ```
 
-* Use the DESC PIPE command to view detailed information about the specified PIPE object
+**Notes**
+
+* `SHOW PIPES`: Lists Pipe objects in the current Schema by default.
+* `SHOW PIPES IN SCHEMA schema_name`: Lists all Pipe objects in the specified Schema.
+* `SHOW PIPES IN WORKSPACE workspace_name`: Lists all Pipe objects in the specified Workspace.
+
+* Use the `DESC PIPE` command to view detailed information about the specified Pipe object
 
 ```SQL
 DESC PIPE <name>;