Asynchronous Materialized Views Overview for StarRocks Query Acceleration - EMR Serverless StarRocks

Pemodelan data melalui tampilan yang di-materialisasi secara asinkron StarRocks memungkinkan Anda menyederhanakan pengelolaan pipeline dan meningkatkan efisiensi serta fleksibilitas pemodelan data menggunakan bahasa pemodelan deklaratif. Topik ini menjelaskan cara menggunakan tampilan yang di-materialisasi secara asinkron StarRocks untuk pemodelan data.

Latar Belakang

Pemodelan data adalah proses pembersihan, pelapisan, agregasi, dan asosiasi data melalui metode yang sesuai. Ketika kualitas data asli terlalu rendah, terdapat banyak metrik kompleks, atau biaya query tinggi karena kurangnya agregasi, Anda dapat memodelkan data asli untuk mendapatkan hasil data yang lebih mudah dipahami dan digunakan.

Namun, kontradiksi umum dalam pemodelan data dunia nyata adalah bahwa proses pemodelan sulit mengimbangi perkembangan bisnis, dan sulit untuk mengukur pengembalian investasi dari pekerjaan pemodelan data. Meskipun metode pemodelan sederhana, mereka memerlukan para ahli bisnis dengan latar belakang kuat dalam organisasi dan tata kelola data untuk memproses dan mengatur data, yang merupakan proses kompleks. Pada tahap awal bisnis, pembuat keputusan sering kali tidak menginvestasikan cukup sumber daya dalam pemodelan data, sehingga sulit untuk melihat nilai yang dapat dibawa oleh pemodelan data. Selain itu, karena model bisnis dapat berubah dengan cepat, metode pemodelan juga perlu terus diulang dan berkembang. Oleh karena itu, banyak analis data cenderung tidak menggunakan pemodelan data dan langsung menggunakan data mentah, yang tak terhindarkan menyebabkan masalah dengan kualitas data dan kinerja query. Ketika kebutuhan akan pemodelan muncul, mereka menghadapi masalah bahwa pola penggunaan data telah terbentuk dan sulit untuk direstrukturisasi.

Menggunakan tampilan yang di-materialisasi StarRocks untuk pemodelan data dapat secara efektif menyelesaikan masalah di atas. Tampilan yang di-materialisasi secara asinkron StarRocks memiliki kemampuan berikut:

Menyederhanakan arsitektur gudang data: Karena StarRocks menyediakan pengalaman tata kelola data satu atap, Anda tidak perlu memelihara sistem atau komponen pemrosesan data lainnya, menghemat sumber daya manusia dan fisik yang digunakan untuk memelihara sistem tersebut.
Menyederhanakan pengalaman pemodelan: Setiap analis data dengan pengetahuan SQL dasar dapat menggunakan StarRocks untuk pemodelan data tanpa memerlukan insinyur data profesional.
Menyederhanakan pemeliharaan sistem: Tampilan yang di-materialisasi secara asinkron StarRocks dapat secara otomatis mengelola level dan dependensi antar data, tanpa memerlukan seluruh platform data untuk menangani tugas ini.

Dalam praktiknya, Anda dapat menggabungkan tampilan logis StarRocks dan tampilan yang di-materialisasi secara asinkron untuk pemodelan data, seperti yang ditunjukkan di bawah ini:

Gunakan tampilan untuk mengaitkan data waktu nyata dengan data dimensi, dan gunakan tampilan yang di-materialisasi untuk mengaitkan data historis di data lake dengan data dimensi. Pada saat yang sama, lakukan pembersihan data yang diperlukan dan pemetaan semantik bisnis untuk mendapatkan Lapisan Perantara yang mencerminkan data rinci semantik bisnis.
Di Lapisan Aplikasi, lakukan Join data, Agg, Union, dan perhitungan Window untuk skenario bisnis yang berbeda, menghasilkan tampilan untuk tautan waktu nyata dan tampilan yang di-materialisasi untuk tautan hampir waktu nyata.
Di sisi Aplikasi, pilih penyimpanan data analitik (ADS) yang sesuai untuk analisis query berdasarkan persyaratan ketepatan waktu dan kinerja Anda, melayani dasbor waktu nyata, BI hampir waktu nyata, Ad hoc query, dan laporan terjadwal.

Kemampuan tampilan yang di-materialisasi secara asinkron

Tampilan yang di-materialisasi secara asinkron StarRocks memiliki kemampuan atomik berikut untuk membantu pemodelan data:

Pembaruan otomatis: Tampilan yang di-materialisasi dapat diperbarui secara otomatis setelah data diimpor ke tabel dasar. Anda tidak perlu memelihara tugas penjadwalan eksternal.
Pembaruan partisi: Melalui laporan dengan atribut deret waktu, komputasi hampir waktu nyata dapat dicapai melalui pembaruan partisi.
Penggunaan kolaboratif dengan tampilan: Dengan menggunakan tampilan yang di-materialisasi dan tampilan logis secara kolaboratif, Anda dapat mengimplementasikan pemodelan multi-lapis, sehingga mencapai penggunaan kembali lapisan perantara dan penyederhanaan model data.
Perubahan Skema: Anda dapat mengubah hasil komputasi melalui pernyataan SQL sederhana tanpa memodifikasi pipeline data yang kompleks.

Dengan fitur-fitur ini, Anda dapat merancang model data yang komprehensif dan fleksibel untuk memenuhi berbagai persyaratan dan skenario bisnis.

Penyegaran otomatis

Saat membuat tampilan yang di-materialisasi secara asinkron, Anda dapat menggunakan klausa REFRESH untuk menentukan strategi pembaruan. Saat ini, tampilan yang di-materialisasi secara asinkron StarRocks mendukung strategi pembaruan berikut:

Pembaruan otomatis (REFRESH ASYNC): Tugas pembaruan dipicu setiap kali data di tabel dasar berubah. Ketergantungan data dikelola secara otomatis oleh tampilan yang di-materialisasi.
Pembaruan terjadwal (REFRESH ASYNC EVERY (INTERVAL <refresh_interval>)): Tugas pembaruan dipicu secara berkala, seperti setiap menit, hari, atau bulan. Jika tidak ada perubahan data di tabel dasar, tidak ada tugas pembaruan yang akan dipicu.
Pembaruan manual (REFRESH MANUAL): Anda hanya dapat memicu tugas pembaruan dengan menjalankan REFRESH MATERIALIZED VIEW secara manual. Anda dapat menggunakan strategi pembaruan ini jika Anda memicu tugas pembaruan melalui kerangka penjadwalan eksternal.

Sintaksnya adalah sebagai berikut:

CREATE MATERIALIZED VIEW <db_name>.<mv_name>
REFRESH 
    [ ASYNC | 
      ASYNC [START <time>] EVERY(<interval>) | 
      MANUAL
    ]
AS <query>

Penyegaran Partisi

Saat membuat tampilan yang di-materialisasi secara asinkron, Anda dapat menggunakan klausa PARTITION BY untuk mengaitkan partisi tabel dasar dengan partisi tampilan yang di-materialisasi, sehingga mencapai pembaruan pada granularitas partisi.

PARTITION BY <column>: Anda dapat mereferensikan kolom partisi yang sama dengan tabel dasar untuk tampilan yang di-materialisasi, sehingga tabel dasar dan tampilan yang di-materialisasi menggunakan granularitas partisi yang sama.
PARTITION BY date_trunc(<column>): Anda dapat menggunakan fungsi date_trunc untuk menggulung berdasarkan kolom partisi tabel dasar, sehingga menciptakan strategi partisi dengan granularitas berbeda untuk tampilan yang di-materialisasi.
PARTITION BY { time_slice | date_slice }(<column>): Dibandingkan dengan date_trunc, time_slice dan date_slice memberikan penyesuaian granularitas waktu yang lebih fleksibel, memungkinkan kontrol yang lebih halus atas granularitas partisi waktu.

Sintaksnya adalah sebagai berikut.

CREATE MATERIALIZED VIEW <db_name>.<mv_name>
REFRESH ASYNC
PARTITION BY 
    [
        <base_table_column> | 
        date_trunc(<granularity>, <base_table_column>) |
        time_slice(<base_table_column>, <granularity>) | 
        date_slice(<base_table_column>, <granularity>)
    ]
AS <query>

Penggunaan bersama dengan Tampilan

Anda dapat membuat tampilan yang di-materialisasi berdasarkan tampilan. Dalam hal ini, tampilan yang di-materialisasi dapat diperbarui secara otomatis ketika data berubah di tabel dasar yang direferensikan oleh tampilan.
Anda dapat membuat tampilan yang di-materialisasi berdasarkan tampilan yang di-materialisasi lainnya, memungkinkan pembaruan bertingkat berjenjang.
Anda dapat membuat tampilan berdasarkan tampilan yang di-materialisasi, setara dengan membuat berdasarkan tabel reguler.

Perubahan skema

Tampilan yang di-materialisasi secara asinkron dapat diganti secara atomik menggunakan pernyataan ALTER MATERIALIZED VIEW SWAP. Anda dapat membuat tampilan yang di-materialisasi baru, menambahkan kolom baru atau mengubah jenis kolom, dan kemudian mengganti tampilan yang di-materialisasi lama dengan yang baru.
Tampilan dapat dimodifikasi secara langsung menggunakan pernyataan ALTER VIEW.
Tabel reguler di StarRocks dapat dimodifikasi menggunakan operasi SWAP atau ALTER.
Ketika tabel dasar (yang bisa berupa tampilan yang di-materialisasi, tampilan, atau tabel reguler) berubah, perubahan berjenjang akan dipicu di tampilan yang di-materialisasi yang sesuai.

Pemodelan Hirarkis

Dalam skenario bisnis nyata, terdapat berbagai bentuk sumber data, termasuk data rinci waktu nyata, data dimensi, dan data yang diarsipkan di data lake. Di sisi lain, persyaratan bisnis memerlukan metode analitik yang beragam, seperti dasbor waktu nyata, query BI hampir waktu nyata, query Ad hoc analis, dan laporan terjadwal. Skenario yang berbeda memiliki persyaratan yang berbeda, beberapa memerlukan fleksibilitas, beberapa memprioritaskan kinerja, sementara yang lain menekankan efektivitas biaya.

Jelas, solusi tunggal tidak dapat memenuhi persyaratan yang begitu beragam secara memadai. StarRocks dapat secara efisien memenuhi persyaratan ini dengan menggabungkan tampilan dan tampilan yang di-materialisasi. Karena tampilan tidak memelihara data fisik, setiap kali tampilan di-query, query tersebut diurai dan dieksekusi sesuai dengan definisi tampilan. Sebaliknya, tampilan yang di-materialisasi menyimpan hasil pre-komputasi, yang dapat menghindari overhead eksekusi berulang. Tampilan cocok untuk mengekspresikan semantik bisnis dan menyederhanakan kompleksitas SQL, tetapi tidak dapat mengurangi overhead eksekusi query. Di sisi lain, tampilan yang di-materialisasi mengoptimalkan kinerja query dengan pre-komputasi dan menyimpan hasil query, cocok untuk skenario yang menyederhanakan Pipeline ETL.

Perbedaan antara tampilan dan tampilan yang di-materialisasi

Item perbandingan	Lihat	Tampilan yang di-materialisasi
Skenario	Pemodelan bisnis, Tata kelola data	Pemodelan data, percepatan transparan, danau data terpadu
Overhead penyimpanan	Tidak menyimpan data, tidak ada overhead penyimpanan	Menyimpan hasil pre-komputasi, memiliki biaya penyimpanan tambahan
Overhead pembaruan	Tidak ada overhead pembaruan	Memiliki overhead pembaruan ketika data tabel dasar diperbarui
Manfaat kinerja	Tidak ada pre-komputasi, tidak ada manfaat kinerja	Hasil pre-komputasi, mempercepat query
Ketepatan waktu data	Mengembalikan data terbaru saat men-query tampilan	Hasil pre-komputasi, mungkin memiliki latensi data
Dependensi	Mereferensikan tabel dasar berdasarkan nama, tampilan menjadi tidak valid jika nama tabel dasar berubah	Mereferensikan tabel dasar berdasarkan ID, perubahan nama tabel dasar tidak mempengaruhi ketersediaan tampilan yang di-materialisasi
Sintaks	CREATE VIEW	CREATE MATERIALIZED VIEW
Sintaks modifikasi	ALTER VIEW	ALTER MATERIALIZED VIEW

Memodifikasi tampilan dan tabel dasar

Anda dapat menggunakan pernyataan berikut untuk memodifikasi tampilan, tampilan yang di-materialisasi, dan tabel dasar Anda.

-- Modifikasi tabel dasar.
ALTER TABLE <db_name>.<table_name> ADD COLUMN <column_desc>;

-- Ganti tabel dasar secara atomik.
ALTER TABLE <db_name>.<table1> SWAP WITH <table2>;

-- Modifikasi definisi tampilan.
ALTER VIEW <db_name>.<view_name> AS <query>;

-- Ganti tampilan yang di-materialisasi secara atomik (menukar nama dua tampilan yang di-materialisasi tanpa memodifikasi datanya).
ALTER MATERIALIZED VIEW <db_name>.<mv1> SWAP WITH <mv2>;

-- Aktifkan kembali tampilan yang di-materialisasi.
ALTER MATERIALIZED VIEW <db_name>.<mv_name> ACTIVE;

Perubahan Skema mengikuti prinsip-prinsip berikut:

Penggantian nama tabel dan operasi penggantian atomik akan menyebabkan tampilan yang di-materialisasi yang bergantung menjadi Inactive. Untuk operasi Perubahan Skema, tampilan yang di-materialisasi hanya akan menjadi Inactive ketika kolom tabel dasar yang mereka andalkan mengalami Perubahan Skema.
Perubahan definisi tampilan akan menyebabkan tampilan yang di-materialisasi yang bergantung menjadi Inactive.
Penggantian atomik tampilan yang di-materialisasi akan menyebabkan tampilan yang di-materialisasi bersarang yang bergantung menjadi Inactive.
Status Inactive menyebar ke atas secara berjenjang sampai tidak ada lagi dependensi tampilan yang di-materialisasi.
Tampilan yang di-materialisasi Inactive tidak dapat diperbarui atau digunakan untuk penulisan ulang query otomatis.
Tampilan yang di-materialisasi Inactive masih dapat di-query secara langsung, tetapi konsistensi data tidak dapat dijamin sampai mereka diaktifkan kembali.

Karena konsistensi data tidak dapat dijamin untuk tampilan yang di-materialisasi Inactive, Anda dapat menggunakan metode berikut untuk memperbaikinya:

Perbaikan manual: Anda dapat memperbaiki tampilan yang di-materialisasi Inactive secara manual dengan menjalankan ALTER MATERIALIZED VIEW <mv_name> ACTIVE. Pernyataan ini akan mencoba membangun kembali berdasarkan definisi SQL asli tampilan yang di-materialisasi. Perhatikan bahwa agar pembangunan kembali berhasil, definisi SQL harus tetap valid setelah Perubahan Skema yang mendasarinya, jika tidak operasi akan gagal.
Perbaikan selama pembaruan: StarRocks akan secara otomatis mencoba menjalankan perintah perbaikan di atas saat memperbarui tampilan yang di-materialisasi, membangun kembali tampilan yang di-materialisasi sebelum pembaruan.
Perbaikan otomatis: StarRocks akan mencoba secara otomatis memperbaiki tampilan yang di-materialisasi Inactive. Anda dapat menonaktifkan fitur ini dengan menjalankan ADMIN SET FRONTEND CONFIG('enable_mv_automatic_active_check'='false').

Pemodelan Partisi

Selain pemodelan hirarkis, pemodelan partisi juga merupakan aspek penting dari pemodelan data. Pemodelan data sering melibatkan mengaitkan data sesuai dengan semantik bisnis dan menetapkan Waktu hidup (TTL) data berdasarkan persyaratan ketepatan waktu. Pemodelan partisi memainkan peran penting dalam proses ini. Metode asosiasi data yang berbeda akan menghasilkan pendekatan pemodelan yang berbeda, seperti skema bintang dan skema snowflake. Model-model ini memiliki satu kesamaan: mereka semua menggunakan tabel fakta dan tabel dimensi. Beberapa skenario bisnis memerlukan beberapa tabel fakta besar, sementara yang lain melibatkan tabel dimensi kompleks dan hubungan asosiasi. Tampilan yang di-materialisasi StarRocks mendukung asosiasi partisi tabel fakta, artinya tabel fakta dipartisi, dan hasil Join tampilan yang di-materialisasi dipartisi dengan cara yang sama.

Seperti yang ditunjukkan pada gambar di atas, tampilan yang di-materialisasi digunakan untuk mengaitkan tabel fakta dengan beberapa tabel dimensi:

Anda perlu menentukan kunci partisi tabel dasar tertentu (biasanya tabel fakta) di kunci partisi tampilan yang di-materialisasi untuk mencapai asosiasi partisi untuk tampilan yang di-materialisasi (PARTITION BY fact_tbl.col). Tampilan yang di-materialisasi hanya dapat memiliki asosiasi partisi dengan satu tabel dasar.
Ketika data di partisi tertentu dari tabel dasar yang terkait berubah, partisi yang sesuai di tampilan yang di-materialisasi akan diperbarui, tanpa mempengaruhi partisi lainnya.
Ketika tabel dasar non-terkait lainnya berubah, seluruh tampilan yang di-materialisasi akan diperbarui secara default. Namun, Anda dapat memilih untuk mengabaikan perubahan data di tabel non-terkait tertentu sehingga tampilan yang di-materialisasi tidak diperbarui ketika data di tabel-tabel tersebut berubah.

Skenario

Asosiasi partisi dapat mendukung berbagai skenario bisnis:

Pembaruan tabel fakta: Anda dapat mempartisi tabel fakta ke tingkat granularitas halus, seperti per hari atau per jam. Setelah tabel fakta diperbarui, partisi yang sesuai di tampilan yang di-materialisasi akan diperbarui secara otomatis.
Pembaruan tabel dimensi: Biasanya, pembaruan data di tabel dimensi akan menyebabkan semua hasil asosiasi diperbarui, yang mahal. Anda dapat memilih untuk mengabaikan pembaruan data di tabel dimensi tertentu untuk menghindari pembaruan seluruh tampilan yang di-materialisasi, atau Anda dapat menentukan rentang waktu sehingga hanya partisi dalam rentang waktu tersebut yang diperbarui.
Pembaruan otomatis tabel eksternal: Di sumber data eksternal seperti Apache Hive atau Apache Iceberg, data sering berubah pada granularitas partisi. Tampilan yang di-materialisasi StarRocks dapat berlangganan pembaruan data tingkat partisi di tabel eksternal dan hanya memperbarui partisi yang sesuai dari tampilan yang di-materialisasi.
TTL: Saat menetapkan strategi partisi untuk tampilan yang di-materialisasi, Anda dapat menetapkan jumlah partisi terbaru yang akan disimpan, sehingga hanya menyimpan data terbaru. Skenario bisnis yang sesuai memiliki persyaratan tinggi untuk ketepatan waktu data, misalnya, analis hanya perlu men-query data terbaru dalam jendela waktu tertentu tanpa perlu menyimpan semua data historis.

Anda dapat menggunakan beberapa parameter untuk mengontrol perilaku pembaruan:

partition_refresh_number: Jumlah partisi yang akan diperbarui dalam setiap operasi pembaruan.
partition_ttl_number: Jumlah partisi terbaru yang akan disimpan.
excluded_trigger_tables: Tabel yang akan diabaikan untuk menghindari pemicuan pembaruan otomatis.
auto_refresh_partitions_limit: Jumlah partisi yang akan diperbarui dalam setiap operasi pembaruan otomatis.

Batasan

Tampilan yang di-materialisasi berpartisi memiliki batasan berikut:

Hanya mendukung pembuatan tampilan yang di-materialisasi berpartisi berdasarkan tabel berpartisi.
Hanya mendukung jenis kolom partisi DATE dan DATETIME, bukan STRING.
Hanya mendukung penggunaan date_trunc, time_slice, dan date_slice untuk penggulungan partisi.
Hanya mendukung satu kolom sebagai kolom partisi, bukan beberapa kolom partisi.