Pertimbangan performa titik akhir analitik SQL

Titik akhir analitik SQL memungkinkan Anda mengkueri data di lakehouse dengan menggunakan bahasa T-SQL dan protokol TDS. Mesin ini memanfaatkan mesin Fabric Data Warehouse.

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 berjalan saat endpoint SQL analytics aktif dan berhenti setelah 15 menit tanpa aktivitas kueri.

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 dapat memulai sinkronisasi metadata sesuai permintaan di portal Fabric atau menggunakan REST API untuk menyegarkan metadata endpoint analitik SQL.
  • 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.

V-Order terutama menguntungkan Power BI Direct Lake dan, meskipun dapat meningkatkan kompresi untuk beberapa beban kerja, umumnya tidak diwajibkan atau direkomendasikan secara default untuk kinerja endpoint analitik SQL yang optimal.

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

Tata letak partisi memengaruhi berapa lama endpoint analitik SQL membutuhkan waktu untuk menemukan dan menyinkronkan perubahan. Jumlah partisi yang banyak atau file Parquet kecil meningkatkan beban pemindaian metadata. Ikuti praktik berikut:

  • Hindari kolom partisi dengan kardinalitas tinggi, yang dapat membuat partisi untuk setiap nilai unik. Pilih kolom yang menghasilkan partisi mendekati atau lebih dari 1 GB. Untuk informasi lebih lanjut, lihat pembagian tabel Delta Lake.
  • Pengambilan batch dan streaming dapat membuat file kecil ketika perubahan sering atau kecil. Gunakan pemeliharaan rutin tabel lakehouse untuk memadatkan file ini.

Untuk mengevaluasi ukuran dan jumlah file setiap partisi, gunakan skrip contoh untuk detail partisi.

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']}")

Konten terkait

  • Last updated on