Bagikan melalui

Pertimbangan performa titik akhir analitik SQL

Berlaku untuk:✅ Titik akhir analitik SQL di Microsoft Fabric

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

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

Proses latar belakang bertanggung jawab untuk memindai lakehouse untuk perubahan, dan menjaga titik akhir analitik SQL tetap terbarui untuk semua perubahan yang diterapkan pada lakehouse di ruang kerja. Proses sinkronisasi dikelola secara transparan oleh platform Microsoft Fabric. 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. Durasi waktu aktual dapat bervariasi dari beberapa detik hingga menit tergantung pada banyak faktor yang dibahas dalam artikel ini. Proses latar belakang hanya berjalan ketika titik akhir analitik SQL aktif dan dihentikan setelah 15 menit tidak aktif.

Skema yang dihasilkan secara otomatis di titik akhir analitik SQL Lakehouse

Titik akhir analitik SQL mengelola tabel yang dihasilkan secara otomatis sehingga pengguna ruang kerja tidak dapat memodifikasinya. Pengguna dapat memperkaya model database dengan menambahkan skema, tampilan, prosedur, dan objek database SQL mereka sendiri.

Untuk setiap tabel Delta di Lakehouse Anda, titik akhir analitik SQL secara otomatis menghasilkan tabel dalam skema yang sesuai. Untuk jenis data skema yang dibuat secara otomatis untuk titik akhir analitik SQL, lihat Jenis data di Microsoft Fabric.

Tabel di titik akhir analitik SQL dibuat dengan penundaan kecil. Setelah Anda membuat atau memperbarui tabel Delta Lake di danau, tabel titik akhir analitik SQL yang mereferensikan tabel Delta Lake dibuat/disegarkan secara otomatis.

Jumlah waktu yang diperlukan untuk me-refresh tabel terkait dengan seberapa dioptimalkan tabel Delta. Untuk informasi selengkapnya, tinjau Pengoptimalan tabel Delta Lake dan V-Order untuk mempelajari selengkapnya tentang skenario utama, dan panduan mendalam tentang cara mempertahankan tabel Delta secara efisien untuk performa maksimum.

Anda dapat memaksa refresh pemindaian metadata otomatis secara manual di portal Fabric. Pada halaman untuk titik akhir analitik SQL, pilih tombol Refresh di toolbar Explorer untuk me-refresh skema. Buka Mengkueri titik akhir analitik SQL Anda, dan cari tombol refresh, seperti yang diperlihatkan dalam gambar berikut.

Cuplikan layar dari portal Fabric memperlihatkan tombol skema Refresh titik akhir analitik SQL.

Anda juga dapat memprogram secara otomatis untuk memaksa penyegaran pemindaian metadata menggunakan Refresh SQL endpoint metadata REST API.

Panduan

  • Penemuan metadata otomatis melacak perubahan yang diterapkan pada lakehouse, dan merupakan satu instans per ruang kerja Fabric. Jika Anda mengamati peningkatan latensi untuk perubahan sinkronisasi antara danau data dan titik akhir analitik SQL, itu bisa disebabkan oleh lebih banyak danau data dalam satu ruang kerja. Dalam skenario seperti itu, pertimbangkan untuk memigrasikan setiap lakehouse ke ruang kerja terpisah karena ini memungkinkan penemuan metadata otomatis untuk diskalakan.
  • File parket tidak dapat diubah berdasarkan desain. Ketika ada operasi pembaruan atau penghapusan, tabel Delta akan menambahkan file parket baru dengan set perubahan, meningkatkan jumlah file dari waktu ke waktu, tergantung pada frekuensi pembaruan dan penghapusan. Jika tidak ada pemeliharaan yang dijadwalkan, pada akhirnya, pola ini membuat overhead baca dan ini berdampak pada waktu yang diperlukan untuk menyinkronkan perubahan pada titik akhir analitik SQL. Untuk mengatasi hal ini, jadwalkan operasi pemeliharaan tabel lakehouse reguler.
  • Dalam beberapa skenario, Anda mungkin mengamati bahwa perubahan yang diterapkan pada lakehouse tidak terlihat pada endpoint analitik SQL yang terkait. Misalnya, Anda mungkin telah membuat tabel baru di lakehouse, tetapi belum tercantum di titik akhir analitik SQL. Atau, Anda mungkin telah memasukkan sejumlah besar baris ke tabel pada lakehouse tetapi data ini belum terlihat di endpoint analitik SQL. Kami merekomendasikan untuk memulai sinkronisasi metadata sesuai permintaan, yang dapat dipicu dari opsi pita Refresh pada editor kueri SQL atau REST API metadata titik akhir SQL Refresh. Opsi ini memaksa sinkronisasi metadata sesuai permintaan, daripada menunggu sinkronisasi metadata latar belakang selesai.
  • Tidak semua fitur Delta dipahami oleh proses sinkronisasi otomatis. Untuk informasi selengkapnya tentang fungsionalitas yang didukung oleh setiap mesin di Fabric, lihat Interoperabilitas format tabel Delta Lake.
  • Jika ada perubahan volume tabel yang sangat besar selama pemrosesan Extract Transform and Load (ETL), penundaan yang diharapkan dapat terjadi sampai semua perubahan diproses.

Mengoptimalkan tabel lakehouse untuk mengkueri titik akhir analitik SQL

Ketika titik akhir analitik SQL membaca tabel yang disimpan di lakehouse, performa kueri sangat dipengaruhi oleh tata letak fisik file parquet yang mendasarinya.

Sejumlah besar file parquet kecil menyebabkan overhead dan berdampak negatif pada kinerja kueri. Untuk memastikan kinerja yang dapat diprediksi dan efisien, saran kami adalah pertahankan penyimpanan tabel agar setiap file parket berisi dua juta baris. Jumlah baris ini memberikan tingkat paralelisme yang seimbang tanpa memfragmentasi himpunan data menjadi potongan yang terlalu kecil.

Selain panduan jumlah baris, ukuran file juga sama pentingnya. Titik akhir analitik SQL berkinerja terbaik ketika file Parquet cukup besar untuk meminimalkan overhead penanganan file tetapi tidak terlalu besar hingga membatasi efisiensi pemindaian paralel. Untuk sebagian besar beban kerja, menjaga file parket individual mendekati 400 MB mencapai keseimbangan terbaik. Untuk mencapai saldo ini, gunakan langkah-langkah berikut:

  1. Atur maxRecordsPerFile ke 2.000.000 sebelum perubahan data terjadi.
  2. Lakukan perubahan data Anda (penyerapan data, pembaruan, penghapusan).
  3. Atur maxFileSize ke 400 MB.
  4. Jalankan OPTIMIZE. Untuk detail tentang menggunakan OPTIMIZE, lihat Operasi pemeliharaan tabel.

Skrip berikut menyediakan templat untuk langkah-langkah ini, dan harus dijalankan di lakehouse:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Untuk mempertahankan ukuran file yang sehat, pengguna harus secara berkala menjalankan operasi pengoptimalan Delta seperti OPTIMIZE, terutama untuk tabel yang sering menerima penulisan, pembaruan, dan penghapusan inkremental. Operasi pemeliharaan ini memadatkan file kecil menjadi file berukuran tepat, membantu memastikan titik akhir analitik SQL dapat memproses kueri secara efisien.

Nota

Untuk panduan tentang pemeliharaan umum tabel lakehouse, lihat Menjalankan pemeliharaan tabel ad-hoc pada tabel Delta menggunakan Lakehouse.

Pertimbangan ukuran partisi

Pilihan kolom partisi untuk tabel delta di lakehouse juga memengaruhi waktu yang diperlukan untuk menyinkronkan perubahan ke titik akhir analitik SQL. 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. Rekomendasi kami adalah menggunakan kolom yang akan menghasilkan partisi setidaknya (atau mendekati) 1 GB. Sebaiknya ikuti praktik terbaik untuk pemeliharaan tabel delta; pengoptimalan. Untuk skrip python guna mengevaluasi partisi, lihat Contoh skrip untuk detail partisi.

Volume besar file parket berukuran kecil meningkatkan waktu yang diperlukan untuk menyinkronkan perubahan antara lakehouse dan titik akhir analitik SQL terkait. Anda mungkin berakhir dengan sejumlah besar file parket dalam tabel delta karena satu atau beberapa alasan:

  • Jika Anda memilih partisi untuk tabel delta dengan jumlah nilai unik yang tinggi, itu 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.
  • Tingkat penyerapan 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 hal ini, sebaiknya terapkan pemeliharaan tabel lakehouse reguler.

Contoh skrip untuk detail partisi

Gunakan buku catatan berikut untuk mencetak ukuran detail laporan dan detail partisi yang mendasar tabel delta.

  1. Pertama, Anda harus menyediakan jalur ABSFF untuk tabel delta Anda dalam variabel delta_table_path.
    • Anda bisa mendapatkan jalur ABFSS tabel delta dari Penjelajah portal Fabric. 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.

Skrip lengkap dapat disalin 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