Kapan harus mempartisi tabel di Azure Databricks

Catatan

Pada tabel Apache Iceberg terkelola, Unity Catalog hanya mendukung pengklusteran cair dan menginterpretasikan partisi yang ditentukan dalam PARTITION BY klausul sebagai kunci pengklusteran untuk pengklusteran cairan.

Databricks merekomendasikan pengklusteran cairan untuk semua tabel Delta baru dan tabel Iceberg terkelola. Lihat Tabel terkelola Unity Catalog di Azure Databricks untuk Delta Lake dan Apache Iceberg dan Gunakan pengklusteran cair untuk tabel.

Kluster cair terkadang juga disebut sebagai "partisi cair". Artikel ini hanya mengacu pada partisi Delta warisan dan bukan pengklusteran cair.

Artikel ini memberikan gambaran umum tentang bagaimana Anda dapat mempartisi tabel di Azure Databricks dan rekomendasi tertentu saat Anda harus menggunakan partisi untuk tabel yang didukung oleh Delta Lake. Karena fitur dan pengoptimalan bawaan, sebagian besar tabel dengan data kurang dari 1 TB tidak memerlukan partisi.

Azure Databricks menggunakan Delta Lake untuk semua tabel secara default. Rekomendasi berikut mengasumsikan Anda bekerja dengan Delta Lake untuk semua tabel.

Di Databricks Runtime 11.3 LTS ke atas, Azure Databricks secara otomatis mengelompokan data dalam tabel yang tidak dipartisi berdasarkan waktu penyerapan. Lihat Menggunakan pengklusteran waktu penyerapan.

Apakah tabel kecil perlu dipartisi?

Databricks menyarankan Anda tidak mempartisi tabel yang berisi kurang dari terabyte data.

Berapa ukuran minimum untuk setiap partisi dalam tabel?

Databricks merekomendasikan semua partisi berisi setidaknya gigabyte 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 dan Databricks Runtime 11.3 LTS atau lebih tinggi, tabel yang tidak dipartisi yang Anda buat secara otomatis mendapat manfaat dari pengklusteran waktu pengambilan data. Waktu penyerapan memberikan manfaat kueri yang sama dengan strategi pemartisian berdasarkan bidang tanggalwaktu tanpa perlu mengoptimalkan atau menyetel data Anda.

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.

Apakah Delta Lake dan Parquet berbagi strategi pemartisian?

Delta Lake menggunakan Parquet sebagai format utama untuk menyimpan data, dan beberapa tabel Delta dengan partisi yang ditentukan menunjukkan organisasi yang mirip dengan tabel Parquet yang disimpan dengan Apache Spark. Apache Spark menggunakan pemartisian gaya Apache Hive saat menyimpan data dalam format Parquet. Pemartisian gaya Hive tidak termasuk dalam protokol Delta Lake, dan beban kerja tidak boleh mengandalkan strategi pemartisian ini untuk penggunaan tabel Delta.

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

Catatan

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

Bagaimana partisi Delta Lake berbeda dari partisi di data lake lainnya?

Sementara Azure Databricks dan Delta Lake dibangun berdasarkan teknologi sumber terbuka seperti Apache Spark, Parquet, Apache Hive, dan Hadoop, motivasi dan strategi partisi yang berguna dalam teknologi ini umumnya tidak berlaku untuk Azure Databricks. Jika Anda memilih untuk mempartisi tabel Anda, pertimbangkan fakta berikut sebelum memilih strategi:

• Transaksi tidak ditentukan oleh batas partisi. Delta Lake memastikan ACID melalui log transaksi, sehingga Anda tidak perlu memisahkan batch data dengan partisi untuk memastikan penemuan atom.
• 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.

Bagaimana urutan Z dan partisi bekerja sama?

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.

Catatan

Sebagian besar tabel dapat memanfaatkan pengklusteran waktu penyerapan untuk menghindari perlunya khawatir tentang urutan Z dan penyetelan partisi.

Aturan berikut penting untuk diingat saat merencanakan strategi pengoptimalan kueri berdasarkan batas partisi dan urutan Z:

• Z-order bekerja bersama dengan 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.

Jika partisi sangat buruk, mengapa beberapa fitur Azure Databricks menggunakannya?

Partisi data bisa bermanfaat, terutama untuk tabel yang sangat besar. Banyak peningkatan kinerja seputar partisi yang difokuskan pada tabel yang sangat besar (ratusan terabyte atau lebih besar).

Banyak pelanggan bermigrasi ke Delta Lake dari data lake berbasis Parquet. Pernyataan ini CONVERT TO DELTA memungkinkan Anda mengonversi tabel berbasis Parquet yang ada ke tabel Delta tanpa menulis ulang data yang ada. Dengan demikian, banyak pelanggan memiliki tabel besar yang mewarisi strategi partisi sebelumnya. Beberapa pengoptimalan yang dikembangkan oleh Databricks berusaha memanfaatkan partisi ini jika memungkinkan, mengurangi beberapa potensi kelemahan untuk strategi partisi yang tidak dioptimalkan untuk Delta Lake.

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

Apakah mungkin untuk mengungguli pengoptimalan bawaan Azure Databricks dengan partisi kustom?

Beberapa pengguna Berpengalaman Apache Spark dan Delta Lake mungkin dapat merancang dan menerapkan pola yang memberikan performa yang lebih baik daripada pengklusteran waktu penyerapan. Menerapkan stategy partisi yang buruk dapat memiliki dampak yang sangat negatif pada performa hilir dan mungkin memerlukan penulisan ulang data penuh untuk diperbaiki. Databricks merekomendasikan agar sebagian besar pengguna menggunakan pengaturan default untuk menghindari terjadinya inefisiensi yang mahal.