Veri mühendisliğini ilk kez ciddi anlamda çalışmaya başladığımda, açık konuşayım, kafam biraz karışmıştı. Herkes “pipeline”, “streaming”, “warehouse” diyordu; ama işin aslı şu ki, ortada tek bir sihirli kutu yok. Veri dediğiniz şey doğuyor, yolda şekil değiştiriyor, bazen kirleniyor, bazen kayboluyor. En sonunda birine somut bir fayda sağlıyorsa — ancak o zaman — gerçek anlamda değer kazanıyor (buna dikkat edin). İşte veri mühendisliği yaşam döngüsü tam da bu hikâyeyi anlatıyor.
Bu konuyu yıllar önce İstanbul’da bir e-ticaret projesinde çalışırken daha net kavramıştım. Sipariş verisi gece yarısı akıyordu, stok tarafı ayrı telden çalıyordu, pazarlama ekibi ise “şu rapor niye 20 dakika geç geliyor?” diye soruyordu. O gün şunu çok net gördüm: Veri mühendisliği sadece veri taşımak değil, verinin güvenilir biçimde işe dönüşmesini sağlamak.
İşte tam da bu noktada devreye giriyor.
Bir de sık yapılan bir hata var. Veri yaşam döngüsü ile veri mühendisliği yaşam döngüsü aynı şey sanılıyor (ben de ilk duyduğumda şaşırmıştım). Değil. Biri daha çok yönetim ve yönetişim tarafına bakıyor, diğeri ise boru hattının teknik gerçeklerine. Yani biri “bu veri ne kadar yaşayacak?” diye sorarken, öbürü “bu veri nasıl akacak?” diye düşünüyor. Küçük fark gibi görünüyor ama pratikte iki ayrı dünya.
Önce Şunu Ayıralım: Veri Yaşam Döngüsü Nedir?
DAMA-DMBOK çizgisinden baktığınızda veri yaşam döngüsü oldukça tanıdık bir mantığa oturuyor: veri planlanır, oluşturulur ya da toplanır, saklanır, kullanılır, zenginleştirilir, arşivlenir ve gerektiğinde silinir. Mantıklı değil mi? Kağıt üstünde düzenli duruyor; pratikte ise çoğu ekip bu adımların arasını lastik gibi esnetiyor.
İşte tam da bu noktada devreye giriyor.
Mesela 2023’te Ankara’daki bir kurumsal projede buna benzer bir yapı görmüştüm. Hukuk ekibi veriyi 7 yıl saklamak istiyordu, ürün ekibi ise maliyet yüzünden eski kayıtları buzlukta tutmak istemiyordu. Tam o noktada “yaşam döngüsü” dediğimiz şeyin sadece teknik değil, hukuki. Operasyonel bir mesele olduğunu bir kez daha anladım (yanlış duymadınız)
Planlama aşaması kulağa sıkıcı geliyor olabilir. Ama aslında en pahalı yanlışlar burada yapılıyor (buna dikkat edin). Baştan hangi verinin ne kadar süre tutulacağını bilmiyorsanız — sonradan bulut faturası size küçük çaplı bir şok yaşatabiliyor. Hatta bazen şok da değil, resmen hayal kırıklığı oluyor.
Veri Mühendisliği Yaşam Döngüsünün Beş Ana Durağı
Neyse, uzatmayalım. Veri mühendisliği tarafında genelde beş ana aşama konuşulur: üretim (generation), alma/aktarım (ingestion), depolama (storage), dönüştürme (transformation) ve sunma (serving). Bunların her biri ayrı derttir; ama birlikte çalışınca sistemin omurgasını kuruyorlar.
Eh, Bu beşliyi ben hep mutfak benzetmesiyle anlatıyorum. Malzeme geliyor, ayıklanıyor, dolaba giriyor, pişiriliyor ve tabağa çıkıyor. Kötü malzeme gelirse sonuç kötü olur; kötü saklarsanız yine bozulur; kötü pişirirseniz de kimse yemek istemez. Veri de pek farklı değil, inan.
Aşağıdaki tabloyu ilk kez kendi notlarımı toparlarken yapmıştım; hâlâ toplantılarda iş görüyor:
| Aşama | Ana Soru | Sık Risk | Pratik Not |
|---|---|---|---|
| Generation | Veri nereden çıkıyor? | Sahiplik belirsizliği | Kaynaktan haberiniz olsun |
| Ingestion | Veri nasıl içeri alınıyor? | Bottleneck ve gecikme | Batch mi streaming mi karar verin |
| Storage | Nereye koyacağız? | Maliyet patlaması | Sıcak-soğuk katmanları düşünün |
| Transformation | Ham veri nasıl temizlenecek? | Kural karmaşası | Dönüşümü test edin |
| Serving | Kime nasıl sunulacak? | Zayıf performans | Kullanıcı ihtiyacına göre optimize edin |
1) Generation: Verinin Doğduğu Yer
İnanın, Her şey burada başlıyor. Sensörler, uygulamalar, ödeme sistemleri, loglar… Veri kaynaklarının hepsi farklı hızda konuşur ve bazıları bayağı huysuzdur. En büyük hata da kaynağın sahibi sizmişsiniz gibi davranmaktır. Değilsiniz.
Editör masasında geçen ay karşıma çıkan bir örnek hâlâ aklımda. Bir SaaS şirketi müşteri olaylarını topluyordu ama ürün ekibi schema değişikliğini haber vermemişti. Sonuç? Gece çalışan pipeline sabaha kadar sessizce kırıldı — kimse fark etmedi çünkü alarm da yoktu. Klasik.
Kaynaktan gelen frekansı bilmek burada kritik oluyor. Günlük mü geliyor? — en azından ben öyle düşünüyorum — Saatlik mi? Anlık mı? Bir kaynak haftada iki kez güncelleniyorsa onu streaming’e zorlamak gereksiz masraf çıkarır. Saniyelik telemetriyi batch ile taşımaya kalkarsanız da kullanıcı sizi beklemez, o da ayrı dert.
2) Ingestion: Dar Boğazın Başladığı Nokta
Garip gelecek ama, Bence en çok kavga ingestion tarafında çıkıyor. Çünkü herkes kendi ihtiyacını merkeze koyuyor: analitik ekip hız ister, operasyon ekibi doğruluk ister, ürün ekibi ucuzluk ister. Hepsini aynı anda vermek kolay değil — gerçekten değil.
Bakın, Python Performans Darboğazı: Tahmin Etme, Ölç! yazısındaki yaklaşımı hatırlatan bir nokta var burada: önce ölçmeden iyileştirmeye kalkarsanız gözünüz kapalı koşmuş olursunuz. Ingestion için de aynı şey geçerli. Gecikme nerede oluşuyor? API’de mi? Kuyrukta mı? Yazma katmanında mı? Bunları görmeden çözüm üretmek biraz falcılığa kaçıyor.
İyi bir ingestion tasarımı sadece veriyi almakla kalmaz; bozuk veriyi geri iter, gecikmeyi görünür kılar ve sistemi sakin tutar.
İşin garibi, Küçük bir startup için çoğu zaman batch yaklaşımı yeterli olur; günlük çekimler hem ucuzdur hem de yönetmesi kolaydır. Enterprise seviyede ise streaming kaçınılmaz hale gelebiliyor — çünkü müşteri davranışıyla dolandırıcılık tespiti ya da canlı fiyatlama arasında dakikalar bile ciddi fark yaratıyor. Daha fazla bilgi için Sesle Kod Yazan Yerel Yapay Zekâ: Agent’ı Kurarken Neler Öğrendim? yazımıza bakabilirsiniz.
3) Storage: Ucuz Görünüp Pahalılaşan Katman
Burası benim en sevdiğim tuzaklardan biri! Depolama ilk bakışta basit görünür ama ölçek büyüyünce faturanın dili değişir. Hot storage hızlıdır ama pahalı olabilir; cold storage daha ucuzdur ama erişim ağırdır; archive ise neredeyse kasaya kaldırılmış bir dosya gibidir — var ama ona ulaşmak ayrı iş.
Durun, bir saniye.
Bunu geçen yıl Berlin’de çalışan eski bir ekip arkadaşımla konuşmuştum. Logları yıllarca hot bucket’ta tutmuşlar. Sonra aylık fatura patlayınca herkes şaşkın kaldı. Aslında — hayır dur, daha doğrusu şaşıracak durum yoktu; yanlış yerde sıcak tutulan her veri zamanla bütçeyi yakar. Kaçınılmaz. MCP mi, CLI mı? Tarayıcı Otomasyonunda Kazanan Netleşti yazımızda bu konuya da değinmiştik.
FERPA Uyumlu RAG: Kurumsal Sistemler Nerede Çuvallıyor? yazısında gördüğümüz gibi saklama politikaları yalnızca maliyet meselesi değil; uyumluluk da işin içine giriyor. Şimdi gelelim pratik tarafa: Daha fazla bilgi için MacBook Alırken Neye Bakmalı? Nisan 2026 Fırsatları yazımıza bakabilirsiniz.
- Sık sorgulanan veriyi sıcak katmanda tutun.
- Nadiren açılan tarihsel kayıtları soğuk ya da arşiv katmanına atın.
- Saklama süresi biten veriyi otomatik silmeye hazırlayın.
4) Transformation: Kirliyi Temize Çevirmek Ama Özenle
İnanın, Dönüştürme aşaması çoğu kişinin sandığı gibi sadece SQL yazmak değil aslında. Burada iş kuralı devreye girer. Hangi alan boş kalabilir, hangisi asla boş kalamaz, hangi tarih formatı kabul edilir (inanın bana). Bunların hepsi dönüşümün parçası. Ve evet — küçük görünen bir tarih formatı yüzünden bütün raporun sapıtması gayet mümkün, bunu yaşadım (ki bu çoğu kişinin gözünden kaçıyor)
LangChain Ajanlarını Üretimde İzlemek: Gerçek Zamanlı Rehber (evet, doğru duydunuz)
SELECT
customer_id,
COUNT(*) AS order_count,
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_revenue
FROM orders
WHERE created_at >= CURRENT_DATE — INTERVAL '30 days'
GROUP BY customer_id;Dönüşümde en sevmediğim şey hep sessiz hatalar oldu. Kod çalışır, çıktı gelir, dashboard dolar… ama sayıların anlamı kaymıştır. Bu yüzden test etmek şart. Hatta bazen unit test bile yetmez; örnek veri setleriyle uçtan uca kontrol yapmak gerekiyor. Ben bunu 2024’te İzmir’deki küçük bir fintech denemesinde acı şekilde öğrendim: para hareketlerinin biri çift sayıldı, diğerinin kuru çevrilmedi. Ekranda her şey güzeldi; gerçekte ise işler karışıktı.
Nerede İşe Yarıyor? Serving Katmanı Neden Hafife Alınmamalı?
Araya gireyim: Pek çok ekip bütün enerjisini upstream’e gömerken serving kısmını sonradan düşünüyor. Halbuki kullanıcı değeri tam orada görünüyor. Dashboard mu vereceksiniz? API mi sunacaksınız? ML modeline feature mı sağlayacaksınız? Cevap değiştikçe mimari de değişiyor — bu kadar basit.
Servisleme Tarafında Düşünmeniz Gerekenler
- Düşük gecikme gerekiyorsa indeksleme şarttır.
- Anlık analiz gerekiyorsa ön hesaplama iyi fikir olabilir.
- Eğer iç kullanıcı varsa sade rapor yeter; dış müşteri varsa SLA baskısı başlar.
- Bazen tek doğru cevap yoktur; birkaç servis katmanı yan yana yaşar.
Küçük takımlarda tek warehouse üzerinden servis vermek idare eder. Kurumsalda ise ayrı okuma katmanı, cache stratejisi ve rol bazlı erişim kaçınılmaz hale geliyor. Güvenlik ile performans birbirine giriyor burada — tatlı sert bir çekişme yani.
Tüm Aşamaların Üstünde Duran Görünmez Katmanlar
Şimdi gelelim asıl can alıcı yere. Security, data management, DataOps, data architecture, orchestration ve software engineering… Bunlara ben hep “görünmeyen altyapı” diyorum — çünkü ekran görüntüsünde yer almazlar. Sistem çökerse ilk onlar eksik hissedilir.
Bak şimdi, CrowdSec ile Linux Sunucunu Korumaya Al: Uygulamalı Rehber yazısındaki mantık burada da geçerli: güvenlik sonradan eklenen aksesuar değildir; borunun içinden geçen suyun kendisi kadar önemli. Veriye erişimi sınırlamazsanız iyi niyetle kurduğunuz pipeline bile risk üretir.
Küçük Startup ile Kurumsal Yapıda Aynı Değil
Küçük startup’ta amaç genelde hızlı ilerlemektir. Az kişi, az bütçe, çok iş. Bu ortamda fazla soyut mimari kurarsanız ekip nefes alamaz. Basit batch işler, temiz naming convention, iyi dokümantasyon — çoğu zaman yeterli. Fazlası bazen yük olur.
Enterprise tarafta tablo değişiyor (bizzat test ettim). Çok kaynak, çok ülke, çok mevzuat… Bir de üstüne farklı departmanların aynı datayı farklı isimlerle çağırması var ki, o bambaşka bir dert. Burada lineage, audit trail, access control ve kalite metrikleri oyuna giriyor. Aksi halde üç ay sonra kimsenin sahiplenmediği kırık tablolar ordusu oluşuyor; ben buna “sessiz kaos” diyorum.
Şunu fark ettim: Geçen sene Londra’daki bir danışmanlık görüşmesinde bunu birebir gördüm: Startup kökenli ekip production’a büyüyünce tüm tempoyu eski alışkanlıklarla sürdürmeye çalışmıştı. Olmadı tabi. İnsan sayısı artınca manuel kontrol yetmiyor; otomasyon istiyor. Ama otomasyon da kör olmayacak — ölçülü olacak (yanlış duymadınız)
Sık Yapılan Hatalar ve Küçük Kurtarma Taktikleri
- Tedarikçi veya kaynak sahibiyle hiç konuşmadan pipeline kurmak. — bunu es geçmeyin
- Saklama maliyetini küçümsemek. (bu kritik)
- Dönüşümü test etmeden prod’a almak.
- Sonra düzeltiriz” diyerek observability’yi ertelemek.
Bu dört maddeyi görünce gülüyor olabilirsiniz. Ben de güldüm açıkçası — ta ki geçmişte kurulmuş birkaç sistemi devralana kadar. Bazıları gerçekten belge bırakmamıştı; bazılarında ise belge vardı ama kimse okumamıştı. Aradaki fark sandığınızdan küçük değil (şaşırtıcı ama gerçek)
Sıkça Sorulan Sorular
Veri mühendisliği yaşam döngüsü nedir?
Verinin üretildiği andan son kullanıcıya ulaşmasına kadar geçtiği teknik süreci anlatır.
Genelde generation, ingestion, storage, transformation ve serving adımlarından oluşur.
Data lifecycle ile data engineering lifecycle arasındaki fark ne?
Data lifecycle daha çok yönetişim, saklama ve kullanım ömrüne odaklanır.
Data engineering lifecycle ise bu verinin teknik olarak nasıl işlendiğine bakar.
Batch mi streaming mi seçmeliyim?
Kullanım senaryosuna göre değişir.
Günlük raporlama için batch çoğu zaman yeterli ;
gerçek zamanlı karar gerekiyorsa streaming daha uygundur.
Depolamada en önemli konu ne?
Maliyetle erişim hızını dengede tutmak gerekir.
Yanlış katmanda uzun süre tuttuğunuz her veri ileride fatura olarak geri gelir.
Data Engineering Zoomcamp GitHub Sayfası
DAMA International Body of Knowledge
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
