Panduan performa di Fabric Data Warehouse

Berlaku untuk:✅ Gudang di Microsoft Fabric

Artikel ini berisi praktik terbaik untuk penyerapan data, manajemen tabel, persiapan data, statistik, dan kueri di gudang dan titik akhir analitik SQL. Penyetelan performa dan pengoptimalan dapat menghadirkan tantangan unik, tetapi mereka juga menawarkan peluang berharga untuk memaksimalkan kemampuan solusi data Anda.

Petunjuk / Saran

Untuk panduan lintas beban kerja yang komprehensif tentang strategi pengoptimalan tabel Delta, termasuk rekomendasi untuk tabel yang ditulis oleh Spark ataupun yang dicerminkan dan digunakan oleh Fabric Data Warehouse, lihat Cross-workload table maintenance and optimization.

Untuk memantau performa di gudang Anda, lihat Monitor Fabric Data warehouse.

Kinerja kueri

Statistik

Statistik adalah objek bertahan yang mewakili data di kolom tabel Anda. Pengoptimal Kueri menggunakan statistik untuk memilih dan memperkirakan biaya rencana kueri. Fabric Data Warehouse dan lakehouse SQL titik akhir analitik menggunakan dan secara otomatis mempertahankan statistik histogram, statistik rata-rata panjang kolom, dan statistik kardinalitas tabel. Untuk informasi selengkapnya, lihat Statistik di Fabric Data Warehouse.

  • Perintah CREATE STATISTICS dan UPDATE STATISTICS T-SQL didukung untuk statistik histogram kolom tunggal. Anda dapat memanfaatkannya jika ada jendela yang cukup besar antara transformasi tabel dan beban kerja kueri Anda, seperti selama jendela pemeliharaan atau waktu henti lainnya. Ini mengurangi kemungkinan bahwa kueri SELECT Anda harus memperbarui statistik terlebih dahulu.
  • Cobalah untuk menentukan skema tabel yang mempertahankan paritas jenis data dalam perbandingan kolom umum. Misalnya, jika Anda tahu kolom akan sering dibandingkan satu sama lain dalam WHERE klausa, atau digunakan sebagai JOIN ... ON predikat, pastikan jenis data cocok. Jika tidak memungkinkan untuk menggunakan jenis data yang sama persis, gunakan jenis data serupa yang kompatibel untuk konversi implisit. Hindari konversi data eksplisit. Untuk informasi selengkapnya, lihat Konversi jenis data.

Petunjuk / Saran

Untuk pengguna Lakehouse, statistik ACE-Cardinality dapat menggunakan informasi dari file log Delta tabel Anda agar lebih akurat. Pastikan tabel Delta yang dihasilkan Spark Anda menyertakan jumlah baris tabel dengan: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Untuk informasi selengkapnya, lihat Mengonfigurasi dan mengelola Statistik Tabel Otomatis di Fabric Spark.

Saat memfilter tabel lakehouse berdasarkan kolom tanda waktu sebelum runtime Apache Spark 3.5.0, statistik tingkat kelompok baris untuk kolom tanda waktu tidak dihasilkan. Kurangnya statistik ini menyulitkan sistem, seperti Fabric Warehouse, untuk menerapkan eliminasi grup baris (juga dikenal sebagai data skipping atau predikat pushdown), yaitu pengoptimalan performa yang melewati grup baris yang tidak relevan selama eksekusi kueri. Tanpa statistik ini, pemfilteran kueri yang melibatkan kolom tanda waktu mungkin perlu memindai lebih banyak data, yang menyebabkan penurunan performa yang signifikan. Anda dapat meningkatkan runtime Apache Spark di Fabric. Apache Spark 3.5.0 dan versi yang lebih tinggi dapat menghasilkan statistik tingkat grup baris untuk kolom tanda waktu. Anda kemudian perlu membuat ulang tabel dan memasukkan data agar statistik di tingkat grup baris dapat dibuat.

Performa cache dingin

Eksekusi pertama kueri di Fabric Data Warehouse bisa lebih lambat secara tidak terduga dibandingkan dengan eksekusi berikutnya. Ini dikenal sebagai awal dingin, disebabkan oleh inisialisasi sistem atau aktivitas penskalaan yang mempersiapkan lingkungan untuk diproses.

Cold start biasanya terjadi ketika:

  • Data dimuat dari OneLake ke dalam memori karena sedang diakses untuk pertama kalinya, dan belum di-cache.
  • Jika data diakses untuk pertama kalinya, eksekusi kueri ditunda hingga statistik yang diperlukan dibuat secara otomatis.
  • Fabric Data Warehouse secara otomatis menjeda node setelah periode tertentu tidak aktif untuk mengurangi biaya, dan menambahkan node sebagai bagian dari penskalaan otomatis. Meneruskan atau membuat simpul biasanya membutuhkan waktu kurang dari satu detik.

Operasi ini dapat meningkatkan durasi kueri. Awal dingin bisa parsial. Beberapa simpul komputasi, data, atau statistik mungkin sudah tersedia atau di-cache dalam memori, sementara kueri menunggu yang lain tersedia.

Caching in-memory dan disk di Fabric Data Warehouse sepenuhnya transparan dan diaktifkan secara otomatis. Caching secara cerdas meminimalkan kebutuhan membaca penyimpanan jarak jauh dengan memanfaatkan cache lokal. Fabric Data Warehouse menggunakan pola access yang disempurnakan untuk meningkatkan pembacaan data dari storage dan meningkatkan kecepatan eksekusi kueri. Untuk informasi selengkapnya, lihat Cache dalam pergudangan data Fabric.

Anda dapat mendeteksi efek cold start yang disebabkan oleh mengambil data dari storage jarak jauh ke dalam memori dengan mengkueri tampilan queryinsights.exec_requests_history. Periksa kolom data_scanned_remote_storage_mb:

  • Nilai bukan nol dalam data_scanned_remote_storage_mb menunjukkan awal dingin. Data diambil dari OneLake selama pelaksanaan kueri. Tampilan berikutnya harus dapat dibuktikan lebih cepat di queryinsights.exec_requests_history.
  • Nilai nol dalam data_scanned_remote_storage_mb adalah status sempurna di mana semua data di-cache. Tidak ada perubahan node atau data dari OneLake yang diperlukan untuk melayani hasil kueri.

Penting

Jangan menilai performa kueri berdasarkan eksekusi pertama . Selalu periksa data_scanned_remote_storage_mb untuk menentukan apakah kueri terpengaruh oleh cold start. Eksekusi berikutnya sering kali jauh lebih cepat dan mewakili performa aktual, yang akan menurunkan waktu eksekusi rata-rata.

Kueri pada tabel dengan kolom string

Gunakan panjang kolom string terkecil yang dapat mengakomodasi nilai. Fabric Warehouse terus membaik; namun, Anda mungkin mengalami performa suboptimal jika menggunakan jenis data string besar, terutama objek besar (LOB). Misalnya, untuk customer_name jenis data kolom, pertimbangkan persyaratan bisnis dan data yang diharapkan, dan gunakan panjang n yang sesuai saat mendeklarasikan varchar(n), seperti varchar(100), alih-alih varchar(8000) atau varchar(maks). Statistik dan estimasi biaya kueri lebih akurat ketika rentang tipe data lebih sesuai dengan data aktual.

  • Di Fabric Data Warehouse T-SQL, lihat guidance untuk memilih panjang yang sesuai untuk jenis data string.
  • Kolom string tabel Lakehouse tanpa panjang yang ditentukan dalam Spark dikenali oleh Fabric Warehouse sebagai varchar(8000). Untuk performa optimal, gunakan CREATE TABLE pernyataan di SparkSQL untuk menentukan kolom string sebagai varchar(n), di mana n panjang kolom maksimum yang dapat mengakomodasi nilai.

Transaksi dan konkurensi

Fabric Data Warehouse dibangun di atas arsitektur modern cloud-native yang menggabungkan integritas transaksional, isolasi rekam jepret, dan komputasi terdistribusi untuk memberikan konkurensi dan konsistensi tinggi dalam skala besar. Untuk informasi selengkapnya, lihat Transaksi di Tabel Gudang.

Fabric Data Warehouse mendukung transaksi yang mematuhi ACID menggunakan isolasi snapshot. Ini berarti:

  • Operasi baca dan tulis dapat dikelompokkan ke dalam satu transaksi menggunakan T-SQL standar (BEGIN TRANSACTION, COMMIT, ROLLBACK)
  • Semantik semua atau tidak sama sekali: Jika transaksi mencakup beberapa tabel dan satu operasi gagal, seluruh transaksi digulung balik.
  • Konsistensi baca: SELECT kueri dalam transaksi melihat cuplikan data yang konsisten, tidak terpengaruh oleh penulisan bersamaan.

Dukungan transaksi Fabric Warehouse:

  • Data Definition Language (DDL) di dalam transaksi: Anda dapat menyertakan CREATE TABLE dalam blok transaksi.
  • Transaksi lintas database: Didukung dalam area kerja yang sama, termasuk pembacaan dari titik akhir analitik SQL.
  • Perulangan berbasisParquet: Karena Fabric Data Warehouse menyimpan data dalam file Parquet yang tidak dapat diubah, pembatalan dilakukan dengan cepat. Putar kembali hanya kembali ke versi file sebelumnya.
  • Pengompakan dan checkpointing data otomatis:Pengompakan data mengoptimalkan penyimpanan dan kinerja baca dengan menggabungkan file Parquet kecil dan menghapus baris yang dihapus secara logis.
  • Titik pemeriksaan otomatis: Setiap operasi tulis (INSERT, UPDATE, ) DELETEmenambahkan file log JSON baru ke log transaksi Delta Lake. Seiring waktu, ini dapat mengakibatkan ratusan atau ribuan file log, terutama dalam skenario streaming atau penyerapan frekuensi tinggi. Titik pemeriksaan otomatis meningkatkan efisiensi baca metadata dengan meringkas log transaksi ke dalam satu file titik pemeriksaan. Tanpa titik pemeriksaan, setiap pembacaan harus memindai seluruh log transaksi. Dengan titik pemeriksaan, satu-satunya log yang dibaca adalah file titik pemeriksaan terbaru dan log setelahnya. Ini secara drastis mengurangi penguraian I/O dan metadata, terutama untuk tabel besar atau yang sering diperbarui.

Pemadatan dan titik pemeriksaan sangat penting untuk kesehatan tabel, terutama di lingkungan jangka panjang atau konkurensi tinggi.

Kontrol dan isolasi konkurensi

Fabric Data Warehouse menggunakan isolasi rekam jepret secara eksklusif. Upaya untuk mengubah tingkat isolasi melalui T-SQL diabaikan.

Praktik terbaik dengan transaksi

  • Gunakan transaksi eksplisit dengan bijak. Selalu COMMIT atau ROLLBACK. Jangan biarkan transaksi terbuka.
    • Jaga agar transaksi tetap berlangsung singkat. Hindari transaksi jangka panjang yang mempertahankan kunci secara tidak perlu, terutama untuk transaksi eksplisit yang berisi DDL. Ini dapat menyebabkan perselisihan dengan SELECT pernyataan pada tampilan katalog sistem (seperti sys.tables) dan dapat menyebabkan masalah pada portal Fabric yang bergantung pada tampilan katalog sistem.
  • Tambahkan logika coba ulang dengan penundaan dalam pipelines atau aplikasi untuk menangani konflik sementara.
    • Gunakan penurunan eksponensial untuk menghindari lonjakan percobaan ulang yang dapat memperburuk gangguan jaringan sementara.
    • Untuk informasi selengkapnya, lihat pola Retry.
  • Pantau kunci dan konflik di gudang.

Mengurangi ukuran himpunan data yang dikembalikan

Kueri dengan ukuran data besar dalam eksekusi kueri menengah atau dalam hasil kueri akhir dapat mengalami lebih banyak masalah performa kueri. Untuk mengurangi ukuran himpunan data yang dikembalikan, pertimbangkan strategi berikut:

  • Partisi atau klusterisasi tabel besar (Liquid Clustering) di Lakehouse.
  • Batasi jumlah kolom yang dikembalikan. SELECT * bisa mahal.
  • Batasi jumlah baris yang dikembalikan. Lakukan pemfilteran data sebanyak mungkin di gudang, bukan di aplikasi klien.
    • Cobalah untuk memfilter sebelum bergabung untuk mengurangi himpunan data di awal eksekusi kueri.
    • Filter pada kolom ber-kardinalitas rendah untuk mengurangi himpunan data besar pada tahap awal sebelum operasi JOIN.
    • Kolom dengan kardinalitas tinggi sangat ideal untuk pemfilteran dan JOIN. Ini sering digunakan dalam WHERE klausul dan mendapat manfaat dari predikat yang diterapkan pada tahap sebelumnya dalam eksekusi kueri untuk memfilter data.
  • Di Fabric Data Warehouse, karena batasan kunci primer dan kunci unik tidak diberlakukan, kolom dengan batasan ini belum tentu merupakan kandidat yang baik untuk operasi JOIN.

Rencana kueri dan petunjuk kueri

Di Fabric Data Warehouse, pengoptimal kueri menghasilkan rencana eksekusi kueri untuk menentukan cara paling efisien untuk menjalankan kueri SQL. Pengguna tingkat lanjut dapat mempertimbangkan untuk menyelidiki masalah performa kueri dengan rencana kueri atau dengan menambahkan petunjuk kueri.

  • Pengguna dapat menggunakan SHOWPLAN_XML di SQL Server Management Studio untuk menampilkan paket tanpa menjalankan kueri.
  • Petunjuk kueri opsional dapat ditambahkan ke pernyataan SQL untuk memberikan instruksi lebih lanjut kepada pengoptimal kueri sebelum pembuatan rencana. Menambahkan petunjuk kueri memerlukan pengetahuan tingkat lanjut tentang beban kerja kueri, oleh karena itu biasanya digunakan setelah praktik terbaik lainnya diterapkan tetapi masalah berlanjut.

Operasi yang tidak dapat diskalakan

Fabric Data Warehouse dibangun di atas arsitektur pemrosesan paralel (MPP) besar-besaran, di mana kueri dijalankan di beberapa simpul komputasi. Dalam beberapa skenario, eksekusi node tunggal dibenarkan:

  • Seluruh eksekusi rencana kueri hanya memerlukan satu simpul komputasi.
  • Subtree rencana dapat ditempatkan dalam satu simpul komputasi.
  • Seluruh kueri atau bagian kueri harus dijalankan pada satu simpul untuk memenuhi semantik kueri. Misalnya, TOP operasi, pengurutan global, kueri yang memerlukan pengurutan hasil dari eksekusi paralel untuk menghasilkan satu hasil, atau menggabungkan hasil untuk langkah terakhir.

Dalam kasus ini, pengguna dapat menerima pesan peringatan "Satu atau beberapa operasi yang tidak dapat diskalakan terdeteksi", dan kueri mungkin berjalan lambat atau gagal setelah eksekusi panjang.

  • Pertimbangkan untuk mengurangi ukuran himpunan data kueri yang difilter.
  • Jika semantik kueri tidak memerlukan eksekusi node tunggal, coba paksa rencana kueri terdistribusi dengan FORCE DISTRIBUTED PLAN, misalnya OPTION (FORCE DISTRIBUTED PLAN);.

Mengkueri titik akhir analitik SQL

Anda dapat menggunakan titik akhir analitik SQL untuk mengkueri tabel Lakehouse yang diisi dengan Spark SQL, tanpa menyalin atau menyerap data ke dalam Gudang.

Praktik terbaik berikut berlaku untuk mengkueri data gudang di Lakehouse melalui titik akhir analitik SQL. Untuk informasi selengkapnya tentang performa titik akhir analitik SQL, lihat Pertimbangan performa titik akhir analitik SQL.

Petunjuk / Saran

Praktik terbaik berikut berlaku untuk menggunakan Spark untuk memproses data ke lakehouse yang dapat dikueri oleh titik akhir analitik SQL.

Melakukan pemeliharaan tabel reguler untuk tabel Lakehouse

Dalam Microsoft Fabric, Gudang secara otomatis mengoptimalkan tata letak data, dan melakukan pengumpulan dan pemadatan sampah. Untuk Lakehouse, Anda memiliki lebih banyak kontrol atas pemeliharaan tabel. Pengoptimalan dan vakum tabel diperlukan dan dapat secara signifikan mengurangi waktu pemindaian yang diperlukan untuk himpunan data besar. Pemeliharaan tabel di Lakehouse juga meliputi pintasan dan dapat membantu Anda meningkatkan performa dalam konteks tersebut secara signifikan.

Mengoptimalkan tabel atau pintasan lakehouse dengan banyak file kecil

Memiliki banyak file kecil menciptakan beban lebih untuk memproses metadata file. Gunakan perintah OPTIMIZE di portal Fabric atau Notebook untuk menggabungkan file kecil menjadi file yang lebih besar. Ulangi proses ini ketika jumlah file berubah secara signifikan.

Untuk mengoptimalkan tabel di Fabric Lakehouse, buka Lakehouse di portal Fabric. Di Explorer, klik kanan pada tabel, pilih Pemeliharaan. Pilih opsi dari halaman Jalankan perintah pemeliharaan , lalu pilih Jalankan sekarang.

Mengkueri tabel atau pintasan lakehouse yang terletak di wilayah yang sama

Fabric menggunakan komputasi di lokasi di mana kapasitas Fabric berada. Mengambil data, seperti dari Azure Data Lake Storage Anda sendiri atau dari OneLake, di wilayah lain dapat menyebabkan penurunan kinerja karena latensi jaringan. Pastikan data berada di wilayah yang sama. Bergantung pada persyaratan performa Anda, pertimbangkan untuk hanya menyimpan tabel kecil seperti tabel dimensi di wilayah terpencil.

Memfilter tabel dan pintasan lakehouse pada kolom yang sama

Jika Anda sering memfilter baris tabel pada kolom tertentu, pertimbangkan untuk mempartisi tabel.

Pemartisian berfungsi dengan baik untuk kolom dengan kardinalitas rendah atau kardinalitas yang dapat diprediksi seperti tahun atau tanggal. Untuk informasi selengkapnya, lihat Tutorial Lakehouse - Menyiapkan dan mengubah data lakehouse dan Memuat data ke Lakehouse menggunakan partisi.

Pengklusteran berfungsi dengan baik untuk kolom selektivitas tinggi. Jika Anda memiliki kolom lain yang sering Anda gunakan untuk pemfilteran, selain mempartisi kolom, pertimbangkan untuk mengklusterkan tabel menggunakan optimalkan dengan sintaks ZORDER BYSpark SQL . Untuk informasi selengkapnya, lihat Pengoptimalan tabel Delta Lake.

Pengklusteran data

Anda juga dapat menyelesaikan pengklusteran data pada kolom tertentu dalam CREATE TABLE pernyataan T-SQL dan CREATE TABLE AS SELECT (CTAS). Pengklusteran data bekerja dengan menyimpan baris dengan nilai serupa di lokasi yang berdekatan pada storage selama penyerapan.

  • Pengklusteran data menggunakan kurva pengisian ruang untuk menata data dengan cara yang mempertahankan lokalitas di beberapa dimensi, yang berarti baris dengan nilai serupa di seluruh kolom pengklusteran disimpan secara fisik berdekatan. Pendekatan ini secara dramatis meningkatkan performa kueri dengan melakukan lompati file dan mengurangi jumlah file yang dipindai.
  • Metadata pengklusteran data disematkan dalam manifes selama proses penyerapan, memungkinkan mesin gudang data membuat keputusan cerdas tentang file mana yang akan diakses selama kueri pengguna. Metadata ini, dikombinasikan dengan bagaimana baris dengan nilai serupa disimpan bersama-sama, memastikan bahwa kueri dengan predikat filter dapat melewati seluruh file dan grup baris yang berada di luar cakupan predikat.

Misalnya: jika kueri hanya menargetkan 10% data tabel, pengklusteran memastikan bahwa hanya file yang berisi data dalam rentang filter yang dipindai, mengurangi I/O dan konsumsi komputasi. Tabel yang lebih besar mendapatkan lebih banyak manfaat dari pengklusteran data, karena manfaat dari file skipping meningkat seiring dengan volume data.

Pengoptimalan jenis data

Memilih jenis data yang tepat sangat penting untuk performa dan efisiensi storage di gudang Anda. Panduan berikut membantu memastikan desain skema Anda mendukung kueri cepat, storage yang efisien, dan keberlanjutan.

Untuk informasi selengkapnya tentang jenis data yang didukung oleh Fabric Data Warehouse, lihat jenis Data di Fabric Data Warehouse.

Petunjuk / Saran

Jika Anda menggunakan alat eksternal untuk menghasilkan tabel atau kueri, seperti dengan metodologi penyebaran kode-pertama, tinjau jenis data kolom dengan hati-hati. Jenis data karakter dan panjang kueri harus mengikuti praktik terbaik ini.

Mencocokkan jenis data dengan semantik data

Untuk memastikan kejernihan dan kinerja, penting untuk menyelaraskan jenis data setiap kolom dengan karakteristik dan perilaku data yang sebenarnya disimpan.

  • Gunakan tanggal, waktu, atau datetime2(n) untuk nilai temporal alih-alih menyimpannya sebagai string.
  • Gunakan jenis bilangan bulat untuk nilai numerik, kecuali pemformatan (misalnya, nol di depan) diperlukan.
  • Gunakan jenis karakter (karakter, varchar) saat mempertahankan pemformatan sangat penting (misalnya, angka yang dapat dimulai dengan nol, kode produk, angka dengan tanda hubung).

Gunakan tipe bilangan bulat untuk angka bulat

Saat menyimpan nilai seperti pengidentifikasi, penghitung, atau bilangan bulat lainnya, lebih memilih jenis bilangan bulat (smallint, int, bigint) daripadanumerik/. Jenis bilangan bulat memerlukan lebih sedikit storage daripada jenis data yang memungkinkan digit di sebelah kanan titik desimal. Akibatnya, operasi tersebut memungkinkan operasi aritmatika dan perbandingan yang lebih cepat dan meningkatkan pengindeksan dan performa kueri.

Ketahui rentang nilai untuk setiap jenis data bilangan bulat yang didukung oleh Fabric Data Warehouse. Untuk informasi selengkapnya, int, bigint, smallint (Transact-SQL).

Pertimbangkan penggunaan presisi dan skala desimal dan numerik

Jika Anda harus menggunakannumerik/, saat membuat kolom, pilih presisi dan skala terkecil yang dapat mengakomodasi data Anda. Kelebihan penetapan yang berlebihan meningkatkan persyaratan penyimpanan dan dapat menurunkan kinerja saat data bertambah.

  • Perkirakan pertumbuhan dan kebutuhan yang diharapkan dari gudang Anda. Misalnya, jika Anda berencana untuk menyimpan tidak lebih dari empat digit di sebelah kanan titik desimal, gunakan decimal(9,4) atau decimal(19,4) untuk storage yang paling efisien.
  • Selalu tentukan presisi dan skala saat membuat kolomnumerik/. Saat dibuat dalam tabel yang didefinisikan sebagai hanya decimal, tanpa menentukan (p,s)presisi dan skala, kolom desimal/ dibuat sebagai decimal(18,0). desimal dengan presisi 18 digit memerlukan 9 byte penyimpanan per baris. Skala 0 tidak menyimpan data di sebelah kanan titik desimal. Untuk banyak bilangan bulat bisnis, smallint, int, bigint jauh lebih efisien daripada decimal(18,0). Misalnya, bilangan bulat sembilan digit apa pun dapat disimpan sebagai bilangan bulat untuk 4 byte penyimpanan per baris.

Untuk informasi lengkap, lihat desimal dan numerik (Transact-SQL).

Pertimbangkan kapan harus menggunakan varchar ketimbang char

Gunakan varchar(n) alih-alih char(n) untuk kolom string, kecuali jika padding panjang tetap diperlukan secara eksplisit. Kolom varchar hanya menyimpan panjang string aktual per baris, ditambah overhead kecil, sehingga mengurangi ruang yang terbuang dan meningkatkan efisiensi I/O.

  • Gunakan varchar(n) untuk nilai seperti nama, alamat, dan deskripsi, karena memiliki nilai variabel yang luas. Statistik dan estimasi biaya kueri lebih akurat ketika rentang tipe data lebih sesuai dengan data aktual.
  • Gunakan char(n) ketika Anda tahu string akan menjadi panjang tetap setiap kali. Misalnya, menyimpan string 000000000 sebagai karakter(9) masuk akal jika string selalu tepat 9 karakter numerik yang dapat dimulai dengan nol.
  • Panjang n dalam deklarasi jenis data kolom adalah byte storage. Untuk kumpulan karakter pengodean multibyte seperti UTF-8, pengodean untuk Fabric Data Warehouse, karakter Latin, dan angka memerlukan 1 byte penyimpanan. Namun, ada karakter Unicode yang membutuhkan lebih dari 1 byte, seperti karakter Jepang yang memerlukan 3 byte untuk disimpan, sehingga jumlah karakter Unicode yang benar-benar disimpan bisa kurang dari panjang njenis data . Untuk informasi selengkapnya, lihat Argumen char dan varchar.

Hindari kolom nullable jika memungkinkan

Tentukan kolom seperti NOT NULL saat model data memungkinkan. Secara bawaan, kolom dalam tabel mengizinkan nilai NULL. Kolom yang dapat diubah ke null memiliki karakteristik berikut:

  • Mereka menambahkan beban metadata.
  • Dapat mengurangi efektivitas pengoptimalan kueri dan statistik.
  • Dapat memengaruhi performa dalam kueri analitik skala besar.

Penyerapan dan persiapan data ke dalam gudang

SALIN KE

Perintah T-SQL COPY INTO adalah cara yang disarankan untuk menyerap data dari Azure Data Lake Storage ke Data Warehouse Fabric. Untuk informasi dan contoh selengkapnya, lihat Memasukkan data ke gudang data Anda menggunakan perintah COPY.

Pertimbangkan rekomendasi berikut untuk performa terbaik:

  • Ukuran file: Pastikan bahwa setiap file yang Anda serap idealnya antara 100 MB dan 1 GB untuk throughput yang dimaksimalkan. Ini membantu mengoptimalkan proses penyerapan dan meningkatkan performa.
  • Jumlah file: Untuk memaksimalkan paralelisme dan performa kueri, bertujuan untuk menghasilkan sejumlah besar file. Prioritaskan pembuatan file sebanyak mungkin sambil mempertahankan ukuran file minimum 100 MB.
  • Pemuatan paralel: Gunakan beberapa COPY INTO pernyataan yang berjalan secara paralel untuk memuat data ke dalam tabel yang berbeda. Pendekatan ini dapat secara signifikan mengurangi jendela ETL/ELT karena paralelisme.
  • Ukuran kapasitas: Untuk volume data yang lebih besar, pertimbangkan untuk memperluas skala ke Kapasitas Fabric yang lebih besar untuk mendapatkan sumber daya komputasi tambahan yang diperlukan untuk mengakomodasi jumlah pemrosesan paralel tambahan dan volume data yang lebih besar.

Fabric Data Warehouse juga mendukung pernyataan BULK INSERT yang merupakan sinonim untuk COPY INTO. Rekomendasi yang sama berlaku untuk BULK INSERT pernyataan.

CTAS atau INSERT

Gunakan CREATE TABLE AS SELECT (CTAS) atau INSERT dikombinasikan dengan perintah pintasan/shortcut tabel SELECT FROM Lakehouse. Metode ini bisa lebih berkinerja dan efisien daripada menggunakan pipelines, memungkinkan transfer data yang lebih cepat dan lebih andal. Untuk informasi dan contoh selengkapnya, lihat Menyerap data ke gudang Anda menggunakan Transact-SQL.

Konsep peningkatan jumlah paralelisme dan penskalaan ke kapasitas Fabric yang lebih besar juga berlaku untuk operasi CTAS/INSERT guna meningkatkan throughput.

Membaca data dari Azure Data Lake Storage atau Blob Storage dengan OPENROWSET

Fungsi OPENROWSET memungkinkan Anda membaca file CSV atau Parquet dari Azure Data Lake atau Azure Blob storage, tanpa menyerapnya ke Gudang. Untuk informasi dan contoh selengkapnya, lihat Menelusuri konten file menggunakan fungsi OPENROWSET.

Untuk informasi dan contoh selengkapnya tentang mengkueri data eksternal, lihat Kueri file data lake eksternal dengan menggunakan fabric Data Warehouse atau titik akhir analitik SQL.

Saat membaca data menggunakan fungsi OPENROWSET, pertimbangkan rekomendasi berikut untuk performa terbaik:

  • Parket: Cobalah untuk menggunakan Parquet alih-alih CSV, atau konversi CSV ke Parquet, jika Anda sering mengkueri file. Parquet adalah format kolom. Karena data dikompresi, ukuran filenya lebih kecil dari file CSV yang berisi data yang sama. Fabric Data Warehouse melewati kolom dan baris yang tidak diperlukan dalam kueri jika Anda membaca file Parquet.
  • Ukuran file: Pastikan bahwa setiap file yang Anda serap idealnya antara 100 MB dan 1 GB untuk throughput yang dimaksimalkan. Ini membantu mengoptimalkan proses penyerapan dan meningkatkan performa. Lebih baik memiliki file berukuran sama.
  • Jumlah file: Untuk memaksimalkan paralelisme dan performa kueri, bertujuan untuk menghasilkan sejumlah besar file. Prioritaskan pembuatan file sebanyak mungkin sambil mempertahankan ukuran file minimum 100 MB.
  • Partisi: Partisi data Anda dengan menyimpan partisi ke dalam folder atau nama file yang berbeda jika beban kerja Anda memfilternya menurut kolom partisi.
  • Estimasi: Coba atur ROWS_PER_BATCH agar sesuai dengan jumlah baris dalam file yang mendasar jika Anda merasa tidak mendapatkan performa yang diharapkan.
  • Ukuran kapasitas: Untuk volume data yang lebih besar, pertimbangkan untuk memperluas skala ke SKU yang lebih besar untuk mendapatkan lebih banyak sumber daya komputasi yang diperlukan untuk mengakomodasi jumlah pemrosesan paralel tambahan dan volume data yang lebih besar.

Hindari penyisipan, pembaruan, dan penghapusan trickle

Untuk memastikan tata letak file yang efisien dan performa kueri yang optimal di Fabric Data Warehouse, hindari menggunakan banyak transaksi INSERT kecil, UPDATE, dan DELETE. Perubahan tingkat baris ini menghasilkan file Parquet baru untuk setiap operasi, menghasilkan sejumlah besar file kecil dan grup baris terfragmentasi. Fragmentasi ini mengarah pada:

  • Peningkatan latensi kueri karena pemindaian file yang tidak efisien.
  • Biaya storage dan komputasi yang lebih tinggi.
  • Ketergantungan yang lebih besar pada proses pemadatan latar belakang.

Pendekatan yang direkomendasikan:

  • Transaksi batch yang ditulis ke dalam Fabric Data Warehouse.
    • Misalnya, alih-alih banyak statement kecil INSERT, tahap data terlebih dahulu bersama-sama, dan masukkan data dalam satu statement INSERT.
  • Gunakan COPY INTO untuk menyisipkan secara massal dan melakukan pembaruan dan penghapusan dalam batch jika memungkinkan.
  • Pertahankan ukuran file minimum yang diimpor sebesar 100 MB untuk memastikan pembentukan grup baris yang efisien.
  • Untuk panduan selengkapnya dan praktik terbaik tentang penyerapan data, lihat Praktik terbaik untuk menyerap data ke dalam gudang.

Pemadatan data

Dalam Fabric Data Warehouse, pemadatan data adalah proses pengoptimalan latar belakang yang menggabungkan file Parquet kecil yang tidak efisien menjadi file yang lebih sedikit dan lebih besar. Seringkali file-file ini dibuat oleh operasi trickle INSERT, UPDATE, atau DELETE yang sering. Pemadatan data mengurangi fragmentasi file, meningkatkan efisiensi grup baris, dan meningkatkan performa kueri secara keseluruhan.

Meskipun mesin Fabric Data Warehouse secara otomatis menyelesaikan fragmentasi dari waktu ke waktu melalui pemadatan data, performa mungkin menurun hingga proses tersebut selesai. Pemadatan data berjalan secara otomatis tanpa intervensi pengguna untuk Fabric Data Warehouse.

Pemadatan data tidak berlaku untuk Lakehouse. Untuk tabel Lakehouse yang diakses melalui titik akhir analitik SQL, penting untuk mengikuti praktik terbaik Lakehouse dan menjalankan perintah OPTIMIZE secara manual setelah perubahan data yang signifikan untuk mempertahankan tata letak storage yang optimal.

Pencegahan pemadatan data

Fabric Data Warehouse secara cerdas dan aktif menghindari konflik tulis-tulis antara tugas pemadatan latar belakang dan operasi pengguna. Mulai Oktober 2025, pencegahan kompakan data diaktifkan.

Pemadatan memeriksa kunci bersama yang disimpan oleh kueri pengguna. Jika pemadatan data mendeteksi kunci sebelum dimulai, proses tersebut akan menunggu dan mencoba lagi nanti. Jika pemadatan data dimulai dan mendeteksi kunci sebelum mensahkan, pemadatan data dibatalkan untuk menghindari konflik tulis dengan kueri pengguna.

Konflik tulis-tulis dengan layanan pemadatan data latar belakang dari Data Warehouse Fabric masih mungkin terjadi. Dimungkinkan untuk membuat konflik tulis-tulis dengan pemadatan data, misalnya, jika aplikasi menggunakan transaksi eksplisit dan melakukan pekerjaan yang tidak bertentangan (seperti INSERT) sebelum operasi yang bertentangan (UPDATE, , DELETEMERGE). Pemadatan data dapat diselesaikan dengan sukses, menyebabkan transaksi eksplisit berikutnya gagal karena konflik. Untuk informasi selengkapnya tentang konflik penulisan atau pembaruan, lihat Transactions dalam tabel Gudang di Microsoft Fabric.

V-Order dalam Fabric Data Warehouse

V-Order adalah pengoptimalan waktu penulisan ke format file parquet yang memungkinkan pembacaan cepat dalam Microsoft Fabric. V-Order in Fabric Data Warehouse meningkatkan performa kueri dengan menerapkan pengurutan dan pemadatan ke file tabel.

Secara default, V-Order diaktifkan di semua gudang untuk memastikan bahwa operasi baca, terutama kueri analitik, secepat dan seefisien mungkin.

Namun, V-Order memperkenalkan overhead pengambilan data kecil, terlihat dalam beban kerja yang berfokus pada penulisan. Untuk alasan ini, menonaktifkan V-Order harus dipertimbangkan hanya untuk gudang yang memiliki intensitas penulisan tinggi dan tidak digunakan untuk kueri yang sering dilakukan. Penting untuk dicatat bahwa setelah V-Order dinonaktifkan di gudang, V-Order tidak dapat diaktifkan kembali.

Sebelum memutuskan untuk menonaktifkan V-Order, pengguna harus menguji performa beban kerja mereka secara menyeluruh untuk memastikan pertukaran tersebut dibenarkan. Pola umum adalah menggunakan gudang penahapan dengan V-Order yang dinonaktifkan untuk pemrosesan throughput tinggi, transformasi data, dan mengambil data dasar ke dalam Data Warehouse yang mendukung V-Order untuk performa baca yang lebih baik. Untuk informasi selengkapnya, lihat Nonaktifkan V-Order di Warehouse dalam Microsoft Fabric.

Mengkloning tabel alih-alih menyalin tabel

klon Table di Fabric Data Warehouse menyediakan cara yang cepat dan efisien untuk membuat tabel tanpa menyalin data. Dengan pendekatan kloning tanpa salinan, hanya metadata tabel yang diduplikasi, sementara file data asli dirujuk langsung dari OneLake. Ini memungkinkan pengguna untuk membuat salinan tabel yang konsisten dan andal hampir seketika, tanpa overhead duplikasi data penuh.

Kloning tanpa salinan langsung sangat ideal untuk skenario seperti pengembangan, pengujian, dan pencadangan, menawarkan solusi berkinerja tinggi dan penyimpanan yang efisien yang membantu mengurangi biaya infrastruktur.

  • Tabel kloning juga menyalin semua fitur keamanan utama dari sumbernya, termasuk Row-Level Security (RLS), Column-Level Security (CLS), dan Dynamic Data Masking (DDM), tanpa perlu menerapkan kembali kebijakan setelah kloning.
  • Klon dapat dibuat pada titik waktu tertentu dalam periode retensi data, mendukung kemampuan perjalanan waktu.
  • Tabel kloning ada secara independen dari sumbernya, perubahan yang dilakukan pada sumber tidak memengaruhi kloning, dan perubahan pada kloning tidak memengaruhi sumber. Baik sumber maupun kloning dapat dihilangkan secara independen.

Tampilan kueri metadata

Untuk informasi selengkapnya tentang queryinsights view, lihat Wawasan kueri di pergudangan data Fabric.

Untuk informasi lebih lanjut tentang daur hidup kueri DMVs, lihat Memantau koneksi, sesi, dan permintaan menggunakan DMV.

Konten terkait

  • Last updated on