Kapan harus mempartisi tabel di Azure Databricks

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 pengklusteran waktu penyerapan

Dengan menggunakan Delta Lake dan Databricks Runtime 11.3 LTS atau lebih tinggi, tabel yang tidak dipartisi, Anda membuat manfaat secara otomatis dari pengklusteran waktu penyerapan. 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 Anda melakukan sejumlah besar modifikasi menggunakan UPDATE atau MERGE pernyataan pada tabel, Databricks merekomendasikan untuk berjalan OPTIMIZE dengan menggunakan kolom yang cocok dengan ZORDER BY urutan penyerapan. Misalnya, ini bisa berupa kolom yang berisi tanda waktu peristiwa atau tanggal pembuatan.

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 Apache Hive bukan bagian dari protokol Delta Lake, dan beban kerja tidak boleh mengandalkan strategi pemartisian ini untuk berinteraksi dengan 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.

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?

Anda dapat menggunakan indeks pesanan Z bersama 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 OPTIMIZE perintah . 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 bisa bermanfaat, terutama untuk tabel yang sangat besar. Banyak peningkatan performa di sekitar fokus partisi 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 pengenalan inefisiensi yang mahal.