Rakamların birbirini tuttuğu veri platformları.
Veri ambarları, akış veri hatları ve yönetişimli modeller — böylece her pano, rapor ve yapay zekâ sistemi aynı kaynaktan beslenir.
- Kaynak & doğruluk denetimi
- Platform temeli
- Yaygınlaştırma
- İşletim & yönetişim
Veri kalitesi bir mühendislik özelliğidir.
Çoğu kurumun eksiği veri değil — mutabakat. Üç pano, üç gelir rakamı ve karar yerine tanımlar üzerine tartışmaya dönen bir yönlendirme toplantısı. Sebep nadiren veri ambarıdır. Sebep, aynı hesabın altı ayrı yerde durmasıdır — bir BI aracı, bir saklı yordam, her pazartesi birinin elle düzelttiği bir dışa aktarım — ve hiçbiri bağlayıcı değildir. Biz, veri kökeninin açıkça göründüğü, kalitenin kod gibi test edildiği ve “bu rakam nereden geliyor” sorusunun tıklanabilir bir yanıtı olduğu veri platformları kuruyoruz.
Yöntem, veriye uygulanan sıradan mühendisliktir. Dönüşümler sürüm kontrolünde tutulur ve ikinci bir kişi tarafından incelenir. Her modelin adı belli bir sahibi, yazılı bir sözleşmesi ve birleştirilmeden önce çalışan testleri vardır. Veri hatları tazelik SLA’ları taşır; bir ihlal, üç gün sonra bir yönetim kurulu sunumunda ortaya çıkmak yerine nöbetteki kişiyi arar. Bu, kendi platformlarımızın altında çalışan disiplinin aynısıdır: Loyalty & Retention içindeki puan kayıt defterine ve Sales Performance içindeki prim hesaplanmış satışlara ilişkin raporlama, yönetişimli modelleri okur; hiçbir zaman doğrudan operasyonel tabloları değil.
Veri kalitesi bir mühendislik özelliğidir: CI’da test edilir, canlı ortamda izlenir, ihlalde uyarı üretir — tıpkı çalışma süresi gibi. 06:00 yüklemesi tazelik penceresini kaçırırsa bunu CFO’dan önce nöbetteki mühendis öğrenir ve pano, dünü bugünmüş gibi göstermek yerine durumu açıkça yüzüne yazar.
Bir veri platformunun yapması gereken dört şey.
Depolama işin kolay kısmı. Bir platformu güvenilir kılan, üzerindeki modelleme katmanı, çevresindeki testler ve her veri setinin yanında kayıtlı olan sahipliktir.
Veri ambarı & lakehouse
dbt ile modellenmiş, belgelenmiş ve test edilmiş dönüşümlere sahip Snowflake, BigQuery veya Databricks platformları. Motoru, iş yükü karmanıza ve halihazırda kullandığınız buluta göre seçeriz — AWS, Azure ve Google Cloud sayfalarına bakın — tercihe göre değil. Staging, ara ve mart katmanları ayrı durur; böylece tek bir metriği değiştirmek kırk rapor içinde sessizce dalgalanmaz.
Akış veri hatları
Dünün toplu işleminin geç kaldığı durumlar için Kafka ve CDC tabanlı akışlar: dolandırıcılık kontrolleri, operasyonel panolar, temas anında kişiselleştirme. Debezium ile değişiklik yakalama, kimsenin ellemek istemediği bir sistemi koduna dokunmadan bir olay kaynağına dönüştürür. Tüketiciler idempotenttir; bu sayede yeniden oynatma kaydı ikiye katlamak yerine düzeltir — desenleri Kafka sayfamızda anlatıyoruz.
Veri kalitesi & veri kökeni
Her modelde sözleşmeler ve testler, uçtan uca köken grafikleri, uyarıya bağlı tazelik SLA’ları. Testler önce pull request üzerinde CI’da, sonra her yüklemenin ardından canlı ortamda çalışır; böylece adı değişen bir yukarı akış kolonu, çeyrek sonu raporlarını değil derlemeyi bozar. Köken bilgisi gerçekten çalışan koddan üretilir; bir diyagramın aksine gerçeklikten sapamamasının sebebi budur.
Analitik & BI etkinleştirme
Semantik katmanlar ve Power BI ya da Looker modelleri — her yerde kullanılan tek bir gelir tanımı. İş mantığını tek tek raporlardan çıkarıp modellenmiş katmana taşırız; böylece bir metrik bir kez tanımlanır ve her araç aynı rakamı okur. Analistler belgelenmiş veri martları, bir veri sözlüğü ve tanımı çatallamadan yeni ölçüler eklemek için bir inceleme yolu edinir.
İş günlük olarak nasıl yürür?
Her rakamın bir adresi var.
Tartışmalı her raporda ilk soru “bu nereden geliyor” olur ve çoğu ortamda dürüst yanıt uzun sürer. Bizim platformlarımızda bir tıklama sürer. Her mart kolonu, kendisini üreten modeller üzerinden kaynak tabloya ve o tablonun sahibi olan sisteme kadar geri izlenir; dönüşüm de bir sorgunun ekran görüntüsü olarak değil, incelenmiş kod olarak görünür. Sahiplik, iki reorganizasyon önce eskimiş bir wiki sayfasında değil veri setinin yanında kayıtlıdır; böylece rakama dair bir sorunun bir yolu olduğu kadar bir muhatabı da olur.
- Derlenmiş modellerden üretilen köken bilgisi; böylece grafik ile veri hattı birbiriyle çelişemez
- Yayımlanan her veri seti için adı belli bir sahip ve yazılı bir sözleşme — şema, kırılım, tazeleme ve anlam
- Bir değişiklik birleştirilmeden önce kolon düzeyinde etki analizi: bu alanın biçimi değişirse kim etkilenir
Kalite, göründüğü yerde değil bozulduğu yerde test edilir.
Bir veri hatası yüklemede en ucuz, bir kararın içinde en pahalıdır. Bu yüzden testler sınırda durur: anahtarlarda teklik ve referans kontrolleri, kodlarda kabul edilen değer kontrolleri, hareketli bir taban çizgisine karşı hacim ve dağılım kontrolleri, işin üzerinde anlaştığı SLA’ya karşı tazelik kontrolleri. Başarısız bir test sessizce uyarı kaydı düşmez. Aşağı akıştaki modelleri bekletir, son sağlam anlık görüntüyü görünür tutar ve sorunlu satırları ekleyerek uyarı üretir; böylece platform “bugün, ama yanlış” durumuna değil “dün, ve bunu söylüyor” durumuna geriler.
- Modelin yanında kod içinde tanımlanan ve bir değişiklik birleştirilmeden önce CI’da çalışan testler
- Her yüklemeden sonra canlı ortam doğrulamaları; sessizce satır düşürmek yerine karantina tabloları
- Veri seti başına tazelik ve hacim SLA’ları; uyarılar kaynağın sahibi ekibe gider
Akış, yalnızca maliyetini hak ettiği yerde.
Gerçek zamanlılık bir gereksinimdir, bir rozet değil. Her kullanım senaryosunu, bir kararın değiştiği ana göre konumlandırırız: yarın sabahtan önce kimse harekete geçmiyorsa gecelik bir toplu işlem hem daha ucuza çalışır hem de daha sakin işletilir. Karar bir saat içinde veriliyorsa — bir dolandırıcılık bloğu, bir sevkiyat ataması değişikliği, müşterinin görebildiği bir stok rakamı — akış yolunu düzgün kurarız: kaynağın write-ahead log’undan değişiklik yakalama, şemaları bir şema kayıt servisinde tutulan bir olay omurgası, iş anahtarına göre idempotent tüketiciler ve anlatılmış değil provası yapılmış bir yeniden oynatma prosedürü.
- Kaynak sistemi değiştirmeden Oracle, SQL Server, MySQL veya PostgreSQL üzerinden Debezium CDC
- Akış ve toplu işlem yollarının paylaştığı tek bir modellenmiş tanım; böylece hızlı rakam ile kesinleşmiş rakam birbirini tutar
- Her operasyonel akış için dead-letter konuları, gecikme uyarıları ve yazılı bir yeniden oynatma runbook’u
Fatura da tasarımın parçasıdır.
Bulut veri ambarları dikkatsizliğin faturasını keser. Geldiğimizde karşılaştığımız harcamanın büyük kısmı birkaç alışkanlıktan doğar: artımlı bir modelin yeteceği yerde tam tazelemeler, ham tabloları doğrudan sorgulayan panolar, dördüncüsüne kimse güvenmediği için beş raporda tekrarlanan dönüşümler ve günlük değişen veri için on beş dakikada bir çalışan bir zamanlayıcı. Katmanı düzgün modellemek bu işin çoğunu optimize etmek yerine ortadan kaldırır. Veri ambarı harcamasını en baştan itibaren model ve tüketici bazında raporlarız; böylece konuşma bir toplam üzerinden değil, belirli sorgular üzerinden yürür.
- Gerçek sorgu desenlerine göre seçilen artımlı modeller, bölümleme ve kümeleme
- Model, pano ve ekip bazında dağıtılan harcama — bunu değiştirebilecek kişilere görünür
- Zamanlayıcı sıklığı alışkanlığa göre değil, işin üzerinde anlaştığı tazeliğe göre belirlenir
Tek platform, dört farklı iş.
Bir kez tanımlanan, her yerde okunan metrik.
Analistler her rapor için mantığı yeniden kurmayı bırakır. Gelir, marj, müşteri kaybı ve aktif müşteri tanımlarını semantik katman tutar; BI aracı onu okur. Yeni ölçüler incelemeden geçer; böylece sözlük bir istek listesi değil, var olanın tarifi olarak kalır.
- Kırılımı, anahtarları ve anlamı yazılı, belgelenmiş veri martları
- Ad-hoc keşiften ayrılmış, sertifikalı panolar
- Yeni ölçüler için, sahibi belirtilmiş bir inceleme yolu
Vardiya devrinden sağ çıkan rakamlar.
Operasyonel raporlamanın çıtası aylık analizden farklıdır: güncel olmalı, güncel değilse bunu söylemeli ve insanların içinde çalıştığı sistemle birbirini tutmalıdır. Operasyonel veri martları her ekranda bir tazelik damgası taşır ve eksik bir yüklemeyi göstermek yerine son sağlam anlık görüntüye döner.
- Tazelik raporun üzerinde görünür, dipnota gömülü değil
- Karar bir saat içindeyse akış yolu, diğer durumlarda toplu işlem
- Kayıt kaynağıyla sabit bir takvimde mutabakat
Mühendislerinizin okuyabileceği bir kod tabanı.
Kurduğumuz her şey kod olarak durur: dbt modelleri, orkestrasyon, altyapı, testler, uyarı politikaları. Ekibiniz en baştan pull request’lerimizi inceler, ardından kendi pull request’lerini birleştirir. Yetkinlik aktarımı sonda yapılan bir atölye değil, teslimatın parçasıdır — hedef, ekibin bizsiz işlettiği bir platformdur.
- Yazılı bir stil kılavuzu ve adlandırma kurallarıyla dbt projesi
- Kod olarak orkestrasyon ve altyapı; uygulama kodu gibi incelenir
- Geciken yüklemeler, şema kayması ve geriye dönük doldurmalar için, nöbetçi ekibinizle provası yapılmış runbook’lar
Kimsenin önce bütçelemek istemediği ön koşul.
Getirme sistemleri ve modeller, panoları bozan şeyin aynısında takılır: belirsiz kırılım, eksik geçmiş, köken bilgisinin olmaması. Bir feature store’u, bir getirme indeksini ya da bir tahmini tekrarlanabilir kılan şey, yönetişimli veri martları ve olay geçmişidir. Yapay Zekâ & Makine Öğrenmesi çalışmalarımız tam da bu katmanın üzerine kurulur ve MLOps onun testlerini ve izlemesini yeniden kullanır.
- Zaman noktasına göre doğru geçmiş; böylece eğitim verisi o an bilinebilir olanla örtüşür
- Eğitim ve servis yolları arasında paylaşılan öznitelik tanımları
- Doküman ve olay kaynakları, raporlamayla aynı sözleşmelerle indekslenir
Neler standart, neler müşteriye göre şekillenir.
Dört faz ve önce en çok tartışılan metrik.
Kaynak & doğruluk denetimi
Sistemler, sahipler ve rakamların bugün nerede uyuşmadığı — platformun görev tanımı. En çok tartışılan iki üç rakamı, onları üreten her yol üzerinden geriye doğru izler, her paydaşın gerçekte hangi tanımı kullandığını yazar ve her kaynak sistemin neyi yanıtlayıp neyi yanıtlayamadığını kayda geçeriz. Çıktı, genellikle başlattığından daha fazla tartışmayı kapatan kısa bir dokümandır.
Platform temeli
Veri ambarı, veri alımı ve ilk yönetişimli modeller — herkesin üzerinde en çok kavga ettiği metrikler, karara bağlanmış olarak. Ortamlar, CI, orkestrasyon ve erişim kontrolü aynı fazda kod olarak ayağa kaldırılır. Testleri, sahibi ve tazelik SLA’sı olmayan hiçbir şey yayımlanmaz.
Yaygınlaştırma
Alan alan: modeller, testler, köken bilgisi, panolar — her veri seti için sahibi belirtilmiş olarak. Her alan, kayıt sistemiyle kendi mutabakatıyla birlikte devreye girer; legacy raporlar yenilerinin yanında çalışır hâlde bırakılmaz, bilinçli olarak kapatılır. Mühendisleriniz en baştan inceleme yapar, ardından alanlara liderlik eder.
İşletim & yönetişim
Tazelik SLA’ları, maliyet izleme, erişim yönetişimi — ve platformu işleten bir platform ekibi (sizinki). Biz destek ve inceleme rolüne geçeriz: nöbet çizelgesi devredilir, runbook’ların provası yapılır, harcama ve kalite sizinle belirlenen bir düzende, düzenli olarak raporlanır. İşletmeye devam etmemizi isterseniz bu, içine düştüğünüz bir bağımlılık değil, bir yönetilen hizmet kararıdır.
Devir teslimde masada ne var.
- Yönetişimli modellerle devreye alınmış veri ambarı/lakehouse
- dbt kod tabanı: test edilmiş, belgelenmiş, kökeni eksiksiz
- Gecikmenin önemli olduğu yerlerde akış veri hatları
- Tek tanımlı metriklerle semantik katman ve BI modelleri
- Tazelik SLA’larıyla veri kalitesi panoları
- Kod olarak orkestrasyon ve altyapı
- Geriye dönük doldurma, şema kayması ve geciken yüklemeler için runbook’lar — ekibinizle provası yapılmış
- Model ve tüketici bazında, azaltma aksiyonları önceliklendirilmiş bir maliyet raporu
Bu ne zaman doğru tercih.
Raporlar birbirini tutmuyor ve hangisinin doğru olduğunu kimse söyleyemiyorsa; finans, operasyon ve ürün aynı rakamın kendine ait bir sürümünü tutuyorsa; bir veri hattı sessizce bozulup günler sonra fark ediliyorsa; veri ambarı harcaması kullanımdan daha hızlı artıyorsa ya da altındaki veriye güvenilemediği veya veri yeniden üretilemediği için bir yapay zekâ girişimi tıkandıysa bunu seçin. Ayrıca bir yapay zekâ programından önce, verinin nereden geldiğini değiştirecek bir modernizasyondan önce ve bir satın alma size her şeyden iki tane bıraktığında atılacak doğru ilk adımdır.
Asıl sorun bir kaynak sistemin yanlış şeyi kaydetmesiyse başka yere bakın — önce süreci ya da uygulamayı düzeltin, çünkü veri ambarı hatayı yalnızca sadakatle modeller. Tek bir ekibin tek bir veritabanından tek bir rapora ihtiyacı varsa başka yere bakın; bu bir platform değil, küçük bir iştir. Devir sonrası sizin tarafınızda veri setlerine sahip çıkacak kimse yoksa başlamaya temkinli yaklaşın: sahipsiz yönetişim zamanla çürür ve biz, sahipsiz eksiksiz bir platform yerine gerçek sahipleri olan daha küçük bir platformu kapsamlandırmayı tercih ederiz.
Sık sorulan sorular
Ekiplerinizin tartıştığı rakamı söyleyin.
Metriği ve arkasındaki sistemleri bize anlatın. Bu tartışmayı daha önce kapatmış bir mühendis okur ve neler gerektiğine dair yazılı bir değerlendirme iletir.