Veri mühendisi mülakat rehberi

Çerçeve: Deterministik sıralamalı pencere fonksiyonu

Her event_id partition'ı içinde satırlara numara atamak için bir pencere fonksiyonu kullanırım. Sıralamayı en güvenilir güncellik kolonuna göre azalan şekilde yaparım; örneğin ingestion_timestamp veya updated_at. Eşitlik ihtimali varsa source_sequence_number ya da raw_file_name gibi deterministik bir eşitlik bozucu (tie-breaker) eklerim. Sorgu kalıbı şöyle: Tüm satırları seçerim, row_number() over(partition by event_id order by ingestion_timestamp desc, source_sequence_number desc) değerini hesaplarım ve ardından where row_number = 1 koşuluyla filtrelerim. Mülakatta asıl önemli olan ayrıntı determinizmdir. İki kaydın zaman damgası aynıysa ve tie-breaker yoksa sonuç bir çalıştırmadan diğerine değişebilir. Ayrıca “en güncel event” ifadesinin en son ingestion zamanı mı, en son event zamanı mı, yoksa kaynaktaki en son güncelleme zamanı mı olduğunu netleştiririm. Canlı ortamda duplicate oranını, geç gelen event'leri, null event_id sayısını ve tekilleştirmenin downstream metrikleri beklenmedik şekilde değiştirip değiştirmediğini izlerim.

Çerçeve: Aktif event'leri filtreleme → tarihi normalleştirme → tarih ve kullanıcıya göre gruplama

Önce aktif kullanıcıyı tanımlarım. Genellikle her event sayılmamalıdır. Sayfa görüntülemelerinin, bot event'lerinin, arka plan yenilemelerinin ve şirket içi kullanıcıların hariç tutulması gerekebilir. Ürüne göre session_start, purchase, message_sent veya feature_used gibi anlamlı event'leri seçerim. Ardından uygun event'leri filtreleyen, event zaman damgalarını şirketin raporlamada esas aldığı saat dilimine çeviren, activity_date ve user_id'ye göre gruplayan ve her gün için aktif kullanıcı başına bir satır üreten bir dönüşüm kurarım. Nihai tablo toplulaştırılmış (aggregate) bir tabloysa her gün için tekil kullanıcıları sayarım. Tablo bir serving modeliyse date, user_id, platform, country ve first_active_timestamp alanlarını tutarım. Canlı ortamda önemli ayrıntılar arasında saat dilimi, geç gelen event'ler, bot/test filtrelemesi, silinmiş kullanıcılar, duplicate event'ler ve activity_date'e göre partitioning yer alır. Artımlı build'lerde geç gelen event'leri yakalamak için yalnızca bugünü değil, son partition'ları da yeniden işlerim. Güçlü bir yanıt doğrulamayı da içerir: DAU'yu kaynak event sayılarıyla karşılaştırmak, günden güne değişimleri izlemek ve segment bazında tutarlılığı kontrol etmek.

Çerçeve: Kapsam → sorgu planı → veri büyümesi → join'ler → partition'lar → son değişiklikler

Önce sorunun bu sorguya mı özgü olduğunu, tüm veri ambarını mı etkilediğini, yoksa altyapıyla mı ilgili olduğunu kontrol ederim. Birçok sorgu yavaşladıysa sebep cluster kapasitesi, veri ambarındaki yük veya servis kaynaklı bir performans düşüşü olabilir. Yalnızca bir sorgu yavaşladıysa sorguyu ve veriyi incelerim. Son değişikliklere bakarım: tablo boyutundaki büyüme, şema değişiklikleri, yeni join'ler, değişen filtreler, devreye girmeyen partition pruning, güncelliğini yitirmiş istatistikler, veri çarpıklığı (skew), satır sayısını patlatan join'ler ya da sonradan eklenen distinct/order by işlemleri. Varsa sorgu planını incelerim. Sık görülen nedenler arasında yanlış grain'de join yapmak, eksik tarih filtreleri, çoka çok join'ler, tüm partition'ları taramak, verimsiz pencere fonksiyonları, büyük shuffle'lar ve partition kolonlarına uygulanıp pruning'i engelleyen fonksiyonlar bulunur. Çözüm olarak filtrelemeyi daha erken yapmak, veriyi önceden toplulaştırmak, partition filtreleri eklemek, clustering/sorting uygulamak, ara modelleri materialize etmek, istatistikleri güncellemek, seçilen kolonları azaltmak veya join mantığını düzeltmek gerekebilir. Ayrıca çalışma süresi, taranan byte miktarı, satır sayıları ve maliyet için izleme eklerim.

Çerçeve: İş süreçleri → fact'ler → boyutlar → grain → metrikler

Temel iş süreçleriyle başlarım: ürün gezinme, sepet, siparişler, ödemeler, sevkiyatlar, ürün iadeleri, para iadeleri, stok ve pazarlama atribüsyonu. Kullanım şekline göre her süreç bir fact tablosuna veya event modeline dönüşebilir. Önemli fact tabloları şunlardır: Her sipariş için bir satır içeren fact_orders, her siparişteki her ürün için bir satır içeren fact_order_items, fact_payments, fact_refunds, fact_shipments ve fact_inventory_snapshot. Boyutlar arasında dim_customer, dim_product, dim_date, dim_store ya da depo boyutu, dim_channel ve dim_campaign yer alır. Grain'i açıkça tanımlarım. Ürün kategorisine göre gelir genellikle sipariş grain'inden değil, sipariş kalemi grain'inden gelmelidir. Müşteri yaşam döngüsü metrikleri müşteri veya abonelik grain'ini kullanabilir. Stok analizi için günlük snapshot grain'i gerekebilir. Modellemede dikkat ettiğim noktalar: yavaş değişen müşteri veya ürün nitelikleri, para iadeleri ve iptaller, sipariş düzeyinde ya da kalem düzeyinde uygulanan indirimler, para birimi, vergiler, kargo, misafir olarak satın alma (guest checkout) ve geç gelen veri. Tek doğru kaynak (source of truth) kabul edilen metrikleri tanımlar; finans, pazarlama, ürün ve operasyon için semantik modeller veya data mart'lar kurarım. Doğrulama kapsamında geliri finans verileriyle, sipariş sayılarını işlem sistemleriyle, para iadesi toplamlarını ödeme sistemleriyle ve stoğu depo sistemleriyle mutabık kılarım.

Çerçeve: Tarihçe ihtiyacına göre Type 1 mi, Type 2 mi

Doğru yaklaşım, tarihsel doğruluğun önemli olup olmadığına bağlıdır. Type 1 eski değerlerin üzerine yazar; basittir ve yalnızca en son değerin önemli olduğu durumlarda işe yarar. Type 2 ise her nitelik değişikliğinde yeni bir boyut satırı oluşturarak geçmişi korur; bunu genellikle effective_start_date, effective_end_date, current_flag ve bir surrogate key ile yapar. Örneğin bir müşterinin bölgesi Batı'dan Doğu'ya değişirse Type 1 müşteri satırını Doğu olarak günceller. Bu durumda tarihsel gelir raporları eski geliri de Doğu altında gösterir; bu da yanlış olabilir. Type 2 eski Batı satırını korur ve yeni bir Doğu satırı oluşturur; böylece fact'ler event anındaki doğru versiyona join edilebilir. Type 2 karmaşıklık getirir: surrogate key'ler, tarih aralığı join'leri, geç gelen fact'ler, güncel ve tarihsel raporlama ayrımı ve daha büyük boyut tabloları. Raporlamanın nitelikleri event anındaki hâliyle yansıtması gerekiyorsa Type 2'yi kullanırım. Güçlü bir yanıt, SCD tipini seçmeden önce iş ihtiyacını açıklar.

Çerçeve: Yönetişim ve esneklik ile sorgu sadeliği ve performans arasındaki denge

Yıldız şema fact'leri ve boyutları birbirinden ayırır. Yeniden kullanılabilir boyutlara, tutarlı metriklere, yönetişime, net bir grain'e ve esnek analize ihtiyaç duyulduğunda işe yarar. Veri tekrarını azaltır ve boyutlardaki değişikliklerin yönetimini kolaylaştırır. Geniş denormalize bir tablo ise yoğun kullanılan belirli analizler, makine öğrenmesi feature'ları veya sorgu sadeliğinin ve performansın önemli olduğu dashboard'lar için faydalı olabilir. Tüketiciler için join karmaşıklığını azaltabilir; ancak veriyi tekrarlayabilir ve birçok geniş tablo metrikleri farklı tanımlarsa yönetişim riski yaratabilir. Pratikte çoğu zaman temiz, kanonik fact ve boyut tablolarını korur, ardından belirli kullanım senaryoları için derlenmiş data mart'lar veya geniş tablolar yayımlarım. Veri ambarının temeli güvenilir kalmalı; downstream modeller ise kullanıcı ihtiyaçlarına göre optimize edilmelidir. Karar; ölçeğe, tüketicilere, BI aracının davranışına, maliyete, gecikmeye ve iş tanımlarının ne sıklıkla değiştiğine bağlıdır.

Çerçeve: Veriyi çekme → ham veriyi landing alanına yazma → dönüştürme → doğrulama → yayımlama → izleme

Önce gereksinimleri netleştiririm: veri güncelliği, sipariş hacmi, kabul edilebilir gecikme, kaynak veritabanına binebilecek yükün sınırları, downstream tüketiciler ve geçmişe dönük düzeltmelerin olup olmadığı. Basit bir tasarım şöyle olur: Siparişleri updated_at veya CDC kullanarak artımlı şekilde çekerim, ham veriyi object storage'a ya da ham bir veri ambarı tablosuna yazarım, staging tablolarına dönüştürürüm ve ardından fact_orders ile fact_order_items gibi modellenmiş fact tablolarını yayımlarım. Orkestrasyonu Airflow, Dagster, dbt Cloud veya yönetilen bir iş akışı aracıyla yaparım. Pipeline idempotent olmalıdır. Bir tarih veya batch için yeniden çalıştığında duplicate kayıt eklemek yerine veriyi deterministik biçimde değiştirmeli ya da merge etmelidir. Watermark'ları dikkatli kullanır, geç gelen güncellemeleri yakalamak için geriye dönük bir zaman aralığını (lookback window) yeniden işlerim. Doğrulama kontrolleri: satır sayıları, null primary key'ler, duplicate sipariş ID'leri, gelir toplamları, durum dağılımı, güncellik ve kaynakla mutabakat. İzleme; hatalarda, olağandışı hacim değişikliklerinde, yüksek duplicate oranlarında veya geciken veride alarm üretmelidir. Sahipliği ve downstream bağımlılıkları da dokümante ederim.

Çerçeve: Aynı girdiyle yeniden çalıştırma aynı çıktıyı üretir

Idempotent bir pipeline, aynı girdiyle birden fazla kez çalıştırıldığında duplicate kayıt veya istenmeyen yan etkiler oluşturmadan aynı doğru çıktıyı üretir. Bu önemlidir; çünkü pipeline'lar hata verir, yeniden denenir ve backfill gerektirir. Örneğin idempotent olmayan bir pipeline her çalıştığında dünün siparişlerini tabloya ekler (append). Bir hatadan sonra yeniden denenirse gelir iki katına çıkar. Idempotent bir versiyon ise hedef partition'ı silip yeniden yazar, primary key'e göre merge eder ya da veriyi geçici bir tabloya yazıp ardından atomik olarak swap eder. Idempotency; net anahtarlar, bir partition stratejisi, deterministik dönüşümler ve yan etkilerin dikkatle ele alınmasını gerektirir. Kurtarılabilirlik doğrudan buna bağlı olduğu için canlı ortamdaki veri mühendisliğinin en önemli kavramlarından biridir.

Çerçeve: Tespit etme → sınıflandırma → koruma → iletişim → geçiş

Önce şema değişikliklerini schema registry, metadata kontrolleri, contract testleri veya ingestion doğrulamasıyla otomatik olarak tespit ederim. Ardından değişikliği sınıflandırırım: eklenen kolon, kaldırılan kolon, yeniden adlandırılan kolon, tip değişikliği, nullability değişikliği veya anlamsal değişiklik. Null olabilen yeni kolonların eklenmesi genellikle güvenlidir. Kaldırılan kolonlar, yeniden adlandırılan alanlar ve tip değişiklikleri downstream dönüşümleri ve dashboard'ları bozabilir. Anlamsal değişiklikler ise özellikle tehlikelidir; çünkü şema geçerli görünürken verinin anlamı değişmiş olabilir. Pipeline'ı ham verinin saklanması, uyumluluk kontrolleri, alarmlar ve kritik kaynaklar için veri sözleşmeleriyle korurum. Kırıcı (breaking) değişikliklerde kaynak sistem sahipleriyle koordinasyon kurar, dönüşümleri günceller, gerekirse backfill yapar ve downstream etkisini paylaşırım. Olgun bir yanıt; veri sözleşmelerini, versiyonlamayı, lineage'i, testleri ve net sahipliği içerir. Böylece şema değişiklikleri analitiği sessizce bozmaz.

Çerçeve: Karar gecikmesi ile karmaşıklık arasındaki denge

Düşük gecikme anlamlı bir değer yaratıyorsa streaming'i tercih ederim. Dolandırıcılık tespiti, operasyonel alarmlar, gerçek zamanlı kişiselleştirme, stok güncellemeleri, canlı deney metrikleri ve taze event'lere ihtiyaç duyan, kullanıcıya dönük ürün özellikleri buna örnektir. Günlük raporlama, tarihsel analitik, finansal mutabakat ve saatler mertebesinde gecikmenin kabul edilebilir olduğu dönüşümler için batch çoğu zaman daha iyidir. Batch'i işletmek daha basittir, replay daha kolaydır ve genellikle daha ucuzdur. Karar; güncellik gereksinimlerini, event hacmini, sıralama ihtiyacını, stateful işlemeyi, hata toleransını, ekibin uzmanlığını, maliyeti ve downstream tüketicileri dikkate almalıdır. Streaming kendiliğinden daha iyi değildir. Duplicate'ler, geç gelen event'ler, checkpoint'ler, şema evrimi ve izleme konularında karmaşıklık ekler. Güçlü bir yanıtın özü şudur: İş gereksinimini karşılayan en basit mimariyi kullanmak. İş tarafı yalnızca günlük metriklere ihtiyaç duyuyorsa prestij uğruna streaming sistemi kurulmamalıdır.

Çerçeve: Event'ler → stream → zenginleştirme → kurallar/model → aksiyon → depolama → izleme

Gereksinimlerle başlarım: event hacmi, gecikme hedefi, dolandırıcılık kararının türü, yanlış pozitiflere tolerans ve kararların işlemleri bloke mi edeceği, yoksa incelemeyi mi tetikleyeceği. Olası bir tasarım şöyle: Ödeme event'leri Kafka veya Kinesis'e publish edilir. Bir stream processor event'leri tüketir, şemayı doğrular, event_id'ye göre tekilleştirir; kullanıcı, cihaz, üye iş yeri ve geçmişe dayalı hız (velocity) feature'larıyla zenginleştirir, ardından kuralları veya bir modeli uygular. Yüksek riskli event'ler bir karar servisini, manuel inceleme kuyruğunu veya ek kimlik doğrulama adımını (step-up authentication) tetikler. Ham event'ler ve kararlar, denetim ve model eğitimi için kalıcı depolamaya yazılır. Temel mühendislik konuları: duplicate event'ler, sırası bozuk gelen event'ler, feature güncelliği, state store boyutu, exactly-once ya da fiilen exactly-once (effectively-once) işleme, backpressure, dead-letter queue'lar, replay, gecikme izleme ve model/kural versiyonlama. Dolandırıcılık kararları müşterileri doğrudan etkilediği için veri kalitesi ve yönetişim önemlidir. Gerekçe kodlarını loglar, yanlış pozitif oranlarını izler ve bir kural ya da model hatalı davranırsa rollback yapılabilmesini sağlarım.

Çerçeve: Verinin partition'lar arasında yeniden dağıtılması

Shuffle, Spark'ın veriyi partition'lar arasında yeniden dağıtması gerektiğinde gerçekleşir; genellikle groupBy, join, distinct, orderBy ve repartition gibi işlemlerde. Pahalıdır; çünkü verinin ağ üzerinden taşınması, serialize/deserialize edilmesi, diske yazılması ve executor'lar arasında koordine edilmesi gerekir. Shuffle'lar çoğu zaman job'ın çalışma süresinin büyük kısmını oluşturur ve veri çarpık (skewed) olduğunda ya da ara veri çok büyüdüğünde hatalara yol açabilir. Tek bir sıcak anahtar (hot key) tek bir partition'a fazla veri gönderip straggler task'lara veya out-of-memory hatalarına neden olabilir. Shuffle maliyetini azaltmanın yolları: erken filtrelemek, yalnızca gereken kolonları seçmek, veriyi önceden toplulaştırmak, küçük tablolar için broadcast join kullanmak, join anahtarlarına göre partition'lamak, çarpık anahtarlara salting uygulamak, gereksiz distinct/orderBy işlemlerinden kaçınmak ve partition sayılarını ayarlamak. Güçlü bir yanıt, kavramı pratik debug süreciyle ilişkilendirir: Spark UI'da stage'leri, shuffle read/write değerlerini, veri çarpıklığını, spill'i, task sürelerini ve executor belleğini incelemek.

Çerçeve: Stage'i belirleme → veriyi azaltma → çarpıklığı giderme → partition'ları ayarlama → sorunlu işlemlerden kaçınma

Önce Spark UI'ı veya logları kullanarak hatanın nerede oluştuğunu belirlerim: hangi stage, hangi işlem, hangi partition ve hangi executor. OOM; veri çarpıklığından, büyük join'lerden, collect işlemlerinden, aşırı büyük partition'lardan, verimsiz UDF'lerden veya gereğinden fazla verinin cache'lenmesinden kaynaklanabilir. Ardından veriyi erken aşamada azaltırım: Satırları filtreler, yalnızca gerekli kolonları seçer, predicate'leri aşağı iter ve gereksiz partition'ları okumaktan kaçınırım. Join'leri kontrol ederim: Tablolardan biri küçükse broadcast join kullanırım. Bir anahtar çarpıksa salting uygular veya ağır anahtarları ayırırım. Partition'lar çok büyükse partition sayısını artırırım; çok sayıda küçük partition varsa uygun şekilde coalesce ederim. Büyük veride collect() kullanmaktan, native fonksiyonlar iş görürken Python UDF'lerinden kaçınırım; cache'i yalnızca veri yeniden kullanılıyorsa ve bellek yetiyorsa kullanırım. Dosya çıktısında çok sayıda küçük dosya üretmekten kaçınır, sıkıştırmalı Parquet gibi kolon bazlı formatları seçerim. Kaynak ayarı gerekiyorsa executor belleğini, core sayısını, shuffle partition sayısını ve memory overhead'i ayarlarım; ancak yalnızca daha büyük cluster'lara güvenmem. Verinin yapısını ve sorgu planını düzeltmek genellikle çok daha kalıcı bir çözümdür.

Çerçeve: Kolon bazlı depolama, şema, sıkıştırma, predicate pushdown

Parquet kolon bazlı (columnar) bir dosya formatıdır. Sorgular çoğu zaman kolonların yalnızca bir kısmını okuduğu için analitikte verimlidir. Sıkıştırmayı destekler, veri tiplerini kodlar, şemayı saklar ve birçok motorda predicate pushdown ile column pruning'i mümkün kılar. CSV ise satır bazlı düz metindir. İnsan tarafından okunabilir ve taşınabilir; ancak güçlü tiplerden yoksundur, daha büyük olabilir, daha yavaş taranır, ayraç/escape karakterleri nedeniyle hataya daha açıktır ve ilgisiz kolonları verimli şekilde atlayamaz. Data lake'ler ve veri ambarları için Parquet genellikle depolama maliyetini düşürür ve sorgu performansını artırır. CSV basit dışa aktarımlar, küçük dosyalar veya sistemler arası uyumluluk için hâlâ işe yarayabilir; ancak ana analitik depolama formatı olarak ideal değildir.

Çerçeve: Güncellik → eksiksizlik → teklik → geçerlilik → mutabakat

Bir gelir pipeline'ında güncellik, satır sayısı, null primary key'ler, duplicate işlem ID'leri, geçerli durumlar, geçerli para birimleri, uygun olduğu yerlerde negatif olmayan tutarlar, kabul edilen tarih aralıkları ve siparişler, ödemeler, para iadeleri ve müşteriler arasındaki referans bütünlüğü için kontroller eklerim. Mutabakat kontrolleri de eklerim: Toplam geliri kaynak ödeme sistemleriyle, finans raporlarıyla veya pipeline'ın önceki versiyonuyla karşılaştırırım. Günden güne ve haftadan haftaya değişimleri eşik değerlerle izlerim; ancak mevsimselliği ve bilinen olayları da hesaba katarım. İş kuralları önemlidir: İptal edilen siparişler gelir sayılmamalı, para iadeleri net geliri düşürmeli, test işlemleri hariç tutulmalı ve döviz çevriminde doğru kur kullanılmalıdır. Alarmlar aksiyon alınabilir olmalı, bir sorumluya yönlendirilmeli ve bağlam içermelidir: başarısız olan kontrol, etkilenen tablo, önem derecesi, downstream bağımlılıklar ve önerilen runbook. Çok fazla gürültülü alarm sonunda görmezden gelinir.

Çerçeve: Etkiyi değerlendirme → versiyonları karşılaştırma → lineage'i inceleme → etkiyi azaltma → kök neden

Önce etkiyi değerlendiririm: Hangi dashboard, hangi metrik, hangi kullanıcılar, hangi tarih aralığı ve hangi kararlar etkileniyor? Rakamın mı yanlış olduğunu, yoksa deployment'ın önceki bir sorunu mu düzelttiğini belirlerim. Yeni çıktıyı önceki versiyonla tablo, partition, satır sayısı, distinct sayısı, metrik toplamları ve temel segmentler bazında karşılaştırırım. Upstream değişiklikleri belirlemek için lineage'i kullanırım. Kod değişikliklerini, şema değişikliklerini, filtreleri, join'leri, tekilleştirmeyi ve tarih mantığını incelerim. Metrik yanlışsa ve iş kullanıcıları etkileniyorsa etkiyi hızla azaltırım: Dönüşümü rollback ederim, tablonun önceki versiyonunu geri yüklerim, dashboard'u devre dışı bırakırım veya bir uyarı eklerim. Ardından kök neden analizi yapar, gerekirse düzeltilmiş veriyi backfill ederim. İletişim kritik önemdedir. Paydaşlara neyin değiştiğini, neyin etkilendiğini, ne kadar emin olduğumuzu, tahmini düzeltme süresini ve geçmiş kararların yeniden gözden geçirilmesi gerekip gerekmediğini bildiririm.

Çerçeve: Enstrümantasyon → veri alımı → depolama → işleme → modelleme → sunum → yönetişim

Gereksinimlerle başlarım: event hacmi, gecikme, tüketiciler, saklama süresi, şema evrimi, gizlilik ve güvenilirlik. Ürün analitiği event'leri dashboard'ları, deneyleri, kişiselleştirmeyi ve makine öğrenmesi feature'larını besleyebilir. İstemciler event'leri bir SDK üzerinden event_name, user_id, session_id, timestamp, properties, uygulama versiyonu, platform ve anonim ID ile gönderir. Event'ler bir ingestion API'sine veya event collector'a, oradan da Kafka/Kinesis/Pub/Sub gibi kalıcı bir stream'e gider. Ham event'ler replay için object storage'a, analitik için de bir veri ambarına veya lakehouse'a yazılır. İşleme adımları şema doğrulama, tekilleştirme, bot/şirket içi trafik filtreleme, sessionization, kimlik eşleştirme (identity resolution) ve verinin fact_events, fact_sessions, dim_users gibi modellenmiş tablolara ve ürüne özel mart'lara dönüştürülmesini kapsar. Güncellik ihtiyacına göre batch ve streaming yolları bir arada bulunabilir. Kalite ve yönetişim: event sözleşmeleri, schema registry, kişisel verilerin (PII) yönetimi, onay (consent) kurallarının uygulanması, lineage, sahiplik, güncellik kontrolleri, hacim anomalisi alarmları ve dokümantasyon. Sunum katmanları BI dashboard'larını, deney analizlerini, reverse ETL'yi ve feature store'ları kapsar. Trade-off'lar arasında gerçek zamanlı ve batch maliyeti, katı ve esnek şema, ham event saklama süresi, kimlik eşleştirmenin karmaşıklığı ve mantığın ne kadarının ingestion'da, ne kadarının dönüşüm katmanında yer alacağı bulunur.

Çerçeve: Offline/online tutarlılık → feature tanımları → güncellik → serving → izleme

Bir feature store, eğitim ve serving için yeniden kullanılabilir, güvenilir feature'lar sağlamalıdır. Gereksinimler arasında feature tanımları, point-in-time doğruluğu, offline eğitim verisi, düşük gecikmeli online serving, güncellik, erişim kontrolü ve izleme yer alır. Offline feature'lar tarih ve entity'ye göre partition'lanmış şekilde bir veri ambarında veya lakehouse'ta saklanabilir. Online feature'lar düşük gecikmeli bir key-value store'dan sunulabilir. Bir feature registry şu metadata'yı tutar: feature adı, sahibi, entity anahtarı, dönüşüm mantığı, güncellik SLA'sı, kaynak tablolar ve açıklama. Point-in-time doğruluğu kritiktir. Eğitim verisi gelecekteki değerleri değil, tahmin anında mevcut olan feature değerlerini kullanmalıdır. Online/offline tutarlılık için mümkün olduğunda aynı dönüşüm mantığı yeniden kullanılmalı; ayrı pipeline'lar varsa kapsamlı şekilde test edilmelidir. İzleme; feature güncelliğini, null oranlarını, dağılım kaymasını (drift), online serving gecikmesini, training-serving skew'u ve downstream model etkisini kapsamalıdır. Yönetişim ise PII kontrollerini, lineage'i, kullanımdan kaldırma süreçlerini ve sahipliği içerir.

Çerçeve: Etki → triyaj → etkiyi azaltma → kök neden → önleme

Gerçek etkisi olan bir incident seçin: eksik veri, yanlış metrikler, geciken pipeline, duplicate kayıtlar, bozuk dashboard, model feature'ı sorunu veya downstream ürün etkisi. Kimin etkilendiğini ve bunun neden önemli olduğunu anlatarak başlayın. Ardından triyaj sürecinizi açıklayın: loglar, orkestrasyon durumu, kaynak güncelliği, son deployment'lar, şema değişiklikleri, satır sayıları, partition'lar, lineage ve downstream bağımlılıklar. Sorunu nasıl kontrol altına aldığınızı anlatın: yeniden çalıştırma, rollback, yama, backfill veya paydaşlara uyarı. En güçlü yanıt önlemeyi de içerir. Veri kalitesi kontrolleri, alarmlar, yeniden denemeler, şema sözleşmeleri, idempotent yazma işlemleri, runbook'lar, lineage veya daha iyi deployment kontrolleri eklediniz mi? Upstream ekipleri suçlamaktan kaçının. Sisteme ve iletişime sahip çıktığınızı gösterin. Güvenilirlik hakkında ne öğrendiğinizi ve sonrasında sürecinizin nasıl değiştiğini anlatarak bitirin.

Çerçeve: Netleştirme → yeniden üretme → lineage'i izleme → çözme → dokümante etme

Önce tam olarak neyin yanlış göründüğünü netleştiririm: metrik, tablo, tarih aralığı, dashboard, filtre, beklenen değer ve iş tarafındaki gerekçe. “Veri yanlış” ifadesinin yeniden üretilebilir bir soruna dönüşmesi gerekir. Ardından analistin sorgusunu veya dashboard'unu kaynak tablolar ve model tanımlarıyla karşılaştırırım. Grain'i, filtreleri, join'leri, saat dilimlerini, güncelliği, metrik tanımlarını ve son değişiklikleri kontrol ederim. Upstream bağımlılıkları izlemek için lineage'i kullanırım. Veri yanlışsa düzeltir ve etkisini paylaşırım. Veri doğru ama tanım beklentiden farklıysa metrik tanımı ve dokümantasyon üzerinde uzlaşırız. Belirsizlik sürüyorsa neyin bilindiğini, neyin kontrol edildiğini ve ne zaman geri dönüş yapacağımı açıklarım. İlişki önemlidir. Analistler veri platformunun müşterileridir; güven de hızlı, net ve kanıta dayalı yanıtlarla inşa edilir.

Çerçeve: Etki → güvenilirlik → aciliyet → bağımlılıklar → kaldıraç etkisi

İş etkisine, güvenilirlik riskine, aciliyete, downstream bağımlılıklara ve kaldıraç etkisine göre önceliklendiririm. Bozuk bir gelir pipeline'ı veya bir uyumluluk sorunu, olsa iyi olur denebilecek bir dashboard modelinin genellikle önüne geçer. Birçok ekibin önünü açıyorsa bir platform iyileştirmesi tek seferlik bir talepten daha öncelikli olabilir. Acil incident'ları, stratejik platform çalışmalarını, paydaş taleplerini, teknik borcu ve operasyonel angarya işleri de birbirinden ayırırım. Ekip yalnızca ticket'larla uğraşırsa güvenilirlik ve platform kalitesi zamanla bozulur. Ekip yalnızca platform soyutlamaları geliştirirse iş birimlerinin işi tıkanabilir. Güçlü bir önceliklendirme süreci; sahipliği, SLA'ları, önem seviyelerini, roadmap uyumunu ve şeffaf trade-off'ları içerir. Neyin yapıldığını, neyin ertelendiğini, nedenini ve bunun hangi riski doğurduğunu açıkça paylaşırım.