Hologres Dynamic Table adalah arsitektur pemrosesan data deklaratif yang secara otomatis memproses dan menyimpan hasil agregasi dari satu atau beberapa tabel dasar. Fitur ini mencakup kebijakan penyegaran data bawaan yang dapat dikonfigurasi untuk mengaktifkan penerusan data otomatis dari tabel dasar ke Dynamic Table, sehingga menjawab kebutuhan akan pengembangan terpadu, penerusan data otomatis, serta pemrosesan data yang tepat waktu.
Latar Belakang
Skenario gudang data real-time sering melibatkan logika bisnis kompleks, seperti penggabungan tabel (table join) dan agregasi pada tabel besar. Operasi ini biasanya menangani volume data besar, mulai dari terabyte hingga petabyte, dengan berbagai tingkat kebutuhan ketepatan waktu. Transformasi data dalam skenario tersebut umumnya menghadirkan tantangan berikut:
Arsitektur Lambda yang terlalu redundan: Untuk menyeimbangkan biaya sumber daya, efisiensi pengembangan, dan ketepatan waktu bisnis, arsitektur Lambda banyak diadopsi. Namun, arsitektur ini bergantung pada beragam produk untuk skenario berbeda, sehingga menyebabkan redundansi arsitektur dan penyimpanan, inefisiensi dalam Pengembangan dan Operasi (O&M), serta inkonsistensi definisi data.
Penjadwalan ETL offline berulang dengan ketepatan waktu yang buruk: Menggunakan mesin komputasi offline, seperti Hive, untuk ekstrak, transformasi, dan muat (ETL) merupakan metode transformasi data yang umum. Pendekatan ini cocok untuk pemrosesan volume data besar dengan throughput tinggi, tetapi tidak memiliki kemampuan komputasi real-time. Untuk meningkatkan kesegaran data, data sering dihitung ulang secara berulang melalui penjadwalan periodik. Hal ini membuang banyak sumber daya dan tidak sepenuhnya memenuhi kebutuhan ketepatan waktu bisnis.
Biaya komputasi real-time yang tinggi: Untuk meningkatkan ketepatan waktu pemrosesan data, penggunaan mesin komputasi real-time dalam transformasi data menjadi tren baru. Namun, tidak semua layanan dalam gudang data memerlukan komputasi real-time. Banyak skenario, seperti kueri laporan Intelijen Bisnis (BI), hanya membutuhkan pemrosesan near-real-time pada tingkat menit. Menggunakan komputasi real-time untuk skenario semacam ini mengakibatkan biaya sumber daya yang terlalu tinggi.
Untuk mengatasi tantangan transformasi data tersebut, Hologres memperkenalkan Dynamic Table. Fitur ini mendukung mode komputasi penuh (full) dan inkremental, sehingga mampu menangani pemrosesan penuh offline untuk volume data besar sekaligus menggunakan komputasi inkremental untuk meningkatkan ketepatan waktu data dengan biaya lebih rendah dibanding komputasi real-time. Dynamic Table memungkinkan komputasi data otomatis dan pembaruan hasil, sehingga menciptakan alur data otomatis serta pelapisan gudang data yang lebih efisien dan hemat biaya. Dikombinasikan dengan fitur asli Hologres, Dynamic Table menyatukan lapisan penyimpanan, komputasi, transformasi data, dan layanan gudang data guna memenuhi kebutuhan efisiensi pengembangan dan ketepatan waktu.
Keunggulan Dynamic Table
Arsitektur gudang data yang disederhanakan
Dynamic Table mendukung mode refresh penuh dan inkremental, sehingga memungkinkan transformasi data offline (komputasi penuh) maupun transformasi data near-real-time (komputasi inkremental) untuk memenuhi berbagai kebutuhan ketepatan waktu kueri. Berdasarkan penyimpanan terpadu Hologres untuk data real-time dan offline, Dynamic Table secara langsung mendukung kebutuhan kueri dari berbagai skenario aplikasi, seperti kueri OLAP (online analytical processing), layanan online, serta AI dan model besar. Satu mesin, satu komputasi, dan satu pernyataan SQL dengan berbagai mode komputasi dapat menggantikan arsitektur Lambda, sehingga menyederhanakan arsitektur gudang data serta mengurangi biaya pengembangan dan O&M.
Pelapisan gudang data otomatis
Dynamic Table dapat secara otomatis memicu refresh berdasarkan kesegaran data tabel dasar, sehingga memungkinkan penerusan data otomatis dari lapisan operation data store (ODS) > data warehouse detail (DWD) > data warehouse service (DWS) > application data service (ADS) dan meningkatkan pengalaman pengembangan dalam pelapisan gudang data.
Efisiensi pemrosesan data (ETL) yang lebih baik
Refresh inkremental pada Dynamic Table hanya memproses data baru dari tabel dasar pada setiap siklus refresh, sehingga secara efektif mengurangi volume data yang diproses dalam setiap proses ETL dan secara signifikan meningkatkan efisiensi pemrosesan data. Sumber daya tidak perlu aktif terus-menerus seperti pada komputasi stream. Refresh otomatis yang dipicu oleh kesegaran data dapat mengurangi biaya secara efektif.
Biaya pengembangan dan O&M yang lebih rendah
Semua mode refresh untuk Dynamic Table menggunakan antarmuka SQL terpadu. Dynamic Table secara otomatis mengelola tugas refresh dan ketergantungan hierarkis antar data, sehingga menyederhanakan pengembangan dan O&M yang kompleks serta meningkatkan efisiensi pengembangan.
Istilah
Base Table
Base Table adalah sumber data untuk Dynamic Table. Base Table dapat berupa satu tabel internal atau tabel eksternal (foreign table), atau gabungan beberapa tabel. Jenis base table yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Fitur dan batasan yang didukung Dynamic Table.
Query
Kueri yang ditentukan saat membuat Dynamic Table adalah kueri yang memproses data base table, mirip dengan proses ETL. Jenis kueri yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Fitur dan batasan yang didukung Dynamic Table.
Refresh
Ketika data dalam base table berubah, Dynamic Table harus direfresh agar mencerminkan perubahan tersebut. Dynamic Table secara otomatis menjalankan tugas refresh di latar belakang berdasarkan waktu mulai dan interval refresh yang dikonfigurasi. Untuk informasi selengkapnya tentang cara memantau dan mengelola tugas refresh, lihat Mengelola tugas refresh Dynamic Table.
Cara Kerja
Data dari base table ditulis ke Dynamic Table melalui proses refresh, mengikuti alur pemrosesan data yang ditentukan oleh kueri Dynamic Table. Bagian ini menjelaskan prinsip teknis di balik Dynamic Table, dengan fokus pada mode refresh, sumber daya komputasi, penyimpanan data, dan indeks tabel.
Mode refresh
Dynamic Table saat ini mendukung dua mode refresh: penuh (full) dan inkremental. Prinsip teknis dasarnya berbeda tergantung pada mode refresh yang dikonfigurasi.
Full refresh
Full refresh memproses seluruh data pada setiap eksekusi. Fitur ini mematerialisasi hasil agregasi dari base table dan menuliskannya ke Dynamic Table. Prinsip teknisnya mirip dengan operasi INSERT OVERWRITE.
Incremental refresh
Pada mode incremental refresh, setiap refresh hanya membaca data baru dari base table. Fitur ini menghitung hasil akhir berdasarkan status agregasi antara dan data inkremental, lalu memperbarui Dynamic Table. Dibandingkan full refresh, incremental refresh memproses lebih sedikit data pada setiap eksekusi, sehingga lebih efisien. Hal ini secara signifikan meningkatkan ketepatan waktu tugas refresh sekaligus mengurangi penggunaan sumber daya komputasi.
Prinsip teknis
Saat Anda membuat Dynamic Table dengan incremental refresh, sistem membaca data inkremental dari base table menggunakan metode Stream atau Binlog. Kemudian, sistem membuat tabel status berorientasi kolom (column-oriented state table) di latar belakang. Tabel status ini menyimpan status agregasi antara dari kueri. Mesin DPI mengoptimalkan enkode dan penyimpanan status antara ini untuk mempercepat pembacaan dan pembaruannya. Data inkremental diagregasi dalam mikro-batch di memori, lalu digabungkan dengan data di tabel status. Hasil agregasi terbaru kemudian dituliskan secara efisien ke Dynamic Table menggunakan metode BulkLoad. Pemrosesan inkremental mikro-batch ini mengurangi volume data yang diproses dalam satu refresh dan secara signifikan meningkatkan ketepatan waktu komputasi.
Perbandingan metode Stream dan Binlog untuk membaca data inkremental
Metode pembacaan data inkremental
Prinsip
Kinerja baca
Fitur
Catatan
Stream (Direkomendasikan)
Mendeteksi perubahan data pada level file untuk menghitung data inkremental dari base table.
Lebih dari 10 kali lebih tinggi dibanding metode Binlog.
Lebih mudah digunakan.
Tidak mencatat perubahan inkremental secara terpisah. Artinya, tidak ada overhead penyimpanan tambahan, dan Anda tidak perlu mengelola siklus hidup penyimpanan log biner.
Tidak mendukung penggunaan tabel berorientasi baris (row-oriented tables) sebagai base table.
Binlog
Pencatatan log biner merekam perubahan Data Manipulation Language (DML) pada base table dan menyimpannya sebagai log biner di latar belakang. Saat mengonsumsi data inkremental dari base table, sistem membaca log biner untuk mendeteksi perubahan data.
Lebih rendah.
Menimbulkan overhead penyimpanan tambahan karena mencatat perubahan DML.
Memerlukan pengelolaan siklus hidup penyimpanan log biner (TTL). Jika tidak, penggunaan penyimpanan akan terus meningkat seiring perubahan atau pertumbuhan data.
Tidak ada.
Catatan
Terdapat batasan tertentu pada base table yang didukung oleh mode incremental refresh. Untuk informasi selengkapnya, lihat Fitur dan batasan yang didukung Dynamic Table.
Tabel status bawaan untuk incremental refresh menempati sebagian storage space. Sistem menetapkan TTL untuk membersihkan data secara berkala. Anda dapat menggunakan fungsi untuk melihat ukuran penyimpanan tabel status. Untuk informasi selengkapnya, lihat Mengelola tabel status.
Sumber daya komputasi
Sumber daya komputasi untuk menjalankan tugas refresh dapat berasal dari instans saat ini atau sumber daya Serverless:
Sumber daya Serverless (default): Di Hologres V3.1 dan versi setelahnya, Dynamic Table baru secara default menggunakan sumber daya Serverless untuk menjalankan refresh. Jika kueri kompleks dan memproses volume data besar, penggunaan sumber daya Serverless dapat meningkatkan stabilitas tugas refresh dan menghindari resource contention antar berbagai tugas dalam instans. Anda juga dapat mengubah sumber daya komputasi untuk satu tugas refresh guna mengoptimalkan penggunaan sumber daya Serverless.
Sumber daya instans saat ini: Tugas refresh menggunakan sumber daya instans saat ini dan berbagi dengan tugas lain dalam instans tersebut. Hal ini dapat menyebabkan resource contention selama jam sibuk.
Penyimpanan data
Penyimpanan data Dynamic Table sama seperti tabel standar, yang secara default menggunakan mode hot storage. Untuk mengurangi biaya penyimpanan, Anda dapat memindahkan data yang jarang dikueri ke cold storage.
Indeks tabel
Saat menjalankan kueri, Anda dapat langsung mengkueri Dynamic Table. Hal ini setara dengan mengkueri hasil agregasi secara langsung, yang secara signifikan meningkatkan kinerja kueri. Seperti tabel standar, Dynamic Table juga mendukung pengaturan indeks tabel, seperti row store atau column store, Distribution Key, dan Clustering Key. Biasanya, mesin DPI melakukan inferensi terhadap indeks yang sesuai berdasarkan kueri Dynamic Table. Jika Anda memerlukan optimasi lebih lanjut, Anda dapat menetapkan indeks baru untuk meningkatkan kinerja kueri.
Perbandingan dengan materialized view
Dynamic Table vs. materialized view Real-time Hologres
Hologres memperkenalkan materialized view yang dikelola SQL di V1.3, tetapi kemampuannya relatif terbatas. Perbedaan antara materialized view yang dikelola SQL dan Dynamic Table adalah sebagai berikut:
Kategori fitur | Hologres Dynamic Table | Materialized view Real-time Hologres |
Jenis base table |
| Single internal table |
Operasi Dasar Tabel |
| Append-only writes |
Prinsip refresh | Refresh asinkron (full refresh, incremental refresh) | Sinkronisasi |
Ketepatan waktu refresh |
| Real-time |
Jenis kueri |
Catatan Jenis kueri yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Fitur dan batasan yang didukung Dynamic Table. | Dukungan operator terbatas (fungsi AGG, RB, dll.) |
Mode permintaan | Kueri Dynamic Table secara langsung |
|
Dynamic Table vs. materialized view asinkron
Produk lain di pasar menawarkan fitur serupa dengan Dynamic Table, seperti materialized view asinkron pada produk OLAP dan Dynamic Table Snowflake. Perbedaannya adalah sebagai berikut:
Kategori fitur | Hologres Dynamic Table | Materialized view asinkron produk OLAP | Dynamic Table Snowflake |
Jenis base table |
Catatan Jenis kueri yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Fitur dan batasan yang didukung Dynamic Table. |
|
|
Mode refresh |
|
|
|
Ketepatan waktu refresh |
| Tingkat jam |
|
Jenis kueri |
Catatan Jenis kueri yang didukung bervariasi tergantung pada mode refresh. Untuk informasi selengkapnya, lihat Fitur dan batasan yang didukung Dynamic Table. |
|
|
Mode permintaan | Kueri Dynamic Table secara langsung |
| Kueri Dynamic Table secara langsung |
Pemantauan/O&M |
| Metrik pemantauan yang lengkap | Antarmuka visualisasi |
Skenario Khas
Dynamic Table secara otomatis menyelesaikan transformasi dan penyimpanan data. Anda dapat menggunakan Dynamic Table untuk mempercepat kueri data dan meningkatkan ketepatan waktu bisnis. Skenario yang direkomendasikan meliputi hal-hal berikut:
Peningkatan arsitektur Lambda
Untuk memenuhi berbagai kebutuhan ketepatan waktu dalam pemrosesan data bisnis, arsitektur Lambda menggunakan berbagai komponen produk. Hal ini menyebabkan arsitektur redundan, definisi data tidak konsisten, pemeliharaan sistem sulit, serta redundansi penyimpanan. Hologres Dynamic Table mendukung transformasi data batch dan pemrosesan near-real-time. Dikombinasikan dengan penyimpanan terpadu dan layanan data terpadu Hologres yang mendukung kueri OLAP dan kueri titik key-value (KV), fitur ini dapat mendukung berbagai skenario aplikasi dalam satu produk, sehingga menyederhanakan arsitektur serta mengurangi kompleksitas pengembangan, kurva pembelajaran, dan biaya penyimpanan.
Pemrosesan data near-real-time
Jika base table berisi volume data besar dan memerlukan pemrosesan ETL kompleks untuk memenuhi kebutuhan ketepatan waktu bisnis, praktik umum adalah pelapisan gudang data. Untuk gudang data real-time, terdapat berbagai solusi pelapisan, seperti penggunaan materialized view atau penjadwalan periodik. Meskipun solusi ini dapat mengatasi beberapa masalah, solusi tersebut juga menimbulkan isu terkait ketepatan waktu data dan kompleksitas pengembangan. Hologres Dynamic Table memiliki kemampuan bawaan untuk pemrosesan data otomatis, sehingga memudahkan implementasi pelapisan gudang data.
Praktik yang direkomendasikan adalah sebagai berikut:
Bangun lapisan DWD > DWS > ADS di Hologres menggunakan Dynamic Table:
Gunakan mode incremental refresh untuk sinkronisasi data antar lapisan. Hal ini memastikan bahwa volume data yang diproses di setiap lapisan lebih sedikit, mengurangi perhitungan berulang yang tidak perlu, serta meningkatkan kecepatan sinkronisasi. Anda juga dapat mengirimkan tugas refresh ke Serverless Computing untuk meningkatkan ketepatan waktu dan stabilitas refresh.
Untuk merefresh data setiap lapisan, Anda dapat melakukan full refresh sekali saja untuk memastikan konsistensi data lintas lapisan. Anda juga dapat mengirimkan tugas refresh ke Serverless Computing untuk meningkatkan ketepatan waktu dan stabilitas.
Setiap lapisan dibangun di Hologres dengan pelapisan gudang data yang jelas. Setiap lapisan dapat dikueri sesuai kebutuhan, sehingga memastikan visibilitas dan reusabilitas data.
Solusi Hologres Dynamic Table dapat menangani transformasi data dan skenario aplikasi sekaligus, sehingga secara signifikan meningkatkan efisiensi pengembangan dan O&M gudang data.
Akselerasi Lakehouse
Data base table untuk Dynamic Table dapat berasal dari tabel Hologres, gudang data seperti MaxCompute, atau data lake seperti OSS dan Paimon. Dengan melakukan refresh penuh atau inkremental pada data base table, Anda dapat memenuhi berbagai kebutuhan kueri dan eksplorasi data dengan tingkat ketepatan waktu berbeda. Skenario yang direkomendasikan meliputi hal-hal berikut:
Kueri laporan periodik
Untuk skenario pengamatan periodik, seperti laporan periodik, jika volume data kecil atau kueri tidak kompleks, Anda dapat menggunakan mode refresh penuh atau inkremental. Refresh secara periodik hasil agregasi dan analisis data lakehouse ke Dynamic Table. Sisi aplikasi kemudian dapat langsung mengkueri Dynamic Table untuk mengambil hasil analisis, sehingga mempercepat kueri laporan.
Dasbor/laporan real-time
Untuk skenario seperti dasbor dan laporan real-time, kebutuhan ketepatan waktu data lebih tinggi. Kami merekomendasikan penggunaan mode incremental refresh. Refresh hasil agregasi dan analisis dari Paimon atau data real-time ke Dynamic Table. Hal ini mempercepat pemrosesan data real-time. Sisi aplikasi dapat langsung mengkueri Dynamic Table untuk mengambil hasil analitik data dan mencapai analisis near-real-time.
Menggantikan penjadwalan offline periodik dan berulang
Dalam skenario pemrosesan offline khas, volume data besar dan siklus komputasi panjang. Untuk meningkatkan ketepatan waktu komputasi, pendekatan umum adalah solusi penjadwalan periodik:
Dari DWD ke DWS hingga ADS, data beberapa hari terakhir diproses secara T+H, misalnya dijadwalkan setiap 30 menit. Untuk memastikan akurasi data, pipeline offline terpisah juga dijalankan secara T+1 untuk memproses data beberapa hari terakhir. Hal ini setara dengan refresh data, yang menghasilkan volume komputasi redundan, pemborosan sumber daya, dan redundansi data. Selain itu, sistem tidak dapat menjamin penyelesaian setiap tugas terjadwal, sehingga dapat menghambat tugas berikutnya, menunda komputasi bisnis, dan gagal memenuhi jaminan ketepatan waktu.
Dengan Hologres, Anda dapat menggunakan incremental refresh T+H untuk setiap lapisan dari DWD ke DWS hingga ADS. Pekerjaan asli dapat digabungkan menjadi satu pekerjaan komputasi inkremental. Anda tidak perlu khawatir tentang rentang kueri data spesifik. Anda hanya perlu mengelola refresh. SQL-nya lebih sederhana, dan Dynamic Table menangani penjadwalan secara otomatis, sehingga menghilangkan kebutuhan untuk memelihara pekerjaan penjadwalan eksternal. Hanya data inkremental yang dihitung setiap kali. Hal ini menghindari komputasi redundan, mempercepat perhitungan, mencegah penumpukan tugas, serta secara signifikan mengurangi penggunaan sumber daya komputasi.
