Kapan harus mempartisi tabel di Azure Databricks

Catatan

Databricks merekomendasikan pengklusteran cairan untuk semua tabel terkelola. Untuk tabel terkelola menggunakan Apache Iceberg, Unity Catalog hanya mendukung pengklusteran cairan dan menafsirkan PARTITION BY kolom sebagai kunci pengklusteran. Lihat Mengonversi tabel yang dipartisi menjadi pengklusteran cairan.

Sebagian besar tabel di Azure Databricks dengan kurang dari 100 TB data tidak memerlukan partisi. Azure Databricks menggunakan Delta Lake untuk semua tabel secara bawaan dan secara otomatis mengelompokkan data dalam tabel yang tidak dipartisi berdasarkan waktu ingesti, sehingga Anda memperoleh kinerja setara partisi tanpa penyetelan manual. Pertimbangkan strategi pemartisian kustom hanya jika performanya lebih baik daripada opsi bawaan ini. Lihat Menggunakan pengklusteran waktu penyerapan.

Strategi pemartisian kustom

Pengguna mahir Apache Spark dan Delta Lake mungkin dapat menentukan strategi partisi yang bekerja lebih baik daripada pengelompokan berdasarkan waktu ingesti default.

Warning

Strategi partisi yang tidak efektif mungkin berdampak negatif pada performa kueri dan memerlukan penulisan ulang data penuh untuk diperbaiki. Penulisan ulang penuh mungkin sangat mahal dan lambat untuk tabel besar.

Sebelum menggunakan strategi pemartisian kustom, Databricks merekomendasikan pengklusteran cair untuk semua tabel dan pengoptimalan prediktif untuk tabel terkelola Unity Catalog. Lihat Menggunakan pengklusteran cair untuk tabel dan Pengoptimalan prediktif untuk tabel terkelola Katalog Unity.

Untuk mengubah tabel Delta Lake berpartisi yang sudah ada menjadi klaster cair, gunakan ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Pengklusteran cairan berfungsi untuk kolom kardinalitas rendah dan tinggi dan menghindari batas partisi tetap dan masalah file kecil yang umum dengan partisi statis. Lihat Mengonversi tabel yang dipartisi menjadi pengklusteran cairan.

Jenis data yang didukung untuk kolom partisi

Pemartisian mendukung jenis data ini untuk kolom partisi:

  • Tanggal
  • Timestamp
  • TimestampNTZ
  • Jarak Waktu
  • String
  • Binary
  • Boolean
  • Bilangan bulat, Panjang, Pendek, Byte
  • Float, Double, Desimal

Kolom partisi harus berupa kolom tingkat atas. Anda tidak dapat mempartisi berdasarkan salah satu hal berikut:

  • Jenis kompleks, seperti StructType, MapType, ArrayType, atau VariantType
  • Struktur bidang, seperti struct_col.field. Delta Lake memperlakukan bidang struct dalam PARTITIONED BY sebagai ekspresi daripada referensi kolom.

Untuk menata tabel menurut bidang struct, gunakan pengklusteran cair sebagai gantinya, yang mengenali bidang struct sebagai kunci pengklusteran. Pengklusteran cairan adalah satu-satunya cara untuk melewatkan data pada bidang struct tanpa terlebih dahulu mengekstraknya ke kolom tingkat atas. Lihat Menggunakan pengklusteran cair untuk tabel.

Rekomendasi ukuran minimum

Pemartisian di bawah ukuran minimum ini kemungkinan akan berdampak negatif pada performa kueri daripada meningkatkannya. Pertimbangkan hal berikut saat Anda memutuskan apakah akan mempartisi tabel:

  • Untuk tabel:
    • Dengan kurang dari 1 TB data, jangan partisi.
    • Dengan lebih dari 1 TB hingga 100 TB data, gunakan pengklusteran cair alih-alih partisi. Pemartisian kemungkinan lebih sering berdampak negatif pada kinerja daripada meningkatkannya.
    • Dengan 100 TB atau lebih data, pemartisian dapat meningkatkan performa, tetapi Databricks merekomendasikan penggunaan pengklusteran cair terlebih dahulu dan memverifikasi peningkatan performa.
  • Untuk partisi, verifikasi bahwa setiap partisi berisi setidaknya 1 GB data. Tabel dengan partisi yang lebih sedikit dan lebih besar cenderung mengungguli tabel dengan banyak partisi yang lebih kecil.

Menggunakan pengelompokan waktu pemasukan

Dengan menggunakan Delta Lake, tabel yang tidak dipartisi secara otomatis menggunakan pengklusteran waktu penyerapan. Waktu ingesti memberikan peningkatan performa kueri yang serupa dengan strategi partisi data menggunakan kolom datetime, tanpa perlu mengoptimalkan atau menyetel data Anda secara manual.

Catatan

Untuk mempertahankan pengklusteran waktu penyerapan saat melakukan sejumlah besar modifikasi menggunakan UPDATE atau MERGE pernyataan pada tabel, Databricks merekomendasikan penggunaan pengklusteran cairan pada kolom yang cocok dengan urutan penyerapan, seperti tanda waktu peristiwa atau tanggal pembuatan. Lihat Menggunakan pengklusteran cair untuk tabel.

Kompatibilitas pemartisian Delta Lake dan Parquet

Delta Lake menggunakan Parquet untuk menyimpan data, dan beberapa tabel Delta Lake yang dipartisi memiliki tata letak data yang mirip dengan tabel Parquet yang disimpan dengan Apache Spark. Apache Spark menggunakan pemartisian gaya Apache Hive saat menyimpan data dalam format Parquet. Partisi bergaya Hive bukan bagian dari protokol Delta Lake, dan beban kerja tidak boleh mengandalkan strategi partisi ini saat berinteraksi dengan tabel Delta Lake.

Databricks merekomendasikan agar Anda berinteraksi dengan data yang disimpan di Delta Lake menggunakan klien dan API yang didukung secara resmi. Banyak fitur Delta Lake memutus asumsi tentang tata letak data yang mungkin telah digunakan dengan versi protokol Parquet, Apache Hive, atau bahkan Delta Lake sebelumnya.

Catatan

Saat Anda mengaktifkan pemetaan kolom untuk tabel Delta Lake, awalan acak menggantikan nama kolom di direktori partisi untuk pemartisian bergaya Hive. Lihat mengganti nama dan menghapus kolom dengan menggunakan pemetaan kolom Delta Lake.

Pemartisian Delta Lake dibandingkan dengan data lake lainnya

Teknik partisi yang berguna dalam teknologi sumber terbuka lain (seperti Apache Spark, Parquet, Apache Hive, dan Hadoop) tidak selalu berlaku untuk Azure Databricks. Jika Anda memilih untuk mempartisi tabel Anda, pertimbangkan hal berikut:

  • Transaksi tidak ditentukan oleh batas partisi. Karena Delta Lake memastikan ACID melalui log transaksi, Anda tidak perlu memisahkan batch data dengan partisi untuk menjamin atomitas.
  • Kluster komputasi Azure Databricks tidak memiliki lokalitas data yang terkait dengan media fisik. Data yang diserap ke lakehouse disimpan dalam penyimpanan objek cloud. Saat data di-cache ke penyimpanan disk lokal selama pemrosesan data, Azure Databricks menggunakan statistik berbasis file untuk mengidentifikasi jumlah data minimal untuk pemuatan paralel.

Urutan Z dan partisi

Catatan

Databricks merekomendasikan penggunaan liquid clustering dibandingkan Z-ordering untuk semua tabel baru. Lihat Menggunakan pengklusteran cair untuk tabel.

Anda dapat menggunakan indeks Z-order bersama dengan partisi untuk mempercepat kueri pada himpunan data besar. Sebagian besar tabel menggunakan pengklusteran waktu penyerapan untuk menghindari perlunya menyetel urutan Z dan partisi.

Ingatlah aturan berikut saat Anda merencanakan strategi pengoptimalan kueri berdasarkan batas partisi dan urutan Z:

  • Z-order memerlukan perintah OPTIMIZE. Anda tidak dapat menggabungkan file di seluruh batas partisi, sehingga pengklusteran urutan Z hanya dapat terjadi dalam partisi. Untuk tabel yang tidak dipartisi, file dapat digabungkan di seluruh tabel.
  • Pemartisian hanya berfungsi dengan baik untuk bidang kardinalitas rendah atau dikenal (misalnya, bidang tanggal atau lokasi fisik), tetapi tidak untuk bidang dengan kardinalitas tinggi seperti tanda waktu. Z-order berfungsi untuk semua bidang, termasuk bidang dan bidang kardinalitas tinggi yang dapat tumbuh tanpa batas (misalnya, tanda waktu atau ID pelanggan dalam tabel transaksi atau pesanan).
  • Anda tidak dapat melakukan Z-order pada bidang yang digunakan untuk pemartisian.

Bagaimana Azure Databricks mengoptimalkan sekeliling partisi yang ada

Banyak pelanggan bermigrasi ke Delta Lake dari data lake berbasis Parquet, seperti menggunakan CONVERT TO DELTA pernyataan untuk mengonversi tabel berbasis Parquet yang ada ke tabel Delta Lake tanpa menulis ulang data yang ada. Karena konversi tidak menulis ulang data yang ada, tabel besar mungkin mewarisi strategi partisi sebelumnya.

Beberapa optimasi Databricks menggunakan partisi ini jika memungkinkan, sehingga memitigasi dampak negatif terhadap performa dari strategi pemartisian yang tidak dioptimalkan untuk Delta Lake.

Delta Lake dan Apache Spark adalah teknologi sumber terbuka. Meskipun Databricks memiliki fitur yang mengurangi keandalan pada partisi, komunitas sumber terbuka mungkin membangun fitur baru yang menambah kompleksitas.