Bir Staffing Operasyonunu Microsoft Fabric'e Taşırken Yakaladığım 4 Hata

Microsoft Fabric demoda kusursuz görünür. Bir veri kaynağı gösterirsiniz, bir Lakehouse kurarsınız, üzerine semantik model atarsınız ve Power BI raporu saniyeler içinde açılır. Herkes onaylar. Sorun üç hafta sonra, üretimde, operasyon gerçek ve veri dağınıkken başlar.

Yakın zamanda bir Hollandalı staffing ve konaklama operasyonunu — 2000’den fazla saha çalışanı, bordro, doluluk ve ulaşım verisi — dağınık Excel’ler ve yorgun bir SQL Server’dan alıp Fabric medallion mimarisine, üzerine Power BI ile taşıdım. Mimari diyagramı temizdi. İlk üretim haftaları değildi. İşte gerçekten önemli olan dört hata — hiçbiri hiçbir “Fabric’e başlangıç” eğitiminde geçmez.

Bunları yaşandığı gibi yazıyorum: ne bozuldu, nasıl fark ettim, neyi değiştirdim. Düzeltme sıkıcı kısımdır. Fark etmek ise asıl beceridir.

1. Direct Lake’in sessizce DirectQuery’ye düşmesi

Direct Lake, Fabric’te olmanın asıl sebebidir: semantik model Parquet’i doğrudan OneLake’ten okur, import yok, zamanlı refresh yok, import’a yakın performans. Vaat budur. Demonun asla göstermediği şey, Direct Lake’in sert sınırları olduğudur — kapasite SKU’su, tablo başına satır sayısı, model belleği. Bir sorgu bunları aşınca Fabric hata vermez. Sessizce DirectQuery’ye düşer, warehouse’a satır satır gider ve “anlık” raporunuz on saniyelik bir bekleme çarkına döner.

Raporlar doğru göründüğü için kimse bug açmadı. Sadece, konaklama ve vardiya tabloları büyüdükçe yavaş yavaş kötüleşiyorlardı. Bunu yakalamamın tek sebebi, sayıların doğru ama hissin yanlış olmasıydı — ve his, güvenmeyi öğrendiğim bir sinyal. Power BI Performance Analyzer ve Fabric kapasite metriklerinde doğruladım: Direct Lake olması gereken sorgular DirectQuery düşüşü gösteriyordu.

Çözüm “daha büyük kapasite al” değildi. Modelleme disipliniydi: semantik modeli raporların gerçekten kullandığı kolonlara indir, geniş dönüşümleri modele sürüklemek yerine gold katmanına it, ve sıcak tabloları düşüş eşiğinin altında tut. Direct Lake dar, bilinçli bir modeli ödüllendirir; Power BI Import modundan taşınan “her şeyi import et” alışkanlığını cezalandırır.

Ders: Direct Lake’te performans bir donanım kararı değil, modelleme kararıdır. Düşüşü izlemezseniz, platform size hiç söylemeden bozulur.

2. Tek kapasitenin aynı anda ingest, dönüşüm ve raporlama yapması

İlk düzgün tasarım her şeyi — gece ingest, medallion dönüşümleri ve etkileşimli Power BI — tek bir Fabric kapasitesinde çalıştırıyordu. Testte işe yaradı, çünkü test kimse kullanmazken yapılır.

Üretimde gece hattı ile sabah raporlaması çakıştı. Fabric’in kapasite throttling’i ve smoothing’i, ağır bir gece dönüşümünün sonraki birkaç saatlik compute’tan borç almasına yol açtı; böylece sabah 8’de dashboard’unu açan operasyon yöneticileri gece batch’inin yavaş, throttle’lanmış kuyruğunu aldı. Platform bozuk değildi; paylaşımlı bir kapasitenin yaptığını yapıyordu. Sadece en görünür kullanıcılara, en görünmez işin faturasını ödetiyordu.

İş yüklerini ayırdım: ağır arka plan işleri iş gününden çok önce bitip kapasiteyi serbest bırakacak şekilde zamanlandı ve boyutlandı, etkileşimli raporlama batch penceresinden korundu. Mesele belirli bir SKU değil — Fabric’te günün saatinin mimarinizin bir parçası olduğunu anlamaktır.

Ders: Fabric’te kapasite planlaması yalnızca boyutlandırma değil, zamanlamadır. Compute’u saate eşleyin, yoksa en yoğun kullanıcılarınız batch işlerinizi emer.

3. Medallion katmanlarını sözleşme değil klasör sanmak

Bronze, silver, gold üç kutu olarak çizilir ve onları arasında veri kopyaladığınız üç klasör sanmak cazip gelir. “Raporu çıkarmak için” bronze’da iş mantığı yapmaya, referans sandığınız OneLake shortcut’larıyla veri çoğaltmaya ve hiç değişmemiş şeyleri yeniden işleyen bir refresh’e böyle varırsınız.

Buradaki spesifik tuzak shortcut ile kopya farkıydı. OneLake shortcut bir işaretçidir; kopya ise artık sahibi olduğunuz ve refresh etmeniz gereken veridir. İkisini bilinçsizce karıştırmak, bazı “tek kaynak” tablolarının sessizce çoğaltılmasına, senkronu kaybetmesine ve her downstream refresh’i şişirmesine yol açtı.

Sınırları öneri değil kural olarak yeniden kurdum: bronze ham ve değişmez, silver temizlenmiş ve uyumlanmış (sunum mantığı yok), gold ise işin sorularını sorduğu şekle tam uygun. İş mantığı tek katmanda, bir kez yaşar.

Ders: Medallion, her tür işin nerede yapılmasına izin verildiğine dair bir sözleşmeler kümesidir. Bir katman başkasının işini yaptığı an, hem refresh maliyetiniz hem güveniniz sızmaya başlar.

4. Incremental refresh yokluğu — her gece dünyayı yeniden yüklemek

Pilot boyutunda her gece tam yükleme görünmezdir; dakikalar içinde biter. 2000+ çalışan, günlük doluluk, bordro ve ulaşım hareketleriyle “her şeyi yeniden yükle” artık bedava değildir. Refresh penceresi uzadı, sabaha taşmaya başladı.

Veri büyük ölçüde append-only’di — dün değişmez — ama hat, kimse aksini söylemediği için her gece tüm geçmişi yeniden okuyordu. Çözüm doğru partitioning’li incremental refresh oldu: yalnızca gerçekten değişen pencereyi işle, yerleşmiş geçmişe dokunma. Refresh penceresi sessiz saatlerde rahatça biten bir şeye geri çöktü.

Ders: Pilot ölçekte “yeterince hızlı” bir tuzaktır. Altıncı aydaki veri hacmine göre tasarlayın ve hattın yalnızca değişene dokunmasını sağlayın.

Neden yazdım

Bu dört hatanın hiçbiri bir kavram kanıtında görünmez. Üçüncü hafta, gerçek hacim ve gerçek kullanıcılarla ortaya çıkarlar — tam da en pahalı bulundukları ve açıklaması en utandırıcı oldukları an. Fabric gerçekten güçlü bir platform; buradaki hatalar Fabric’in suçu değil, demoda çalışan bir geçişle operasyonda çalışan bir geçiş arasındaki farktır.

Operasyonunuzu Fabric’e taşıyorsanız ve bunların biri zaten başınıza geliyorsa, benim iyi olduğum konuşma tam bu. Ne kurduğunuzu anlatın.