全部产品
Search
文档中心

Hologres:BUAT TABEL DINAMIS

更新时间:Dec 25, 2025

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)

Catatan

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 kueri

Parameter

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:

  • auto: Mesin DPI secara otomatis memilih mode refresh. Jika kueri mendukung Pembaruan bertahap (incremental refresh), mode tersebut diprioritaskan. Jika tidak, mode beralih ke Pembaruan penuh (full refresh).

  • incremental: Hanya data inkremental yang direfresh setiap kali. Untuk informasi selengkapnya, lihat Pembaruan bertahap.

  • full: Seluruh data dalam tabel direfresh setiap kali. Untuk informasi selengkapnya, lihat Pembaruan penuh.

Tidak

auto

auto_refresh_enable

Menentukan apakah auto-refresh diaktifkan. Nilai yang valid:

  • true: mengaktifkan auto-refresh.

  • false: menonaktifkan auto-refresh. Setelah Anda menonaktifkan auto-refresh, semua refresh berikutnya untuk tabel tersebut akan dihentikan.

Tidak

true

base_table_cdc_format

Metode yang digunakan untuk mengonsumsi data dari tabel dasar untuk Pembaruan bertahap.

  • stream (default): membaca catatan perubahan data pada level file untuk menghitung data inkremental. Dibandingkan dengan metode binary logging, metode ini tidak memiliki overhead penyimpanan tambahan dan memberikan performa lebih tinggi. Untuk informasi selengkapnya, lihat Tabel Dinamis.

  • binlog: mengonsumsi data dari tabel dasar menggunakan binary logging. Setelah Anda mengatur parameter ini, Anda harus mengaktifkan binary logging untuk tabel dasar secara manual. Untuk informasi selengkapnya, lihat Berlangganan log biner Hologres.

    begin;
    call set_table_property('<table_name>', 'binlog.level', 'replica');
    call set_table_property('<table_name>', 'binlog.ttl', '2592000');
    commit;
Catatan
  • Mulai dari Hologres V3.1, metode stream digunakan secara default untuk mengonsumsi perubahan data dari tabel dasar untuk semua tabel. Jika Anda telah mengaktifkan binary logging untuk tabel Anda, segera nonaktifkan untuk menghindari pemborosan penyimpanan.

  • Ketika tabel dasar adalah tabel berorientasi baris, hanya metode binary logging yang didukung. Metode stream tidak didukung.

  • Anda tidak dapat mengubah parameter ini setelah tabel dibuat. Untuk mengubahnya, buat ulang tabel tersebut.

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 auto_refresh_partition_active_time dan partition_key_time_format untuk tabel partisi tersebut.

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 Waktu saat ini - Waktu mulai partisi (diinferensi dari nama partisi) < auto_refresh_partition_active_time.

Catatan
  • Satuan `auto_refresh_partition_active_time` harus lebih besar dari satu unit partisi. Misalnya, jika tabel dipartisi berdasarkan hari, `auto_refresh_partition_active_time` harus lebih besar dari 24 jam.

  • Anda dapat mengubah parameter ini. Perubahan hanya berlaku untuk partisi mendatang.

Ya

Unit waktu partisi + 1 jam.

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:

  • Jika kunci partisi bertipe TEXT atau VARCHAR:

    YYYYMMDDHH24, YYYY-MM-DD-HH24, YYYY-MM-DD_HH24, YYYYMMDD, YYYY-MM-DD, YYYYMM, YYYY-MM, YYYY.

  • Jika kunci partisi bertipe INT:

    YYYYMMDDHH24, YYYYMMDD, YYYYMM, YYYY.

  • Jika kunci partisi bertipe DATE:

    YYYY-MM-DD

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 column menunjukkan penyimpanan berorientasi kolom.

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:

  • hot: penyimpanan panas.

  • cold: penyimpanan dingin.

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
  • Parameter ini hanya didukung di Hologres V3.1.18 dan versi selanjutnya.

  • Jangan aktifkan binary logging untuk Tabel Dinamis yang menggunakan Pembaruan penuh (full refresh).

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 kueri

Parameter

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:

  • true: mengaktifkan auto-refresh.

  • false: menonaktifkan auto-refresh.

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 timezone, atur parameter menjadi refresh_guc_timezone = 'GMT-8:00'.

Tidak

Tidak ada

Refresh inkremental (incremental)

incremental_auto_refresh_schd_start_time

Waktu mulai untuk Pembaruan bertahap. Nilai yang valid:

  • immediate: Nilai default. Pembaruan bertahap dimulai segera setelah tabel dibuat.

  • <timestamptz>: Waktu mulai kustom untuk Pembaruan bertahap. Misalnya, jika Anda mengaturnya ke 2024-08-24 1:00, tugas refresh dimulai pada pukul 1:00 tanggal 24 Agustus 2024.

Tidak

immediate

incremental_auto_refresh_interval

Interval untuk Pembaruan bertahap. Satuan yang valid: minute, minutes, hour, dan hours.

  • Nilainya berkisar dari 1 menit hingga 48 jam.

  • Jika Anda tidak mengatur parameter ini, operasi refresh hanya dilakukan sekali pada waktu mulai yang ditentukan.

Tidak

Tidak ada

incremental_guc_hg_computing_resource

Menentukan sumber daya komputasi untuk Pembaruan bertahap. Nilai yang valid:

  • local: sumber daya instans saat ini.

  • serverless: Sumber daya Serverless. Periksa apakah instans memenuhi persyaratan untuk Serverless. Untuk informasi selengkapnya, lihat Panduan pengguna Komputasi Serverless.

Catatan

Anda dapat menjalankan perintah ALTER DATABASE xxx SET incremental_guc_hg_computing_resource=xx untuk mengatur sumber daya komputasi untuk Pembaruan bertahap di tingkat database.

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:

  • immediate: Nilai default. Pembaruan penuh dimulai segera setelah tabel dibuat.

  • <timestamptz>: Waktu mulai kustom untuk Pembaruan penuh. Misalnya, jika Anda mengaturnya ke 2024-08-24 1:00, tugas refresh dimulai pada pukul 1:00 tanggal 24 Agustus 2024.

Tidak

immediate

full_auto_refresh_interval

Interval untuk Pembaruan penuh. Satuan yang valid: minute, minutes, hour, dan hours.

  • Nilainya berkisar dari 1 menit hingga 48 jam.

  • Jika Anda tidak mengatur parameter ini, operasi refresh hanya dilakukan sekali pada waktu mulai yang ditentukan.

Tidak

Tidak ada

full_guc_hg_computing_resource

Menentukan sumber daya komputasi untuk Pembaruan penuh. Nilai yang valid:

  • local: sumber daya instans saat ini.

  • serverless: Sumber daya Serverless. Periksa apakah instans memenuhi persyaratan untuk Serverless. Untuk informasi selengkapnya, lihat Panduan pengguna Komputasi Serverless.

Catatan

Anda dapat menjalankan perintah ALTER DATABASE xxx SET full_guc_hg_computing_resource=xx untuk mengatur sumber daya komputasi untuk Pembaruan penuh di tingkat database.

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 column menunjukkan penyimpanan berorientasi kolom.

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:

  • hot: penyimpanan panas.

  • cold: penyimpanan dingin.

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

Catatan

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:

Catatan

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	1
  • Kueri 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	1
  • Kueri 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.

Catatan

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.

Catatan

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.

Catatan

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.

  1. 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;
  2. 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,ds
  3. Kueri Tabel Dinamis.

    SELECT * FROM ads_dt_github_event ;
  4. 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:

  1. 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;
  2. 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;
  3. 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:

Catatan

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:

Catatan

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:

  1. 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.

  2. Buat Tabel Dinamis sebagai tabel partisi induk. Gunakan mode Pembaruan bertahap untuk partisi terbaru untuk memenuhi persyaratan bisnis untuk analitik data near-real-time.

  3. 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:

  1. 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');
  2. 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;
  3. 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.

Catatan

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();
Catatan

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 refresh_mode='incremental' menjadi auto_refresh_mode='incremental' setelah 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 full_auto_refresh_interval='30 minutes' menjadi freshness='30 minutes' setelah konversi.

{refresh_mode}_auto_refresh_interval

{refresh_mode}_guc_hg_computing_resource

computing_resource

Nilai parameter tetap sama setelah konversi. Misalnya, konfigurasi sebelum konversi full_guc_hg_computing_resource='serverless' menjadi computing_resource='serverless' setelah 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 incremental_guc_hg_experimental_max_consumed_rows_per_refresh='1000000' menjadi refresh_guc_hg_experimental_max_consumed_rows_per_refresh='1000000' setelah 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:

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 nullable
  • Penyebab: 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;