💡 If you are using dbt to perform data transformation and modeling on Singdata Lakehouse, Singdata Studio provides native development, orchestration, and operations capabilities — no need to maintain a separate dbt project:
Step 1: Develop transformation logic in Studio SQL tasks
Studio SQL tasks are Singdata's native data modeling approach, supporting SQL authoring and scheduled execution in an IDE. Choose the appropriate object type based on your transformation scenario:
Pre-computed results stored physically; BI queries hit directly
Standard SQL ETL logic
Regular table + INSERT/MERGE
Standard SQL writes with flexible execution control
Step 2: Orchestrate multiple SQL tasks into a workflow
Multiple SQL tasks can be combined into a workflow (DAG), defining dependencies between tasks for unified scheduling.
Step 3: Scheduling, monitoring, and operations
Studio has a built-in scheduling system supporting cron triggers, task dependencies, failure alerts, run log viewing, and failure reruns. See Using Studio In Depth.
If you have an existing dbt project to migrate, or your team prefers the dbt development workflow, continue reading the integration guide below.
Installation
Requires Python 3.10+ (3.12 recommended) and dbt-core 1.8+.
API address, e.g., cn-shanghai-alicloud.api.clickzetta.com
instance
Yes
Instance name
workspace
Yes
Workspace name
username
Yes
Username
password
Yes
Password
schema
Yes
Default schema name
vcluster
Yes
Compute cluster name, e.g., default
connect_retries
No
Connection retry count, default 3
Verify the connection:
dbt debug
Supported Features
Feature
Support
table materialization
✅
view materialization
✅
incremental materialization
✅
ephemeral materialization
✅
snapshot (SCD Type 2)
✅
dynamic_table materialization
✅
materialized_view materialization
✅
dbt test (generic + singular)
✅
dbt seed
✅
dbt docs generate
✅ (includes row count, size, last modified time)
dbt source freshness
✅
persist_docs (relation + columns)
✅
Partitioned tables
✅
Bucketed tables
✅
Python models
❌ Not supported; SQL models only
on_schema_change
✅ (append_new_columns, sync_all_columns)
grants
✅
clone materialization
✅ (zero-copy clone + Time Travel clone)
Indexes (Bloomfilter / Inverted / Vector)
✅ (auto-created via indexes config)
Table Stream as source
✅ (declared in sources.yml, referenced via source())
VCluster per-model
✅ (via vcluster config)
Incremental Strategies
Four incremental strategies are supported:
Strategy
Description
merge (default)
MERGE INTO, requires unique_key
append
INSERT INTO, no deduplication
insert_overwrite
INSERT OVERWRITE, dynamic partition mode
delete+insert
Delete matching rows by unique_key first, then insert (unique_key required)
{{ config(
materialized='incremental',
incremental_strategy='merge',
unique_key='id'
) }}
select * from {{ ref('stg_orders') }}
{% if is_incremental() %}
where updated_at >= (select max(updated_at) from {{ this }})
{% endif %}
Dynamic Table
Dynamic Table automatically refreshes incrementally at refresh_interval without external scheduling:
{{ config(
materialized='dynamic_table',
refresh_interval='5 MINUTE',
refresh_vc='default'
) }}
select
customer_id,
count(order_id) as order_count,
sum(amount) as total_amount
from {{ ref('stg_orders') }}
group by customer_id
Indexes are automatically created when building tables. Three types are supported: Bloomfilter (equality queries), Inverted (full-text search), and Vector (similarity search):
{{ config(materialized='incremental', incremental_strategy='append') }}
select
`__change_type` as cdc_change_type,
`__commit_timestamp` as cdc_commit_ts,
order_id, customer_id, amount
from {{ source('my_streams', 'orders_stream') }}
⚠️ Note: __change_type, __commit_timestamp, and __commit_version are Table Stream system columns and must be wrapped in backticks when referenced. When consuming, it is recommended to use SELECT * EXCEPT(__change_type, __commit_timestamp, __commit_version) to filter out system columns.
Clone
Zero-copy clone, suitable for CI/CD environment isolation or quickly creating test copies:
