@clickzetta/cz-cli-darwin-arm64 0.3.95 → 0.3.96

package/bin/skills/lakehouse-doc-en/references/external_object_user_guide.md

@@ -0,0 +1,298 @@
+## **1. Overview**
+
+The Lakehouse architecture provides powerful external object federation capabilities, allowing users to access and analyze data stored in multiple heterogeneous data sources without moving data. This guide details the usage scenarios, configuration methods, and best practices for External Catalogs, External Schemas, and External Tables.
+
+### **1.1 External Object Hierarchy**
+
+```Plain
+Catalog > Schema > Table
+```
+
+* **External Catalog**: Top-level container, mapping to an external data system
+* **External Schema**: Intermediate-level container, similar to a database
+* **External Table**: Bottom-level object, directly accessing data files from external data sources
+
+## **2. Applicable Scenarios**
+
+### **2.1 External Catalog Scenarios**
+
+1\. **Unified Multi-Source Data Management**
+
+* Scenario: An enterprise has multiple data platforms (Hive, Databricks, etc.)
+* Advantage: Access all data sources directly in the Lakehouse without data migration
+* Application: Data governance, unified metadata management
+
+2\. **Cross-Platform Federated Queries**
+
+* Scenario: Need to simultaneously analyze data stored in different systems
+* Advantage: Real-time querying across multiple data sources without ETL
+* Application: Cross-system reports, comprehensive analysis
+
+3\. **Data Lakehouse Architecture**
+
+* Scenario: Building a unified data analytics platform
+* Advantage: Combines the flexibility of a data lake with the performance of a data warehouse
+* Application: Full-chain analysis from historical data to real-time data
+
+4\. **Incremental Data Migration**
+
+* Scenario: Migrate data from legacy systems to new systems in phases
+* Advantage: Maintain business continuity during migration
+* Application: System upgrades, architecture transformation
+
+### **2.2 External Schema Scenarios**
+
+1\. **Hive Metadata Integration**
+
+* Scenario: Connect to an existing Hive Metastore Service (HMS)
+* Advantage: Reuse existing metadata without redefining table structures
+* Application: Big data platform consolidation
+
+2\. **Database-Level Access Control**
+
+* Scenario: Assign permissions at the Schema level
+* Advantage: Simplified permission management, improved security
+* Application: Multi-department data sharing
+
+3\. **External Database Mapping**
+
+* Scenario: Import an external database as a whole into the Lakehouse
+* Advantage: Preserve the original data organization structure
+* Application: Database migration, cross-database analysis
+
+### **2.3 External Table Scenarios**
+
+1\. **Direct Query of Object Storage Data**
+
+* Scenario: Analyze data files stored in object storage such as S3/OSS/COS
+* Advantage: Avoid data duplication, save storage space
+* Application: Log analysis, large file processing
+
+2\. **Streaming Data Ingestion**
+
+* Scenario: Connect to message queue systems such as Kafka
+* Advantage: Real-time data querying and processing
+* Application: Real-time monitoring, event processing
+
+3\. **Data Lake Format Support**
+
+* Scenario: Access open-source data lake formats such as Delta and Hudi
+* Advantage: Leverage the open-source ecosystem and avoid data silos
+* Application: Data lake construction, open-source compatibility
+
+4\. **Hot and Cold Data Separation**
+
+* Scenario: Store cold data in lower-cost external storage
+* Advantage: Optimize storage costs and query performance
+* Application: Data archiving, cost optimization
+
+## **3. Configuration Guide**
+
+### **3.1 External Catalog Configuration**
+
+#### **Create a Catalog Connection**
+
+```SQL
+-- Create a Catalog connection to Databricks
+CREATE CATALOG CONNECTION IF NOT EXISTS databricks_conn 
+TYPE databricks 
+HOST = 'https://dbc-12345678-9abc.cloud.databricks.com' 
+CLIENT_ID = 'client_id_value' 
+CLIENT_SECRET = 'client_secret_value' 
+ACCESS_REGION = 'us-west-2';
+
+-- Create a Catalog connection to Hive
+CREATE CATALOG CONNECTION IF NOT EXISTS hive_conn
+TYPE hms
+hive_metastore_uris = 'metastore-host'
+storage_connection = 9083;
+```
+
+#### **Create an External Catalog**
+
+```SQL
+-- Create an External Catalog based on the connection above
+CREATE EXTERNAL CATALOG databricks_catalog 
+CONNECTION databricks_conn;
+
+CREATE EXTERNAL CATALOG hive_catalog
+CONNECTION hive_conn;
+```
+
+### **3.2 External Schema Configuration**
+
+```SQL
+-- Create a mapping to a database in Hive
+CREATE EXTERNAL SCHEMA external_db_schema 
+CONNECTION hive_catalog 
+OPTIONS ( 'schema'='default');
+```
+
+### **3.3 External Table Configuration**
+
+```SQL
+-- Create a Delta Lake External Table
+CREATE EXTERNAL TABLE delta_sales
+USING DELTA 
+CONNECTION oss_delta 
+LOCATION 'oss://bucketname/delta-format/sales/' 
+COMMENT 'Delta external table example';
+
+-- Create a Kafka External Table
+CREATE EXTERNAL TABLE kafka_messages (
+  key STRING,
+  value STRING,
+  topic STRING,
+  partition INT,
+  offset BIGINT,
+  timestamp BIGINT
+)
+USING KAFKA
+CONNECTION kafka_conn
+OPTIONS (
+  'kafka.bootstrap.servers' = 'broker:9092',
+  'subscribe' = 'test-topic'
+);
+```
+
+## **4. Query Usage**
+
+### **4.1 Query Tables in External Catalogs**
+
+```SQL
+-- Use three-part syntax to query tables in an External Catalog
+SELECT * FROM databricks_catalog.default.sales 
+WHERE region = 'APAC'
+LIMIT 10;
+
+-- Join query between an External Catalog and internal tables
+SELECT a.customer_id, a.order_total, b.customer_name
+FROM databricks_catalog.sales.orders a
+JOIN internal_schema.customers b
+ON a.customer_id = b.id
+WHERE a.order_date >= '2024-01-01';
+```
+
+### **4.2 Query Tables in External Schemas**
+
+```SQL
+-- Query tables in an External Schema
+SELECT * FROM external_db_schema.customer_table
+WHERE register_date > '2023-01-01';
+```
+
+### **4.3 Query External Tables**
+
+```SQL
+-- Query a Delta External Table
+SELECT product, SUM(price) as total_sales
+FROM delta_sales
+WHERE sale_date BETWEEN '2024-01-01' AND '2024-04-30'
+GROUP BY product
+ORDER BY total_sales DESC;
+
+-- Query a Kafka External Table
+SELECT * FROM kafka_messages
+WHERE timestamp > 1715132800000 -- 2024-05-08 00:00:00 UTC
+LIMIT 100;
+```
+
+## **5. Performance Optimization Best Practices**
+
+### **5.1 Data Import Strategy**
+
+Since data in external tables is stored outside the Lakehouse, query performance may not match that of internal tables. For frequently queried data, it is recommended to import it into internal tables:
+
+```SQL
+-- Import external table data into an internal table
+INSERT INTO internal_sales_table 
+SELECT * FROM databricks_catalog.sales.orders
+WHERE order_date >= '2024-01-01';
+
+```
+
+### **5.2 Partitioning and Filtering**
+
+Use partition information and filter conditions to reduce the amount of data scanned:
+
+```SQL
+-- Use partition filtering
+SELECT * FROM delta_sales
+WHERE sale_date = '2024-05-15'  -- Using a partition column here can significantly improve performance
+AND product = 'Laptop';
+```
+
+## **6. Management and Monitoring**
+
+### **6.1 View External Objects**
+
+```SQL
+-- View all Catalogs
+SHOW CATALOGS;
+
+-- View all External Schemas
+SHOW SCHEMAS EXTENDED WHERE type='external';
+
+-- View tables in an External Schema
+SHOW TABLES IN external_db_schema;
+
+-- Check External Table structure
+DESCRIBE TABLE delta_sales;
+```
+
+## **7. Typical Use Cases**
+
+### **7.1 Unified Data Lake and Data Warehouse Query**
+
+Scenario: An enterprise has both a Hive data lake and a Databricks data warehouse and needs to perform cross-platform analysis.
+
+Solution:
+
+1. Create External Catalogs connecting to Hive and Databricks
+2. Use federated queries to join data from both platforms
+3. Build unified views to provide a consistent data access layer
+
+### **7.2 Historical Data Archiving and Querying**
+
+Scenario: Archive historical data to object storage but still need occasional queries.
+
+Solution:
+
+1. Store historical data in Delta or Parquet format in object storage
+2. Create External Tables mapping to the archived data
+3. Query on demand without occupying primary storage space
+
+### **7.3 Real-Time and Batch Data Integration**
+
+Scenario: Need to simultaneously analyze real-time data from Kafka and historical data from the data warehouse.
+
+Solution:
+
+1. Create a Kafka External Table to process real-time data
+2. Use federated queries to join real-time data with historical data
+3. Build real-time dashboards displaying comprehensive analysis results
+
+## **8. Troubleshooting**
+
+### **8.1 Connection Issues**
+
+\- **Symptom**: Unable to connect to the external data source
+
+\- **Solution**:
+
+* Check network connectivity and firewall settings
+* Verify that connection credentials are valid
+* Confirm that the external service is available
+
+### **8.2 Performance Issues**
+
+\- **Symptom**: External Table query performance is slow
+
+\- **Solution**:
+
+* Use partition filtering to reduce the amount of data scanned
+* Consider importing frequently queried data into internal tables
+
+## **9. Summary**
+
+The Lakehouse's external object functionality provides powerful data federation capabilities, enabling enterprises to integrate multiple heterogeneous data sources without moving data. By properly utilizing External Catalogs, External Schemas, and External Tables, you can build a unified data analytics platform, implement a data lakehouse architecture, and enhance data value.

package/bin/skills/lakehouse-doc-en/references/external_volume.md

@@ -0,0 +1,199 @@
+# External Volume
+
+An External Volume is used to mount external object storage (Alibaba Cloud OSS, Tencent Cloud COS, Amazon S3). Through an External Volume, Singdata Lakehouse can directly access and manage files stored in external cloud storage without migrating data into Singdata Lakehouse.
+
+## What Is an External Volume
+
+An External Volume is an object in Singdata Lakehouse that points to a specific path in external object storage. It is created with `CREATE EXTERNAL VOLUME` to mount external object storage (OSS/COS/S3).
+
+> ⚠️ **Note**: A Named Volume (created with `CREATE VOLUME`) is an **internal Volume** — data is stored inside Singdata Lakehouse. It is a different type from an External Volume. See [Named Volume](om-named-volume.md).
+
+With an External Volume, you can:
+
+- Query CSV/JSON/Parquet files directly in object storage
+- Import data from object storage into Singdata Lakehouse tables
+- Export Singdata Lakehouse table data to object storage
+- Manage files in external storage in a unified way
+
+**Key characteristics**:
+- Data is stored in external cloud storage; Singdata Lakehouse only stores path metadata
+- Supports Alibaba Cloud OSS, Tencent Cloud COS, and Amazon S3
+
+## Creating an External Volume
+
+### Prerequisites
+
+Before creating an External Volume (mounting external storage), you must first create a Storage Connection:
+
+```sql
+-- Create an Alibaba Cloud OSS storage connection
+CREATE STORAGE CONNECTION IF NOT EXISTS oss_conn
+    TYPE oss
+    ENDPOINT = 'oss-cn-hangzhou.aliyuncs.com'
+    ACCESS_ID = 'your_access_key_id'
+    ACCESS_KEY = 'your_access_key_secret';
+```
+
+### Create an External Volume (Mount External Storage)
+
+```sql
+CREATE EXTERNAL VOLUME [IF NOT EXISTS] [schema_name.]<volume_name>
+    LOCATION '<storage_url>'
+    USING CONNECTION <connection_name>
+    DIRECTORY = (
+        enable = true,
+        auto_refresh = true
+    )
+    RECURSIVE = true;
+```
+
+**Parameter reference**:
+
+| Parameter | Description |
+|-----------|-------------|
+| `volume_name` | Volume name; must be unique within the same schema |
+| `LOCATION` | Object storage path, e.g. `oss://bucket_name/path/` |
+| `USING CONNECTION` | Name of the referenced Storage Connection |
+| `DIRECTORY.enable` | Whether to enable directory functionality |
+| `DIRECTORY.auto_refresh` | Whether to automatically refresh file metadata |
+| `RECURSIVE` | Whether to recursively scan subdirectories |
+
+**Example**:
+
+```sql
+-- Create an External Volume mounting an OSS bucket
+CREATE EXTERNAL VOLUME my_oss_vol
+    LOCATION 'oss://mcp-data-hangzhou/test/'
+    USING CONNECTION oss_conn
+    DIRECTORY = (enable = true, auto_refresh = true)
+    RECURSIVE = true;
+```
+
+### Create a Named Volume
+
+> A Named Volume is an internal Volume. For the creation syntax, see [CREATE VOLUME](create-volume.md). For the usage guide, see [Named Volume](om-named-volume.md).
+
+## Viewing an External Volume
+
+### View Volume Details
+
+```sql
+DESC VOLUME my_oss_vol;
++------------------------+--------------------------------+
+| info_name              | info_value                     |
++------------------------+--------------------------------+
+| name                   | my_oss_vol                     |
+| creator                | qiliang                        |
+| created_time           | 2026-05-20 00:23:49.074        |
+| last_modified_time     | 2026-05-20 00:23:49.074        |
+| external               | true                           |
+| url                    | oss://mcp-data-hangzhou/test/  |
+| connection_name        | quick_start.oss_conn           |
+| recursive              | true                           |
+| directory_enabled      | true                           |
+| directory_auto_refresh | true                           |
++------------------------+--------------------------------+
+```
+
+### List Files in a Volume
+
+```sql
+SHOW VOLUME DIRECTORY my_oss_vol;
++---------------------------------+--------------------------------------------------------------+----------+---------------------+
+| relative_path                   | url                                                          | size     | last_modified_time  |
++---------------------------------+--------------------------------------------------------------+----------+---------------------+
+| green_tripdata_2025-03.parquet  | oss://mcp-data-hangzhou/test/green_tripdata_2025-03.parquet  | 1253510  | 2025-09-03 17:33:05 |
+| taxi_data.parquet               | oss://mcp-data-hangzhou/test/taxi_data.parquet               | 69964745 | 2025-06-07 03:42:52 |
++---------------------------------+--------------------------------------------------------------+----------+---------------------+
+```
+
+## Querying Files in an External Volume
+
+```sql
+-- Query a Parquet file
+SELECT * FROM VOLUME my_oss_vol
+    USING PARQUET
+    FILES ('green_tripdata_2025-03.parquet')
+    LIMIT 5;
+
+-- Query a CSV file
+SELECT * FROM VOLUME my_oss_vol
+    USING CSV
+    OPTIONS ('header' = 'true')
+    FILES ('data.csv')
+    LIMIT 5;
+```
+
+## Importing External Volume Data into a Table
+
+```sql
+-- Create the target table
+CREATE TABLE green_trip (
+    VendorID INT,
+    lpep_pickup_datetime TIMESTAMP,
+    trip_distance DOUBLE,
+    fare_amount DOUBLE,
+    total_amount DOUBLE
+);
+
+-- Import data from the Volume
+COPY INTO green_trip FROM VOLUME my_oss_vol
+    (VendorID INT, lpep_pickup_datetime TIMESTAMP, trip_distance DOUBLE, fare_amount DOUBLE, total_amount DOUBLE)
+    USING PARQUET
+    FILES ('green_tripdata_2025-03.parquet');
+```
+
+## Exporting Data to an External Volume
+
+```sql
+-- Export table data to an External Volume
+COPY INTO VOLUME my_oss_vol
+    SUBDIRECTORY 'export/'
+    FROM green_trip
+    FILE_FORMAT = (TYPE = CSV HEADER = true);
+```
+
+> Named Volumes also support `COPY INTO VOLUME` for export using the same syntax — simply replace `my_oss_vol` with the Named Volume name.
+
+## Refreshing Volume File Metadata
+
+When files in external storage change, you can manually refresh the Volume's file metadata:
+
+```sql
+ALTER VOLUME my_oss_vol REFRESH;
+```
+
+> ⚠️ **Note**: Only External Volumes (mounted external storage) support the REFRESH operation. Named Volumes (internal storage) do not require refreshing.
+
+## Dropping an External Volume
+
+```sql
+DROP VOLUME [IF EXISTS] my_oss_vol;
+```
+
+> ⚠️ **Note**: Dropping an External Volume only removes the metadata reference in Singdata Lakehouse — it does not delete the actual files in external object storage or internal storage. To delete files, use the `REMOVE` command first.
+
+## Required Permissions
+
+| Permission | Description |
+|------------|-------------|
+| READ METADATA | View Volume object metadata |
+| READ VOLUME | Read files and directories under the Volume |
+| WRITE VOLUME | Write data to the Volume |
+| ALTER VOLUME | Modify Volume properties (e.g., REFRESH) |
+
+## Notes
+
+- An External Volume (external storage) only stores path metadata; actual data resides in external cloud storage
+- Storage costs for an External Volume (external storage) are charged at the cloud provider's standard rates; there are no additional storage charges on the Singdata Lakehouse side
+- Storage costs for a Named Volume (internal storage) are charged at Singdata Lakehouse storage rates
+- Cross-cloud creation is not supported: an Alibaba Cloud instance can only create an OSS Connection; a Tencent Cloud instance can only create a COS Connection
+- Dropping an External Volume does not delete the actual files in external or internal storage
+
+## Related Documentation
+
+- [Data Lake Storage Management: Volume](datalake_volume.md)
+- [Create a Storage Connection](create-storage-connection.md)
+- [Using Internal Volumes](internal_volume.md)
+- [Import Data from a Volume](from_volume_to_table.md)
+- [Export Data to a Volume](from_lakehouse_to_volume.md)

package/bin/skills/lakehouse-doc-en/references/f6fc6447ee.md

@@ -0,0 +1,161 @@
+# Task Scheduling and Instance Execution
+
+## Overview
+
+### Concepts
+
+In task development scenarios, offline tasks run periodically (e.g., multiple times a day, once a day, etc.). In addition, there are often upstream-downstream dependencies between tasks, and they execute in dependency order. This periodic execution with upstream-downstream task dependencies is the core concept of scheduling.
+
+### Tasks and Instances
+
+When a user submits a development script to the production environment, a periodic task is created. Each run of a periodic task generates a periodic instance, and each periodic instance may contain multiple execution records, such as automatic reruns.
+
+Therefore, periodic tasks and periodic instances typically have a one-to-many relationship.
+
+## How the Scheduling System Works
+
+The scheduling system has two main responsibilities: **generating instances** and **running instances on schedule**. The specific concepts are as follows:
+
+### Instance Generation
+
+After a task is submitted to the scheduling system, the system generates instances based on the scheduling configuration. The system currently provides two instance generation modes:
+
+* Next-Day Effective: All instances that need to be executed on the next day are uniformly generated at 22:00 of the current day.
+* Effective Immediately After Publishing: After the user clicks submit, the system immediately generates instances that need to be executed on the current day. Instances for the next day are uniformly generated at 22:00 using the system default method.
+
+The specific generation rules are detailed in the "Instance Generation" section under Scheduling Properties Configuration.
+
+### Running Instances on Schedule
+
+When running instances on schedule each day, the scheduling system determines whether an instance can run. Generally, two conditions must be met:
+
+* Whether the task has reached its scheduled time
+* Whether all upstream tasks have succeeded
+
+^
+
+If both conditions are met, the scheduling system submits the instance task for execution. Once the instance task obtains the corresponding resources, it will execute normally as planned (**Instance Running**).
+
+If either condition is not met, the task instance will remain in the **Not Started** state. However, to prevent a large number of task instances from remaining in the Not Started state for a long time due to configuration issues or paused upstream tasks, which would waste resources, the system will execute a kill operation based on the user-configured "Scheduling Wait Duration". That is, the task instance will be directly determined as failed by the system.
+
+| Note: If the periodic task in the production environment does not have a scheduling wait duration configured, the default instance scheduling wait duration is 3 days. That is, when the task reaches its scheduled time, after 3 days, regardless of whether all upstream tasks have succeeded, it will change from the **Not Started** state to the **Failed** state. If the user has configured a "Scheduling Wait Duration" in the scheduling configuration, once the task reaches its scheduled time, regardless of whether all upstream tasks have succeeded, once the scheduling wait duration is exceeded, the task instance state will change from **Not Started** to **Failed**. |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+
+## Scheduling Properties Configuration
+
+In the **Development** module, open any task, click the Schedule Configuration function, and you can configure a series of scheduling property information for that task, including basic information, scheduling time, instance information, scheduling dependencies, and task outputs.
+
+*This document focuses on* scheduling time, instance information, and scheduling dependencies. *For other content, please refer to the help documentation.*
+
+### Scheduling Time
+
+![](.topwrite/assets/f6fc6447ee/b35ef5af588033e07f3e757c89edfd025ec25ca6.png =582)
+
+***
+
+**Scheduling Cycle**: Configure the scheduling cycle, scheduling frequency, scheduling start time, and scheduling end time. After the user configures this information, the system will automatically generate a standard cron expression that complies with the rules. This automatically generated time expression will be parsed by the scheduling engine, which uses a time-wheel algorithm to derive all specific execution instances that meet the criteria within future cycles.
+
+The scheduling frequencies in the current system are Minute, Hour, and Day. If a task's Cron expression has values set to single values or multiple values (rather than \*) in positions above the day level, such as week, month, or year, and as long as these position values do not conflict and are valid, the original time type of the task is not changed (it does not become a weekly, monthly, or yearly task). It only constrains which specific days the task runs on, as a minute, hour, or day task within those days. (In other words, there is no concept of weekly, monthly, or yearly tasks.)
+
+For example:
+
+* On the 1st and 3rd of each month, if a task runs once at a specified time, it is a daily task, not a monthly task.
+* On Monday and Wednesday of each week, if a task runs every two hours, it is an hourly task, not a weekly task, nor a daily task.
+* Similarly for minute tasks: when a task's interval is at the minute level, it is a minute task.
+
+***
+
+**Effective Date**: Refers to the effective date range of the current scheduling task. Users can choose Never End or specify a date.
+
+Never End means permanent effect. The current system supports up to the year 2099.
+
+If the user specifies a date, instances of this scheduling task will no longer be generated once the effective date range is exceeded.
+
+####
+
+### Instance Information
+
+#### Instance Generation
+
+![](.topwrite/assets/f6fc6447ee/9260e6641b50d8940c20836bfdb9330b4ba7eeab.png =556)
+
+**Instance Generation**: Based on the user-configured **scheduling configuration information and dependency relationships**, **instances are generated according to the instance generation rule selected by the user**.
+
+Effective After Publishing: Takes effect immediately after submitting the task. The specific instance change/generation scope is:
+
+* If the submission time is earlier than the scheduling start time, instances are updated/generated starting from the scheduling start time.
+* If the submission time is later than the scheduling start time, instances are updated/generated starting from the submission/publishing time.
+* Historically generated instances are not affected; only subsequent instances are changed starting from the start time.
+
+![](.topwrite/assets/f6fc6447ee/94bccbdeead608afb473198307e1466cab001784.jpeg =757)
+
+Next-Day Effective: All instances that need to be executed on the next day are uniformly generated at 22:00 of the current day.
+
+####
+
+#### Instance Rerun Methods
+
+![](.topwrite/assets/f6fc6447ee/6d2c0d8953eac7b7256337937f6f795fd084a154.png =522)
+
+The product provides three rerun methods, which mainly affect behavior in the following two scenarios:
+
+* After an instance fails to run, whether the system automatically reruns it.
+* After an instance succeeds or fails, whether the user can click the rerun operation in the instance maintenance list of the Operations Center.
+
+***
+
+The different values and behavior definitions are as follows:
+
+* **Rerun is allowed whether the run succeeds or fails**: After selecting this method, you must also set the "Instance Auto Rerun Count" and "Instance Rerun Interval". After selecting this behavior, when an instance fails to run, the system will trigger automatic reruns based on the configured rerun count and interval. Once the run succeeds or reaches the agreed-upon rerun count, the automatic rerun capability is no longer triggered. At the same time, you can find this instance in the Operations Center, and regardless of whether the instance state is success or failure, the user is supported to manually click the rerun operation to trigger rerun behavior.
+* **Rerun is allowed on failure, not allowed on success**: The specific behavior is the same as above, with the only difference being: when operating in the Operations Center, if the instance state is success, clicking the rerun operation is not allowed.
+* **Rerun is not allowed whether the run succeeds or fails**: After selecting this method, automatic rerun behavior will not be triggered, and users are also not allowed to click the rerun operation in the Operations Center.
+
+#### Run Timeout Duration
+
+![](.topwrite/assets/f6fc6447ee/e99998089947ef23c63b79f948c107be37e9cac6.png =602)
+
+When the user configures a run timeout duration, if the task instance's run time exceeds the set time, it will be forcibly killed and the run state will change to failed. The purpose is that when a task is in the "Running" state for an extended period, it occupies resources. By setting a "timeout duration," resources can be released in a timely manner.
+
+#### Scheduling Wait Duration
+
+![](.topwrite/assets/f6fc6447ee/7eb115526d02c946b30b1b2b9d78730794eb5d85.png =619)
+
+After configuring the scheduling wait duration, when the task instance reaches its scheduled run time, regardless of whether upstream tasks have succeeded, a forced kill behavior will be triggered. This configuration is mainly used to prevent resource waste caused by large numbers of downstream instances being unable to execute due to paused upstream tasks. It is recommended to configure with caution.
+
+#### Delayed Run Skip Duration
+
+![](.topwrite/assets/image_1780052779009.png)
+
+The determination is based on the difference between the time the task instance enters the running state and the configured scheduled time.
+
+If this difference exceeds the configured skip duration, the instance is immediately marked as a dry-run skip and its status is set to succeeded.
+
+For example: an instance is scheduled to run every 5 minutes, with a skip duration of 6 minutes. For an instance scheduled at 14:05, if upstream instance delays cause it to not enter the running state until 14:12, the interval is 7 minutes — exceeding the configured 6 minutes — so the system immediately performs a dry-run skip and marks the instance as succeeded.
+
+### Scheduling Dependencies
+
+Scheduling dependencies refer to the upstream-downstream dependency relationships between periodic scheduling nodes. Through the dependency relationships between nodes, upstream and downstream nodes are orderly scheduled and executed. That is, downstream nodes will only start running after upstream nodes have run successfully, ensuring the timely production of valid business data.
+
+For more details on instance execution behavior related to scheduling dependencies, see: [Task Scheduling Dependencies](task_scheduling_dependency.md)
+
+## Operations Management
+
+### Periodic Tasks
+
+* **Pause**: Periodic tasks with the status "Scheduling" support clicking Pause. After clicking Pause, all instance tasks starting from the current trigger onwards will be set to "Paused". The concept of all instances includes: instances already generated for the current day and not yet run, as well as all instances for the next day generated at 22:00 daily. That is, although the user clicked the pause operation, it only operates on the instance state and does not block the task's behavior of generating instances on schedule. The pause behavior only sets the instances in the periodic task to the paused state. Downstream states will typically be blocked by the paused task and unable to run. However, if the downstream task has a scheduling wait duration configured (or the downstream task's scheduling wait duration from its planned start time exceeds 3 days), the downstream task will be forcibly killed.
+* **Start**: Periodic tasks with the status "Scheduling Paused" support clicking Start. After clicking Start, all paused instances in the current periodic task will trigger execution behavior.
+* **Offline**: After a periodic task is directly taken offline, it will not be managed in the periodic tasks, and instances will no longer be generated. If the current task has downstream tasks running, it is not allowed to directly take it offline. The downstream tasks must be taken offline first, or click Offline (Including Downstream) to take the current task and all downstream tasks offline.
+* **Backfill**: Regardless of the periodic task's status, users are supported to click the backfill operation. After the user triggers the backfill behavior, a corresponding backfill task will be generated in the backfill tasks.
+
+^
+
+### Instance Operations
+
+* **Rerun**: Only periodic instances that have completed execution can use the rerun function. Whether rerun is allowed for different states depends on the specific options in the user's scheduling configuration. If the user has configured **Rerun is not allowed whether the run succeeds or fails**, clicking rerun is also not allowed. In the rerun operation, users are supported to choose to run only the current node or run downstream nodes. If the user has code adjustments and wishes to rerun a node with the latest code, they can check the ability to use the latest code and configuration and directly execute the rerun operation.
+* **Pause**: Only operable for task instances not in the paused state. After operation, the task instance's scheduling property will be set to "Scheduling Paused", meaning the task instance will no longer be scheduled to run.
+* **Resume**: Only operable for task instances in the paused state. After operation, the task instance's scheduling property will be restored to "Normal Scheduling", meaning the task instance will run according to the set scheduling time.
+* **Terminate**: Only operable for running task instances. After operation, the task instance's run will be terminated, and the task instance state will be set to failed.
+* **Set to Success**: Only operable for task instances that have failed to run. After operation, the task instance is forcibly set to success. This can be used in emergency operations scenarios, where it is determined that even if the current task instance fails, it does not affect the data correctness of downstream tasks, thereby unblocking the execution of downstream task instances.
+* **Set to Failure**: Only operable for task instances that have run successfully. After operation, the task instance is forcibly set to failed.
+
+^