Microsoft Fabric kapasitenizi değerlendirme ve iyileştirme

Bu makalede, Microsoft Fabric kapasitelerinizdeki yükü değerlendirme ve iyileştirme açıklanmaktadır. Ayrıca aşırı yükleme durumlarını ele alma stratejilerini açıklar ve doku deneyimlerinin her biri için işlem iyileştirmeye yardımcı olacak yönergeler sağlar.

Doku kapasite modeli kurulumu basitleştirip işbirliğine olanak sağlarken, kapasitenin paylaşılan işlem kaynaklarının tükenme olasılığı yüksektir. Ayrıca gerektiğinden daha fazla kaynak için ödeme yapıyor olabilirsiniz. Bazı Hizmet Yapısı deneyimlerinin tasarımı en iyi uygulamalara uymadığında bu tür durumlar yaşanabilir.

Paylaşılan kaynakların tükenme riskini azaltmak önemlidir. Yönetilen hizmet olarak Doku, bu tür durumları otomatik olarak iki şekilde ele alır.

• Patlama ve yumuşatma, yoğun CPU kullanan etkinliklerin daha yüksek bir SKU gerektirmeden hızlı bir şekilde tamamlanmasını sağlar (ve günün herhangi bir saatinde çalıştırılabilir).
• Boğma, bir kapasite sürekli olarak yüksek ve yoğun CPU talebiyle karşılaştığında (SKU sınırının üzerinde), işlemleri geciktirir veya reddeder.

Yumuşatma, kısıtlama olasılığını azaltır (kısıtlama yine de gerçekleşebilir). Düzgünleştirme, kullanımın sınırlarla karşılaştırılarak nasıl dağıtıldığını gösterir, ancak işlerin yürütülmesinden bağımsızdır. Düzeltme performansı değiştirmez, yalnızca tüketilen işlem hesaplamasını daha uzun bir süreye yayar, böylece en yüksek işlem için daha büyük bir SKU'ya ihtiyaç duyulmaz.

Fabric kapasitesi hakkında daha fazla bilgi edinmek için bkz. Microsoft Fabric kavramları ve lisansları ve Fabric Kapasiteleri – Yenilikler ve gelecek hakkında bilmeniz gereken her şey.

Planlama ve bütçe araçları

Kapasite boyutunu planlamak zor olabilir. Bunun nedeni, gerçekleştirilen işlemler, ne kadar iyi yürütüldükleri (örneğin, bir DAX sorgusunun verimliliği veya not defterindeki Python kodu) veya eşzamanlılık düzeyi nedeniyle gerekli işlemin büyük ölçüde değişebileceğidir.

Doğru kapasite boyutunu belirlemenize yardımcı olmak için, F SKU ayrılmış örneğini satın almadan önce gereken gerçek kapasite boyutunu ölçmek amacıyla deneme kapasiteleri veya kullandıkça öde F SKU'ları sağlayabilirsiniz.

İpucu

Küçük bir başlangıç yapmak ve ardından kapasitenizin boyutunu gerektiği gibi kademeli olarak artırmak her zaman iyi bir stratejidir.

Kapasiteleri izleme

Kapasitelerinizden en iyi şekilde yararlanmak için kullanımı izlemeniz gerekir. Her şeyden önce, Fabric işlemlerinin ya etkileşimli ya da arka planlı olduğunu anlamak önemlidir. Örneğin, bir Power BI raporundaki DAX sorguları etkileşimli işlemler olan isteğe bağlı istekler, anlamsal model yenilemeleri ise arka plan işlemleridir. İşlemler ve Fabric içindeki kaynakları nasıl kullandıkları hakkında daha fazla bilgi için Fabric işlemleri bölümüne bakın.

İzleme, hız sınırlamasının gerçekleştiğini ortaya çıkarabilir. Çok sayıda veya uzun süre çalışan etkileşimli işlemler olduğunda yavaşlatma/sınırlama gerçekleşebilir. Genellikle SQL ve Spark deneyimleriyle ilgili arka plan işlemleri düzeltilir ve bu da 24 saatlik bir süreye yayıldığı anlamına gelir.

Doku Kapasitesi Ölçümleri Uygulaması , son kullanımı izlemenin ve görselleştirmenin en iyi yoludur. Uygulama öğe türüne (anlam modeli, not defteri, işlem hattı ve diğerleri) ayrılır ve yüksek işlem düzeyleri kullanan öğeleri veya işlemleri tanımlamanıza yardımcı olur (böylece iyileştirilebilirler).

Yöneticiler, sık kullanılan öğeler (ve genel benimseme) hakkında bilgi edinmek için Yönetici izleme çalışma alanını kullanabilir. Kiracıdaki mevcut ve son etkinlikleri görüntülemek için İzleme Merkezi'ni de kullanabilirler. Bazı işlemler hakkında daha fazla bilgi için Log Analytics veya on-premises data gateway logs de kullanılabilir.

Yüksek işlem kullanımını yönetme

Kapasite yüksek oranda kullanıldığında ve azaltma veya reddetme göstermeye başladığında, bunu çözmek için üç strateji vardır: iyileştirme, ölçeği artırma ve ölçeği genişletme.

Kapasite kullanımının belirlenen eşiği aştığını öğrenmek için bildirimleri ayarlamak iyi bir uygulamadır. Ayrıca, işlemlerin boyutunu sınırlamak için iş yüküne özgü ayarları kullanmayı göz önünde bulundurun (örneğin, Power BI sorgu zaman aşımı veya satır sınırları veya Spark çalışma alanı ayarları).

Optimize Etmek

İçerik oluşturucular, verimli olduğundan ve mümkün olan en düşük işlem kaynaklarını kullandığından emin olmak için her zaman Yapı öğelerinin tasarımını iyileştirmelidir. Bu makalede her Fabric deneyimi için özel yönergeler sağlanmıştır.

Ölçek büyütme

SKU boyutunu (daha fazla işlem kapasitesiyle) geçici veya kalıcı olarak artırmak için kapasiteyi artırırsınız. Ölçeği artırma, kapasitedeki tüm öğeler için yeterli hesaplama kaynaklarının olmasını sağlayarak kısıtlamayı önler.

Ayrıca, tüketim eğilimlerine uyumlu hale getirmek için Fabric F SKUs'u yeniden boyutlandırabilir, duraklatabilir ve devam ettirebilirsiniz.

Yatay ölçeklendirme

İş yükünü yaymak için bazı çalışma alanlarınızı veya öğelerinizi farklı bir Doku kapasitesine taşıyarak ölçeği genişletirsiniz. Farklı kapasite stratejileri, ayarları veya yöneticileri gerektiğinde iyi bir seçenek olabilir. Birden fazla kapasite sağlamak, yüksek öncelikli öğeler ve kendin yap veya geliştirme içeriği için hesaplama işlemlerini yalıtmaya yardımcı olan iyi bir stratejidir. Örneğin, kuruluşunuzdaki yöneticiler son derece hızlı yanıt veren raporlar ve panolar bekler. Bu raporlar ve panolar, yönetici raporlamaya ayrılmış ayrı bir kapasitede bulunabilir.

Tüketicilerin içeriğe erişmeye devam etmelerini sağlayan Power BI Pro lisansları olması koşuluyla, Power BI çalışma alanlarını paylaşılan kapasiteye taşımayı da düşünebilirsiniz.

Aşırı gerilim korumasını yapılandırma

Aşırı Gerilim koruması, işlem arka plan işlerinin tükettiği toplam miktarı sınırlayarak kapasitenizin aşırı kullanılmasını sınırlandırmanıza yardımcı olur. Bu, etkileşimli gecikmelerin veya reddetmelerin daha az olası olması için toplam işlemi azaltır. Eğer azaltma veya reddetme aşaması varsa, kapasitenin daha hızlı iyileşmesine de yardımcı olur. Her kapasite için aşırı gerilim korumasını yapılandırabilirsiniz. Aşırı gerilim koruması hız sınırlamalarını ve reddetmeleri önlemeye yardımcı olur, ancak kapasite optimizasyonu, ölçeği artırma ve genişletmenin yerini tutmaz.

Aşırı gerilim koruması etkin olduğunda arka plan işleri reddedilir. Bu, aşırı gerilim koruması etkinleştirildiğinde bile kapasiteniz üzerinde bir etki olduğu anlamına gelir. Aşırı gerilim korumasını kullanarak, kapasite içinde işlem gereksinimlerini en iyi dengeleyen bir kullanım aralığı içinde kalmak için kapasitenizi ayarlarsınız. Kritik çözümleri tam olarak korumak için bunları doğru boyutta bir kapasitede yalıtmak önerilir.

"Fabric deneyimi ile hesaplama optimizasyonu"

Fabric'deki deneyimler ve öğeler farklı çalışır, bu nedenle bunları aynı şekilde optimize etmeniz gerekmez. Bu bölümde Fabric öğeleri deneyime göre listelenir ve bunları optimize etmek için gerçekleştirebileceğiniz eylemler listelenir.

Yapı Data Warehouse

Veri ambarı sunucusuz bir mimari kullanır ve düğümleri hizmet tarafından otomatik olarak yönetilir. Kapasite kullanımı, ön uç ve arka uç düğümlerinin sağlanma süresi yerine sorgu başına etkin kapasite birimi saniyelerine göre hesaplanır.

Tüm veri ambarı işlemleri arka plan işlemleridir ve 24 saatlik bir süre boyunca düzeltilir .

SQL analizi uç noktası, varsayılan olarak bir performans deneyimi sağlamayı amaçlar. Bu amaçla, SQL Server veya Azure Synapse Analytics ayrılmış SQL havuzlarına kıyasla daha az sorgu ayarlama seçeneği vardır.

İşlemi en aza indirmeye yardımcı olmak için göz önünde bulundurmanız gereken bazı noktalar aşağıdadır.

• Mümkün olan en uygun T-SQL'i kullanarak sorgular yazın. Mümkün olduğunda, sorgu kaynağı kullanımını gereksiz yere artırabilecek sütunların, hesaplamaların, toplamaların ve diğer işlemlerin sayısını sınırlayın.
• Tabloları mümkün olan en küçük veri türlerini kullanacak şekilde tasarlar. Veri türü seçiminiz, SQL altyapısı tarafından oluşturulan sorgu planlarını büyük ölçüde etkileyebilir. Örneğin, bir VARCHAR alanının uzunluğunun 500'den 25'e düşürülmesi veya DECIMAL(32, 8)'in DECIMAL(10, 2) olarak değiştirilmesi, sorgu için ayrılan kaynaklarda önemli bir azalmaya neden olabilir.
• Okunan satır sayısını azaltmak ve sorgu birleştirmelerini en aza indirmek için yıldız şeması tasarımını kullanın.
• İstatistiklerin mevcut olduğundan ve güncel olduğundan emin olun. İstatistikler, en uygun yürütme planının oluşturulmasında önemli bir rol oynar. Çalışma zamanında otomatik olarak oluşturulurlar ancak özellikle veriler yüklendikten veya güncelleştirildikten sonra bunları el ile güncelleştirmeniz gerekebilir. Örneklemeyi kullanan otomatik oluşturulan istatistiklere güvenmek yerine, FULLSCAN seçeneğini kullanarak istatistik oluşturmayı göz önünde bulundurun.
• Özellikle sorunları giderirken sorguları ve kullanımı izlemek için yerleşik görünümleri kullanın.
  • sys.dm_exec_requests dinamik yönetim görünümü (DMV), etkin olarak yürütülen tüm sorgular hakkında bilgi sağlar, ancak geçmiş bilgileri depolamaz. Doku Araç Kutusu bu DMV'yi kullanan bir sorgu sağlar ve sorgu metni gibi ayrıntıları sağlamak için diğer görünümlere katılarak sorgu sonucunu kullanıcı dostu hale getirir.
  • Doku veri ambarı özelliğinin bir özelliği olan sorgu içgörüleri, SQL analiz uç noktasında geçmiş sorgu etkinliğinin bütünsel bir görünümünü sağlar. Özellikle, queryinsights.exec_requests_history görünümü tamamlanan her SQL isteği hakkında bilgi sağlar. Kapasite kullanımını izlemek için en önemli sütunlar: distributed_statement_id, komut (sorgu metni),sql_pool_name, allocated_cpu_time_ms, start_time ve end_time sütunlarıdır.

Doku Veri Madenciliği ve Doku Veri Bilimi

Veri Mühendisliği ve Veri Bilimi deneyimleri, verileri bir Fabric lakehouse'ta işlemek, analiz etmek ve depolamak için Spark hesaplamasını kullanır. Spark hesaplama, vCores açısından ayarlanır ve ölçülür. Ancak, Fabric; Spark not defterleri, Spark iş tanımları ve lakehouse işleri gibi çeşitli öğeler tarafından tüketilen işlem gücünü ölçmek için CU'ları kullanır.

Spark'ta bir CU, iki Spark vCore hesaplama anlamına gelir. Örneğin, bir müşteri F64 SKU satın aldığında, Spark deneyimleri için 128 Spark vCore mevcuttur.

Tüm Spark işlemleri arka plan işlemleridir ve 24 saatlik bir süreye yayılır.

Daha fazla bilgi için bkz . Fabric Spark'ta faturalama ve kullanım raporlama.

İşlemi en aza indirmeye yardımcı olmak için göz önünde bulundurmanız gereken bazı noktalar aşağıdadır.

• Her zaman verimli Spark kodu yazmaya çalışın. Daha fazla bilgi için bkz. Azure Synapse Analytics'te Apache Spark işlerini optimize etme ve Apache Spark'ta yazmayı optimize etme gerekliliği.
• Diğer Spark işleri veya iş yükleri için kaynakları boşaltmak için Spark işleriniz için gerekli yürütücüleri ayırın. Aksi takdirde, Spark işlerinin HTTP 430 durumuyla başarısız olma olasılığını artırırsınız; bu da kapasite için çok fazla istek olduğu anlamına gelir. Fabric izleme merkezinde bir notebook'a ayrılan yürütücü sayısını görüntüleyebilirsiniz. Burada not defteri tarafından kullanılan yürütücülerin gerçek sayısını da belirleyebilirsiniz. Spark işleri yalnızca gerekli düğümleri ayırır ve SKU sınırları içinde paralel gönderimlere izin verir.
• Spark havuzu yalnızca SKU tarafından desteklenen sanal çekirdek sayısı üst sınırını kullanacak şekilde yapılandırılabilir. Ancak, SKU sınırları içinde paralel Spark işlerini kabul ederek veri mühendisliği iş yüklerinin ölçeğini genişletebilirsiniz. Bu yaklaşım genellikle seri artış faktörü olarak bilinir ve Spark iş yükleri için kapasite düzeyinde varsayılan olarak etkinleştirilir. Daha fazla bilgi için bkz . Eşzamanlılık azaltma ve kuyruğa alma.
• Etkin Spark oturumları, bir kapasitede CU kullanımını artırabilir. Bu nedenle, kullanılmadığında etkin Spark oturumlarını durdurmak önemlidir. Varsayılan Spark oturumu süre sonu süresinin 20 dakika olarak ayarlandığını unutmayın. Kullanıcılar bir not defterinde veya Spark iş tanımında oturum zaman aşımını değiştirebilir.

Gerçek Zamanlı Analiz

KQL veritabanı CU tüketimi, veritabanının etkin olduğu saniye sayısına ve kullanılan sanal çekirdek sayısına göre hesaplanır. Örneğin, veritabanınız dört sanal çekirdek kullandığında ve 10 dakika boyunca etkin olduğunda 2.400 (4 x 10 x 60) saniye CU kullanırsınız.

Tüm KQL veritabanı işlemleri etkileşimli işlemlerdir.

KQL veritabanınızın boyutunu belirlemek için otomatik ölçeklendirme mekanizması kullanılır. Kullanım desenlerine göre en uygun maliyetli ve en iyi performansın elde edilmesini sağlar.

Verilerin diğer Doku altyapıları tarafından kullanılabilir duruma gelmesine izin vermek için KQL veritabanı OneLake ile eşitlenir. KQL veritabanınızın gerçekleştirdiği okuma ve yazma işlemlerinin sayısına bağlı olarak, kapasitenizden CU'lar kullanılır. Azure Data Lake Storage (ADLS) 2. Nesil hesaplarında okuma ve yazma işlemlerine eşdeğer olan OneLake Okuma ve Yazma ölçümlerini kullanır.

Veri Fabrikası

Bu bölüm Data Factory'deki veri akışları ve işlem hatları için iyileştirmelerle ilgilidir.

Tüm işlemler arka plan işlemleridir ve 24 saatlik bir süre boyunca yumuşatılır.

İşlemi en aza indirmeye yardımcı olmak için göz önünde bulundurmanız gereken bazı noktalar aşağıdadır.

• Birleştirme ve sıralama gibi pahalı veri dönüşümlerini en aza indirmek ve iyileştirmek için verimsiz Power Query mantığından kaçının.
• Sorgu katlamayı mümkün olduğunda gerçekleştirmeye çalışın. Veri kaynağı ile hedef arasında aktarılması gereken veri miktarını azaltarak veri akışlarınızın performansını artırabilir. Sorguyu kaynağa döndürme gerçekleşmediğinde, Power Query veri kaynağındaki tüm verileri alır ve verimsiz ve yavaş olabilecek dönüştürmeleri yerel olarak gerçekleştirir.
• Küçük veri birimleriyle çalışırken ve/veya basit dönüştürmeler gerçekleştirirken hazırlamayı devre dışı bırakın. Hazırlama, veri ambarı yüklerken olduğu gibi bazı durumlarda gerekli olabilir.
• Verileri veri kaynağının gerektirdiğinden daha sık yenilemekten kaçının. Örneğin, veri kaynağı yalnızca 24 saatte bir güncelleştirilirse verilerin saatlik olarak yenilenmesi daha fazla değer sağlamaz. Bunun yerine, güncel ve doğru olduğundan emin olmak için verileri uygun sıklıkta yenilemeyi göz önünde bulundurun.

Power BI

Power BI işlemleri etkileşimli veya arka plandır.

Aşağıdaki etkileşimli işlemler genellikle yüksek işlem kullanımına neden olur.

• En iyi yöntemleri izlemeyen anlamsal modeller. Örneğin, bire çok ilişkileriyle yıldız şeması tasarımını benimsemeyebilirler. Ya da karmaşık ve pahalı satır düzeyi güvenlik (RLS) filtreleri içerebilir. En iyi yöntemlerin izlenip izlenmediğini belirlemek için Tablosal Düzenleyici ve En İyi Yöntem Çözümleyicisi'ni kullanmayı göz önünde bulundurun.
• DAX ölçüleri verimsizdir.
• Rapor sayfaları çok fazla görsel içeriyor ve bu da görselin yavaş yenilemesine neden olabilir.
• Rapor görselleri yüksek kardinalite sonuçları (çok fazla satır veya sütun) görüntüler veya çok fazla ölçü içerir.
• Kapasite boyutuna göre çok fazla kullanıcı olması nedeniyle kapasite yüksek eşzamanlılık yaşar. Yüksek eşzamanlılık semantik modellerinde kullanıcı deneyimini geliştirmek için sorgu ölçeği genişletmeyi etkinleştirmeyi göz önünde bulundurun (ancak daha fazla işlem elde edilmesini sağlamaz).

Aşağıdaki arka plan işlemleri genellikle yüksek işlem kullanımına neden olur.

• Power Query mantığındaki verimsiz veya aşırı karmaşık veri dönüştürmeleri.
• Büyük veri tabloları için sorgu katlama veya artımlı yenilemenin olmaması.
• Power BI raporlarının veya sayfalandırılmış raporların aynı anda oluşturulması anlamına gelen rapor patlamaları.

İlgili içerik

• Microsoft Fabric kavramları ve lisansları
• Blog: Fabric Kapasiteleri – Yeni özellikler ve yakında gelecek olanlar hakkında bilmeniz gereken her şey

Başka sorunuz var mı? Lütfen Fabric Topluluğu'na sormayı deneyin.