Arsitektur LTAP

Lake Transactional/Analytical Processing (LTAP) adalah arsitektur data yang melayani beban kerja transaksional (OLTP) dan analitik (OLAP) dari lapisan penyimpanan data terpadu di danau, di bawah satu model tata kelola, sehingga Anda tidak perlu menjaga sistem transaksional dan analitik tetap sinkron. Ini menghilangkan pipeline penangkapan data perubahan (CDC), replikasi, dan transformasi yang secara tradisional dikelola tim untuk menyalin data operasional ke dalam sistem analitik terpisah. Azure Databricks membangun LTAP di atas arsitektur penyimpanan Lakebase. Untuk pengumuman tersebut, lihat Databricks meluncurkan LTAP: arsitektur Lake untuk Pemrosesan Transaksional/Analitis pertama.

LTAP adalah sebuah arsitektur, bukan satu fitur tunggal. Azure Databricks menyediakannya melalui serangkaian kapabilitas Lakebase yang secara aktif sedang dikembangkan dan diperluas. Kemampuan yang tersedia untuk Anda bergantung pada cloud Anda. Halaman ini menjelaskan arsitekturnya. Untuk kemampuan yang dapat Anda gunakan hari ini di cloud Anda, lihat Kapabilitas yang mengimplementasikan LTAP.

Important

Sebelum Anda membaca halaman ini, bacalah arsitektur Lakebase untuk memahami arsitektur Lakebase dan komponennya: komputasi Postgres stateless, safekeeper, pageserver, dan penyimpanan objek cloud. LTAP dibangun langsung dari bagaimana Lakebase memisahkan komputasi dari penyimpanan, dan sisa halaman ini mengasumsikan fondasi tersebut.

Biaya menjaga dua tumpukan tetap sinkron

Aplikasi membagi pekerjaan data mereka menjadi dua jenis beban kerja. Beban kerja Transaksional (OLTP) bekerja pada beberapa baris sekaligus dan membutuhkan isi lengkap dari baris tersebut dengan cepat, seperti memproses pembayaran atau mengembalikan hasil API. Beban kerja analitis (OLAP) bertujuan menggali wawasan dari kumpulan data besar, sering kali dengan mengagregasikan dan menggabungkan banyak baris data, misalnya untuk meramalkan penjualan atau mendeteksi penipuan. Pola-pola ini menarik ke arah yang berlawanan: OLTP membutuhkan pembacaan dan penulisan berlatensi rendah secara konstan pada baris individual, sementara OLAP perlu memindai dan mengagregasi data dalam volume besar. Selama beberapa dekade, jawabannya adalah dua sistem terpisah: basis data transaksional untuk aplikasi, dan gudang data atau lakehouse untuk analitik.

Menjembatani kedua tumpukan itu adalah bagian yang mahal. Menjaga sinkronisasi berarti menjalankan penangkapan data perubahan (CDC), pipeline streaming, dan replika baca yang tugasnya hanya menyalin data dari satu sistem ke sistem lain. Infrastruktur itu rapuh, menambah latensi antara saat data ditulis dan saat dapat dianalisis, serta bersaing untuk sumber daya dengan basis data transaksi utama. Seiring aplikasi dan agen AI semakin membutuhkan analitik pada data transaksi terbaru, kesenjangan ini memperlambat tim. Menyalin data antara dua sistem juga menciptakan risiko tata kelola: garis keturunan dapat terputus seiring data bergerak, yang membuat kewajiban seperti permintaan penghapusan GDPR menjadi lebih sulit dipenuhi.

Bagaimana LTAP menyatukan data di lapisan penyimpanan

Alih-alih membangun pipeline yang lebih baik antara dua stack, LTAP menghilangkan kebutuhan akan pipeline sama sekali. Ini dilakukan dengan memikirkan ulang database dari penyimpanan ke atas.

Lakebase sudah memisahkan komputasi Postgres tanpa status dari lapisan penyimpanan yang tahan lama berupa safekeeper, pageserver, dan penyimpanan objek cloud. Sebuah transaksi dikomitkan setelah kuorum safekeeper menyimpan write-ahead log (WAL)-nya secara persisten, dan pageserver kemudian secara asinkron menuliskan perubahan tersebut ke penyimpanan objek awan, sehingga data tidak lagi tersimpan dan terkunci di dalam satu mesin basis data.

Note

Untuk bagaimana Lakebase memisahkan komputasi dan penyimpanan, lihat Arsitektur Lakebase.

LTAP menambahkan satu langkah ke lapisan penyimpanan tersebut. Saat penyimpanan Lakebase mematerialkan data ke penyimpanan objek, sistem ini mentranskode data Postgres yang berorientasi baris ke format kolumnar Parquet saat data masuk ke lake, yang kemudian dapat dibaca melalui format tabel terbuka seperti Delta dan Iceberg. Transcoding inilah yang memungkinkan satu salinan data melayani beban kerja OLTP dan OLAP. Desain ini dibuat agar salinan kolom tetap menjadi representasi setia dan efisien dari versi asli Postgres:

  • Semantik tetap dipertahankan. Penyimpanan Lakebase mentranskode setiap nilai ke dalam bentuk kolomnya sambil mempertahankan representasi Postgres asli, sehingga mesin yang kompatibel dengan Postgres dapat menafsirkan ulang data tanpa kehilangan informasi. Tipe yang tidak dapat dipetakan dengan baik ke Parquet, seperti NaN, NUMERIC overflow, atau tipe ekstensi seperti vector, array, geografi, dan JSON, dipertahankan dalam kolom overflow yang menyimpan representasi Postgres kanonis.
  • Versi baris dipertahankan. Transkode mempertahankan versi baris perantara, sehingga salinan kolumnar menyimpan informasi versi yang sama seperti data baris.
  • Data kolumnar dapat dikompresi dengan baik. Format kolumnar dikompresi secara signifikan, sehingga mengurangi kapasitas penyimpanan yang digunakan dan jumlah data yang dipindahkan ke dan dari penyimpanan objek.

Transcoding berjalan sepenuhnya di lapisan penyimpanan, terisolasi dari instance Postgres utama, sehingga tidak memengaruhi beban kerja layanan transaksional Anda. Ini membangun sesuatu yang sudah dilakukan Lakebase: memindahkan data yang sudah dikomitmenkan ke penyimpanan objek cloud. LTAP hanya menambahkan format kolumnar ke flush yang sama. Tidak ada pipeline yang bisa Anda bangun, dan tidak ada proses eksternal yang melakukan polling pada database Anda.

Lapisan komputasi Lakebase mengalirkan WAL ke lapisan penyimpanan, tempat para safekeeper melakukan commit atasnya dan Lakebase storage mengonversi data Postgres berformat baris menjadi Parquet berformat kolom, yang dapat dibaca menggunakan format tabel terbuka seperti Delta dan Iceberg.

Tidak semuanya ditranskodekan. Indeks Postgres tetap dalam representasi aslinya di lapisan penyimpanan yang tahan lama, bukan diubah menjadi kolom, sehingga pembacaan dan pencarian titik transaksi tetap cepat sementara salinan kolom melayani analitik.

Karena data berada di penyimpanan eksternal yang berversi, membuat cabang atau memulihkan ke titik waktu tertentu adalah operasi metadata, bukan salinan fisik. Anda dapat memecahkan database produksi besar dalam hitungan detik, menjalankan eksperimen atau migrasi berisiko terhadap cabang tersebut, dan membuangnya, tanpa menduplikasi data dasarnya.

Note

Cabang Lakebase adalah klon copy-on-write dari penyimpanan basis data Anda: cabang ini menggunakan bersama data yang sudah ada dari induknya dan hanya menyimpan perubahan, sehingga tidak ada data yang diduplikasi sejak awal. Pemulihan ke titik waktu tertentu menggunakan penyimpanan berversi yang sama untuk mengembalikan database ke titik waktu sebelumnya dalam jangka waktu pemulihannya. Untuk mempelajari lebih lanjut, lihat Cabang basis data dan Pemulihan titik waktu.

Pendekatan tingkat penyimpanan inilah yang membedakan LTAP dari penangkapan data perubahan (CDC). CDC mereplikasi data dari penyimpanan OLTP Anda ke lapisan analitik terpisah menggunakan proses eksternal yang terus-menerus memantau basis data utama secara berkala serta alur pemrosesan yang mengubah perubahan pada baris menjadi data berorientasi kolom. Pipeline itu menghabiskan sumber daya pada basis data transaksional utama Anda, memaksa Anda menangani sendiri perubahan skema dan kasus tepi, serta mengorbankan kesegaran data demi menekan biaya pipeline, sambil menambah titik potensi kegagalan. LTAP menggunakan pendekatan tingkat penyimpanan: Penyimpanan Lakebase mentranskode data ke dalam danau sebagai bagian dari operasi penyimpanan normal, tanpa proses eksternal yang bersaing dengan beban kerja Anda dan tanpa pipeline yang harus Anda bangun atau pelihara.

Tiga pilar LTAP

Menyatukan data di lapisan penyimpanan memberikan LTAP tiga properti utama.

  • Tata kelola universal. Unity Catalog mengatur akses analitis ke satu salinan logis data Anda di kedua beban kerja.
  • Mesin yang dirancang khusus. Postgres melayani transaksi dan Lakehouse melayani analitik, dan keduanya tidak saling mengkompromi.
  • Satu salinan logis dalam penyimpanan terbuka. Kedua mesin membaca satu salinan data Anda dalam format terbuka, tanpa replika atau pipeline yang harus disinkronkan.

Unity Catalog mengelola satu salinan logis data, dengan Lakebase melayani OLTP dari halaman Postgres dan Lakehouse melayani OLAP dari Parquet kolumnar, menggunakan satu salinan di penyimpanan terbuka tanpa replikasi.

Tata kelola universal

Unity Catalog mengatur akses analitis ke data Anda di kedua beban kerja. Setelah Anda mendaftarkan database Lakebase, Unity Catalog menerapkan izin, garis keturunan, dan audit pada komputasi eksternal yang membacanya.

Note

Tata kelola Unity Catalog berlaku saat ini untuk akses analitis : komputasi eksternal, seperti Lakehouse//RT dan Change Data Feed, yang membaca data Lakebase yang terdaftar Anda. Peraturan ini belum mengatur secara langsung tabel Postgres individual. Akses melalui jalur transaksi, artinya aplikasi dan klien yang terhubung ke Postgres, masih dikendalikan oleh hak istimewa standar Postgres (GRANT dan REVOKE), bukan oleh Unity Catalog. Dalam praktiknya, Unity Catalog mengatur akses analitik dan lakehouse, sementara peran dan hak istimewa Postgres mengatur akses transaksional.

Mesin yang dirancang khusus

Postgres melayani beban kerja transaksi Anda dan Lakehouse melayani analitik, masing-masing dengan kekuatan yang menjadi tujuan pembuatannya. Salah paham umum adalah bahwa menyatukan keduanya berarti data operasional Anda menjadi data dingin yang tersimpan di Iceberg. Itu tidak benar. Lakebase tetap menjadi Postgres standar. Pengindeksan, percabangan, pemulihan titik waktu, ekstensi, dan pembacaan serta penulisan titik dengan latensi rendah semuanya tetap berfungsi persis seperti sekarang.

Bacaan analitis tidak bersaing dengan beban kerja transaksional Anda karena terisolasi dari instance Postgres utama. Ketika mesin analitik seperti Lakehouse//RT melakukan query live Lakebase data, ia mengembalikan hasil baru yang konsisten secara transaksional tanpa menyalin data:

  • Mesin membaca sebagian besar data dari salinan kolom di penyimpanan objek, bukan dari Postgres.
  • Untuk mendapatkan tampilan yang konsisten secara transaksional, ia hanya meminta Postgres untuk nomor urut log saat ini (LSN), yaitu satu nilai yang menandai posisi dalam log write-ahead. Ini adalah pencarian metadata murah.
  • Untuk sekumpulan kecil perubahan terbaru yang belum terwujud di danau, ia membacanya dari pageserver dan menggabungkannya di atas.

Postgres tidak melayani lalu lintas baca analitik selain mengembalikan satu LSN itu, dan transcoding berjalan di lapisan penyimpanan, bukan pada instance Postgres yang melayani aplikasi Anda. Beban kerja operasional Anda tetap berjalan sesuai harapan.

Satu salinan logis dalam penyimpanan terbuka

Karena data tersebut tersimpan di lake dalam format Parquet kolumnar, yang dapat dibaca melalui format tabel terbuka seperti Delta dan Iceberg, Lakebase (OLTP) dan Lakehouse (OLAP) memiliki fondasi penyimpanan yang sama. Anda mempertahankan satu salinan logis data di seluruh kedua beban kerja, alih-alih menyelaraskan basis data transaksional dengan salinan analitis yang terpisah.

Setiap engine dapat menyimpan cache atau merepresentasikan data tersebut dalam format fisik yang berbeda untuk performa. Lakebase menggunakan halaman Postgres untuk pembacaan OLTP per titik yang cepat, dan mesin analitik membaca Parquet berformat kolumnar. Anda tetap bekerja dengan satu dataset logis , daripada menyimpan salinan transaksional dan analitis terpisah dan menjaga sinkronisasi.

Setiap tabel memiliki satu penulis, baik Lakebase maupun lakehouse. Kedua mesin membaca salinan logis yang sama, sehingga data yang sama tersedia bagi aplikasi Anda dan untuk analitik tanpa perlu salinan kedua.

Apakah Anda perlu mengubah cara Anda menggunakan Lakebase

No. Mengadopsi kemampuan LTAP tidak memerlukan migrasi data atau perubahan cara aplikasi Anda terhubung ke Lakebase. Lakebase tetap menjadi Postgres standar: ekstensi, indeks, query, dan kode aplikasi yang sudah ada tetap berfungsi tanpa perubahan. Setiap kemampuan LTAP bersifat independen, jadi Anda bisa mengadopsi salah satunya kapan pun dibutuhkan beban kerja.

Kemampuan yang mengimplementasikan LTAP

Anda menerapkan arsitektur LTAP melalui seperangkat kemampuan Lakebase. Masing-masing dibangun di atas fondasi penyimpanan bersama yang dijelaskan di atas, dan bersama-sama mencakup jalur yang diambil data melalui LTAP:

  • Kelola dan daftarkan: bawa data Lakebase ke bawah Unity Catalog.
  • Sajikan data lakehouse di Lakebase: tabel tersinkronisasi, dipercepat dengan LTAP Direct Writes.
  • Cari data Lakebase langsung: Lakehouse//RT untuk analitik, Lakebase Change Data Feed untuk aliran perubahan.

Diagram berikut menunjukkan bagaimana kemampuan ini menulis dan membaca dari satu salinan data Anda, yang diatur oleh Unity Catalog.

Bagaimana data bergerak melalui LTAP: tabel yang disinkronkan dan LTAP Direct Writes memuat data lakehouse ke Lakebase, aplikasi menulis ke dan membaca dari Lakebase secara transaksional, Lakebase mematerialisasikan data menjadi satu salinan dalam penyimpanan terbuka yang diatur oleh Unity Catalog, dan Lakehouse//RT membaca salinan tersebut secara langsung sementara Change Data Feed mengalirkan perubahan tingkat baris data ke tabel dan pipeline Delta.

Lakehouse//RT dan Lakebase Change Data Feed keduanya membaca data dasar yang sama tetapi merepresentasikannya secara berbeda. Lakehouse//RT membaca status terkini data Postgres langsung untuk analitik. Change Data Feed memberikan rangkaian perubahan tingkat baris untuk pipeline dan audit hilir. CDC eksternal yang dihilangkan oleh LTAP juga bukan demikian: keduanya bekerja dengan satu salinan data yang sama.

Tabel berikut mencantumkan setiap kemampuan LTAP dan fungsinya, beserta status rilisnya di cloud Anda. Ketersediaan bervariasi tergantung cloud, jadi kemampuan yang tidak ditawarkan di cloud Anda akan ditandai sebagai tidak tersedia.

Capability Status Description
Daftarkan Lakebase di Unity Catalog GA Kelola akses analitis ke data Lakebase dan jalankan kueri lintas sumber dari lakehouse.
Menyajikan data dengan tabel yang disinkronkan GA Menyajikan data tabel Unity Catalog di Lakebase untuk pembacaan OLTP dengan latensi rendah. LTAP Direct Writes (Beta) mempercepat pemuatan awal di setiap mode sinkronisasi, serta refresh penuh.
Lakehouse//RT mengajukan pertanyaan tentang Lakebase Beta Jalankan kueri OLAP yang konsisten secara transaksional pada data Postgres langsung, tanpa memengaruhi kinerja OLTP Lakebase.
Umpan Data Perubahan Lakebase Pratinjau Umum Simpan perubahan tingkat baris dari tabel Lakebase Postgres sebagai tabel Delta Unity Catalog untuk pipeline dan audit hilir.

Cara mendekati implementasi

Sekarang setelah Anda mengetahui kemampuannya, pertanyaannya adalah mana yang dibutuhkan beban kerja Anda. Anda mengimplementasikan LTAP dengan menggabungkan kemampuan yang sesuai dengan aliran data melalui arsitektur Anda.

Keputusan utamanya adalah arah: untuk setiap dataset, sistem mana yang menjadi pemilik operasi tulis? Setiap tabel memiliki satu penulis, dan itu menentukan kemampuan apa yang Anda gunakan.

  • Lakebase memiliki hak tulis. Aplikasi Anda menulis ke Postgres, dan Anda ingin data operasional itu tersedia untuk analitik tanpa harus menyalinnya. Misalnya, aplikasi penjualan menulis pesanan dan pembayaran ke Lakebase saat proses tersebut terjadi. Gunakan Lakehouse//RT untuk menjalankan dashboard pendapatan langsung pada pesanan tersebut, atau Lakebase Change Data Feed untuk mengalirkan setiap perubahan pesanan ke pipeline atau log audit hilir.
  • Lakehouse memiliki otoritas penulisan. Data Anda dihasilkan atau dipelihara di lakehouse, dan Anda menginginkan pembacaan OLTP berlatensi rendah terhadap data tersebut dari aplikasi Anda. Misalnya, tugas lakehouse yang berjalan setiap malam menghasilkan rekomendasi produk atau tabel harga. Gunakan tabel yang disinkronkan untuk menyajikan data tersebut ke Lakebase sehingga aplikasi Anda dapat membacanya dengan latensi rendah, dan aktifkan LTAP Direct Writes untuk mempercepat beban awal tabel besar.

Petakan setiap dataset ke salah satu arah ini, daftarkan database di Unity Catalog untuk tata kelola, lalu ikuti dokumen kapabilitas untuk mengimplementasikan setiap jalur. Satu aplikasi sering menggunakan kedua arah: menyalurkan data referensi dari lakehouse ke Postgres, sambil mengirimkan kembali data tulis transaksionalnya sendiri ke analitik. Ketersediaan bervariasi tergantung cloud, jadi periksa tabel kemampuan di atas untuk mengonfirmasi apa saja yang ditawarkan di cloud Anda.

Langkah berikutnya

  • Lakebase Change Data Feed: Alirkan perubahan pada tingkat baris ke lakehouse untuk pipeline dan audit. Lihat Lakebase Change Data Feed.

Pelajari lebih lanjut

  • Last updated on