@clickzetta/cz-cli-darwin-x64 0.5.16 → 0.5.17

package/bin/skills/lakehouse-doc-en/references/jobprofile-bestpractices.md

@@ -5,104 +5,100 @@
 The Lakehouse Job History page (Job Profile) provides you with an intuitive way to view detailed information about queries executed in your Lakehouse account over the past 7 days. You can view a history of jobs including tasks submitted via the JDBC interface, Studio ad-hoc queries, and Studio scheduled tasks. This guide will help you analyze jobs that have failed or run slowly and provide corresponding solutions.
 
 ## Job History Search
-- Supports searching by job ID generated by SQL jobs
-- Supports searching by status
-     - setup: SQL initialization phase, including operations such as compilation and optimization
-     - resuming_cluster: Waiting for vc to start, if it takes a long time, please contact technical support
-     - queued: Job is queued waiting for resources, if it takes a long time, check if vc resources are fully occupied, consider expanding vc
-     - running: SQL data processing time, you can click on diagnostics to view the time taken by each operator
-     - finish: Job has ended, some jobs may have a cleanup process in this stage, which can take time
-- Supports filtering by duration
-- Supports filtering by time, currently up to 10,000 jobs from the past seven days can be queried
-- Supports filtering by the name of the cluster where the job ran
-- Supports filtering by the job submitter
-- Supports filtering by queryTag
-    Users can use the command set query_tag="" to indicate the source of the job and tag the job when submitting SQL. This makes it easy to filter in this interface
-    - Set query_tag in the studio interface, select two days of SQL to execute simultaneously
-    ```SQL
-        set query_tag="test";
-        select 1;
-    ```
-- Add `query_tag` in the JDBC URL, so each submitted SQL will carry the `query_tag` to indicate the source, which can be filtered on the page.
-    ```text
-    jdbc:clickzetta://clickzetta.api.singdata.com/default?schema=public&query_tag=test
-
-    ```
-- Set query_tag in python code
-```python
-# Establish connection
-conn = connect(username='',
- password='', 
-service='api.singdata.com', 
-instance='jnsxwfyr',
- workspace='', schema='public', vcluster='default') 
-# Execute SQL
-cursor = conn.cursor() 
-my_param["hints"]["query_tag"] ="test"
-cursor.execute('select 1;', parameters=my_param)
 
-```
-- The default Schema for the job, the context in which the submitted SQL runs, can be obtained through select current_schema().
+* Supports searching by job ID of SQL jobs.
+* Supports searching by status:
+  * setup: SQL initialization phase, including compilation and optimization.
+  * resuming_cluster: Waiting for the Virtual Cluster to start. If it takes a long time to start, please contact technical support.
+  * queued: Job is queued waiting for resources. If this takes a long time, check whether Virtual Cluster resources are fully occupied, or consider scaling up.
+  * running: SQL data processing time. You can click Diagnostics to view the time taken by each operator.
+  * finish: Job has ended. Some jobs may perform a cleanup process at this stage, which takes additional time.
+* Supports filtering by duration.
+* Supports filtering by time. Currently up to 10,000 jobs from the past seven days can be queried.
+* Supports filtering by the name of the cluster where the job ran.
+* Supports filtering by the job submitter.
+* Supports filtering by queryTag.
+  When submitting SQL, users can use the command `set query_tag=””` to tag the job's source, and then filter by this tag in the interface.
+  * Set query_tag in the Studio interface, select two SQL statements and execute them simultaneously:
+  ```SQL
+      set query_tag=”test”;
+      select 1;
+  ```
+  * Add `query_tag` in the JDBC URL so that each submitted SQL carries the `query_tag` to identify its source, which can be filtered on the page.
+  ```text
+  jdbc:clickzetta://instance.region_id.api.clickzetta.com/default?schema=public&query_tag=test
+
+  ```
+  * Set query_tag in Python code:
+  ```python
+  # Establish connection
+  conn = connect(username='',
+   password='',
+  service='region_id.api.clickzetta.com',
+  instance='demo_instance',
+   workspace='', schema='public', vcluster='default')
+  # Execute SQL
+  cursor = conn.cursor()
+  my_param[“hints”][“query_tag”] =”test”
+  cursor.execute('select 1;', parameters=my_param)
+
+  ```
+* The default Schema of a job (the context in which the submitted SQL runs) can be obtained via `select current_schema()`.
 
 ## Analyzing Failed Jobs
 
-When a job fails to run, you can view the reason for the failure through the details in the job profile. Here are some common failure reasons and solutions:
+When a job fails, you can view the reason for the failure through the job's Job Profile details. Here are some common failure reasons and solutions:
 
 ### SQL Syntax Error
 
 **Error Example**:
+
 ```SQL
 Execute select * from ttt;
 Error: CZLH-42000:[1,15] Semantic analysis exception - table or view not found - uat_demo_project.`public`.ttt
 ```
-**Error Code CZLH-42000** indicates an error related to SQL language parsing. [1,15] indicates that the error occurred on line 1, column 15 of the SQL. In this example, the reason is that the `ttt` table does not exist. Please note that if you submit tasks through Studio development, the job editor in development will include descriptive information, which is not submitted to the SQL engine. Therefore, the correct line number should subtract the preceding descriptive information. You can view the correct positional relationship through the job content in the job details or find the error location in the SQL editor.
-
 
+**Error Code CZLH-42000** indicates an error related to SQL language parsing. [1,15] indicates the error occurred on line 1, column 15 of the SQL. In this example, the reason is that the `ttt` table does not exist. Note that if you submit tasks through the Studio development interface, the job editor includes descriptive header information that is not submitted to the SQL engine. Therefore, the correct line number should subtract the preceding header lines. You can view the correct positional relationship through the job content in the job details, or find the error location in the SQL editor.
 
 ## Analyzing Slow Running Jobs
 
-Slow running jobs may encounter issues during the compilation phase, the virtual cluster startup phase, or the execution phase. Below are the analyses and solutions for these phases:
+Slow running jobs may encounter issues during the compilation phase, the Virtual Cluster startup phase, or the execution phase. The following provides analysis and solutions for each phase:
 
 ### Compilation Phase
 
-**Issue**: Job status shows "Preparing to execute".
+**Symptom**: Job status shows “Initializing”.
 
-**Possible Causes and Solutions**:
+**Possible causes and solutions**:
 
 1. **Complex execution plan**: The job may require a long time to optimize. Please be patient; it should not take more than 10 minutes under normal circumstances.
-2. **Compilation resources are fully occupied**: If you submit a large number of SQLs at once, it may lead to insufficient compilation resources. Please reduce the frequency of SQL submissions. If you have a large number of high-concurrency query requirements, please submit a ticket for assistance.
+2. **Compilation resources fully occupied**: If you submit a large number of SQL statements at once, compilation resources may be insufficient. Please reduce the frequency of SQL submissions. If you have high-concurrency query requirements, please submit a ticket for assistance.
 
 ### Virtual Cluster Startup Phase
 
-**Issue**: Job status shows "Cluster starting". The current status is that the computing cluster is being started.
-
-### Waiting Execution Phase
+**Symptom**: Job status shows “Cluster Starting”. (The Virtual Cluster is currently being started.)
 
-**Issue**: Job status shows "Waiting to execute".
+### Waiting for Execution Phase
 
-**Possible Causes and Solutions**:
+**Symptom**: Job status shows “Waiting for Execution”.
 
-**Insufficient computing resources in the current cluster**: You can filter and view the currently running jobs through the interface. A large number of running jobs may be causing resource waiting. You can expand resources or terminate large running jobs to free up resources.
+**Possible causes and solutions**:
+1. **Insufficient computing resources in the current cluster**: You can filter and view currently running jobs through the interface. A large number of simultaneously running jobs may be causing resource contention. Consider scaling up resources, or terminating large running jobs to free up resources.
 
 ### Execution Phase
 
-**Issue**: Job status shows "Running". At this stage, you can click to view the execution status of each operator.
+**Symptom**: Job status shows “Running”. At this stage, you can click in to view the execution status of each operator.
 
-**Possible Causes and Solutions**:
+**Possible causes and solutions**:
+1. **Waiting for resources**: The job may be waiting for resource allocation. Check resource usage and submit a ticket if needed.
+2. **Slow data reading**: The job may be executing slowly due to slow data reads. Check the data storage and read strategy, and optimize the storage structure or adjust the read strategy if needed.
 
-1. **Waiting for resources**: The job may be waiting for resource allocation. Please check the resource usage. If necessary, please submit a ticket for assistance.
-2. **Slow data reading speed**: The job may be executing slowly due to slow data reading speed. Please check the data storage and reading strategy. If necessary, optimize the data storage structure or adjust the reading strategy.
+### Sharing for Diagnosis
 
-## Viewing Execution Plan and Operator Details
-
-During the execution phase, you can click on the executing operator to query specific steps and strategies. For example, moving the mouse over a specific operator can correspond to the specific operator executed in the SQL. This helps you identify which specific operator is causing the job to run slowly.
-
-![](.topwrite/assets/image_1700210552306.png)
+After entering the job details page, click the “Share” button to share the job with others. Recipients can view the content without logging in. ![](.topwrite/assets/image_1740557522715.png =774)
+If you have questions or need further assistance, copy the link above and contact the Lakehouse team. We will diagnose and resolve the issue for you.
 
+## Viewing Execution Plan and Operator Details
 
-## Share for Diagnosis  
+During the execution phase, you can click on an executing operator to view the specific steps and strategy. For example, hovering the mouse over a specific operator highlights the corresponding operator in the SQL. This helps you identify which specific operator is causing the job to run slowly.
 
-After entering the assignment details page, click the “Share” button to share the assignment with others. Recipients can view the content without logging in.  
-![](.topwrite/assets/image_1740558353576.png)
-If you need to stop sharing, you can revoke access to the link at any time.  
-If you have any questions or need further assistance, please copy the link above and contact the Lakehouse team. We will diagnose and resolve the issue for you.
+![](.topwrite/assets/image_1700210552306.png =771)

package/bin/skills/lakehouse-doc-en/references/kafka-connection.md

@@ -1,6 +1,5 @@
 ## Overview
 
-> **[Public Preview]** This feature is currently in public preview phase.
 
 This document describes how to create an external table connected to the Kafka messaging system in SQL. By defining an external table, you can easily read data streams from Kafka and query and analyze this data as a table.