Pertimbangan performa titik akhir analitik SQL

Titik akhir analitik SQL memungkinkan Anda mengkueri data di lakehouse dengan menggunakan bahasa T-SQL dan protokol TDS.

Tip

Untuk panduan beban kerja silang yang komprehensif tentang mengoptimalkan tabel Delta untuk konsumsi titik akhir analitik SQL, termasuk ukuran file dan rekomendasi grup baris, lihat Pemeliharaan dan pengoptimalan tabel lintas beban kerja.

Setiap lakehouse memiliki satu titik akhir analitik SQL. Jumlah titik akhir analitik SQL di ruang kerja sesuai dengan jumlah lakehouse dan database cermin yang disediakan di ruang kerja tersebut.

Sebuah proses latar belakang bertanggung jawab untuk memindai lakehouse guna mendeteksi perubahan dan menjaga titik akhir analitik SQL tetap mutakhir untuk semua perubahan yang dikomitkan ke lakehouse dalam ruang kerja. Platform Fabric mengelola proses sinkronisasi secara transparan. Ketika perubahan terdeteksi di lakehouse, proses latar belakang memperbarui metadata dan titik akhir analitik SQL mencerminkan perubahan yang diterapkan pada tabel lakehouse. Dalam kondisi operasi normal, jeda antara lakehouse dan titik akhir analitik SQL kurang dari satu menit. Panjang waktu aktual dapat bervariasi dari beberapa detik hingga menit tergantung pada banyak faktor yang dibahas artikel ini. Proses latar belakang hanya berjalan ketika titik akhir analitik SQL aktif dan berhenti setelah 15 menit tidak aktif.

Guidance

  • Penemuan metadata otomatis melacak perubahan yang diterapkan pada lakehouse, dan merupakan satu instans per ruang kerja Fabric. Jika Anda melihat latensi yang lebih tinggi saat perubahan disinkronkan antara lakehouse dan titik akhir analitik SQL, hal ini dapat disebabkan oleh banyaknya lakehouse dalam satu ruang kerja. Dalam skenario seperti itu, pertimbangkan untuk memigrasikan setiap lakehouse ke ruang kerja yang terpisah karena pendekatan ini memungkinkan penemuan metadata secara otomatis untuk diskalakan.
  • File parket tidak dapat diubah berdasarkan desain. Saat ada operasi pembaruan atau penghapusan, tabel Delta menambahkan file Parquet baru dengan set perubahan, yang meningkatkan jumlah file dari waktu ke waktu, tergantung pada frekuensi pembaruan dan penghapusan. Jika Anda tidak menjadwalkan pemeliharaan, pola ini pada akhirnya menyebabkan overhead pembacaan, dan kondisi ini memengaruhi waktu yang dibutuhkan untuk menyinkronkan perubahan ke endpoint analitik SQL. Untuk mengatasi masalah ini, jadwalkan operasi pemeliharaan tabel lakehouse secara rutin.
  • Dalam beberapa skenario, Anda mungkin mengamati bahwa perubahan yang diterapkan pada lakehouse tidak terlihat pada endpoint analitik SQL yang terkait. Misalnya, Anda mungkin membuat tabel baru di lakehouse, tetapi belum tercantum di titik akhir analitik SQL. Atau, Anda mungkin menerapkan sejumlah besar baris ke tabel di lakehouse tetapi data ini belum terlihat di titik akhir analitik SQL. Anda memiliki opsi untuk memulai sinkronisasi metadata sesuai permintaan.
  • Proses sinkronisasi otomatis tidak mendukung semua fitur Delta. Untuk informasi selengkapnya tentang fungsionalitas yang didukung oleh setiap mesin di Fabric, lihat Interoperabilitas format tabel Delta Lake.
  • Jika ada volume perubahan tabel yang sangat besar selama pemrosesan Extract Transform and Load (ETL), akan terjadi penundaan yang diperkirakan hingga semua perubahan diproses.

Mengoptimalkan tabel lakehouse untuk mengkueri titik akhir analitik SQL

Ketika endpoint analitik SQL membaca tabel yang disimpan di lakehouse, kinerja kueri sangat bergantung pada tata letak fisik file Parquet yang mendasarinya. Mesin ini memparalelkan pemindaian pada level file Parquet. Terlalu banyak file kecil meningkatkan beban file dan metadata, sementara terlalu sedikit file besar dapat membatasi paralelisme pemindaian.

Untuk tabel yang ditulis oleh Spark, gunakan pengaturan default di runtime Fabric Spark 2.0 atau versi lebih baru. Runtime ini memungkinkan ukuran file target adaptif secara default untuk memilih ukuran file target paling optimal berdasarkan tabel, mulai dari 128 MB untuk tabel yang lebih kecil hingga 1 GB untuk tabel terbesar. Hindari menetapkan target statis atau batas jumlah baris sembarang di atas konfigurasi default. Batas baris tidak memperhitungkan lebar baris dan dapat membuat file kecil untuk tabel yang sempit.

Jika Anda menggunakan runtime Fabric Spark 1.3, aktifkan target ukuran file adaptif dan target pemadatan tingkat file, yang tersedia sebagai fitur opsional.

Anda tidak memerlukan V-Order untuk meningkatkan kinerja endpoint analitik SQL karena Spark menulis file Parquet yang dikompresi dengan Snappy untuk mengurangi I/O pembacaan dan penulisan.

Pengaturan tulis default tidak menggantikan pemeliharaan tabel. Gunakan praktik berikut untuk menjaga tata letak yang sehat saat tabel berubah:

  • Aktifkan pemadatan otomatis untuk beban kerja di mana latensi penulisan sinkron yang ditambahkan secara periodik dapat diterima. Pemadatan otomatis adalah fitur Spark yang hanya berjalan ketika terlalu banyak file kecil dalam satu tabel.
  • Jadwalkan pekerjaan berkala OPTIMIZE untuk beban kerja di mana latensi tambahan berkala dari pemadatan otomatis tidak memenuhi SLA pembaruan data.
  • Jalankan VACUUM sesuai dengan kebutuhan retensi dan perjalanan waktu Anda untuk menghapus file yang tidak lagi direferensikan oleh log Delta. VACUUM mengurangi penyimpanan yang tertahan tetapi tidak memperbaiki tata letak file aktif.
  • Hindari partisi dengan kardinalitas tinggi dan konfigurasi penulis yang disesuaikan yang menghasilkan banyak file kecil.

Jika Anda tidak menggunakan auto compaction, untuk mengidentifikasi tabel yang perlu pemeliharaan, gunakan data pipeline dan prosedur tersimpan sys.sp_get_table_health_metrics T-SQL sebelum menjalankan OPTIMIZE. Untuk tutorial, lihat Mengoptimalkan tabel Lakehouse berdasarkan pemeriksaan kesehatan.

Note

Untuk panduan pemeliharaan umum tabel lakehouse, lihat Menjalankan pemeliharaan tabel melalui Lakehouse.

Pertimbangan ukuran partisi

Pilihan kolom partisi untuk tabel Delta di lakehouse juga memengaruhi waktu yang dibutuhkan untuk menyinkronkan perubahan ke endpoint SQL analytics. Jumlah dan ukuran partisi kolom partisi penting untuk performa:

  • Kolom dengan kardinalitas tinggi (sebagian besar atau seluruhnya terbuat dari nilai unik) menghasilkan sejumlah besar partisi. Sejumlah besar partisi berdampak negatif pada performa pemindaian penemuan metadata untuk perubahan. Jika kardinalitas kolom tinggi, pilih kolom lain untuk partisi.
  • Ukuran setiap partisi juga dapat memengaruhi performa. Gunakan kolom yang menghasilkan partisi setidaknya (atau mendekati) 1 GB. Ikuti praktik terbaik untuk pemeliharaan tabel Delta dan pemartisian. Untuk skrip Python guna mengevaluasi partisi, lihat contoh skrip untuk detail partisi.

Jumlah besar file parquet yang berukuran kecil memperpanjang waktu yang diperlukan untuk menyinkronkan perubahan antara lakehouse dan titik akhir analitik SQL yang terkait. Anda mungkin akan memiliki banyak file parquet dalam tabel Delta karena satu atau lebih alasan:

  • Jika Anda memilih partisi untuk tabel Delta dengan jumlah nilai unik yang tinggi, tabel dipartisi oleh setiap nilai unik dan mungkin dipartisi berlebihan. Pilih kolom partisi yang tidak memiliki kardinalitas tinggi, dan menghasilkan partisi individual setidaknya masing-masing 1 GB.
  • Laju pengambilan data batch dan streaming juga dapat mengakibatkan file kecil tergantung pada frekuensi dan ukuran perubahan yang ditulis ke lakehouse. Misalnya, mungkin ada volume kecil perubahan yang masuk ke lakehouse, menghasilkan file parket kecil. Untuk mengatasi masalah ini, terapkan pemeliharaan tabel lakehouse secara teratur.

Contoh skrip untuk detail partisi

Gunakan buku catatan berikut untuk mencetak laporan yang merinci ukuran dan detail partisi yang mendasari tabel Delta.

  1. Pertama, berikan jalur ABFSS untuk tabel Delta Anda di variabel delta_table_path.
    • Anda bisa mendapatkan jalur ABFSS dari tabel delta di portal Fabric Explorer. Klik kanan pada nama tabel, lalu pilih COPY PATH dari daftar opsi.
  2. Skrip mengeluarkan semua partisi untuk tabel Delta.
  3. Skrip berulang melalui setiap partisi untuk menghitung ukuran total dan jumlah file.
  4. Skrip menghasilkan detail partisi, file per partisi, dan ukuran per partisi dalam GB.

Anda dapat menyalin skrip lengkap dari blok kode berikut:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Skema yang dihasilkan secara otomatis di titik akhir analitik SQL Lakehouse

Untuk setiap tabel Delta di Lakehouse Anda, titik akhir analitik SQL secara otomatis menghasilkan tabel dalam skema yang sesuai. Mesin titik akhir analitik SQL didasarkan pada mesin Fabric Data Warehouse.

Untuk informasi selengkapnya, lihat Sinkronisasi metadata titik akhir analitik SQL. Anda juga dapat secara terprogram memaksa refresh pemindaian metadata otomatis dengan menggunakan REST API metadata titik akhir Refresh SQL.

Konten terkait

  • Last updated on