Topik ini menjelaskan cara membuat Tabel Dinamis.
Catatan
Untuk informasi mengenai batasan Tabel Dinamis, lihat Dukungan dan batasan Tabel Dinamis.
Mulai dari Hologres V3.1, Tabel Dinamis baru menggunakan sintaks baru secara default. Untuk Tabel Dinamis yang dibuat di Hologres V3.0, Anda hanya dapat melakukan operasi ALTER dan tidak dapat membuat tabel baru menggunakan sintaks V3.0. Untuk tabel non-partisi, Anda dapat menggunakan perintah konversi sintaks untuk mengonversi sintaks V3.0 ke sintaks V3.1 yang baru. Untuk tabel partisi, Anda harus membuat ulang secara manual.
Mulai dari Hologres V3.1, Anda harus membuat ulang Tabel Dinamis yang menggunakan Pembaruan bertahap (incremental refresh). Anda dapat menggunakan perintah konversi sintaks untuk membuat ulangnya.
Mulai dari Hologres V3.1, Mesin DPI secara otomatis mengoptimalkan eksekusi refresh Tabel Dinamis untuk meningkatkan stabilitas. Oleh karena itu, angka negatif pada ID kueri terkait refresh adalah hal yang normal.
Sintaks
Hologres V3.1 dan versi selanjutnya (sintaks baru)
Mulai dari Hologres V3.1, Anda hanya dapat menggunakan sintaks baru untuk membuat tabel.
Sintaks
Mulai dari Hologres V3.1, sintaks untuk membuat Tabel Dinamis adalah sebagai berikut:
CREATE DYNAMIC TABLE [ IF NOT EXISTS ] [<schema_name>.]<table_name>
[ (<col_name> [, ...] ) ]
[LOGICAL PARTITION BY LIST(<partition_key>)]
WITH (
-- Properti Tabel Dinamis
freshness = '<num> {minutes | hours}', -- Wajib
[auto_refresh_enable = {true | false},] -- Opsional
[auto_refresh_mode = {'full' | 'incremental' | 'auto'},] -- Opsional
[base_table_cdc_format = {'stream' | 'binlog'},] -- Opsional
[auto_refresh_partition_active_time = '<num> {minutes | hours | days}',] -- Opsional
[partition_key_time_format = {'YYYYMMDDHH24' | 'YYYY-MM-DD-HH24' | 'YYYY-MM-DD_HH24' | 'YYYYMMDD' | 'YYYY-MM-DD' | 'YYYYMM' | 'YYYY-MM' | 'YYYY'},] --Opsional
[computing_resource = {'local' | 'serverless' | '<warehouse_name>'},] -- Opsional. Nilai warehouse_name hanya didukung di Hologres V4.0.7 dan versi selanjutnya.
[refresh_guc_hg_experimental_serverless_computing_required_cores=xxx,]--Opsional. Spesifikasi sumber daya komputasi.
[refresh_guc_<guc_name> = '<guc_value>',] -- Opsional
-- Properti umum
[orientation = {'column' | 'row' | 'row,column'},]
[table_group = '<tableGroupName>',]
[distribution_key = '<columnName>[,...]]',]
[clustering_key = '<columnName>[:asc] [,...]',]
[event_time_column = '<columnName> [,...]',]
[bitmap_columns = '<columnName> [,...]',]
[dictionary_encoding_columns = '<columnName> [,...]',]
[time_to_live_in_seconds = '<non_negative_literal>',]
[storage_mode = {'hot' | 'cold'},]
)
AS
<query>; -- Definisi kueriParameter
Mode refresh dan sumber daya
Parameter | Deskripsi | Wajib | Nilai default |
freshness | Kefresh-an data. Satuan yang valid: minutes dan hours. Nilai minimum adalah 1 menit. Mesin DPI secara otomatis menjadwalkan refresh berikutnya berdasarkan waktu refresh terakhir dan nilai freshness yang ditentukan. Dibandingkan dengan interval refresh tetap, freshness memastikan kefresh-an data secara lebih otomatis. | Ya | Tidak ada |
auto_refresh_mode | Mode refresh. Nilai valid:
| Tidak | auto |
auto_refresh_enable | Menentukan apakah auto-refresh diaktifkan. Nilai yang valid:
| Tidak | true |
base_table_cdc_format | Metode yang digunakan untuk mengonsumsi data dari tabel dasar untuk Pembaruan bertahap.
Catatan
| Tidak | stream |
computing_resource | Untuk informasi selengkapnya, lihat bagian Parameter di Atur sumber daya refresh untuk Tabel Dinamis. | Tidak | serverless |
refresh_guc_<guc_name> | Anda dapat mengatur parameter GUC untuk refresh. Untuk informasi selengkapnya mengenai parameter GUC yang didukung, lihat Parameter GUC. | Tidak | Tidak ada |
Properti partisi
Parameter partisi logis
Parameter | Deskripsi | Wajib | Nilai default |
LOGICAL PARTITION BY LIST(<partition_key>) | Membuat Tabel Dinamis sebagai tabel partisi logis. Anda juga harus mengatur parameter | Tidak | Tidak ada |
auto_refresh_partition_active_time | Cakupan refresh partisi. Satuan yang valid: minutes, hours, dan days. Sistem secara otomatis merefresh data dalam partisi yang berada dalam cakupan tersebut dengan melacak mundur partisi historis dari waktu saat ini berdasarkan auto_refresh_partition_active_time yang ditentukan. Partisi aktif: Partisi dianggap aktif jika Catatan
| Ya |
Artinya, latensi data yang diizinkan untuk tabel dasar adalah 1 jam. Misalnya, jika tabel dipartisi berdasarkan hari, nilai default-nya adalah 25 jam (1 hari + 1 jam). |
partition_key_time_format | Format partisi. Ketika Tabel Dinamis adalah tabel partisi logis, sistem menghasilkan partisi berdasarkan format yang ditentukan. Tipe data yang didukung untuk bidang partisi dan format datanya yang sesuai adalah sebagai berikut:
| Ya | Tidak ada |
Parameter partisi fisik
Parameter | Deskripsi | Wajib | Nilai default |
PARTITION BY LIST(<partition_key>) | Membuat Tabel Dinamis sebagai tabel partisi standar. Dibandingkan dengan Tabel Dinamis partisi logis, Tabel Dinamis partisi standar tidak dapat membuat partisi secara dinamis dan memiliki batasan tertentu. Kami menyarankan Anda menggunakan partisi logis. Untuk informasi selengkapnya mengenai perbedaan tersebut, lihat BUAT TABEL PARTISI LOGIS. Penting Mulai dari Hologres V3.1, Anda tidak dapat membuat Tabel Dinamis sebagai tabel partisi fisik ketika menggunakan sintaks baru. | Tidak | Tidak ada |
Parameter properti tabel
Parameter | Deskripsi | Wajib | Nilai default | |
penuh | inkremental | |||
col_name | Nama bidang Tabel Dinamis. Anda dapat secara eksplisit menentukan nama kolom untuk Tabel Dinamis, tetapi tidak dapat menentukan properti kolom dan tipe data. Mesin DPI akan menginferensinya secara otomatis. Catatan Jika Anda menentukan properti kolom dan tipe data, Mesin DPI mungkin gagal menginferensinya dengan benar. | Tidak | Nama kolom kueri | Nama kolom kueri |
orientation | Menentukan mode penyimpanan Tabel Dinamis. Nilai | Tidak | column | column |
table_group | Menentukan kelompok tabel tempat Tabel Dinamis berada. Secara default, ini adalah kelompok tabel default dari database saat ini. Untuk informasi selengkapnya, lihat Kelola kelompok tabel dan jumlah shard. | Tidak | Nama kelompok tabel default | Nama kelompok tabel default |
distribution_key | Menentukan kunci distribusi Tabel Dinamis. Untuk informasi lebih lanjut, lihat Kunci distribusi. | Tidak | Tidak ada | Tidak ada |
clustering_key | Menentukan kunci pengelompokan Tabel Dinamis. Untuk informasi lebih lanjut, lihat Kunci pengelompokan. | Tidak | Dapat diatur. Memiliki nilai inferensi default. | Dapat diatur. Memiliki nilai inferensi default. |
event_time_column | Menentukan event_time_column Tabel Dinamis. Untuk informasi selengkapnya, lihat Kolom waktu event (kunci segmen). | Tidak | Tidak ada | Tidak ada |
bitmap_columns | Menentukan bitmap_columns Tabel Dinamis. Untuk informasi lebih lanjut, lihat Indeks bitmap. | Tidak | Bidang tipe TEXT | Bidang tipe TEXT |
dictionary_encoding_columns | Menentukan dictionary_encoding_columns Tabel Dinamis. Untuk informasi lebih lanjut, lihat Encoding kamus. | Tidak | Bidang tipe TEXT | Bidang tipe TEXT |
time_to_live_in_seconds | Menentukan siklus hidup data dalam Tabel Dinamis. | Tidak | Permanen | Permanen |
storage_mode | Mode penyimpanan Tabel Dinamis. Nilai yang valid:
Catatan Untuk informasi selengkapnya mengenai mode penyimpanan, lihat Penyimpanan data bertingkat. | Tidak | hot | hot |
binlog_level | Menentukan apakah binary logging diaktifkan untuk Tabel Dinamis. Untuk informasi lebih lanjut tentang cara menggunakan binary logging, lihat Berlangganan log biner Hologres. Catatan
| Tidak | none | none |
binlog_ttl | Siklus hidup log biner setelah Anda mengaktifkan binary logging untuk Tabel Dinamis. | Tidak | 2592000 | 2592000 |
Query
Kueri yang menghasilkan data dalam Tabel Dinamis. Jenis kueri dan jenis tabel dasar yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Dukungan dan batasan Tabel Dinamis.
V3.0
Sintaks
Di Hologres V3.0, sintaks untuk membuat Tabel Dinamis adalah sebagai berikut:
CREATE DYNAMIC TABLE [IF NOT EXISTS] <schema.tablename>(
[col_name],
[col_name]
) [PARTITION BY LIST (col_name)]
WITH (
[refresh_mode='[full|incremental]',]
[auto_refresh_enable='[true|false',]
--Parameter khusus untuk Pembaruan bertahap:
[incremental_auto_refresh_schd_start_time='[immediate|<timestamptz>]',]
[incremental_auto_refresh_interval='[<num> {minute|minutes|hour|hours]',]
[incremental_guc_hg_computing_resource='[ local | serverless]',]
[incremental_guc_hg_experimental_serverless_computing_required_cores='<num>',]
--Parameter khusus untuk Pembaruan penuh:
[full_auto_refresh_schd_start_time='[immediate|<timestamptz>]',]
[full_auto_refresh_interval='[<num> {minute|minutes|hour|hours]',]
[full_guc_hg_computing_resource='[ local | serverless]',]--Nilai default hg_full_refresh_computing_resource adalah serverless. Anda dapat mengaturnya di tingkat database. Anda tidak perlu mengatur parameter ini.
[full_guc_hg_experimental_serverless_computing_required_cores='<num>',]
--Parameter bersama, GUC dapat diatur:
[refresh_guc_<guc>='xxx]',]
-- Properti umum Tabel Dinamis:
[orientation = '[column]',]
[table_group = '[tableGroupName]',]
[distribution_key = 'columnName[,...]]',]
[clustering_key = '[columnName{:asc]} [,...]]',]
[event_time_column = '[columnName [,...]]',]
[bitmap_columns = '[columnName [,...]]',]
[dictionary_encoding_columns = '[columnName [,...]]',]
[time_to_live_in_seconds = '<non_negative_literal>',]
[storage_mode = '[hot | cold]']
)
AS
<query> --Definisi kueriParameter
Mode refresh dan sumber daya
Kategori parameter | Parameter | Deskripsi | Wajib | Nilai default |
Parameter pembaruan bersama | refresh_mode | Menentukan mode refresh data. Mode yang didukung: full dan incremental. Jika Anda tidak mengatur parameter ini, tidak ada refresh yang dilakukan. | Tidak | Tidak ada |
auto_refresh_enable | Menentukan apakah auto-refresh diaktifkan. Nilai yang valid:
| Tidak | false | |
refresh_guc_<guc> | Anda dapat mengatur parameter GUC untuk refresh. Untuk informasi selengkapnya mengenai parameter GUC yang didukung, lihat Parameter GUC. Catatan Sebagai contoh, untuk mengatur parameter GUC | Tidak | Tidak ada | |
Refresh inkremental (incremental) | incremental_auto_refresh_schd_start_time | Waktu mulai untuk Pembaruan bertahap. Nilai yang valid:
| Tidak | immediate |
incremental_auto_refresh_interval | Interval untuk Pembaruan bertahap. Satuan yang valid: minute, minutes, hour, dan hours.
| Tidak | Tidak ada | |
incremental_guc_hg_computing_resource | Menentukan sumber daya komputasi untuk Pembaruan bertahap. Nilai yang valid:
Catatan Anda dapat menjalankan perintah | Tidak | local | |
incremental_guc_hg_experimental_serverless_computing_required_cores | Jika Anda menggunakan sumber daya Serverless untuk refresh, Anda harus mengatur jumlah sumber daya komputasi untuk refresh tersebut. Catatan Sumber daya Serverless yang tersedia terbatas untuk instans dengan spesifikasi berbeda. Untuk informasi selengkapnya, lihat Panduan pengguna Komputasi Serverless. | Tidak | Tidak ada | |
Refresh penuh (full) | full_auto_refresh_schd_start_time | Waktu mulai untuk Pembaruan penuh. Nilai yang valid:
| Tidak | immediate |
full_auto_refresh_interval | Interval untuk Pembaruan penuh. Satuan yang valid: minute, minutes, hour, dan hours.
| Tidak | Tidak ada | |
full_guc_hg_computing_resource | Menentukan sumber daya komputasi untuk Pembaruan penuh. Nilai yang valid:
Catatan Anda dapat menjalankan perintah | Tidak | local | |
full_guc_hg_experimental_serverless_computing_required_cores | Jika Anda menggunakan sumber daya Serverless untuk refresh, Anda harus mengatur jumlah sumber daya komputasi untuk refresh tersebut. Catatan Sumber daya Serverless yang tersedia terbatas untuk instans dengan spesifikasi berbeda. Untuk informasi selengkapnya, lihat Panduan pengguna Komputasi Serverless. | Tidak | Tidak ada |
Parameter properti tabel
Parameter | Deskripsi | Wajib | Nilai default | |
penuh | inkremental | |||
col_name | Nama bidang Tabel Dinamis. Anda dapat secara eksplisit menentukan nama kolom untuk Tabel Dinamis, tetapi tidak dapat menentukan properti kolom dan tipe data. Mesin DPI akan menginferensinya secara otomatis. Catatan Jika Anda menentukan properti kolom dan tipe data, Mesin DPI mungkin gagal menginferensinya dengan benar. | Tidak | Nama kolom kueri | Nama kolom kueri |
orientation | Menentukan mode penyimpanan Tabel Dinamis. Nilai | Tidak | column | column |
table_group | Menentukan kelompok tabel tempat Tabel Dinamis berada. Secara default, ini adalah kelompok tabel default dari database saat ini. Untuk informasi selengkapnya, lihat Kelola kelompok tabel dan jumlah shard. | Tidak | Nama kelompok tabel default | Nama kelompok tabel default |
distribution_key | Menentukan kunci distribusi Tabel Dinamis. Untuk informasi lebih lanjut, lihat Kunci distribusi. | Tidak | Tidak ada | Tidak ada |
clustering_key | Menentukan kunci pengelompokan Tabel Dinamis. Untuk informasi lebih lanjut, lihat Kunci pengelompokan. | Tidak | Dapat diatur. Memiliki nilai inferensi default. | Dapat diatur. Memiliki nilai inferensi default. |
event_time_column | Menentukan event_time_column Tabel Dinamis. Untuk informasi selengkapnya, lihat Kolom waktu event (kunci segmen). | Tidak | Tidak ada | Tidak ada |
bitmap_columns | Menentukan bitmap_columns Tabel Dinamis. Untuk informasi lebih lanjut, lihat Indeks bitmap. | Tidak | Bidang tipe TEXT | Bidang tipe TEXT |
dictionary_encoding_columns | Menentukan dictionary_encoding_columns Tabel Dinamis. Untuk informasi lebih lanjut, lihat Encoding kamus. | Tidak | Bidang tipe TEXT | Bidang tipe TEXT |
time_to_live_in_seconds | Menentukan siklus hidup data dalam Tabel Dinamis. | Tidak | Permanen | Permanen |
storage_mode | Mode penyimpanan Tabel Dinamis. Nilai yang valid:
Catatan Untuk informasi selengkapnya mengenai mode penyimpanan, lihat Penyimpanan data bertingkat. | Tidak | hot | hot |
PARTITION BY LIST | Menentukan apakah tabel merupakan tabel partisi. Anda dapat membuat Tabel Dinamis partisi. Digunakan dengan cara yang sama seperti tabel partisi standar. Anda dapat mengatur mode refresh berbeda untuk partisi anak yang berbeda untuk memenuhi persyaratan ketepatan waktu skenario bisnis yang berbeda. | Tidak | Tabel tanpa partisi | Tabel tanpa partisi |
Query
Kueri yang menghasilkan data dalam Tabel Dinamis. Jenis kueri dan jenis tabel dasar yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Dukungan dan batasan Tabel Dinamis.
Pembaruan bertahap
Pembaruan bertahap secara otomatis mendeteksi perubahan pada tabel dasar dan menulis data kueri secara inkremental ke Tabel Dinamis. Dibandingkan dengan Pembaruan penuh, Pembaruan bertahap memproses volume data yang lebih kecil dan membutuhkan waktu pemrosesan lebih singkat. Gunakan mode Pembaruan bertahap untuk aplikasi yang memerlukan kueri data near-real-time tingkat menit. Saat menggunakan Tabel Dinamis inkremental, perhatikan hal-hal berikut:
Batasan tabel dasar:
Hologres V3.1 menggunakan mode Stream secara default untuk mengonsumsi data inkremental. Jika Anda mengaktifkan binary logging untuk tabel dasar di V3.0, segera nonaktifkan untuk mencegah peningkatan biaya penyimpanan.
Di V3.0, Anda harus mengaktifkan binary logging untuk tabel dasar. Jika Anda melakukan JOIN tabel dimensi, Anda tidak perlu mengaktifkan binary logging untuk tabel dimensi tersebut. Mengaktifkan binary logging untuk tabel dasar mengonsumsi beberapa sumber daya penyimpanan. Untuk memeriksa penyimpanan yang digunakan oleh binary logging, lihat Detail penyimpanan tabel.
Setelah Anda mengaktifkan Pembaruan bertahap, sistem membuat tabel status di latar belakang untuk mencatat hasil agregasi antara. Untuk informasi selengkapnya mengenai prinsip teknis tabel status, lihat Tabel Dinamis. Tabel status menyimpan data agregat antara dan karena itu mengonsumsi sumber daya penyimpanan. Untuk melihat penggunaan penyimpanan, lihat Lihat skema tabel dan alur data Tabel Dinamis.
Untuk informasi selengkapnya mengenai kueri dan operator yang saat ini didukung oleh Pembaruan bertahap, lihat Dukungan dan batasan Tabel Dinamis.
JOIN multi-tabel (stream-stream JOIN)
stream-stream JOIN adalah JOIN multi-tabel. Semantiknya sama dengan kueri Pemrosesan Analitik Online (OLAP). Diimplementasikan berdasarkan HASH JOIN dan mendukung empat jenis JOIN: INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, dan FULL OUTER JOIN.
Versi 3.1
Mulai dari Hologres V3.1, parameter Grand Unified Configuration (GUC) untuk stream-stream JOIN diaktifkan secara default. Anda tidak perlu mengaturnya secara manual.
Berikut adalah contoh pernyataan SQL:
CREATE TABLE users (
user_id INT,
user_name TEXT,
PRIMARY KEY (user_id)
);
INSERT INTO users VALUES(1, 'hologres');
CREATE TABLE orders (
order_id INT,
user_id INT,
PRIMARY KEY (order_id)
);
INSERT INTO orders VALUES(1, 1);
CREATE DYNAMIC TABLE dt WITH (
auto_refresh_mode = 'incremental',
freshness='10 minutes'
)
AS
SELECT order_id, orders.user_id, user_name
FROM orders LEFT JOIN users ON orders.user_id = users.user_id;
-- Setelah refresh, satu catatan terkait terlihat.
REFRESH TABLE dt;
SELECT * FROM dt;
order_id | user_id | user_name
----------+---------+-----------
1 | 1 | hologres
(1 row)
UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);
-- Setelah refresh, dua catatan terkait terlihat. Pembaruan tabel dimensi berlaku untuk semua data dan dapat memperbaiki data yang sebelumnya terkait.
REFRESH TABLE dt;
SELECT * FROM dt;Hasil berikut dikembalikan:
order_id | user_id | user_name
----------+---------+---------------
1 | 1 | dynamic table
4 | 1 | dynamic table
(2 rows)Versi 3.0
Hologres telah mendukung JOIN multi-tabel (stream-stream JOIN) sejak versi 3.0.26. Sebelum menggunakan fitur ini, upgrade instans Anda dan atur parameter GUC berikut untuk mengaktifkan stream-stream JOIN.
-- Aktifkan di tingkat session.
SET hg_experimental_incremental_dynamic_table_enable_hash_join TO ON;
-- Aktifkan di tingkat DB. Pengaturan berlaku untuk koneksi baru.
ALTER database <db_name> SET hg_experimental_incremental_dynamic_table_enable_hash_join TO ON;Berikut adalah contoh pernyataan SQL:
CREATE TABLE users (
user_id INT,
user_name TEXT,
PRIMARY KEY (user_id)
) WITH (binlog_level = 'replica');
INSERT INTO users VALUES(1, 'hologres');
CREATE TABLE orders (
order_id INT,
user_id INT,
PRIMARY KEY (order_id)
) WITH (binlog_level = 'replica');
INSERT INTO orders VALUES(1, 1);
CREATE DYNAMIC TABLE dt WITH (refresh_mode = 'incremental')
AS
SELECT order_id, orders.user_id, user_name
FROM orders LEFT JOIN users ON orders.user_id = users.user_id;
-- Setelah refresh, satu catatan terkait terlihat.
REFRESH TABLE dt;
SELECT * FROM dt;
order_id | user_id | user_name
----------+---------+-----------
1 | 1 | hologres
(1 row)
UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);
-- Setelah refresh, dua catatan terkait terlihat. Pembaruan tabel dimensi berlaku untuk semua data dan dapat memperbaiki data yang sebelumnya terkait.
REFRESH TABLE dt;
SELECT * FROM dt;Hasil berikut dikembalikan:
order_id | user_id | user_name
----------+---------+---------------
1 | 1 | dynamic table
4 | 1 | dynamic table
(2 rows)JOIN tabel dimensi
Semantik JOIN tabel dimensi adalah sebagai berikut: setiap catatan hanya dikaitkan dengan versi terbaru data tabel dimensi pada saat operasi JOIN dilakukan. Jika data dalam tabel dimensi berubah (ditambahkan, diperbarui, atau dihapus) setelah operasi JOIN, data tabel dimensi yang sebelumnya terkait tidak diperbarui. Berikut adalah contoh pernyataan SQL:
Operasi JOIN pada tabel dimensi tidak bergantung pada volume data tabel yang terlibat. Anda hanya perlu menggunakan semantik JOIN tabel dimensi dalam pernyataan SQL Anda.
Versi 3.1
CREATE TABLE users (
user_id INT,
user_name TEXT,
PRIMARY KEY (user_id)
);
INSERT INTO users VALUES(1, 'hologres');
CREATE TABLE orders (
order_id INT,
user_id INT,
PRIMARY KEY (order_id)
) WITH (binlog_level = 'replica');
INSERT INTO orders VALUES(1, 1);
CREATE DYNAMIC TABLE dt_join_2 WITH (
auto_refresh_mode = 'incremental',
freshness='10 minutes')
AS
SELECT order_id, orders.user_id, user_name
-- FOR SYSTEM_TIME AS OF PROCTIME() mengidentifikasi tabel users sebagai tabel dimensi.
FROM orders LEFT JOIN users FOR SYSTEM_TIME AS OF PROCTIME()
ON orders.user_id = users.user_id;
-- Setelah refresh, satu catatan terkait terlihat.
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;
order_id | user_id | user_name
----------+---------+-----------
1 | 1 | hologres
(1 row)
UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);
-- Setelah refresh, dua catatan terkait terlihat. Pembaruan tabel dimensi hanya berlaku untuk data baru dan tidak dapat memperbaiki data yang sebelumnya terkait.
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;Hasil berikut dikembalikan:
order_id | user_id | user_name
----------+---------+---------------
1 | 1 | hologres
4 | 1 | dynamic table
(2 rows)Versi 3.0
CREATE TABLE users (
user_id INT,
user_name TEXT,
PRIMARY KEY (user_id)
);
INSERT INTO users VALUES(1, 'hologres');
CREATE TABLE orders (
order_id INT,
user_id INT,
PRIMARY KEY (order_id)
) WITH (binlog_level = 'replica');
INSERT INTO orders VALUES(1, 1);
CREATE DYNAMIC TABLE dt_join_2 WITH (refresh_mode = 'incremental')
AS
SELECT order_id, orders.user_id, user_name
-- FOR SYSTEM_TIME AS OF PROCTIME() mengidentifikasi tabel users sebagai tabel dimensi.
FROM orders LEFT JOIN users FOR SYSTEM_TIME AS OF PROCTIME()
ON orders.user_id = users.user_id;
-- Setelah refresh, satu catatan terkait terlihat.
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;
order_id | user_id | user_name
----------+---------+-----------
1 | 1 | hologres
(1 row)
UPDATE users SET user_name = 'dynamic table' WHERE user_id = 1;
INSERT INTO orders VALUES(4, 1);
-- Setelah refresh, dua catatan terkait terlihat. Pembaruan tabel dimensi hanya berlaku untuk data baru dan tidak dapat memperbaiki data yang sebelumnya terkait.
REFRESH TABLE dt_join_2;
SELECT * FROM dt_join_2;Hasil berikut dikembalikan:
order_id | user_id | user_name
----------+---------+---------------
1 | 1 | hologres
4 | 1 | dynamic table
(2 rows)Mengonsumsi inkremental tabel lake (Paimon)
Pembaruan bertahap mendukung mengonsumsi data dari tabel lake Paimon untuk membangun danau data terpadu (data lakehouse).
Tabel Dinamis Eksternal mendukung pembacaan dan penulisan inkremental data danau data terpadu dan penulisan balik otomatis inkremental ke data lake (Paimon). Kemampuan ini menyediakan transformasi data cepat, akselerasi kueri, dan penulisan balik otomatis untuk data lake. Ini menyederhanakan pengalaman transformasi data di data lake dan menurunkan biaya. Untuk informasi selengkapnya, lihat Pengantar Tabel Dinamis Eksternal.
Pembaruan penuh dan inkremental terintegrasi
Tabel Dinamis Inkremental juga mendukung konsumsi penuh dan inkremental terintegrasi. Artinya, sistem pertama-tama mengonsumsi semua data yang ada dari tabel dasar yang dipengaruhi kueri, lalu mengonsumsi data baru dari tabel dasar.
Versi 3.1
Di V3.1, Pembaruan penuh dan inkremental terintegrasi diaktifkan secara default. Berikut adalah contohnya:
-- Siapkan tabel dasar dan masukkan data.
CREATE TABLE base_sales(
day TEXT NOT NULL,
hour INT,
user_id BIGINT,
ts TIMESTAMPTZ,
amount FLOAT,
pk text NOT NULL PRIMARY KEY
);
-- Impor data ke tabel dasar.
INSERT INTO base_sales values ('2024-08-29',1,222222,'2024-08-29 16:41:19.141528+08',5,'ddd');
-- Lalu, impor data inkremental ke tabel dasar.
INSERT INTO base_sales VALUES ('2024-08-29',2,3333,'2024-08-29 17:44:19.141528+08',100,'aaaaa');
-- Buat Tabel Dinamis inkremental dengan auto-refresh.
-- Konsumsi data penuh dan inkremental terintegrasi diaktifkan secara default.
CREATE DYNAMIC TABLE sales_incremental
WITH (
auto_refresh_mode='incremental',
freshness='10 minutes'
)
AS
SELECT day, hour, SUM(amount), COUNT(1)
FROM base_sales
GROUP BY day, hour;Bandingkan konsistensi data:
Kueri tabel dasar
SELECT day, hour, SUM(amount), COUNT(1) FROM base_sales GROUP BY day, hour;Hasil berikut dikembalikan:
day hour sum count 2024-08-29 2 100 1 2024-08-29 1 5 1Kueri Tabel Dinamis
SELECT * FROM sales_incremental;Hasil berikut dikembalikan:
day hour sum count 2024-08-29 1 5 1 2024-08-29 2 100 1
Versi 3.0
Di V3.0, Anda harus mengaktifkan parameter GUC untuk mengimplementasikan Pembaruan penuh dan inkremental terintegrasi. Berikut adalah contohnya:
-- Siapkan tabel dasar dan masukkan data.
CREATE TABLE base_sales(
day TEXT NOT NULL,
hour INT,
user_id BIGINT,
ts TIMESTAMPTZ,
amount FLOAT,
pk text NOT NULL PRIMARY KEY
);
-- Impor data ke tabel dasar.
INSERT INTO base_sales values ('2024-08-29',1,222222,'2024-08-29 16:41:19.141528+08',5,'ddd');
-- Aktifkan binary logging untuk tabel dasar.
ALTER TABLE base_sales SET (binlog_level = replica);
-- Lalu, impor data inkremental ke tabel dasar.
INSERT INTO base_sales VALUES ('2024-08-29',2,3333,'2024-08-29 17:44:19.141528+08',100,'aaaaa');
-- Buat Tabel Dinamis inkremental dengan auto-refresh dan aktifkan GUC untuk konsumsi data penuh dan inkremental terintegrasi.
CREATE DYNAMIC TABLE sales_incremental
WITH (
refresh_mode='incremental',
incremental_auto_refresh_schd_start_time = 'immediate',
incremental_auto_refresh_interval = '3 minutes',
incremental_guc_hg_experimental_enable_hybrid_incremental_mode= 'true'
)
AS
SELECT day, hour, SUM(amount), COUNT(1)
FROM base_sales
GROUP BY day, hour;Bandingkan konsistensi data:
Kueri tabel dasar
SELECT day, hour, SUM(amount), COUNT(1) FROM base_sales GROUP BY day, hour;Hasil berikut dikembalikan:
day hour sum count 2024-08-29 2 100 1 2024-08-29 1 5 1Kueri Tabel Dinamis
SELECT * FROM sales_incremental;Hasil berikut dikembalikan:
day hour sum count 2024-08-29 1 5 1 2024-08-29 2 100 1
Refresh penuh
Pembaruan penuh menulis semua data dari kueri ke Tabel Dinamis. Dibandingkan dengan Pembaruan bertahap, Pembaruan penuh memiliki keunggulan berikut:
Mendukung lebih banyak jenis tabel dasar.
Mendukung lebih banyak jenis kueri dan operator.
Pembaruan penuh memproses lebih banyak data dan mungkin menggunakan lebih banyak sumber daya daripada Pembaruan bertahap. Oleh karena itu, umumnya digunakan untuk skenario seperti melihat laporan periodik dan merefresh data secara berkala.
Untuk informasi selengkapnya, lihat Pembaruan penuh.
Contoh
Versi 3.1
Contoh 1: Buat Tabel Dinamis untuk Pembaruan bertahap
Sebelum memulai, impor dataset publik tpch_10g ke Hologres. Untuk informasi selengkapnya, lihat Impor dataset publik dengan satu klik.
Sebelum membuat Tabel Dinamis untuk Pembaruan bertahap, aktifkan binary logging untuk tabel dasar. Anda tidak perlu mengaktifkannya untuk tabel dimensi.
-- Buat Tabel Dinamis untuk Pembaruan bertahap tabel tunggal.
-- Atur interval refresh menjadi 3 menit.
CREATE DYNAMIC TABLE public.tpch_q1_incremental
WITH (
auto_refresh_mode='incremental',
freshness='3 minutes'
) AS SELECT
l_returnflag,
l_linestatus,
COUNT(*) AS count_order
FROM
hologres_dataset_tpch_10g.lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
l_returnflag,
l_linestatus;Contoh 2: Buat Tabel Dinamis untuk Pembaruan bertahap dengan JOIN multi-tabel
Sebelum memulai, impor dataset publik tpch_10g ke Hologres. Untuk informasi selengkapnya, lihat Impor dataset publik dengan satu klik.
Sebelum membuat Tabel Dinamis untuk Pembaruan bertahap, aktifkan binary logging untuk tabel dasar. Anda tidak perlu mengaktifkannya untuk tabel dimensi.
-- Buat Tabel Dinamis untuk Pembaruan bertahap dengan JOIN multi-tabel.
CREATE DYNAMIC TABLE dt_join
WITH (
auto_refresh_mode='incremental',
freshness='30 minutes'
)
AS
SELECT
l_shipmode,
SUM(CASE
WHEN o_orderpriority = '1-URGENT'
OR o_orderpriority = '2-HIGH'
THEN 1
ELSE 0
END) AS high_line_count,
SUM(CASE
WHEN o_orderpriority <> '1-URGENT'
AND o_orderpriority <> '2-HIGH'
THEN 1
ELSE 0
END) AS low_line_count
FROM
hologres_dataset_tpch_10g.orders,
hologres_dataset_tpch_10g.lineitem
WHERE
o_orderkey = l_orderkey
AND l_shipmode IN ('FOB', 'AIR')
AND l_commitdate < l_receiptdate
AND l_shipdate < l_commitdate
AND l_receiptdate >= DATE '1997-01-01'
AND l_receiptdate < DATE '1997-01-01' + INTERVAL '1' YEAR
GROUP BY
l_shipmode;Contoh 3: Buat Tabel Dinamis dengan auto-refresh
Anda dapat mengatur Tabel Dinamis untuk auto-refresh. Mesin DPI secara otomatis memilih mode refresh. Mesin memprioritaskan Pembaruan bertahap. Jika Pembaruan bertahap tidak didukung, mesin beralih ke Pembaruan penuh.
Sebelum memulai, impor dataset publik tpch_10g ke Hologres. Untuk informasi selengkapnya, lihat Impor dataset publik dengan satu klik.
-- Buat Tabel Dinamis dengan auto-refresh. Mesin DPI secara otomatis memilih mode refresh.
-- Hasilnya adalah mode Pembaruan bertahap yang digunakan.
CREATE DYNAMIC TABLE thch_q6_auto
WITH (
auto_refresh_mode='auto',
freshness='1 hours'
)
AS
SELECT
SUM(l_extendedprice * l_discount) AS revenue
FROM
hologres_dataset_tpch_100g.lineitem
WHERE
l_shipdate >= DATE '1996-01-01'
AND l_shipdate < DATE '1996-01-01' + INTERVAL '1' YEAR
AND l_discount BETWEEN 0.02 - 0.01 AND 0.02 + 0.01
AND l_quantity < 24;Contoh 4: Buat Tabel Dinamis dengan partisi logis
Pertimbangkan dashboard transaksi real-time. Dalam skenario ini, bisnis sering perlu melihat data hari ini secara near real-time dan juga memperbaiki data historis. Hal ini memerlukan analitik real-time dan offline terintegrasi. Untuk informasi selengkapnya, lihat Kognisi bisnis dan data. Anda dapat menggunakan partisi logis Tabel Dinamis untuk skenario ini. Solusinya adalah sebagai berikut:
Tabel dasar dipartisi berdasarkan hari. Partisi terbaru ditulis oleh Flink secara real-time atau near real-time. Data untuk partisi historis ditulis dari MaxCompute.
Tabel Dinamis dibuat berdasarkan tabel dasar dan menggunakan partisi logis. Dua partisi terbaru aktif dan direfresh menggunakan mode inkremental. Hal ini memenuhi persyaratan bisnis untuk analitik data near-real-time.
Partisi historis tidak aktif dan menggunakan mode Pembaruan penuh. Jika data historis dalam tabel sumber diperbaiki atau direfresh, Anda dapat melakukan Pembaruan penuh pada partisi historis Tabel Dinamis.
Contoh ini menggunakan dataset GitHub publik untuk demonstrasi.
Siapkan tabel dasar.
Data terbaru untuk tabel dasar berasal dari penulisan real-time oleh Flink. Untuk informasi selengkapnya, lihat Implementasikan analitik offline dan real-time terintegrasi berdasarkan dataset event GitHub publik.
DROP TABLE IF EXISTS gh_realtime_data; BEGIN; CREATE TABLE gh_realtime_data ( id BIGINT, actor_id BIGINT, actor_login TEXT, repo_id BIGINT, repo_name TEXT, org_id BIGINT, org_login TEXT, type TEXT, created_at timestamp with time zone NOT NULL, action TEXT, iss_or_pr_id BIGINT, number BIGINT, comment_id BIGINT, commit_id TEXT, member_id BIGINT, rev_or_push_or_rel_id BIGINT, ref TEXT, ref_type TEXT, state TEXT, author_association TEXT, language TEXT, merged BOOLEAN, merged_at TIMESTAMP WITH TIME ZONE, additions BIGINT, deletions BIGINT, changed_files BIGINT, push_size BIGINT, push_distinct_size BIGINT, hr TEXT, month TEXT, year TEXT, ds TEXT, PRIMARY KEY (id,ds) ) PARTITION BY LIST (ds); CALL set_table_property('public.gh_realtime_data', 'distribution_key', 'id'); CALL set_table_property('public.gh_realtime_data', 'event_time_column', 'created_at'); CALL set_table_property('public.gh_realtime_data', 'clustering_key', 'created_at'); COMMENT ON COLUMN public.gh_realtime_data.id IS 'Event ID'; COMMENT ON COLUMN public.gh_realtime_data.actor_id IS 'ID of the event initiator'; COMMENT ON COLUMN public.gh_realtime_data.actor_login IS 'Logon name of the event initiator'; COMMENT ON COLUMN public.gh_realtime_data.repo_id IS 'Repo ID'; COMMENT ON COLUMN public.gh_realtime_data.repo_name IS 'Repo name'; COMMENT ON COLUMN public.gh_realtime_data.org_id IS 'ID of the organization that the repo belongs to'; COMMENT ON COLUMN public.gh_realtime_data.org_login IS 'Name of the organization that the repo belongs to'; COMMENT ON COLUMN public.gh_realtime_data.type IS 'Event type'; COMMENT ON COLUMN public.gh_realtime_data.created_at IS 'Time when the event occurred'; COMMENT ON COLUMN public.gh_realtime_data.action IS 'Event behavior'; COMMENT ON COLUMN public.gh_realtime_data.iss_or_pr_id IS 'Issue or pull request ID'; COMMENT ON COLUMN public.gh_realtime_data.number IS 'Issue or pull request ordinal number'; COMMENT ON COLUMN public.gh_realtime_data.comment_id IS 'Comment ID'; COMMENT ON COLUMN public.gh_realtime_data.commit_id IS 'Commit record ID'; COMMENT ON COLUMN public.gh_realtime_data.member_id IS 'Member ID'; COMMENT ON COLUMN public.gh_realtime_data.rev_or_push_or_rel_id IS 'Review, push, or release ID'; COMMENT ON COLUMN public.gh_realtime_data.ref IS 'Name of the created or deleted resource'; COMMENT ON COLUMN public.gh_realtime_data.ref_type IS 'Type of the created or deleted resource'; COMMENT ON COLUMN public.gh_realtime_data.state IS 'State of the issue, pull request, or pull request review'; COMMENT ON COLUMN public.gh_realtime_data.author_association IS 'Relationship between the actor and the repo'; COMMENT ON COLUMN public.gh_realtime_data.language IS 'Programming language'; COMMENT ON COLUMN public.gh_realtime_data.merged IS 'Indicates whether the merge is accepted'; COMMENT ON COLUMN public.gh_realtime_data.merged_at IS 'Time when the code was merged'; COMMENT ON COLUMN public.gh_realtime_data.additions IS 'Number of added lines of code'; COMMENT ON COLUMN public.gh_realtime_data.deletions IS 'Number of deleted lines of code'; COMMENT ON COLUMN public.gh_realtime_data.changed_files IS 'Number of files changed in the pull request'; COMMENT ON COLUMN public.gh_realtime_data.push_size IS 'Number of commits'; COMMENT ON COLUMN public.gh_realtime_data.push_distinct_size IS 'Number of distinct commits'; COMMENT ON COLUMN public.gh_realtime_data.hr IS 'Hour when the event occurred. For example, if the time is 00:23, hr is 00.'; COMMENT ON COLUMN public.gh_realtime_data.month IS 'Month when the event occurred. For example, for October 2015, month is 2015-10.'; COMMENT ON COLUMN public.gh_realtime_data.year IS 'Year when the event occurred. For example, for 2015, year is 2015.'; COMMENT ON COLUMN public.gh_realtime_data.ds IS 'Day when the event occurred. ds=yyyy-mm-dd.'; COMMIT;Buat Tabel Dinamis dengan partisi logis.
CREATE DYNAMIC TABLE ads_dt_github_event LOGICAL PARTITION BY LIST(ds) WITH ( -- Properti Tabel Dinamis freshness = '5 minutes', auto_refresh_mode = 'auto', auto_refresh_partition_active_time = '2 days' , partition_key_time_format = 'YYYY-MM-DD' ) AS SELECT repo_name, COUNT(*) AS events, ds FROM gh_realtime_data GROUP BY repo_name,dsKueri Tabel Dinamis.
SELECT * FROM ads_dt_github_event ;Refresh partisi historis.
Jika data historis dalam tabel dasar berubah, seperti data dari 2025-04-01, Anda harus menyinkronkan data dalam Tabel Dinamis. Anda dapat mengatur partisi historis Tabel Dinamis ke mode Pembaruan penuh dan melakukan refresh satu kali menggunakan sumber daya komputasi Serverless.
REFRESH OVERWRITE DYNAMIC TABLE ads_dt_github_event PARTITION (ds = '2025-04-01') WITH ( refresh_mode = 'full' );
Contoh 5: Hitung UV untuk periode panjang apa pun menggunakan Pembaruan bertahap untuk Tabel Dinamis
Mulai dari Hologres V3.1, Pembaruan bertahap untuk Tabel Dinamis mendukung fungsi RB_BUILD_AGG. Fungsi ini memungkinkan Anda menghitung metrik seperti unique visitors (UV) selama periode panjang apa pun. Dibandingkan dengan solusi pra-agregasi sebelumnya, Pembaruan bertahap menawarkan keunggulan berikut:
Performa lebih cepat: Setiap perhitungan hanya memproses data inkremental, yang meningkatkan performa.
Biaya lebih rendah: Volume data yang lebih kecil untuk perhitungan mengonsumsi lebih sedikit sumber daya komputasi, yang secara efektif menurunkan biaya. Hal ini mendukung perhitungan selama periode yang lebih lama.
Berikut adalah contohnya:
Siapkan tabel detail pengguna.
BEGIN; CREATE TABLE IF NOT EXISTS ods_app_detail ( uid INT, country TEXT, prov TEXT, city TEXT, channel TEXT, operator TEXT, brand TEXT, ip TEXT, click_time TEXT, year TEXT, month TEXT, day TEXT, ymd TEXT NOT NULL ); CALL set_table_property('ods_app_detail', 'orientation', 'column'); CALL set_table_property('ods_app_detail', 'bitmap_columns', 'country,prov,city,channel,operator,brand,ip,click_time, year, month, day, ymd'); -- Atur distribution_key sesuai kebutuhan. Pilih dimensi untuk sharding yang memberikan performa terbaik untuk kueri real-time pada tabel ini. CALL set_table_property('ods_app_detail', 'distribution_key', 'uid'); -- Gunakan ini untuk kondisi filter WHERE. Kami menyarankan Anda mengatur bidang yang berisi tanggal lengkap (tahun, bulan, dan hari) sebagai clustering_key dan event_time_column. CALL set_table_property('ods_app_detail', 'clustering_key', 'ymd'); CALL set_table_property('ods_app_detail', 'event_time_column', 'ymd'); COMMIT;Hitung UV menggunakan Pembaruan bertahap untuk Tabel Dinamis.
CREATE DYNAMIC TABLE ads_uv_dt WITH ( freshness = '5 minutes', auto_refresh_mode = 'incremental') AS SELECT RB_BUILD_AGG(uid), country, prov, city, ymd, COUNT(1) FROM ods_app_detail WHERE ymd >= '20231201' AND ymd <='20240502' GROUP BY country,prov,city,ymd;Kueri UV untuk periode apa pun.
SELECT RB_CARDINALITY(RB_OR_AGG(rb_uid)) AS uv, country, prov, city, SUM(pv) AS pv FROM ads_uv_dt WHERE ymd = '20240329' GROUP BY country,prov,city;
Versi 3.0
Contoh 1: Buat Tabel Dinamis untuk Pembaruan penuh dan mulai refresh secara otomatis
Sebelum memulai, impor dataset publik tpch_10g ke Hologres. Untuk informasi selengkapnya, lihat Impor dataset publik dengan satu klik.
-- Buat skema "test".
CREATE SCHEMA test;
-- Buat Tabel Dinamis untuk Pembaruan penuh tabel tunggal.
-- Refresh dimulai segera dan dijalankan setiap 1 jam.
CREATE DYNAMIC TABLE test.thch_q1_full
WITH (
refresh_mode='full',
auto_refresh_enable='true',
full_auto_refresh_interval='1 hours',
full_guc_hg_computing_resource='serverless',
full_guc_hg_experimental_serverless_computing_required_cores='32'
)
AS
SELECT
l_returnflag,
l_linestatus,
SUM(l_quantity) AS sum_qty,
SUM(l_extendedprice) AS sum_base_price,
SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
AVG(l_quantity) AS avg_qty,
AVG(l_extendedprice) AS avg_price,
AVG(l_discount) AS avg_disc,
COUNT(*) AS count_order
FROM
hologres_dataset_tpch_10g.lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
l_returnflag,
l_linestatus;Contoh 2: Buat Tabel Dinamis untuk Pembaruan bertahap dan tentukan waktu mulai
Sebelum memulai, impor dataset publik tpch_10g ke Hologres. Untuk informasi selengkapnya, lihat Impor dataset publik dengan satu klik.
Contoh berikut menunjukkan cara membuat Tabel Dinamis untuk Pembaruan bertahap:
Sebelum membuat Tabel Dinamis untuk Pembaruan bertahap, aktifkan binary logging untuk tabel dasar. Anda tidak perlu mengaktifkannya untuk tabel dimensi.
-- Aktifkan binary logging untuk tabel dasar.
BEGIN;
CALL set_table_property('hologres_dataset_tpch_10g.lineitem', 'binlog.level', 'replica');
COMMIT;
-- Buat Tabel Dinamis untuk Pembaruan bertahap tabel tunggal.
-- Tentukan waktu mulai refresh dan atur interval refresh menjadi 3 menit.
CREATE DYNAMIC TABLE public.tpch_q1_incremental
WITH (
refresh_mode='incremental',
auto_refresh_enable='true',
incremental_auto_refresh_schd_start_time='2024-09-15 23:50:0',
incremental_auto_refresh_interval='3 minutes',
incremental_guc_hg_computing_resource='serverless',
incremental_guc_hg_experimental_serverless_computing_required_cores='30'
) AS SELECT
l_returnflag,
l_linestatus,
COUNT(*) AS count_order
FROM
hologres_dataset_tpch_10g.lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
l_returnflag,
l_linestatus
;Contoh 3: Buat Tabel Dinamis untuk Pembaruan penuh dengan JOIN multi-tabel
-- Buat Tabel Dinamis yang kuerinya berisi JOIN multi-tabel.
-- Gunakan mode Pembaruan penuh dan atur interval refresh menjadi 3 jam.
CREATE DYNAMIC TABLE dt_q_full
WITH (
refresh_mode='full',
auto_refresh_enable='true',
full_auto_refresh_schd_start_time='immediate',
full_auto_refresh_interval='3 hours',
full_guc_hg_computing_resource='serverless',
full_guc_hg_experimental_serverless_computing_required_cores='64'
)
AS
SELECT
o_orderpriority,
COUNT(*) AS order_count
FROM
hologres_dataset_tpch_10g.orders
WHERE
o_orderdate >= DATE '1996-07-01'
AND o_orderdate < DATE '1996-07-01' + INTERVAL '3' MONTH
AND EXISTS (
SELECT
*
FROM
hologres_dataset_tpch_10g.lineitem
WHERE
l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY
o_orderpriority;Contoh 4: Buat Tabel Dinamis untuk Pembaruan bertahap dengan JOIN tabel dimensi
Contoh berikut menunjukkan cara membuat Tabel Dinamis untuk Pembaruan bertahap dengan JOIN tabel dimensi:
Sebelum membuat Tabel Dinamis untuk Pembaruan bertahap, aktifkan binary logging untuk tabel dasar. Anda tidak perlu mengaktifkannya untuk tabel dimensi.
Semantik JOIN tabel dimensi adalah sebagai berikut: setiap catatan hanya dikaitkan dengan versi terbaru data tabel dimensi pada saat operasi JOIN dilakukan. Jika data dalam tabel dimensi berubah (ditambahkan, diperbarui, atau dihapus) setelah operasi JOIN, data tabel dimensi yang sebelumnya terkait tidak disinkronkan. Berikut adalah contoh pernyataan SQL:
-- Tabel detail
BEGIN;
CREATE TABLE public.sale_detail(
app_id TEXT,
uid TEXT,
product TEXT,
gmv BIGINT,
order_time TIMESTAMPTZ
);
-- Aktifkan binary logging untuk tabel dasar. Anda tidak perlu mengaktifkannya untuk tabel dimensi.
CALL set_table_property('public.sale_detail', 'binlog.level', 'replica');
COMMIT;
-- Tabel properti
CREATE TABLE public.user_info(
uid TEXT,
province TEXT,
city TEXT
);
CREATE DYNAMIC TABLE public.dt_sales_incremental
WITH (
refresh_mode='incremental',
auto_refresh_enable='true',
incremental_auto_refresh_schd_start_time='2024-09-15 00:00:00',
incremental_auto_refresh_interval='5 minutes',
incremental_guc_hg_computing_resource='serverless',
incremental_guc_hg_experimental_serverless_computing_required_cores='128')
AS
SELECT
sale_detail.app_id,
sale_detail.uid,
product,
SUM(sale_detail.gmv) AS sum_gmv,
sale_detail.order_time,
user_info.province,
user_info.city
FROM public.sale_detail
INNER JOIN public.user_info FOR SYSTEM_TIME AS OF PROCTIME()
ON sale_detail.uid =user_info.uid
GROUP BY sale_detail.app_id,sale_detail.uid,sale_detail.product,sale_detail.order_time,user_info.province,user_info.city;Contoh 5: Buat Tabel Dinamis partisi
Pertimbangkan dashboard transaksi real-time. Bisnis sering perlu melihat data hari ini secara near real-time dan juga memperbaiki data historis. Dalam skenario ini, Anda dapat menggunakan Pembaruan penuh dan Pembaruan bertahap untuk Tabel Dinamis. Prosedurnya adalah sebagai berikut:
Buat tabel partisi sebagai tabel dasar. Anda dapat menulis data ke partisi terbaru secara real-time atau near real-time. Anda juga dapat sesekali memperbaiki data di partisi historis.
Buat Tabel Dinamis sebagai tabel partisi induk. Gunakan mode Pembaruan bertahap untuk partisi terbaru untuk memenuhi persyaratan bisnis untuk analitik data near-real-time.
Alihkan partisi historis ke mode Pembaruan penuh. Jika data di partisi historis tabel sumber diperbaiki atau direfresh, Anda juga dapat melakukan refresh satu kali pada partisi historis Tabel Dinamis yang sesuai. Kami menyarankan Anda menggunakan sumber daya komputasi Serverless untuk mempercepat refresh.
Berikut adalah contohnya:
Persiapkan tabel dasar dan data.
Tabel dasar adalah tabel partisi. Data ditulis ke partisi terbaru secara real-time.
-- Buat tabel sumber partisi. CREATE TABLE base_sales( uid INT, opreate_time TIMESTAMPTZ, amount FLOAT, tt TEXT NOT NULL, ds TEXT, PRIMARY KEY(ds) ) PARTITION BY LIST (ds) ; -- Partisi historis CREATE TABLE base_sales_20240615 PARTITION OF base_sales FOR VALUES IN ('20240615'); INSERT INTO base_sales_20240615 VALUES (2,'2024-06-15 16:18:25.387466+08','111','2','20240615'); -- Partisi terbaru, yang biasanya ditulis secara real-time. CREATE TABLE base_sales_20240616 PARTITION OF base_sales FOR VALUES IN ('20240616'); INSERT INTO base_sales_20240616 VALUES (1,'2024-06-16 16:08:25.387466+08','2','1','20240616');Buat Tabel Dinamis partisi induk. Untuk tabel induk, definisikan hanya kueri dan jangan atur mode refresh.
-- Buat ekstensi. CREATE EXTENSION roaringbitmap; CREATE DYNAMIC TABLE partition_dt_base_sales PARTITION BY LIST (ds) as SELECT public.RB_BUILD_AGG(uid), opreate_time, amount, tt, ds, COUNT(1) FROM base_sales GROUP BY opreate_time ,amount,tt,ds;Buat tabel anak dan atur mode refresh untuk mereka.
Anda dapat membuat Tabel Dinamis partisi anak secara manual, atau membuatnya secara dinamis menggunakan Pengembangan Data di DataWorks. Anda dapat membuat partisi terbaru dalam mode Pembaruan bertahap dan mengatur partisi historis ke mode Pembaruan penuh.
-- Aktifkan binary logging untuk tabel dasar. ALTER TABLE base_sales SET (binlog_level = replica); -- Asumsikan berikut ini adalah Tabel Dinamis partisi anak historis: CREATE DYNAMIC TABLE partition_dt_base_sales_20240615 PARTITION OF partition_dt_base_sales FOR VALUES IN ('20240615') WITH ( refresh_mode='incremental', auto_refresh_enable='true', incremental_auto_refresh_schd_start_time='immediate', incremental_auto_refresh_interval='30 minutes' ); -- Buat Tabel Dinamis partisi anak baru. -- Atur mode refresh untuk partisi terbaru ke inkremental. -- Refresh dimulai segera setelah tabel dibuat, dijalankan dengan interval 30 menit, dan menggunakan sumber daya instans saat ini. CREATE DYNAMIC TABLE partition_dt_base_sales_20240616 PARTITION OF partition_dt_base_sales FOR VALUES IN ('20240616') WITH ( refresh_mode='incremental', auto_refresh_enable='true', incremental_auto_refresh_schd_start_time='immediate', incremental_auto_refresh_interval='30 minutes' ); -- Ubah partisi historis ke mode Pembaruan penuh. ALTER DYNAMIC TABLE partition_dt_base_sales_20240615 SET (refresh_mode = 'full'); -- Jika data di partisi historis perlu diperbaiki, Anda dapat menjalankan operasi refresh. -- Kami menyarankan Anda menggunakan sumber daya komputasi Serverless untuk operasi ini. SET hg_computing_resource = 'serverless'; REFRESH DYNAMIC TABLE partition_dt_base_sales_20240615;
Perintah konversi sintaks
Hologres meningkatkan sintaks untuk Tabel Dinamis di V3.1. Setelah Anda upgrade dari V3.0, Anda harus membuat ulang tabel menggunakan sintaks V3.1. Hologres menyediakan alat konversi sintaks untuk menyederhanakan proses ini.
Kapan harus membuat ulang tabel
Tabel Dinamis yang menggunakan Pembaruan bertahap harus dibuat ulang.
Jika pemeriksaan upgrade melaporkan sintaks yang tidak kompatibel, Anda harus membuat ulang tabel tersebut. Untuk kasus spesifik, lihat laporan pemeriksaan upgrade.
Kecuali untuk skenario di atas, Anda tidak perlu membuat ulang Tabel Dinamis yang dibuat menggunakan sintaks V3.0. Anda hanya dapat melakukan operasi ALTER pada tabel-tabel tersebut. Anda tidak dapat membuat tabel baru menggunakan sintaks V3.0.
Skenario untuk perintah transformasi sintaks
Perintah konversi sintaks hanya berlaku untuk tabel non-partisi yang menggunakan Pembaruan bertahap atau Pembaruan penuh. Jika Anda memiliki Tabel Dinamis partisi dari V3.0, Anda harus membangun ulang secara manual dan menggunakan fitur partisi logis Tabel Dinamis.
Lihat tabel yang memerlukan konversi
Anda dapat menggunakan perintah berikut untuk melihat tabel di instans saat ini yang memerlukan konversi setelah upgrade:
Tabel non-partisi
SELECT DISTINCT
p.dynamic_table_namespace as table_namespace,
p.dynamic_table_name as table_name
FROM hologres.hg_dynamic_table_properties p
JOIN pg_class c ON c.relname = p.dynamic_table_name
JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = p.dynamic_table_namespace
WHERE p.property_key = 'refresh_mode'
AND p.property_value = 'incremental'
AND c.relispartition = false
AND c.relkind != 'p';Tabel partisi
SELECT DISTINCT
pn.nspname as parent_schema,
pc.relname as parent_name
FROM hologres.hg_dynamic_table_properties p
JOIN pg_class c ON c.relname = p.dynamic_table_name
JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = p.dynamic_table_namespace
JOIN pg_inherits i ON c.oid = i.inhrelid
JOIN pg_class pc ON pc.oid = i.inhparent
JOIN pg_namespace pn ON pn.oid = pc.relnamespace
WHERE p.property_key = 'refresh_mode'
AND p.property_value = 'incremental'
AND c.relispartition = true
AND c.relkind != 'p';Menggunakan perintah konversi sintaks
Perhatikan hal berikut saat menggunakan perintah konversi sintaks:
Sintaks perintah ini hanya didukung di Hologres V3.1.11 dan versi selanjutnya.
superuser harus mengeksekusi perintah ini.
Setelah perintah dijalankan, perilaku berubah sebagai berikut:
Jika auto-refresh diaktifkan untuk tabel, proses auto-refresh dimulai segera. Jalankan perintah selama jam sepi untuk mencegah tugas dimulai bersamaan dan bersaing untuk sumber daya. Anda dapat menggunakan sumber daya Serverless untuk menjalankan refresh guna fencing tugas yang lebih baik.
Perubahan dalam penggunaan sumber daya:
Dengan sintaks baru di V3.1 dan V3.2, instans kelompok komputasi menggunakan gudang leader kelompok tabel (TG) untuk tabel dasar dan gudang leader TG untuk Tabel Dinamis.
Dengan sintaks lama V3.0, atau dengan sintaks baru di instans V4.1, instans kelompok komputasi menggunakan gudang leader TG untuk Tabel Dinamis.
Perubahan dalam koneksi. Sintaks baru menggunakan mekanisme penjadwalan dasar yang lebih stabil dan efisien. Setiap Tabel Dinamis menggunakan satu koneksi tambahan. Jika instans Anda memiliki penggunaan koneksi tinggi dan banyak Tabel Dinamis, misalnya beberapa ratus, Anda harus membersihkan koneksi idle terlebih dahulu.
Perintah konversi sintaks adalah sebagai berikut:
--Hanya berlaku untuk tabel non-partisi yang menggunakan Pembaruan penuh atau Pembaruan bertahap. Untuk tabel partisi, buat ulang secara manual dan gunakan partisi logis.
--Konversi satu tabel
call hg_dynamic_table_config_upgrade('<table_name>');
--Konversi batch semua tabel. Gunakan dengan hati-hati.
call hg_upgrade_all_normal_dynamic_tables();Metode ini meng-upgrade semua tabel partisi Tabel Dinamis di database saat ini dari V3.0 ke V3.1.
Pemetaan parameter sintaks
Perintah konversi sintaks memetakan parameter dan nilai V3.0 ke V3.1 sebagai berikut:
Nama parameter V3.0 | Nama parameter V3.1 | Deskripsi |
refresh_mode | auto_refresh_mode | Nilai parameter tetap sama setelah konversi. Misalnya, konfigurasi sebelum konversi |
auto_refresh_enable | auto_refresh_enable | Nilai parameter tetap sama. |
{refresh_mode}_auto_refresh_schd_start_time | freshness | Nilai auto_refresh_interval akan dikonversi menjadi nilai freshness. Nilai `auto_refresh_interval` digunakan untuk `freshness`. Misalnya, konfigurasi sebelum konversi |
{refresh_mode}_auto_refresh_interval | ||
{refresh_mode}_guc_hg_computing_resource | computing_resource | Nilai parameter tetap sama setelah konversi. Misalnya, konfigurasi sebelum konversi |
{refresh_mode}_guc_hg_experimental_serverless_computing_required_cores | refresh_guc_hg_experimental_serverless_computing_required_cores | Nilai parameter tetap sama setelah konversi. |
{refresh_mode}_guc_<guc> | refresh_guc_<guc_name> | Nilai parameter sama dengan nilai sebelum transformasi. Misalnya, konfigurasi sebelum transformasi Nilai parameter tetap sama setelah konversi. Misalnya, konfigurasi sebelum konversi |
Properti tabel seperti orientation | Properti tabel seperti orientation | Properti dasar tabel tetap tidak berubah. |
Langkah selanjutnya: Kelola Tabel Dinamis
Setelah membuat Tabel Dinamis, Anda dapat melakukan operasi berikut:
Lihat Data Definition Language (DDL), alur data, dan detail lainnya dari Tabel Dinamis. Untuk informasi selengkapnya, lihat Lihat skema dan alur data Tabel Dinamis.
Ubah properti Tabel Dinamis. Untuk informasi selengkapnya, lihat ALTER TABEL DINAMIS.
FAQ
Gejala: Terjadi error jika Segment Key atau Clustering Key kosong. Berikut adalah contoh pesan error:
ERROR: commit ddl phase1 failed: the index partition key "xxx" should not be nullablePenyebab: Segment Key dan Clustering Key Tabel Dinamis adalah kolom yang tidak boleh null. Untuk informasi selengkapnya mengenai aturan pengaturan kunci-kunci ini, lihat Kolom Waktu Event (Segment Key).
Solusi: Tambahkan parameter Grand Unified Configuration (GUC) berikut dan jalankan bersama pernyataan DDL yang membuat Tabel Dinamis.
SET hg_experimental_enable_nullable_segment_key = true; SET hg_experimental_enable_nullable_clustering_key = true;Berikut adalah contohnya.
SET hg_experimental_enable_nullable_segment_key = true; SET hg_experimental_enable_nullable_clustering_key = true; CREATE DYNAMIC TABLE dt WITH ( auto_refresh_mode = 'incremental', freshness='10 minutes' ) AS SELECT order_id, orders.user_id, user_name FROM orders LEFT JOIN users ON orders.user_id = users.user_id;