Fabric Data Warehouse performans yönergeleri

Şunlara uygulanır:✅ Warehouse in Microsoft Fabric

Bu makale, veri alımı, tablo yönetimi, veri hazırlama, istatistikler ve ambarlarda ve SQL analiz uç noktalarındaki sorgulamaya yönelik en iyi yöntemleri içerir. Performans ayarlama ve iyileştirme benzersiz zorluklar sunabilir, ancak aynı zamanda veri çözümlerinizin özelliklerini en üst düzeye çıkarmak için değerli fırsatlar sunar.

Tavsiye

Spark tarafından yazılan veya Fabric Data Warehouse tarafından tüketilen yansıtan tablolar için öneriler de dahil olmak üzere, Delta tablosu iyileştirme stratejilerine yönelik kapsamlı iş yükleri arası kılavuzlar için bkz. Çapraz iş yükü tablosu bakımı ve optimizasyonu.

Ambarınızın performansını izlemek için bkz. Monitor Fabric Data warehouse.

Sorgu performansı

İstatistikler

İstatistikler, tablolarınızın sütunlarındaki verileri temsil eden kalıcı nesnelerdir. Sorgu İyileştiricisi, sorgu planının maliyetini seçmek ve tahmin etmek için istatistikleri kullanır. Fabric Data Warehouse ve Lakehouse SQL analiz uç noktası, histogram istatistiklerini, ortalama sütun uzunluğu istatistiklerini ve tablo kardinalite istatistiklerini kullanır ve otomatik olarak korur. Daha fazla bilgi için bkz. Fabric Veri Ambarı'nda İstatistikler.

  • CREATE STATISTICS ve UPDATE STATISTICS T-SQL komutları, tek sütunlu histogram istatistikleri için desteklenir. Tablo dönüşümleriniz ile sorgu iş yükünüz arasında bakım penceresi veya diğer kapalı kalma süreleri gibi yeterince büyük bir pencere varsa bunlardan yararlanabilirsiniz. Bu, sorgularınızın SELECT önce istatistikleri güncellemesi gerekliliği olasılığını azaltır.
  • Ortak sütun karşılaştırmalarında veri türü eşliğini koruyan tablo şemasını tanımlamayı deneyin. Örneğin, sütunların genellikle WHERE tümcesinde karşılaştırılacağını veya koşul JOIN ... ON olarak kullanılacağını biliyorsanız, veri türlerinin uyduğundan emin olun. Tam olarak aynı veri türlerini kullanmak mümkün değilse, örtük dönüştürme için uyumlu benzer veri türlerini kullanın. Açık veri dönüştürmelerinden kaçının. Daha fazla bilgi için bkz. Veri türü dönüştürme.

Tavsiye

Lakehouse kullanıcıları için ACE-Cardinality istatistiği, tablolarınızın Delta günlük dosyalarındaki bilgileri daha doğru bir şekilde kullanabilir. Spark tarafından oluşturulan Delta tablolarınızın şu şekilde tablo satır sayılarını içerdiğine emin olun: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Daha fazla bilgi için bkz. Doku Spark'ta Otomatik Tablo İstatistiklerini yapılandırma ve yönetme.

Apache Spark çalışma zamanı 3.5.0'ın öncesinde lakehouse tablolarını zaman damgası sütununda filtrelerken, zaman damgası sütunları için satır grubu düzeyinde istatistikler oluşturulmaz. Bu istatistik eksikliği, Doku Ambarı gibi sistemlerin sorgu yürütme sırasında ilgisiz satır gruplarını atlayan performans iyileştirmesi olan satır grubu eleme (veri atlama veya koşul gönderme olarak da bilinir) uygulamasını zorlaştırır. Bu istatistikler olmadan, zaman damgası sütunlarını içeren sorguları filtrelemenin daha fazla veri taraması gerekebilir ve bu da önemli performans düşüşlerine yol açabilir. Apache Spark çalışma zamanını Fabric'de yükseltebilirsiniz. Apache Spark 3.5.0 ve üzeri sürümler, zaman damgası sütunları için satır grubu düzeyinde istatistikler oluşturabilir. Ardından, satır grubu düzeyi istatistiklerinin oluşturulması için tabloyu yeniden oluşturmanız ve verileri almanız gerekir.

Soğuk önbellek performansı

Fabric Data Warehouse'da bir sorgunun ilk yürütmesi sonraki çalıştırmalardan beklenmedik şekilde daha yavaş olabilir. Bu, sistemi başlatma veya ortamı işlemeye hazırlayan ölçeklendirme etkinliklerinin neden olduğu soğuk başlangıç olarak bilinir.

Soğuk başlatmalar genellikle şu durumlarda gerçekleşir:

  • Veriler OneLake'ten belleğe yüklenir çünkü verilere ilk kez erişilir ve henüz önbelleğe alınmaz.
  • Verilere ilk kez erişilirse, gerekli istatistikler otomatik olarak oluşturulana kadar sorgu yürütme gecikir.
  • Fabric Data Warehouse, maliyeti azaltmak için bir süre işlem yapılmadığında düğümleri otomatik olarak duraklatır ve otomatik ölçeklendirme kapsamında düğümler ekler. Düğümlerin devam ettirilmesi ya da oluşturulması işlemi genellikle bir saniyeden kısa sürer.

Bu işlemler sorgu süresini artırabilir. Soğuk başlangıçlar kısmi olabilir. Sorgu diğerlerinin kullanılabilir olmasını beklerken bazı işlem düğümleri, veriler veya istatistikler zaten kullanılabilir veya bellekte önbelleğe alınmış olabilir.

Fabric Data Warehouse'da bellek içindeki ve disk önbelleği tamamen saydamdır ve otomatik olarak etkinleştirilmektedir. Önbelleğe alma, yerel önbelleklerden yararlanarak uzak storage okuma gereksinimini akıllıca en aza indirir. Fabric Data Warehouse, depolama alanından veri okumalarını geliştirmek ve sorgu yürütme hızını yükseltmek için geliştirilmiş erişim desenleri kullanır. Daha fazla bilgi için bkz. Fabric veri ambarında önbelleğe alma.

queryinsights.exec_requests_history görünümünü sorgulayarak uzak storage gelen verileri belleğe getirmenin neden olduğu soğuk başlatma efektlerini algılayabilirsiniz. data_scanned_remote_storage_mb Sütunu kontrol edin:

  • içindeki data_scanned_remote_storage_mb sıfır olmayan değer, soğuk bir başlangıç olduğunu gösterir. Sorgu yürütme sırasında OneLake'den veriler getirildi. Sonraki görünümler queryinsights.exec_requests_history içinde kesin bir şekilde daha hızlı olmalıdır.
  • içindeki data_scanned_remote_storage_mb sıfır değeri, tüm verilerin önbelleğe alındığı mükemmel durumdur. Sorgu sonuçlarını sunmak için OneLake'ten düğüm değişikliğine veya veriye gerek duyulmadı.

Önemli

Sorgu performansını ilk yürütmeye göre değerlendirmeyin. Sorgunun soğuk başlatmadan etkilenip etkilenmediğini kontrol etmek için her zaman data_scanned_remote_storage_mb denetleyin. Sonraki yürütmeler genellikle önemli ölçüde daha hızlıdır ve gerçek performansı temsil eder ve bu da ortalama yürütme süresini düşürür.

Dize sütunları içeren tablolardaki sorgular

Değerleri barındırabilecek en küçük dize sütun uzunluğunu kullanın. Kumaş Deposu sürekli gelişiyor; ancak, özellikle büyük nesneler (LOB) olmak üzere geniş dize veri türleri kullanıyorsanız, optimal olmayan bir performansla karşılaşabilirsiniz. Örneğin, bir customer_name sütunun veri türünü belirlerken iş gereksinimlerinizi ve beklenen verileri göz önünde bulundurmalı ve n bildiriminde uygun uzunluk varchar(n) kullanmalısınız, örneğin varchar(100) gibi, varchar(8000) veya varchar(max) yerine. Veri türü uzunluğu gerçek veriler için daha kesin olduğunda istatistikler ve sorgu maliyeti tahmini daha doğru olur.

  • Fabric Data Warehouse T-SQL'de, dize veri türleri için uygun uzunluğu seçmek üzere rehberliği görmek için bkz.
  • Spark'ta tanımlanmamış uzunlukları olan Lakehouse tablo dize sütunları, Fabric Warehouse tarafından varchar(8000) olarak kabul edilir. En iyi performans için SparkSQL'deki deyimini kullanarak CREATE TABLE dize sütununu olarak varchar(n)tanımlayın; burada n değerlere uyum sağlayabilen maksimum sütun uzunluğudur.

İşlemler ve eşzamanlılık

Fabric Data Warehouse, büyük ölçeklerde yüksek eşzamanlılık ve tutarlılık sağlamak amacıyla işlem bütünlüğünü, anlık görüntü izolesini ve dağıtılmış hesaplamayı birleştiren modern, bulut tabanlı bir mimari üzerine kurulmuştur. Daha fazla bilgi için bkz. Ambar Tablolarındaki İşlemler.

Doku Data Warehouse, anlık görüntü yalıtımı kullanan ACID uyumlu işlemleri destekler. Bu, şu anlama gelir:

  • Okuma ve yazma işlemleri standart T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK) kullanılarak tek bir işlem halinde gruplandırılabilir
  • Tümü veya hiç semantiği: Bir işlem birden çok tabloya yayılıyorsa ve bir işlem başarısız olursa, işlemin tamamı geri alınır.
  • Okuma tutarlılığı: SELECT bir işlemdeki sorgular, eşzamanlı yazma işlemlerinden etkilenmeden verilerin tutarlı bir anlık görüntüsünü görür.

Doku Ambarı işlemleri desteği:

  • İşlemlerin içindeki Veri Tanımı Dili (DDL): bir işlem bloğuna ekleyebilirsiniz CREATE TABLE .
  • Veritabanları arası işlemler: SQL analytics uç noktalarındaki okumalar da dahil olmak üzere aynı çalışma alanında desteklenir.
  • Parquet tabanlı geri alma: Fabric Data Warehouse verileri sabit Parquet dosyalarında depoladığından geri alma işlemleri hızlıdır. Geri alma işlemleri yalnızca önceki dosya sürümlerine geri döner.
  • Otomatik veri sıkıştırma ve denetim noktası oluşturma:Veri sıkıştırma küçük Parquet dosyalarını birleştirerek ve mantıksal olarak silinen satırları kaldırarak storage ve okuma performansını iyileştirir.
  • Otomatik denetim noktası oluşturma: Her yazma işlemi (INSERT, UPDATE, DELETE) Delta Lake işlem günlüğüne yeni bir JSON günlük dosyası ekler. Zamanla, bu durum özellikle akış veya yüksek frekanslı veri alma senaryolarında yüzlerce veya binlerce günlük dosyasına yol açabilir. Otomatik denetim noktası oluşturma, işlem günlüklerini tek bir denetim noktası dosyasına özetleyerek meta veri okuma verimliliğini artırır. Denetim noktası oluşturmadan, her okuma işlemi tüm işlem günlüğü geçmişini taramalıdır. Kontrol noktası ile, okunan tek günlükler en son kontrol noktası dosyası ve onun ardından gelen günlüklerdir. Bu, özellikle büyük veya sık güncelleştirilen tablolar için G/Ç ve meta veri ayrıştırma işlemini önemli ölçüde azaltır.

Hem sıkıştırma hem de kontrol noktası oluşturma, özellikle uzun süre çalışan veya yüksek eşzamanlılık ortamlarında tablo sağlığı için kritik öneme sahiptir.

Eşzamanlılık denetimi ve yalıtımı

Fabric Data Warehouse yalnızca anlık görüntü yalıtımı kullanır. T-SQL aracılığıyla yalıtım düzeyini değiştirme girişimleri yoksayılır.

İşlemlerle ilgili en iyi yöntemler

  • Açık işlemleri akıllıca kullanın. Her zaman COMMIT veya ROLLBACK. İşlemleri açık bırakmayın.
    • İşlemleri kısa süreli tutun. Özellikle DDL içeren açık işlemler için kilitleri gereksiz yere tutan uzun süreli işlemlerden kaçının. Bu, sistem katalog görünümlerindeki SELECT ifadeleriyle (örneğin sys.tables) çekişmelere ve sistem katalog görünümlerine dayanan Fabric portalında sorunlara neden olabilir.
  • Geçici çakışmaları işlemek için veri yollarına veya uygulamalara gecikmeli yeniden deneme mantığı ekleyin.
    • Geçici ağ kesintilerini daha da kötüleştiren ardışık yeniden denemelerden kaçınmak için üstel geri çekilme kullanın.
    • Daha fazla bilgi için bkz. Retry deseni.
  • Ambardaki kilitleri ve çakışmaları izleyin.

Döndürülen veri kümesi boyutlarını azaltma

Ara sorgu yürütmesinde veya son sorgu sonucunda büyük veri boyutuna sahip sorgular daha fazla sorgu performansı sorunuyla karşılaşabilir. Döndürülen veri kümesi boyutunu küçültmek için aşağıdaki stratejileri göz önünde bulundurun:

  • Lakehouse'da bölümleme veya küme (Liquid Clustering) büyük tabloları.
  • Döndürülen sütun sayısını sınırlayın. SELECT * yüksek maliyetli olabilir.
  • Dönen satır sayısını sınırlayın. İstemci uygulamalarında değil, ambarda mümkün olduğunca çok veri filtrelemesi gerçekleştirin.
    • Sorgu yürütmenin erken aşamalarında veri kümesini azaltmak için birleştirmeden önce filtrelemeyi deneyin.
    • Büyük veri kümesini JOIN'lerden önce azaltmak için düşük kardinalite sütunlarına filtre uygulayın.
    • Yüksek kardinaliteye sahip sütunlar filtreleme ve JOIN'ler için idealdir. Bunlar genellikle WHERE yan tümcelerde kullanılır ve verileri filtrelemek için sorgu yürütmenin önceki aşamalarında önceden uygulanan koşuldan faydalanır.
  • Fabric Veri Ambarı'nda birincil anahtar ve benzersiz anahtar kısıtlamaları uygulanmadığından, bu kısıtlamalara sahip sütunlar JOIN işlemleri için iyi adaylar olmayabilir.

Sorgu planları ve sorgu ipuçları

Doku Data Warehouse'nde sorgu iyileştiricisi, SQL sorgusunu yürütmenin en verimli yolunu belirlemek için bir sorgu yürütme planı oluşturur. Gelişmiş kullanıcılar, sorgu planıyla ilgili sorgu performansı sorunlarını araştırmayı veya sorgu ipuçları eklemeyi göz önünde bulundurabilir.

  • Kullanıcılar, sorguyu yürütmeden planı görüntülemek için SQL Server Management StudioSHOWPLAN_XML kullanabilir.
  • İsteğe bağlı sorgu ipuçları , plan oluşturmadan önce sorgu iyileştiricisine daha fazla yönerge sağlamak için SQL deyimine eklenebilir. Sorgu ipuçları eklemek, sorgu iş yükleri hakkında gelişmiş bilgi gerektirir, bu nedenle genellikle diğer en iyi yöntemler uygulandıktan sonra kullanılır ancak sorun devam eder.

Ölçeklenebilir olmayan işlemler

Fabric Data Warehouse, sorguların birden çok işlem düğümünde yürütüldüğü, büyük ölçekte paralel işleme (MPP) mimarisi üzerine kurulmuştur. Bazı senaryolarda tek düğümlü yürütme haklı çıkar.

  • Sorgu planı yürütmesinin tamamı için yalnızca bir işlem düğümü gerekir.
  • Plan alt ağacı bir işlem düğümüne sığabilir.
  • Sorgu semantiğini karşılamak için sorgunun tamamı veya bir bölümü tek bir düğümde yürütülmelidir . Örneğin, TOP işlemler, genel sıralama, paralel yürütmelerden elde edilen sonuçların sıralanmasını gerektiren veya son adım için sonuçları birleştiren sorgular gibi işlemler.

Bu durumlarda, kullanıcılar "Bir veya daha fazla ölçeklenebilir olmayan işlem algılandı" uyarı iletisi alabilir ve sorgu yavaş çalışabilir veya uzun bir yürütmeden sonra başarısız olabilir.

  • Sorgunun filtrelenmiş veri kümesinin boyutunu küçültmeyi göz önünde bulundurun.
  • Sorgu semantiği tek düğümlü yürütme gerektirmiyorsa, FORCE DISTRIBUTED PLAN ile dağıtılmış sorgu planını zorlamayı deneyin, örneğin OPTION (FORCE DISTRIBUTED PLAN);.

SQL analytics uç noktasını sorgulama

Verileri Depo'ya kopyalamadan veya aktarmadan, Spark SQL ile doldurulmuş Lakehouse tablolarını sorgulamak için SQL analitik uç noktasını kullanabilirsiniz.

Aşağıdaki en iyi yöntemler, SQL analiz uç noktası aracılığıyla Lakehouse'daki ambar verilerini sorgulamak için geçerlidir. SQL analytics uç nokta performansı hakkında daha fazla bilgi için bkz. SQL analytics uç noktası performansında dikkat edilmesi gerekenler.

Tavsiye

Aşağıdaki en iyi uygulamalar, Spark kullanarak verileri SQL analiz uç noktası tarafından sorgulanabilen bir lakehouse'a işlemek için uygulanır.

Lakehouse tabloları için düzenli tablo bakımı gerçekleştirme

Microsoft Fabric'da, Ambar veri düzenlerini otomatik olarak iyileştirir ve çöp toplama ve sıkıştırma gerçekleştirir. Bir Lakehouse için masa bakımı üzerinde daha fazla denetime sahipsiniz. Tablo iyileştirme ve vakumlama gereklidir ve büyük veri kümeleri için gereken tarama süresini önemli ölçüde azaltabilir. Lakehouse'daki tablo bakımı da kısayollara kadar uzanır ve orada performansı önemli ölçüde geliştirmenize yardımcı olabilir.

Birçok küçük dosyayla lakehouse tablolarını veya kısayollarını iyileştirme

Çok sayıda küçük dosya olması, dosya meta verilerini okumak için ek yük oluşturur. Küçük dosyaları daha büyük dosyalarda birleştirmek için Doku portalında veya Not Defteri'nde OPTIMIZE komutunu kullanın. Dosya sayısı önemli ölçüde değiştiğinde bu işlemi yineleyin.

Fabric Lakehouse'daki bir tabloyu optimize etmek için Fabric portalında Lakehouse'u açın. Gezgin'de tabloya sağ tıklayın ve Bakım'ı seçin. Bakım komutlarını çalıştır sayfasında seçenekleri belirleyin ve ardından Şimdi çalıştır'ı seçin.

Aynı bölgede bulunan lakehouse tablolarını veya kısayollarını sorgulama

Fabric, Fabric kapasitesinin bulunduğu yerde işlem yapar. Kendi Azure Data Lake Storage veya OneLake gibi verileri başka bir bölgede sorgulamak, ağ gecikme süresi nedeniyle performans ek yüküne neden olur. Verilerin aynı bölgede olduğundan emin olun. Performans gereksinimlerinize bağlı olarak, yalnızca boyut tabloları gibi küçük tabloları uzak bir bölgede tutmayı göz önünde bulundurun.

Aynı sütunlarda lakehouse tablolarını ve kısayollarını filtreleme

Tablo satırlarını belirli sütunlarda sık sık filtrelediyseniz, tabloyu bölümleyebilirsiniz.

Bölümleme, düşük kardinalite sütunları veya yıllar veya tarihler gibi öngörülebilir kardinaliteye sahip sütunlar için iyi çalışır. Daha fazla bilgi için bkz Lakehouse Tutoryali - Lakehouse verilerini hazırlama ve dönüştürme ve Verileri bölüm kullanarak Lakehouse'a yükleme.

Kümeleme, yüksek seçicilik sütunları için iyi çalışır. Sütunları bölümleme dışında filtreleme için sık kullandığınız başka sütunlarınız varsa Spark SQL söz dizimi ZORDER BYile optimize özelliğini kullanarak tabloyu kümeleyebilirsiniz. Daha fazla bilgi için bkz . Delta Lake tablo iyileştirmesi.

Veri kümeleme

Belirli sütunlarda CREATE TABLE ve CREATE TABLE AS SELECT (CTAS) T-SQL deyimleri kullanarak veri kümeleme gerçekleştirebilirsiniz. Veri kümelemesi, alma sırasında benzer değerlere sahip satırları depolamada bitişik konumlarda depolayarak çalışır.

  • Veri kümeleme, verileri birden çok boyutta yerelliği koruyacak şekilde düzenlemek için bir alan doldurma eğrisi kullanır; bu da kümeleme sütunları arasında benzer değerlere sahip satırların fiziksel olarak birbirine yakın şekilde depolanması anlamına gelir. Bu yaklaşım, dosya atlayarak ve taranan dosya sayısını azaltarak sorgu performansını önemli ölçüde artırır.
  • Veri kümeleme meta verileri, veri alımı sırasında manifestoya eklenir ve bu, ambar motorunun kullanıcı sorguları sırasında hangi dosyalara erişileceği konusunda akıllı kararlar almasına olanak tanır. Benzer değerlere sahip satırların birlikte nasıl depolandığıyla birleştirilen bu meta veriler, filtre koşuluna sahip sorguların koşul kapsamının dışında kalan dosyaların ve satır gruplarının tamamını atlayabilmesini sağlar.

Örneğin: Bir sorgu tablonun verilerinin yalnızca 10% hedefleniyorsa kümeleme yalnızca filtre aralığındaki verileri içeren dosyaların taranmasını sağlayarak G/Ç ve işlem tüketimini azaltır. Dosya atlamanın avantajları veri hacmiyle ölçeklendirildiği için daha büyük tablolar veri kümelemesinden daha fazla yararlanır.

Veri türü iyileştirme

Doğru veri türlerini seçmek, ambarınızdaki performans ve storage verimlilik için önemlidir. Aşağıdaki yönergeler şema tasarımınızın hızlı sorguları, verimli storage ve sürdürülebilirliği desteklediğinden emin olunmasını sağlar.

Doku Data Warehouse tarafından desteklenen veri türleri hakkında daha fazla bilgi için bkz. Doku Data Warehouse'da Veri türleri.

Tavsiye

Kod öncelikli dağıtım metodolojisi gibi tablolar veya sorgular oluşturmak için dış araçlar kullanıyorsanız sütun veri türlerini dikkatle gözden geçirin. Karakter veri türü uzunlukları ve sorguları bu en iyi yöntemleri izlemelidir.

Veri türlerini veri semantiğiyle eşleştirme

Hem netlik hem de performansı sağlamak için, her sütunun veri türünü verinin gerçek doğası ve davranışıyla hizalamak önemlidir.

  • Zamansal değerler için bunları dize olarak depolamak yerine tarih, saat veya datetime2(n) kullanın.
  • Biçimlendirme (örneğin, baştaki sıfırlar) gerekmediği sürece sayısal değerler için tamsayı türlerini kullanın.
  • Biçimlendirmeyi korumak gerekli olduğunda karakter türlerini (karakter, varchar) kullanın (örneğin, sıfırla başlayabilen sayılar, ürün kodları, kısa çizgili sayılar).

Tam sayılar için tamsayı türlerini kullanma

Tanımlayıcılar, sayaçlar veya diğer tam sayılar gibi değerleri depolarken ondalıksayısalyerine tamsayı türlerini (smallint, /, bigint) tercih edin. Tamsayı türleri, ondalık ayırıcının sağındaki basamaklara izin veren veri türlerinden daha az storage gerektirir. Sonuç olarak, daha hızlı aritmetik ve karşılaştırma işlemlerine olanak sağlar ve dizin oluşturma ile sorgu performansını geliştirir.

Fabric Data Warehouse tarafından desteklenen her tamsayı veri türünün değer aralıklarının farkında olun. Daha fazla bilgi için int, bigint, smallint (Transact-SQL).

Ondalık ve sayısal hassasiyet ve ölçeği kullanımını göz önünde bulundurun

Ondalık/sayısal kullanmanız gerekiyorsa, sütun oluştururken verilerinize uygun en küçük duyarlık ve ölçek uygulayın. Aşırı tahsis hassasiyeti depolama gereksinimlerini artırır ve veriler büyüdükçe performansı düşürebilir.

  • Ambarınızın beklenen büyümesini ve ihtiyaçlarını tahmin edin. Örneğin, ondalık noktanın sağında en fazla dört basamak depolamayı planlıyorsanız, en verimli depolama için decimal(9,4) veya decimal(19,4) kullanın.
  • Ondalık/sayısal sütun oluştururken her zaman kesinlik ve ölçek belirtin. Duyarlık decimal belirtilmeden (p,s) yalnızca olarak tanımlanan bir tabloda oluşturulduğunda, ondalık/ sütun olarak decimal(18,0)oluşturulur. Duyarlık değeri 18 olan decimal, satır başına 9 bayt depolama alanı tüketir. ölçeği 0 , ondalık ayırıcının sağındaki verileri depolamaz. Birçok iş tamsayısı için smallint, int ve bigint, decimal(18,0)unkine kıyasla çok daha verimlidir. Örneğin, herhangi bir dokuz basamaklı tamsayı, satır başına 4 bayt storage için integer veri türü olarak depolanabilir.

Ayrıntılı bilgi için bkz. ondalık ve sayısal (Transact-SQL).

Karakter yerine varchar'ın ne zaman kullanılacağını göz önünde bulundurun

Sabit uzunlukta doldurma açıkça gerekmediği sürece dize sütunları için karakter(n) yerine varchar(n) kullanın. Varchar sütunu satır başına yalnızca gerçek dize uzunluğunu ve küçük bir ek yükü depolar ve boşa harcanan alanı azaltarak G/Ç verimliliğini artırır.

  • Adlar, adresler ve açıklamalar gibi değerler için değişken değerlere sahip oldukları için varchar(n) kullanın. Veri türü uzunluğu gerçek veriler için daha kesin olduğunda istatistikler ve sorgu maliyeti tahmini daha doğru olur.
  • Dizenin her seferinde sabit uzunlukta olacağını bildiğinizde char(n) kullanın. Örneğin, dizenin 000000000 her zaman sıfırla başlayabilen 9 sayısal karakter olması durumunda dizenin char (9) olarak depolanması mantıklıdır.
  • Sütun veri türü bildirimindeki n uzunluğu depolama baytlarıdır. UTF-8 gibi çok baytlı kodlama karakter kümeleri için, Fabric Veri Ambarı'nda Latin karakterleri ve sayılar 1 bayt depolama alanı kullanır. Ancak, depolamak için 3 bayt gerektiren Japonca karakterler gibi 1 bayttan daha fazla unicode karakter vardır, bu nedenle gerçekte depolanan Unicode karakterlerinin sayısı veri türü uzunluğundan ndaha az olabilir. Daha fazla bilgi için bkz. char ve varchar Arguments.

Mümkün olduğunda boş değer atanabilir sütunlardan kaçının

Veri modeli izin verdiğinde sütunları NOT NULL olarak tanımlayın. Varsayılan olarak, tablodaki bir sütun değerlere izin verir NULL . Null alabilen sütunların aşağıdaki özellikleri vardır:

  • Meta veri ek yükü ekler.
  • Sorgu iyileştirmelerinin ve istatistiklerin etkinliğini azaltabilir.
  • Büyük ölçekli analitik sorgulardaki performansı etkileyebilir.

Bir ambara veri alımı ve hazırlığı

İÇİNE KOPYALA

T-SQL COPY INTO komutu Azure Data Lake Storage'dan Doku Data Warehouse'ne veri almak için önerilen yoldur. Daha fazla bilgi ve örnek için COPY deyimini kullanarak Verilerinizi Ambarınıza Alma bölümüne bakın.

En iyi performans için aşağıdaki önerileri göz önünde bulundurun:

  • Dosya boyutu: En yüksek aktarım hızı için, almakta olduğunuz her dosyanın ideal olarak 100 MB ile 1 GB arasında olduğundan emin olun. Bu, alım işlemini iyileştirmeye ve performansı geliştirmeye yardımcı olur.
  • Dosya sayısı: Paralellik ve sorgu performansını en üst düzeye çıkarmak için çok sayıda dosya oluşturmayı hedefleyin. En az 100 MB dosya boyutunu korurken mümkün olduğunca çok dosya oluşturmaya öncelik sağlayın.
  • Paralel yükleme: Verileri farklı tablolara yüklemek için paralel olarak çalışan birden çok COPY INTO deyim kullanma. Bu yaklaşım, paralellik nedeniyle ETL/ELT penceresini önemli ölçüde azaltabilir.
  • Kapasite boyutu: Daha büyük veri hacimleri için, ek sayıda paralel işleme ve daha büyük veri hacimlerini barındırmak için gereken ek işlem kaynaklarını almak için ölçeği daha büyük Doku Kapasitesine genişletmeyi göz önünde bulundurun.

Fabric Data Warehouse ayrıca BULK INSERT ifadesine eş anlamlı olan COPY INTO deyimini de destekler. Aynı öneri BULK INSERT ifadesi için de geçerlidir.

CTAS veya INSERT

CREATE TABLE AS SELECT (CTAS) veya INSERTSELECT FROM komutlarını Lakehouse tablo/kısayol komutlarıyla birlikte kullanın. Bu yöntemler, pipelines kullanmaktan daha yüksek performanslı ve verimli olabilir ve daha hızlı ve daha güvenilir veri aktarımlarına olanak sağlar. Daha fazla bilgi ve örnek için bkz. Transact-SQL kullanarak Verileri Ambarınıza alma.

Paralellik sayısını artırma ve daha büyük Doku Kapasitesine ölçeklendirme kavramı, aktarım hızını artırmak için CTAS/INSERT işlemleri için de geçerlidir.

OPENROWSET ile Azure Data Lake Storage veya Blob Storage verileri okuma

OPENROWSET işlevi, CSV veya Parquet dosyalarını Veri Ambarı'na almadan Azure Data Lake veya Azure Blob depolama birimlerinden okumanızı sağlar. Daha fazla bilgi ve örnek için bkz. OPENROWSET işlevini kullanarak dosya içeriğine göz atma.

Dış verileri sorgulama hakkında daha fazla bilgi ve örnek için bkz. Fabric Data Warehouse veya SQL analytics uç noktasını kullanarak dış data lake dosyalarını sorgulama.

OPENROWSET işlevini kullanarak verileri okurken, en iyi performans için aşağıdaki önerileri göz önünde bulundurun:

  • Parke: Dosyaları sık sık sorgularsanız CSV yerine Parquet kullanmayı deneyin veya CSV'yi Parquet'e dönüştürün. Parquet sütunlu bir biçimdir. Veriler sıkıştırıldığından, dosya boyutları aynı verileri içeren CSV dosyalarından daha küçüktür. Fabric Veri Ambarı, Parquet dosyalarını okuyorsanız, sorguda gerek olmayan sütunları ve satırları atlar.
  • Dosya boyutu: En yüksek aktarım hızı için, almakta olduğunuz her dosyanın ideal olarak 100 MB ile 1 GB arasında olduğundan emin olun. Bu, alım işlemini iyileştirmeye ve performansı geliştirmeye yardımcı olur. Eşit boyutta dosyalara sahip olmak daha iyidir.
  • Dosya sayısı: Paralellik ve sorgu performansını en üst düzeye çıkarmak için çok sayıda dosya oluşturmayı hedefleyin. En az 100 MB dosya boyutunu korurken mümkün olduğunca çok dosya oluşturmaya öncelik sağlayın.
  • Bölüm: İş yükünüz bunları bölüm sütunlarına göre filtrelerse, bölümleri farklı klasörlere veya dosya adlarına depolayarak verilerinizi bölümleyin.
  • Tahmin: Beklenen performansı elde edemediğinizi düşünüyorsanız, ROWS_PER_BATCH temel alınan dosyalardaki satır sayısıyla eşleşecek şekilde ayarlamayı deneyin.
  • Kapasite boyutu: Daha büyük veri hacimleri için, ek sayıda paralel işleme ve daha büyük veri hacimlerine uyum sağlamak için gereken daha fazla işlem kaynağı elde etmek için ölçeği daha büyük SKU'ya genişletmeyi göz önünde bulundurun.

Yavaş yavaş yapılan eklemelerden, güncellemelerden ve silmelerden kaçının

Fabric Data Warehouse'da verimli dosya düzeni ve optimal sorgu performansı sağlamak için çok sayıda küçük INSERT, UPDATE ve DELETE işlemi kullanmaktan kaçının. Bu satır düzeyindeki değişiklikler her işlem için yeni bir Parquet dosyası oluşturur ve bu da çok sayıda küçük dosya ve parçalanmış satır grubuyla sonuçlanır. Bu parçalanma aşağıdakilere yol açar:

  • Verimsiz dosya taraması nedeniyle sorgu gecikme süresi artırıldı.
  • Daha yüksek depolama ve hesaplama maliyetleri.
  • Arka plan sıkıştırma işlemlerine daha fazla dayanıklılık.

Önerilen yaklaşımlar:

  • Fabric Veri Ambarı'na yazan toplu işlemler.
    • Örneğin, çok sayıda küçük INSERT deyim yerine verileri bir araya getirin ve tek bir INSERT deyime veri ekleyin.
  • Toplu eklemeler için COPY INTO kullanın ve mümkün olduğunca toplu olarak güncelleştirme ve silme işlemleri gerçekleştirin.
  • Verimli satır grubu oluşumu sağlamak için en az 100 MB içeri aktarılan dosya boyutunu koruyun.
  • Veri alımı hakkında daha fazla bilgi ve en iyi uygulamalar için bkz. Verileri ambara almak için en iyi yöntemler.

Veri sıkıştırma

Fabric Veri Ambarı'nda veri sıkıştırma, küçük, verimsiz Parquet dosyalarını daha büyük ve az sayıda dosya haline getiren bir arka plan iyileştirme işlemidir. Bu dosyalar genellikle sık kullanılan , INSERTUPDATEveya DELETE işlemleri tarafından oluşturulur. Veri sıkıştırma dosya parçalanmayı azaltır, satır grubu verimliliğini artırır ve genel sorgu performansını artırır.

Doku Data Warehouse altyapısı zaman içinde parçalanmayı veri sıkıştırma yoluyla otomatik olarak çözse de, işlem tamamlanana kadar performans düşebilir. Fabric Data Warehouse için, veri sıkıştırma kullanıcı müdahalesi olmadan otomatik olarak gerçekleştirilir.

Veri sıkıştırma Lakehouse için geçerli değildir. SQL analiz uç noktaları aracılığıyla erişilen Lakehouse tablolarında, lakehouse en iyi yöntemlerini izlemek ve en iyi storage düzenini korumak için önemli veri değişiklikleri yaptıktan sonra OPTIMIZE komutunu el ile çalıştırmak önemlidir.

Veri sıkıştırma önalımı

Fabric Data Warehouse akıllıca ve etkin bir şekilde arka plan sıkıştırma işlemleri ile kullanıcı işlemleri arasında yazma-yazma çakışmalarını önler. Ekim 2025'te veri sıkıştırma önalımı etkinleştirilmiştir.

Kullanıcı sorguları tarafından tutulan paylaşılan kilitler için sıkıştırma denetimleri. Veri sıkıştırma başlamadan önce bir kilit algılarsa bekler ve daha sonra yeniden dener. Veri sıkıştırma başlarsa ve işleme başlamadan önce bir kilit algılarsa, kullanıcı sorgusuyla yazma çakışmasını önlemek için sıkıştırma işlemi iptal edilir.

Doku Data Warehouse arka plan veri sıkıştırma hizmetiyle yazma-yazma çakışmaları hala mümkündür. Bir uygulama açık bir işlem kullanıyorsa ve çakışan bir işlemdenINSERTUPDATE (, , DELETE) önce çakışmayan işler (gibiMERGE) gerçekleştiriyorsa, veri sıkıştırma ile yazma-yazma çakışması oluşturmak mümkündür. Veri sıkıştırma başarılı bir şekilde tamamlanabilir ve bu, çakışma nedeniyle açık işlemin daha sonra başarısız olmasına yol açabilir. Yaz-yaz veya güncelleştirme çakışmaları hakkında daha fazla bilgi için bkz. Microsoft Fabric'teki Ambar tablolarında İşlemler.

Dokuda V Sırası Data Warehouse

V-Order, Microsoft Fabric'de hızlı okuma sağlamak amacıyla, parquet dosya biçimi için bir yazma zamanı optimizasyonudur. Fabric Data Warehouse'da V-Order, tablo dosyalarına sıralama ve sıkıştırma uygulayarak sorgu performansını artırır.

Okuma işlemlerinin, özellikle analitik sorguların mümkün olduğunca hızlı ve verimli olmasını sağlamak için V-Order varsayılan olarak tüm ambarlarda etkinleştirilir.

Ancak V-Order, yazma ağırlıklı iş yüklerinde farkedilebilir küçük bir veri yükleme yükü oluşturur. Bu nedenle, V-Order'ın devre dışı bırakılması yalnızca yazma yoğunluklu olan ve sık sorgulama için kullanılmayan veri ambarları için dikkate alınmalıdır. Bir ambarda V-Order devre dışı bırakıldıktan sonra yeniden etkinleştirilemeyeceğini önemli bir not olarak belirtmek gerekir.

V-Order'ı devre dışı bırakmaya karar vermeden önce, kullanıcıların iş yükü performanslarını kapsamlı bir şekilde test ederek dengelemenin haklı olduğundan emin olmaları gerekir. Yaygın bir desen, yüksek hacimli veri alımı ve veri dönüşümü için V-Order devre dışı bırakılmış bir hazırlık ambarı kullanmak ve temel verileri daha iyi okuma performansı için V-Order özellikli bir Veri Ambarı'na yüklemektir. Daha fazla bilgi için Microsoft Fabric'te Depoda V-Order'ı Devre Dışı Bırakma konusuna bakın.

Tabloları kopyalamak yerine tabloları klonlama

Fabric Data Warehouse içindeki tablo kopyaları, verileri kopyalamadan tablo oluşturmak için hızlı ve verimli bir yol sağlar. Sıfır kopya kopyalama yaklaşımıyla yalnızca tablonun meta verileri yinelenirken, temel alınan veri dosyalarına doğrudan OneLake'den başvurulur. Bu, kullanıcıların tam veri yineleme yükü olmadan neredeyse anında tutarlı, güvenilir tablo kopyaları oluşturmasına olanak tanır.

Sıfır kopya klonlar, geliştirme, test ve yedekleme gibi senaryolar için ideal olup, yüksek performanslı ve depolama açısından verimli bir çözüm sunarak altyapı maliyetlerini azaltmaya yardımcı olur.

  • Klonlanan tablolar, ilkeleri yeniden uygulamaya gerek kalmadan, kaynaktan Row-Level Güvenliği (RLS), Column-Level Güvenliği (CLS) ve Dinamik Veri Maskeleme (DDM) dahil tüm önemli güvenlik özelliklerini de kopyalar.
  • Klonlar, veri saklama süresi içinde belirli bir zaman noktasından itibaren oluşturulabilir ve zaman yolculuğu özelliklerini destekler.
  • Kopyalanan tablolar kaynaklarından bağımsız olarak bulunur, kaynakta yapılan değişiklikler kopyayı etkilemez ve kopyada yapılan değişiklikler kaynağı etkilemez. Kaynak veya klon bağımsız olarak bırakılabilir.

Sorgu meta verisi görünümleri

Görünümler hakkında queryinsights daha fazla bilgi için bkz. Fabric veri ambarında içgörüler.

Sorgu yaşam döngüsü üzerindeki DMV'ler hakkında daha fazla bilgi için DMV kullanarak bağlantıları, oturumları ve istekleri izleme sayfasını inceleyin.

İlgili içerik

  • Last updated on