Lakehouse Job History

Through the job history page, you can view detailed information about queries executed in the Lakehouse account over the past 7 days. This page displays a list of historical jobs, including tasks submitted using a JDBC jar, Studio ad-hoc queries, and Studio scheduled tasks.

Job History

View History

Click "Compute" in the left navigation bar, then click "Job History" to enter the job history page:

Interface

Supports searching by job ID generated by SQL jobs
Supports searching by status
- Initializing: SQL initialization phase, including operations such as compilation and optimization
- Cluster Starting: 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 it takes a long time, check whether the Virtual Cluster resources are fully occupied and consider scaling up the Virtual Cluster
- Running: SQL data processing time. You can click into diagnostics to view the time taken by each operator
- Succeeded: Job has ended. Some jobs may have a cleanup process at 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="" when submitting SQL to indicate the job source and tag the job, making it easy to filter in this interface.
- Set query_tag in the Studio interface, select two SQL statements and execute simultaneously:
set query_tag="test"; select 1;
- Add query_tag in the JDBC URL so that every submitted SQL carries the query_tag to indicate the source, which can be filtered on the page:
jdbc:clickzetta://demo_instance.cn-shanghai-alicloud.api.clickzetta.com/default?schema=public&query_tag=test
- Set query_tag in Python code:
# Establish connection conn = connect(username='', password='', service='cn-shanghai-alicloud.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 for the job is the context in which the submitted SQL runs, which can be obtained through select current_schema().

Job Details

Enter the job details to view detailed information about the job.

Stage Interface

SQL execution is divided into stages, which are executed from bottom to top. Clicking on a specific stage will show the specific time consumption of each stage.

Field information is explained as follows


Field	Description
Status	Indicates the status of the job. Currently includes: Queued: Waiting for resources Running: Running, the job is processing data Succeeded: Job ran successfully Failed: Job ran unsuccessfully
Start Time	The start time of the stage. In AP clusters, stages run in parallel
End Time	The end time of the job
Duration	The duration of the stage running
Spill to Disk	The size of the data spilled to disk. This parameter indicates whether slow performance is due to insufficient cluster memory resources
Read from Cache	In AP clusters, data that has already been read is cached first to accelerate computation
Contains Operators	Stage

Operator Interface

In the operator interface, you can view the type of each operator and its upstream and downstream dependencies. An operator is a concept in the query plan that represents the specific steps and strategies for executing a query, including data access, transformation, and updates.

Field information is explained as follows

Field	Description
Belongs to Stage	The stage corresponding to the operator
Spill to Disk	The size of the data spilled to disk. This parameter indicates whether slow performance is due to insufficient cluster memory resources
Read from Cache	In AP clusters, data that has already been read is cached first to accelerate computation
Total Rows	The data currently processed by the operator
Duration	Operators run concurrently. The displayed value is the average time of the operator
Field	Corresponds to the fields in the SQL script

Table Mode

Supports switching stages to table mode

Supports switching operators to table mode

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:

SQL Syntax Error

Error Example:

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] means the error occurred at line 1, column 15 of the SQL. In this example, the reason is that the ttt table does not exist.

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 analyses and solutions for these phases:

Compilation Phase

Issue: Job status shows "Initializing".

Possible Causes and Solutions:

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.
Compilation resources are fully occupied: If you submit a large number of SQL statements 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.

Virtual Cluster Startup Phase

Issue: Job status shows "Cluster Starting". (The current status is that the compute cluster is being started)

Queued Phase

Issue: Job status shows "Queued".

Possible Causes and Solutions:

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 queuing. You can scale up resources, or terminate large running jobs to free up resources.

Execution Phase

Issue: Job status shows "Running". At this stage you can click in to view the execution status of each operator.

Possible Causes and Solutions:

Waiting for resources: The job may be waiting for resource allocation. Please check the resource usage. If necessary, please submit a ticket for assistance.
Slow data reading speed: The job may be executing slowly due to slow data reading. Please check the data storage and reading strategy. If necessary, optimize the data storage structure or adjust the reading strategy.

Share for Diagnosis

After entering the job details page, click the "Share" button to share the job with a third party. Recipients can view the content without logging in. ! 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.

Viewing Execution Plan and Operator Details

During the execution phase, you can click on a specific operator to query its execution steps and strategies. For example, moving the mouse over a specific operator will highlight the corresponding operator in the SQL. This helps you identify which specific operator is causing the job to run slowly.