POWER QUERY’DE HATA AYIKLAMA: KAYNAK DEĞİŞİNCE BOZULMAYAN AKIŞLAR

Power Query ile dönüşüm akışını kurmak kolaydır; zor olan, o akışın aylar sonra da aynı şekilde çalışmasını sağlamaktır. Veri kaynağına yeni bir sütun eklendiğinde, isimler değiştiğinde veya türler kaydığında “Bir önceki yenileme neden çalışıyordu?” sorusu bir anda gündeminize oturur. Bu yazıda odağımız, Power Query’de hata ayıklamayı sistematik hale getirip akışları kaynak değişikliklerine dayanıklı tasarlamak.

Kurumsal ortamlarda veri, tek bir Excel dosyasından ibaret değildir: SharePoint listeleri, SQL görünümleri, API çıktıları, CSV’ler, Dataflow’lar ve Gateway üzerinden yenilenen raporlar aynı zincirin parçası olabilir. Bu zincirdeki en küçük değişim bile, Power Query adımlarında kırılma yaratabilir. İyi haber: doğru desenlerle, “kırılgan” akışları “esnek” akışlara çevirmek mümkün.

Aşağıdaki bölümlerde Power Query hata ayıklama yaklaşımını, şema drift (kolon ve tür kayması) yönetimini, try...otherwise ile güvenli dönüşümleri, performans ve query folding kontrolünü ve en sık yenileme hatalarının kök neden analizini ele alacağız. Son bölümde ayrıca kurum içi yetkinlik geliştirmek isteyenler için ilgili eğitim sayfasına yönlendirme bulacaksınız.

Primary keyword: Power Query hata ayıklama yaklaşımı

Power Query hata ayıklama, yalnızca hatayı “düzeltmek” değil; hatanın neden oluştuğunu bulup aynı sınıftaki sorunların tekrarını engellemek demektir. Bu yüzden ilk iş, hatayı ekranda gördüğünüz noktadan değil, hatayı üreten veri/şema değişikliğinden okumaktır. En sık karşılaşılan kırılmalar şunlardır: eksik sütun, beklenmeyen veri tipi, boş değerlerin artması, locale kaynaklı tarih-sayı parse sorunları ve query folding davranışının değişmesi.

Hatanın türünü doğru okumak: mesaj, adım ve örnek satır

Power Query hata mesajı genelde üç ipucu verir: hangi adımda patladı, hangi sütun/alanla ilgili ve örnek bir değer. “The column ‘X’ of the table wasn’t found” gibi bir hata, kaynağın şemasının değiştiğini (kolon adı farklılaştığını veya kaldırıldığını) işaret eder. “We couldn’t convert to Number” gibi dönüşüm hataları ise veri tipinin kaydığını veya temizleme adımlarının eksik kaldığını anlatır.

Adımları tek tek izole etmek: “Last Step” yerine “First Broken Step”

Akış bozulduğunda çoğu kişi son adımı kurcalar. Daha hızlı yöntem: en son çalışan adımı bulun, ardından bir sonraki adımı devreye alın ve kırılmanın başladığı noktayı yakalayın. Bu, özellikle uzun transform zincirlerinde kritik. Power Query arayüzünde adımlara tıklayarak önizlemeyi kontrol edin; gerekirse kırılan adımın üstünde geçici bir “Buffer” veya “Keep Errors” yaklaşımıyla veriyi gözleyin (performans etkisini ayrıca ele alacağız).

Tekrarlanabilir hata üretmek: sabit örnek ve test sorgusu

Kurumsal ekiplerde “bende çalışıyor” tartışmasını bitiren şey, tekrarlanabilir testtir. Kaynaktan küçük bir örnek alıp (örneğin 1000 satır veya belirli tarih aralığı) aynı adımları ayrı bir test sorgusunda koşturun. Böylece hem geliştirme hem prod yenileme senaryosunu karşılaştırmak kolaylaşır. Ayrıca bu yaklaşım, Power Query’de hata ayıklama sırasında performans düşüşünü yönetmenize yardımcı olur.

Şema drift yönetimi: Kolon değişse bile bozulmayan dönüşümler

Şema drift, veri kaynağındaki kolonların isimlerinin değişmesi, yeni kolon eklenmesi, kolonun kaldırılması veya veri tipinin kaymasıdır. Power Query’de kırılganlık genellikle “kolonları seç/yeniden adlandır/tür dönüştür” adımlarının sabit şema varsayması yüzünden oluşur. O yüzden hedefiniz, değişken şemayı tolere eden desenler kurmak.

Sütun seçimini güvenli hale getirmek: eksik varsa atla

Birçok akışta “Removed Other Columns” gibi bir adım bulunur. Kaynak kolon isimleri değişirse, seçili liste bozulur. Alternatif: önce kolonların kesişimini bulup yalnızca var olanları seçmek. Böylece kaldırılan kolonlar yüzünden yenileme tamamen durmaz; rapor tarafında eksik alanı daha kontrollü ele alırsınız.

let
    Source = Excel.Workbook(File.Contents(Parameter_FilePath), null, true),
    Raw = Source{[Item="Data",Kind="Table"]}[Data],
    Wanted = {"OrderId","CustomerId","OrderDate","Amount","Channel"},
    Existing = List.Intersect({Wanted, Table.ColumnNames(Raw)}),
    SafeSelect = Table.SelectColumns(Raw, Existing, MissingField.Ignore)
in
    SafeSelect

Burada kritik nokta MissingField.Ignore. Bu sayede “Wanted” listesindeki kolon yoksa hata fırlatmak yerine görmezden gelir. Tabii bu tasarım kararını bilinçli almak gerekir: kritik bir kolonsa rapor kalitesi düşebilir. Bu yüzden çoğu ekip, “kritik alan yoksa fail et, opsiyonelse ignore et” kuralı uygular.

Tür dönüşümünde dayanıklılık: tip kayarsa kontrol et

“Changed Type” adımı sık kırılır; çünkü kaynakta sayı alanı bir gün “12,50” (metin) gelmeye başlar veya tarih alanına boş/invalid değer düşer. Bu noktada Power Query hata ayıklama yerine hata üretmeyen dönüşüm yazmak daha iyi: önce normalize et (locale), sonra try ile dönüştür, başarısızsa null veya varsayılan değer üret.

Kolon adını sabitlemek yerine semantik eşleme kullanmak

Kaynak ekipler kolon adını “Order Date” yapar, sonra “OrderDate” yapar, sonra “SiparisTarihi” gelir. Eğer elinizde bir sözlük/eşleme tablosu varsa, kolonları doğrudan isimle yakalamak yerine olası adları haritalayıp tek bir kanonik isme getirmeniz akışı stabil kılar. Bu yaklaşım, özellikle farklı ülke/locale kaynaklarıyla çalışan global ekiplerde işe yarar.

try...otherwise ile güvenli dönüşümler ve kontrollü hata yönetimi

Power Query’de try...otherwise, hata ayıklama için değil, hata yönetimi için temel araçtır. Ama yanlış kullanılırsa hataları gizleyip veri kalitesi sorunlarını raporda görünmez hale getirir. Doğru kullanım: hatayı yakala, alternatif üret ve gerekiyorsa ayrı bir log/diagnostic tabloya yaz.

Veri tipi dönüşümünü güvenli yapmak

Aşağıdaki örnek, “Amount” alanı bazen metin geldiğinde bile sorgunun çalışmasını sağlar. Başarısız dönüşümde null üretir; ardından kalite kontrol adımlarında null oranını izleyebilirsiniz.

let
    Source = Table.Buffer(Raw),
    CleanAmount = Table.TransformColumns(
        Source,
        {{"Amount", each try Number.FromText(Text.Replace(_, ",", ".")) otherwise null, type number}}
    ),
    CleanDate = Table.TransformColumns(
        CleanAmount,
        {{"OrderDate", each try Date.From(_) otherwise null, type date}}
    )
in
    CleanDate

Not: Burada Table.Buffer her senaryoda şart değildir; bazı kaynaklarda query folding’i bozabilir. Ama CSV/Excel gibi yerel kaynaklarda tekrar okuma maliyetini azaltabilir. Performans bölümünde hangi durumda kullanılacağını ayrıca konuşacağız.

Hataları “gizlemek” yerine görünür kılmak

Kurumsal karar vericiler için en kötü senaryo: yenileme “başarılı” görünür ama veri hatalıdır. Bu yüzden try...otherwise kullanırken ikinci bir çıktı üretmek iyi bir pratiktir: hatalı satırları ayrı bir sorguda toplamak, raporda bir uyarı kartı göstermek veya yenileme sonrası kontrollerde eşik aşılırsa bildirim üretmek. Power Query tek başına bildirim atmaz; fakat Dataflow/Refresh izleme süreçleriyle entegre edebilirsiniz.

Kritik alan yoksa kontrollü kırılma tasarlamak

Bazı alanlar “olmazsa olmaz”dır: OrderId yoksa tablo işe yaramaz. Bu durumda MissingField.Ignore yerine MissingField.Error kullanıp net bir hata mesajı üretmek daha sağlıklıdır. Hedef: hata olduğunda hızla teşhis edilebilir bir mesaj bırakmak. “Column not found” yerine “OrderId bulunamadı: kaynak şema değişmiş olabilir” gibi bir iş mesajı tercih edin.

Adım tasarımı: Kırılgan adımları azaltan M dili desenleri

Power Query’de dayanıklılık, çoğu zaman adımları “azaltmak” değil; adımları niyet odaklı yazmaktır. Arayüzün ürettiği otomatik adımlar (Removed Other Columns, Changed Type vb.) hızlıdır ama kaynak değişimlerinde kırılgandır. M diliyle daha kontrollü ve yeniden kullanılabilir desenler kurabilirsiniz.

Fonksiyonlaştırma: aynı dönüşümü farklı kaynaklara uygulamak

Bir dönüşümü fonksiyon haline getirip farklı kaynaklara uyguladığınızda iki kazanım elde edersiniz: (1) değişiklik tek yerde yapılır, (2) test etmek kolaylaşır. Örneğin bir “NormalizeColumns” fonksiyonu, kolon adlarını standartlaştırabilir, gerekli kolonları kontrol edebilir ve tip dönüşümlerini güvenli biçimde yapabilir.

Parametreleştirme: dosya yolu, tarih aralığı, ortam seçimi

Prod ve dev ortamları arasında dosya yolu veya sunucu adı farklıysa, sorgu adımlarını elle değiştirmek kaçınılmaz hatalara yol açar. Bunun yerine Parameter Query kullanın: FilePath, Environment, StartDate gibi parametreler ile tek akışın farklı ortamlarda çalışmasını sağlayın. Bu sayfada yer alan Power Query & Power Pivot eğitimi içeriklerinde parametre tasarımı ve kurumsal modelleme pratikleri de ele alınır.

Kolon ekleme ve dönüşümleri “tek noktada” toplamak

Araya serpiştirilmiş 20 küçük adım yerine, aynı amaçtaki dönüşümleri birlikte toplamak hata ayıklamayı hızlandırır. Örneğin tüm tip dönüşümlerini tek Table.TransformColumnTypes adımında (veya kontrollü try dönüşümlerinde) tutmak; kolon adlandırmaları için ayrı bir blok kullanmak iyi bir düzen sağlar. Bu düzen, “First Broken Step” yaklaşımını da güçlendirir.

Performans ve query folding: Hata ayıklarken sistemi yavaşlatmadan ilerlemek

Power Query hata ayıklama sürecinde, doğru sonucu görmek kadar, doğru performansı korumak da önemlidir. Özellikle SQL gibi katlanabilir (foldable) kaynaklarda, bir adım query folding’i bozduğunda hem yenileme süresi uzar hem de gateway kaynak tüketimi artar. Üstelik performans düşüşü, hatanın kaynağını maskeleyebilir: timeout hataları gerçek veri sorunlarını saklar.

Query folding nerede kırılıyor?

Katlanabilir kaynaklarda “View Native Query” seçeneği, adımın fold edilebilir olup olmadığını anlamanıza yardımcı olur. Kırılma genellikle şu tür adımlarda olur: özel M fonksiyonları, satır bazında karmaşık Text işlemleri, Table.Buffer, bazı custom join desenleri. Folding kırılınca Power Query tüm veriyi istemci tarafına çekip işlemi yerelde yapmaya başlar.

Hata ayıklama için küçük örnekle çalış, sonra büyüt

Ayıklama sırasında veri setini küçültmek, hem daha hızlı iterasyon sağlar hem de gateway limitlerine takılmayı önler. Kaynakta filtreyi mümkün olduğunca erken uygulayın (özellikle SQL tarafında) ve dönüşümlerin mantığını küçük örnek üzerinde doğrulayın. Ardından filtreyi kaldırıp gerçek hacimde test edin. Buradaki kritik: filtre adımı fold edilebilirken ek filtreler fold edilmeyebilir; bu yüzden adım sırası önemlidir.

Table.Buffer ne zaman işe yarar, ne zaman zarar verir?

Table.Buffer, aynı veriye birden fazla kez dokunan adımlarda tekrar okuma maliyetini azaltabilir. Ancak katlanabilir kaynaklarda folding’i bozarak toplam maliyeti artırabilir. Kural: Buffer’ı, folding zaten kırılmışsa veya yerel dosya/CSV gibi kaynaklarda tekrar okuma yükü varsa düşünün. Aksi halde, performans sorunu büyüyebilir. Bu yüzden buffer ekledikten sonra mutlaka yenileme süresini ve kaynak tüketimini ölçün.

Yenileme (refresh) hataları: Kurumsal senaryolarda en sık kök nedenler

Geliştirme ortamında çalışan bir sorgunun prod yenilemede patlaması çok yaygındır. Çünkü prod’da farklı veri hacmi, farklı erişim hakları, gateway kısıtları ve zamanlanmış yenileme koşulları devreye girer. Dayanıklı akışlar tasarlamak için en sık kök nedenleri bilmek faydalıdır.

Erişim ve kimlik doğrulama farkları

Desktop’ta oturumunuzla eriştiğiniz bir kaynağa, service hesabı erişemeyebilir. Bu durumda “Data source credentials” hataları veya boş sonuçlar görürsünüz. Çözüm: kimlik doğrulama modelini netleştirmek, gateway üzerindeki bağlantı sahipliğini doğru yapılandırmak ve mümkünse kaynak erişimini servis kimliğiyle test etmek. Hata ayıklamada, aynı sorguyu servis hesabı koşullarına yakın bir kullanıcıyla denemek teşhisi hızlandırır.

Zaman aşımı ve kapasite sınırları

Veri büyüyünce, daha önce sorun çıkarmayan bir adım timeout üretebilir. Bu her zaman “performans” değildir; bazen hatalı bir join, veri çoğalmasına (row explosion) yol açar. Join sonrası satır sayısını kontrol edin, anahtarların tekilliğini doğrulayın ve mümkünse join’i kaynakta (SQL) fold edecek şekilde tasarlayın. Ayrıca, büyük metin işlemlerini mümkün olduğunca geç aşamaya bırakın.

Locale ve bölgesel ayarlar kaynaklı parse sorunları

Bir ortamda “1.234,56” sayı iken diğerinde “1,234.56” olabilir. Tarihler “DD.MM.YYYY” iken “MM/DD/YYYY” gelebilir. Bu tip sorunlar genelde “Changed Type” adımında patlar. Çözüm: dönüştürmeyi açıkça tanımlamak, metinden sayıya dönüşümde kullanılan ayırıcıları normalize etmek ve kritik alanları try...otherwise ile kontrollü ele almak.

Dayanıklı akışlar için kontrol listesi: tasarım, test ve izleme

Power Query’de “bozulmayan” akış hedefi, tek bir sihirli ayarla değil; tasarım + test + izleme disiplininin birleşimiyle yakalanır. Aşağıdaki kontrol listesi, ekiplerin standartlaştırması için pratik bir başlangıç sunar.

Hızlı kontrol listesi

• Kritik kolonlar için varlık kontrolü yapıldı mı (yoksa net hata)?
• Opsiyonel kolonlarda MissingField.Ignore gibi güvenli seçim kullanıldı mı?
• Tip dönüşümleri için try...otherwise stratejisi belirlendi mi (null/varsayılan/başka alan)?
• Şema drift için kolon eşleme/sözlük yaklaşımı düşünüldü mü?
• Katlanabilir kaynaklarda query folding kırılma noktaları kontrol edildi mi?
• Join adımlarında satır sayısı ve anahtar tekilliği doğrulandı mı?
• Prod yenileme koşullarına benzer şekilde test (hacim, kimlik, gateway) yapıldı mı?
• Hatalı satırlar için ayrı bir kalite raporu/diagnostic çıktı planlandı mı?

Özetle: Power Query hata ayıklama, yalnızca “hatayı bulup geçmek” değil; akışı değişime dayanıklı bir mimariye taşımaktır. Şema drift’i tolere eden seçim ve adlandırma, güvenli tip dönüşümleri, fonksiyonlaştırma ve parametreleştirme, folding ve performans farkındalığı birleştiğinde, kaynak değişse bile akışınız çalışmaya devam eder. Böylece rapor yenilemeleri daha öngörülebilir olur ve operasyonel yük azalır.

Eğer ekibinizde bu pratikleri standartlaştırmak ve M dili desenlerini daha derinlemesine öğrenmek istiyorsanız, Power Query & Power Pivot eğitimi içeriğine göz atabilirsiniz. Kurumsal senaryolarda hata ayıklama, performans ve modelleme disiplinini birlikte ele almak, sürdürülebilir BI altyapısının temelidir.

Ek not: Bu makaledeki örnekler, hem Excel/CSV gibi dosya tabanlı hem de SQL gibi katlanabilir kaynaklarda uygulanabilir desenler sunar. Kendi ortamınızda en doğru yaklaşımı seçerken, veri kalitesi hedeflerinizi ve yenileme SLA’larınızı mutlaka birlikte değerlendirin.