Transactions

Penting

Transaksi yang menulis ke tabel Iceberg yang dikelola oleh Unity Catalog ada di Pratinjau Privat. Untuk bergabung dengan pratinjau ini, kirim formulir pendaftaran pratinjau tabel Iceberg terkelola.

Transaksi memungkinkan Anda mengoordinasikan operasi di beberapa pernyataan dan tabel SQL. Semua perubahan berhasil bersama-sama atau digulung balik bersama-sama, memastikan konsistensi data di seluruh operasi dan tabel Anda. Transaksi termasuk properti ACID: atomitas, konsistensi, isolasi, dan durabilitas. Lihat Apa jaminan ACID pada Azure Databricks?.

Transaksi dapat digunakan dengan prosedur tersimpan dan SQL Scripting untuk membangun beban kerja pergudangan misi penting.

Contoh berikut menunjukkan transaksi:

Non-interaktif

BEGIN ATOMIC
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
  INSERT INTO audit_log VALUES (1, 2, 100, current_timestamp());
END;

Interactive

BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
INSERT INTO audit_log VALUES (1, 2, 100, current_timestamp());
COMMIT;

Ketiga pernyataan berkomitmen bersama-sama. Jika ada pernyataan yang gagal, semua perubahan digulung balik dan Databricks mengakhiri transaksi tanpa efek samping.

Untuk praktik langsung dengan transaksi, lihat Tutorial: Mengoordinasikan transaksi di seluruh tabel.

Persyaratan

Untuk menjalankan transaksi yang mencakup beberapa pernyataan atau beberapa tabel:

  • Semua tabel harus ditulis pada:
    • Jadilah tabel terkelola Unity Catalog (Delta Lake atau Iceberg)
    • Telah diaktifkan komit Katalog
  • Gunakan komputasi yang didukung:
    • Untuk transaksi non-interaktif, gunakan gudang SQL, komputasi tanpa server, atau kluster yang menjalankan Databricks Runtime 18.0 ke atas.
    • Untuk transaksi interaktif, gunakan gudang SQL apa pun.
    • Untuk transaksi pada aset bersama OpenSharing, gunakan Databricks Runtime 18.1 ke atas.

Mode transaksi

Azure Databricks mendukung dua mode transaksi:

Modus Sintaksis Melakukan komitmen Rollback Paling cocok untuk
Non-interaktif Pernyataan gabungan ATOMIC Aktif otomatis saat berhasil Otomatis saat terjadi kesalahan Urutan tetap, pekerjaan terjadwal
Interactive MULAI TRANSAKSI; PENERAPAN; Manual Manual Logika kondisional, validasi dan penelusuran kesalahan, JDBC, ODBC, PyODBC

Untuk sintaks, contoh, dan pola penggunaan terperinci untuk kedua mode, lihat Mode transaksi.

Operasi yang Didukung

Anda dapat menggunakan operasi berikut dalam transaksi:

Pengoperasian Deskripsi
SELECT (pilihan lanjutan) Mengkueri data dan memvalidasi hasil
VALUES klausa Hasilkan data pengujian atau nilai konstanta
INSERT (termasuk semua varian) Menambahkan baris baru
UPDATE Mengubah baris yang sudah ada
COPY INTO Memuat data dari file ke dalam tabel Delta
DELETE FROM Menghapus baris
MERGE INTO Pola upsert menggabungkan sisipkan, perbarui, dan hapus
USE CATALOG dan USE SCHEMA Mengatur katalog atau skema saat ini untuk pernyataan dalam transaksi
EXECUTE IMMEDIATE Menjalankan pernyataan SQL yang Anda buat secara dinamis pada run time
DESCRIBE TABLE Mengembalikan metadata tentang tabel, seperti kolom dan propertinya
SHOW COLUMNS Mencantumkan kolom dalam tabel
GET Pernyataan DIAGNOSTIK Mengambil informasi diagnostik, seperti status transaksi aktif atau jumlah baris yang dipengaruhi oleh pernyataan terbaru

Sumber pembacaan dan tujuan penulisan yang didukung

Transaksi memungkinkan Anda membaca data dari tabel Unity Catalog (Delta Lake dan Iceberg), tabel streaming, tampilan, dan tampilan terwujud.

Berkat jaminan ACID, format tabel terbuka seperti Delta Lake dan Iceberg dapat digunakan dalam transaksi, baik sebagai sumber pembacaan maupun target penulisan. Untuk membaca dari sumber non-transaksional, gunakan allow_nontransactional_read petunjuk. Lihat Membaca dari sumber nontransaksional dan Contoh: pembacaan nontransaksional.

Membaca dari sumber non-transaksional

Peringatan

Pembacaan non-transaksional tidak dapat diulang. Perubahan bersamaan pada data sumber selama transaksi dapat mengakibatkan pembacaan yang tidak konsisten.

Transaksi memungkinkan Anda membaca data dari sumber nontransaksional. Sumber nontransaksial mencakup tabel eksternal menggunakan format file Parquet, Avro, CSV, dan JSON, dan tabel federasi menggunakan JDBC. Untuk membaca sumber nontransaksional, rujuk sumber berdasarkan nama dan gunakan petunjuk allow_nontransactional_read.

Dalam transaksi, Anda juga dapat mengkueri information_schema.

Anda dapat membaca file langsung dengan fungsi read_files bernilai tabel.

Akses berbasis jalur tidak didukung. Jika Anda merujuk ke file secara langsung berdasarkan jalurnya sebagai gantinya, seperti FROM parquet.`/path/to/data`, transaksi akan gagal dengan galat PATH_BASED_ACCESS.

Contoh kode berikut menunjukkan cara menggunakan petunjuk pada tabel eksternal menggunakan JSON:

BEGIN TRANSACTION;
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_json_table
WITH (allow_nontransactional_read = true);

COMMIT;

Contoh: pembacaan nontransaksional

Contoh berikut menunjukkan pembacaan nontransaksional dari tabel eksternal menggunakan Parquet. Contoh ini mengharuskan Anda memiliki lokasi eksternal yang sudah ada dengan akses baca dan tulis.

Lihat Menyambungkan ke lokasi eksternal Azure Data Lake Storage Gen2 (ADLS Gen2).

Untuk mendaftarkan sumber Parquet sebagai tabel eksternal bernama, jalankan hal berikut:

CREATE TABLE main.default.external_parquet_table
USING PARQUET
LOCATION 'abfss://my-container@my-storage-account.dfs.core.windows.net/path/to/data'; -- existing external location

Untuk membaca baik sumber Parquet non-transaksional maupun tabel terkelola dalam sebuah transaksi menggunakan Delta Lake, jalankan perintah berikut:

BEGIN ATOMIC
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_parquet_table
WITH (allow_nontransactional_read = true);

-- Managed table source, no hint is required
INSERT INTO another_table
SELECT * FROM managed_delta_table;
END;

Isolasi transaksi

Transaksi memungkinkan pembacaan yang dapat diulang untuk semua pernyataan. Saat Anda mengakses tabel dalam transaksi, Azure Databricks mengambil rekam jepret tabel yang konsisten pada akses pertama. Semua bacaan berikutnya dari tabel tersebut menggunakan rekam jepret ini, sehingga bacaan Anda tetap konsisten meskipun pengguna lain secara bersamaan memodifikasi tabel yang sama.

Dalam contoh berikut, kueri pertama ke products dalam transaksi mengambil snapshot yang konsisten:

Non-interaktif

BEGIN ATOMIC
  SELECT * FROM products WHERE product_id = 1001;
  SELECT * FROM products WHERE product_id = 1001;
END;

Interactive

BEGIN TRANSACTION;
SELECT * FROM products WHERE product_id = 1001;
SELECT * FROM products WHERE product_id = 1001;
COMMIT;

Kemudian, anggap pengguna lain secara simultan memperbarui baris untuk product_id = 1001 sebelum kueri kedua dimulai:

UPDATE products SET price = 29.99 WHERE product_id = 1001;

Karena rekam jepret diambil pada akses pertama, kueri kedua untuk products mengembalikan baris asli, bukan yang diperbarui.

Deteksi konflik dan konkurensi

Azure Databricks menggunakan kontrol konkurensi optimis. Transaksi berlangsung tanpa penguncian, dan konflik terdeteksi pada waktu komit. Saat Anda berkomitmen, Azure Databricks memeriksa apakah transaksi lain memodifikasi data yang sama setelah transaksi Anda dimulai. Jika ada konflik, transaksi Anda gagal. Untuk transaksi non-interaktif, pembatalan juga terjadi secara otomatis. Untuk transaksi interaktif, Anda harus secara eksplisit menjalankan ROLLBACK untuk menghapus status transaksi sebelum memulai transaksi baru.

Transaksi non-interaktif mendukung konkurensi tingkat baris. Dua transaksi dapat mengubah baris yang berbeda dalam file data yang sama tanpa bertentangan saat konkurensi tingkat baris diaktifkan pada tabel target.

Transaksi interaktif mendukung konkurensi tingkat tabel.

Skenario konflik

Skenario Deskripsi
Konflik tulis-tulis Dua transaksi memperbarui atau menghapus baris yang sama.
Konflik baca-tulis Transaksi lain memodifikasi baris yang dibaca oleh transaksi Anda. Hanya berlaku untuk isolasi Serializable.
Konflik baca phantom Transaksi lain menambahkan baris baru yang sesuai dengan kriteria yang dibaca oleh transaksi Anda. Berlaku untuk isolasi WriteSerializable dan Serializable.
Konflik metadata Transaksi lain mengubah skema tabel atau properti.

Untuk detail selengkapnya tentang tingkat isolasi dan resolusi konflik untuk transaksi, lihat Mode transaksi. Untuk informasi tentang tingkat isolasi dan menulis perilaku konflik untuk tabel Delta Lake di Azure Databricks, lihat rekomendasi Optimisasi pada Azure Databricks.

Bagaimana transaksi muncul di log Delta

Setiap transaksi yang berhasil muncul sebagai entri tunggal dalam log Delta tabel, terlepas dari berapa banyak pernyataan individu yang berjalan dalam transaksi. Hal ini memungkinkan jejak audit yang rapi dan menyederhanakan operasi pengembalian.

Operasi individual dalam transaksi tersedia sebagai metadata JSON dalam entri log Delta untuk transaksi.

Penanganan kesalahan dan pengguliran balik

Tabel berikut menjelaskan bagaimana pembatalan kesalahan terjadi untuk kedua jenis transaksi:

Skenario Perilaku untuk transaksi non-interaktif Perilaku untuk transaksi interaktif
Kegagalan pernyataan Pernyataan apa pun yang menimbulkan kesalahan menyebabkan pembatalan otomatis segera. Anda harus menjalankan ROLLBACK secara eksplisit untuk membuang perubahan jika sesi masih aktif.
Logika validasi atau aturan bisnis yang gagal Gunakan SIGNAL untuk melempar pengecualian dan memicu pemutaran kembali otomatis. Jalankan ROLLBACK untuk membuang perubahan.
Pemutusan sambungan sesi Transaksi secara otomatis dibatalkan. Transaksi secara otomatis dibatalkan.
Jeda Waktu Secara otomatis digulung balik setelah total durasi 48 jam. Secara otomatis kembali setelah 10 menit tidak aktif atau total durasi 48 jam (lihat Batasan). Transaksi dihentikan tanpa efek samping, tetapi Anda harus secara eksplisit menjalankan ROLLBACK untuk menghapus status transaksi jika sesi masih aktif.

Untuk transaksi interaktif, Anda dapat secara eksplisit mengembalikan menggunakan pernyataan ROLLBACK . Ini memungkinkan Anda membuang perubahan berdasarkan logika validasi atau aturan bisnis, atau setelah kegagalan pernyataan ketika sesi tetap aktif.

Praktik terbaik

Ikuti praktik ini untuk mengurangi konflik dan mengoptimalkan performa transaksi.

Hindari konflik

  • Jaga agar transaksi tetap pendek: Transaksi jangka panjang meningkatkan kemungkinan konflik dan menahan sumber daya lebih lama.
  • Validasi lebih awal: Periksa prasyarat di awal transaksi agar gagal dengan cepat.
  • Gunakan BEGIN ATOMIC untuk konkurensi tingkat baris: Transaksi non-interaktif (BEGIN ATOMIC ... END;) mendeteksi konflik di tingkat baris, yang mengurangi konflik dibandingkan dengan deteksi tingkat tabel yang digunakan transaksi interaktif. Lihat Transaksi non-interaktif.
  • Bangun logika percobaan ulang: Transaksi dapat gagal kapan saja akibat konflik. Bangun logika coba lagi ke dalam aplikasi Anda dan coba lagi transaksi yang gagal dengan data baru.
  • Mulai setiap sesi interaktif dengan pemutaran kembali: Jalankan ROLLBACK di awal sesi interaktif untuk menghapus status transaksi yang sudah ada sebelumnya.

Menggunakan transaksi dari klien yang berbeda

Transaksi berfungsi di berbagai antarmuka klien:

Keterbatasan

Batasan berikut berlaku untuk transaksi:

Pembatasan Deskripsi
Konflik transaksi interaktif Transaksi interaktif (BEGIN TRANSACTION; ... COMMIT;) menggunakan deteksi konflik yang lebih konservatif daripada transaksi non-interaktif dan dapat berkonflik di tingkat tabel, kecuali untuk INSERT operasi yang tidak membaca dari tabel target. Gunakan transaksi tanpa interaksi (pernyataan gabungan ATOMIC) saat deteksi konflik tingkat baris penting. Lihat Transaksi non-interaktif.
Menetapkan sasaran Anda hanya dapat menulis ke tabel Delta atau Iceberg yang dikelola oleh Unity Catalog yang memiliki fitur tabel catalogManaged yang diaktifkan. Lihat Penerapan katalog.
Operasi DDL tidak didukung Jalankan operasi DDL, seperti CREATE TABLE, , ALTER TABLEatau DROP TABLE, di luar transaksi. Untuk operasi yang didukung transaksi, lihat Operasi yang didukung.
Beberapa operasi metadata tidak didukung Beberapa operasi metadata tidak berfungsi di dalam transaksi terlepas dari protokol. Ini termasuk panggilan metadata berbasis Thrift RPC (seperti metode JDBC DatabaseMetaData dan fungsi katalog ODBC), perintah berbasis SQL yang menghitung objek (seperti SHOW TABLES dan SHOW DATABASES), dan SELECT kueri terhadap tabel sistem. Jalankan operasi metadata ini di luar transaksi.
COPY INTO Keserempakan Transaksi COPY INTO gagal jika perintah lain COPY INTO berjalan bersamaan untuk menulis ke tabel yang sama dan melakukan commit terlebih dahulu.
Konkurensi tingkat baris untuk MERGE Konkurensi tingkat baris untuk operasi MERGE tidak didukung di AWS GovCloud atau pada cluster pengguna tunggal (khusus). Pada platform ini, operasi MERGE menggunakan konkurensi pada tingkat tabel. Lihat Konkurensi tingkat baris.
Batas tabel dan tampilan Transaksi dapat membaca atau menulis hingga 100 tabel, dan dapat membaca hingga 100 tampilan. Setiap tabel dapat memiliki hingga 100 commit menengah dalam satu transaksi.
Perjalanan waktu tidak didukung Anda tidak dapat menggunakan perjalanan waktu dalam transaksi.
Batas waktu jeda Transaksi interaktif kembali setelah 10 menit tidak aktif. Transaksi dihentikan tanpa efek samping, tetapi Anda harus secara eksplisit menjalankan ROLLBACK untuk menghapus status transaksi jika sesi masih aktif.
Silsilah Transaksi menghasilkan riwayat setiap kali baca dan tulis terjadi. Peristiwa silsilah tetap ada meskipun transaksi digulung balik.
Durasi maksimum Semua transaksi secara otomatis dibatalkan setelah total durasi 48 jam. Untuk transaksi interaktif, transaksi dihentikan tanpa efek samping, tetapi Anda harus secara eksplisit menjalankan ROLLBACK untuk menghapus status transaksi jika sesi masih aktif.
Persyaratan tabel yang dibagikan OpenSharing Penyedia OpenSharing harus berbagi tabel WITH HISTORY untuk memungkinkan penerima menjalankan transaksi di dalamnya. Penerima dapat menjalankan transaksi menggunakan semua jenis komputasi.
Batasan komputasi untuk penerima OpenSharing Azure Databricks penerima hanya dapat menjalankan transaksi pada tampilan berbagi, tampilan materialisasi, tabel streaming, dan tabel asing yang bukan format Iceberg. Penerima di akun Azure Databricks yang sama dengan penyedianya harus menggunakan komputasi bersama atau tanpa server. Penerima di akun lain harus menggunakan komputasi tanpa server.
Konflik tabel sumber OpenSharing Penerima OpenSharing tidak dapat mereferensikan tampilan bersama dan tabel bersama yang mereferensikan tabel sumber yang sama dalam satu transaksi.

Sumber daya tambahan

  • Last updated on