Şirket İçi Veri Sözlüğü: Aynı Metriği Herkesin Aynı Anlaması

Veri sözlüğü eksikliğinin belirtisi her şirkette aynıdır: aynı toplantıda iki farklı ekran açılır, ikisinde de "aktif kullanıcı" yazar ve sayılar tutmaz. Ardından yarım saat, hangi rakamın doğru olduğu tartışılır. Bu tartışmanın gerçek maliyeti kaybedilen zaman değil, veriye duyulan güvenin aşınmasıdır — ve bir kez aşındığında kararlar yeniden sezgiye döner.

Sayılar neden tutmuyor?

Neredeyse hiçbir zaman veri bozuk olduğu için değil. Tipik sebepler şunlardır:

• Farklı zaman dilimi: Bir rapor UTC'ye, diğeri yerel saate göre gün sınırı çiziyordur. Gece yarısı civarındaki hareketler iki farklı güne düşer. Bu, sunucu log'larında da klasik bir tuzaktır; zaman dilimi tuzağı yazımız aynı sorunun operasyon tarafını ele alıyor.
• Farklı dışlama kuralları: Biri test hesaplarını ve şirket içi trafiği çıkarıyor, diğeri çıkarmıyordur.
• Farklı "aktiflik" tanımı: Biri giriş yapmayı, diğeri en az bir işlem yapmayı sayıyordur.
• Farklı iptal/iade muamelesi: Ay içinde iptal edilen bir sipariş gelire dahil mi, değil mi?
• Farklı tazelik: Biri gerçek zamanlı, diğeri gecelik toplu işten besleniyordur.

Bu farkların hepsi tek tek meşrudur. Sorun, hangisinin geçerli olduğunun hiçbir yerde yazmamasıdır.

Veri sözlüğü nedir, ne değildir?

Veri sözlüğü, veritabanı şemasının dökümü değildir — sütun listesi çıkarmak otomatik araçların işidir ve tek başına kimsenin sorusunu cevaplamaz. Veri sözlüğü, iş kavramlarının tek ve yetkili tanımını tutan belgedir. "aktif_kullanici" satırında hangi tabloların birleştirildiği kadar, hangi kullanıcıların neden dışlandığı da yazar.

İyi bir metrik tanımı şu alanları içerir: metriğin adı, tek cümlelik iş tanımı, hesaplama kuralı, açıkça dışlananlar, zaman dilimi ve dönem sınırı, veri tazeliği, sahibi ve son güncelleme tarihi. Bu alanlardan en çok atlanan ve en çok soruna yol açan ikisi dışlananlar ve zaman dilimidir.

Nasıl başlanır: küçük ve kullanılan bir sözlük

En sık yapılan hata, işe her tabloyu belgeleyerek başlamaktır. Böyle projeler yarım kalır ve kalan kısım güncellenmediği için güvenilmez hâle gelir. Daha işleyen bir yaklaşım şudur:

1. Yönetim panosundaki metriklerle başlayın. Şirkette karar verilirken bakılan 10-15 sayı vardır. Sözlüğün ilk sürümü yalnızca bunları içersin.
2. Her metriğe bir sahip atayın. Sahip, tanımı değiştirme yetkisi olan ve sorulduğunda cevap veren kişidir. Sahibi olmayan tanım, üç ay içinde eskir.
3. Tanımı sorgunun yanına koyun. Sözlük ayrı bir wiki sayfasında yaşarsa unutulur. En sürdürülebilir yöntem, tanımı hesaplamanın yapıldığı yere (görünüm tanımı, dbt modeli veya rapor sorgusu içindeki yorum) yerleştirip oradan üretmektir.
4. Tek hesaplama noktası kurun. Aynı metrik beş farklı raporda beş kez hesaplanıyorsa, er ya da geç ayrışır. Metriği tek bir görünüm veya modelde hesaplayıp raporların oradan okumasını sağlamak, tanım farklarını yapısal olarak imkânsız kılar.

Tanım değiştiğinde ne olacak?

Sözlüğün asıl sınavı, bir tanımın değişmesi gerektiğinde başlar. "Aktif kullanıcı" tanımına mobil oturumları da eklemeye karar verdiniz diyelim: tarihsel seriler bir anda kırılır, geçen ayla bu ay kıyaslanamaz hâle gelir ve kimse neden arttığını anlamaz.

Doğru pratik, tanım değişikliğini bir sürüm gibi ele almaktır: değişiklik tarihini kaydedin, mümkünse yeni tanımı geçmişe de uygulayarak seriyi yeniden üretin, bu mümkün değilse grafiklerde değişikliğin olduğu tarihi işaretleyin. En önemlisi, değişikliği metrikleri kullanan ekiplere önceden duyurun. Bu disiplin, API'lerde kırıcı değişiklik yönetimine çok benzer; oradaki adımlar için API sürümleme yazımıza bakabilirsiniz.

Veri kalitesiyle ilişkisi

Tanımlar netleştiğinde, veri kalitesi sorunları da görünür hâle gelir. Çünkü artık "bu sayı yanlış" demek yerine "bu sayı tanıma uymuyor" diyebilirsiniz — ve bu, test edilebilir bir ifadedir. Sözlükteki her tanımın yanına basit doğrulama kuralları (negatif tutar olmamalı, kullanıcı sayısı toplam kayıt sayısını aşmamalı gibi) eklemek, hataları rapora düşmeden yakalar. Veri hazırlığının bu yönü için veri temizleme yazımız tamamlayıcıdır. Yönetişim çerçevesinin daha geniş bir tartışması için Martin Fowler — Data Mesh ilkeleri yazısı okunabilir.

Sonuç

Veri sözlüğü, teknik bir dokümantasyon işi gibi görünse de aslında bir iletişim altyapısıdır: kararların aynı sayılara bakarak alınmasını sağlar. Kurmanın yolu her şeyi belgelemek değil, karar verilen az sayıda metriği sahipli, tek noktada hesaplanan ve değişiklikleri duyurulan tanımlara bağlamaktır. Bugün küçük bir test yapın: şirketinizdeki iki farklı kişiye en çok kullanılan metriğinizin tanımını sorun. Cevaplar farklıysa, yazacağınız ilk sözlük maddesi de belli olmuş demektir.