DATA PİPELİNE NEDİR? INGESTİON, TRANSFORM, ORKESTRASYON VE İZLEME
Ürün, pazarlama, finans ve operasyon ekiplerinin “aynı rakama” bakmasını sağlamak çoğu zaman bir dashboard meselesi değil, sağlam bir data pipeline meselesidir. Verinin nereden geldiği, nasıl taşındığı, hangi kurallarla dönüştürüldüğü ve hatalar olduğunda nasıl toparlandığı net değilse en iyi görselleştirme bile güven kaybını engelleyemez.
Bu yazıda “data pipeline nedir?” sorusunu sadece tanım düzeyinde bırakmadan; ingestion (veri alımı), transform (dönüşüm), orkestrasyon ve izleme adımlarını uçtan uca ele alacağız. Ayrıca ETL/ELT farkını, batch ve streaming akışlarını, veri kalitesi ile güvenilirliği artıran pratikleri ve gerçekçi örnek kodları bulacaksınız.
Hedefimiz; bir veri hattını tasarlarken hangi kararların kritik olduğunu, hangi bileşenlerin hangi problemleri çözdüğünü ve “çalışıyor” görünen bir sistemin neden yine de üretimde sorun çıkardığını anlaşılır bir çerçeveye oturtmak. Okumayı bitirdiğinizde kendi ortamınız için daha net bir mimari harita çıkarabilir, teknik ekiplerle daha doğru sorular üzerinden ilerleyebilirsiniz.

Data pipeline nedir ve neden kritik bir altyapıdır?
Data pipeline (veri hattı), farklı kaynaklardan gelen veriyi belirli bir hedefe düzenli, güvenilir ve izlenebilir şekilde taşıyan süreçler bütünüdür. Basit bir senaryoda bir veritabanından raporlama tablosuna gece yükleme gibi görünür; modern senaryoda ise API’ler, event akışları, dosya sistemleri, SaaS uygulamaları, sensör verileri ve log’lar gibi birçok kaynağı kapsar. Bu süreç sadece “kopyala-yapıştır” değildir; zamanlama, şema yönetimi, kalite kontrolleri, maliyet optimizasyonu ve güvenlik gibi konuların hepsi veri hattının parçasıdır.
Bir data pipeline’ın kritik olmasının temel nedeni, kararların dayandığı verinin “doğru zamanda ve doğru anlamla” sunulmasıdır. Örneğin gelir raporu gün sonunda yenileniyorsa, kampanya optimizasyonu yapan ekip için bu veri geç kalmış olabilir. Ya da sipariş tablosundaki “iptal” durumunun tanımı değiştiyse, aynı metrik farklı sonuçlar üretir. Pipeline, bu tür değişiklikleri kontrollü yönetebilmek için bir sözleşme gibi çalışır.
Pratikte pipeline tasarlarken üç hedef arasında denge kurarsınız: güvenilirlik (hata toleransı), hız (tazelik) ve maliyet. Her senaryoda en hızlı çözüm en ucuzu değildir; en ucuz çözüm de genellikle en güvenilir olan değildir. Bu yüzden pipeline’ı tek bir araç seçimi olarak değil, uçtan uca bir ürün gibi düşünmek faydalıdır: gereksinimleri, SLA’leri, izleme panoları, sürümleme ve dokümantasyonu olan bir ürün.
Veri hattı, veri platformu ve analitik katman ayrımı
Sıklıkla karışan kavramları ayırmak işleri kolaylaştırır. Data pipeline; veriyi taşır ve dönüştürür. Veri platformu; depolama, erişim kontrolü, işlem gücü ve metadata yönetimini sağlar. Analitik katman ise metriklerin tanımlandığı, semantik modelin kurulduğu ve raporlamanın yapıldığı bölümdür. Pipeline olmadan platform “depo” gibi kalır; platform olmadan pipeline geçici bir script yığınına dönüşür.
Başarılı pipeline’ın görünmeyen özellikleri
Çoğu ekip ilk sürümde “veriyi hedefe düşürmeyi” başarı sayar. Oysa asıl başarı; gecikmeleri öngörebilmek, hataları hızlı tespit edebilmek, veri kalitesini ölçebilmek ve değişiklikleri güvenle yayınlayabilmektir. Bu noktada observability (gözlemlenebilirlik), idempotency (tekrar çalıştırmada aynı sonuç) ve backfill (geçmişi yeniden üretme) gibi kavramlar devreye girer.
Ingestion: Veriyi kaynaktan güvenle almak
Ingestion, veriyi kaynak sistemlerden hedef platforma (örneğin data lake veya data warehouse) taşıma adımıdır. Burada karar vermeniz gereken ilk şey, veriyi nasıl alacağınızdır: batch mi, streaming mi? Kaynaklarınız bir veritabanı replikasyonu mu destekliyor, yoksa API çağrılarıyla mı çekmek zorundasınız? Bu sorular, seçilecek yaklaşımı belirler.
İyi bir ingestion katmanı, “veriyi bir kere çekti ve bitti” yaklaşımından fazlasını yapar. Veri artımlı mı aktarılıyor, yoksa her seferinde tam yük mü yapılıyor? Şema değişikliklerinde ne oluyor? Kaynak sistem limitleri (rate limit, CDC gecikmesi, bakım penceresi) göz önünde mi? Bu konular çözülmediyse pipeline’ın geri kalan kısmı ne kadar iyi olursa olsun üretimde sürekli sürpriz çıkar.
Batch ingestion: Planlı ve maliyet kontrollü
Batch ingestion, veriyi belirli aralıklarla toplu olarak taşır. Gece 01:00’de günlük siparişleri almak veya her 15 dakikada bir müşteri güncellemelerini çekmek gibi. Avantajı; iş yükünün planlanabilmesi ve maliyetin kontrol edilebilir olmasıdır. Dezavantajı ise tazelik: kararlarınız daha eski veriye dayanır. Batch ingestion’da sık görülen ihtiyaçlardan biri, artımlı yükleme stratejisidir: “en son güncelleme zamanı” ya da değişen kayıtların hash’i gibi bir işaretle sadece yeni/işlenen kayıtları çekmek.
Streaming ingestion: Gerçek zamana yakın akış
Streaming ingestion, olayları anlık ya da çok düşük gecikmeyle taşır. Sipariş oluşturulduğunda event yayınlamak, uygulama log’larını akıtmak veya IoT telemetrisini gerçek zamanlı işlemek gibi. Avantajı, düşük gecikme ve anlık sinyal üretimidir. Dezavantajı, işletim karmaşıklığı: mesaj sıralaması, yeniden iletim, geç gelen event’ler, “tam bir kere” semantiği gibi konular daha fazla mühendislik ister. Birçok ekip, kritik metrikler için streaming; geri kalan analizler için batch yaklaşımını birlikte kullanır.
Ham veri katmanı: Raw zone prensibi
Ingestion’ın iyi uygulamalarından biri, ham veriyi mümkün olduğunca kaynak formatına yakın şekilde saklamaktır. Bu “raw zone” yaklaşımı, yeniden işleme (reprocess) ihtiyacında hayat kurtarır. Kaynakta bir bug düzeltildiğinde ya da dönüşüm kuralı değiştiğinde, ham veriden tekrar üretim yapabilirsiniz. Ayrıca veri soyu (lineage) takibi için başlangıç noktası sağlar.
- Kaynağa en yakın şema ve alan adları korunur, sadece zorunlu teknik alanlar eklenir.
- Partition stratejisi (tarih, event zamanı, müşteri segmenti) erişim maliyetini düşürür.
- Dosya boyutu ve sıkıştırma ayarı, işlem süresini ve depolama maliyetini etkiler.
- PII alanları daha bu aşamada maskeleme veya erişim kısıtı gerektirebilir.
Transform: ETL mi ELT mi, hangi model ne zaman?
Transform aşaması, ham veriyi analize hazır hale getirdiğiniz bölümdür. Burada iki klasik yaklaşım var: ETL (Extract-Transform-Load) ve ELT (Extract-Load-Transform). ETL’de dönüşüm yüklemeden önce yapılır; ELT’de veri önce hedefe yüklenir, dönüşümler hedef ortamda çalışır. Bulut veri ambarlarının ölçeklenebilirliğiyle birlikte ELT yaklaşımı yaygınlaştı çünkü dönüşüm işini warehouse üzerinde paralel çalıştırmak daha kolay hale geldi.
Yine de tek doğru yok. Çok büyük hacimde ham log verisini lake üzerinde Spark ile işleyip sonra warehouse’a küçük, temizlenmiş bir set yüklemek ETL’ye yakın bir örnektir. Tersine, CRM ve sipariş gibi yapısal verileri warehouse’a alıp modellemek ELT’ye daha uygundur. Kararı etkileyen faktörler; veri hacmi, dönüşüm maliyeti, veri gizliliği, ekip yetkinliği ve mevcut araç ekosistemidir.
Şema yönetimi ve şema değişiklikleri
Transform katmanında en büyük sürpriz, şema değişiklikleridir. Kaynak sistem yeni bir kolon ekler, bir kolonu kaldırır ya da veri tipi değiştirir. Pipeline bu değişiklikleri yönetmezse downstream tablolar kırılır veya daha kötüsü, sessizce yanlış veri üretir. Bu yüzden şema evrimi için net bir strateji gerekir: ek kolonları otomatik kabul etmek mi, yoksa sözleşme tabanlı bir onay süreci mi?
Business kuralları: “Doğru metrik” tartışmasını bitirmek
Transform sadece teknik temizlik değildir; iş tanımlarının kodlandığı yerdir. “Aktif kullanıcı” ne demek? İade edilen sipariş gelirden nasıl düşülüyor? Kampanya maliyeti hangi zaman dilimine yazılıyor? Bu kurallar dağınık rapor script’lerine gömülürse, ekipler farklı tanımlar üretir. Daha sürdürülebilir yaklaşım, kuralları katmanlı modellerde toplamak ve herkese aynı semantik modeli sunmaktır.
dbt benzeri modelleme yaklaşımıyla katmanlar
Birçok ekip dönüşümleri katmanlara ayırır: staging (kaynağı normalize et), intermediate (işe yarar birleşimler ve zenginleştirmeler), mart (rapora hazır ölçümler). Bu yapı hem test yazmayı hem de değişiklikleri daha güvenli yönetmeyi kolaylaştırır. Özellikle “tek tabloya her şeyi yığma” yaklaşımının ölçeklenmediği noktada bu katmanlama büyük fark yaratır.
-- Örnek: Siparişleri rapora hazır hale getiren basit bir ELT modeli (SQL)
with src as (
select
order_id,
customer_id,
created_at,
status,
total_amount,
currency
from raw.orders
),
clean as (
select
order_id,
customer_id,
cast(created_at as timestamp) as created_ts,
lower(status) as status_norm,
case
when lower(status) in ('cancelled', 'canceled') then 0
else total_amount
end as net_amount,
currency
from src
)
select
order_id,
customer_id,
date_trunc('day', created_ts) as order_day,
status_norm,
net_amount,
currency
from clean
where created_ts is not null;Orkestrasyon: Bağımlılıkları yönetmek ve işleri zamanlamak
Pipeline büyüdükçe “hangi iş ne zaman çalışacak” sorusu bir takvim meselesi olmaktan çıkar ve bir bağımlılık grafiği problemine dönüşür. Orkestrasyon araçları (örneğin Airflow, Dagster, Prefect gibi) bu grafiği tanımlamanıza, işleri planlamanıza, yeniden deneme kuralları koymanıza ve başarısızlıkları yönetmenize yardımcı olur. Böylece tek tek cron job’lar yerine, yönetilebilir bir iş akışı elde edersiniz.
Orkestrasyonun değeri sadece zamanlamada değil; görünürlükte ve kontrol mekanizmasında ortaya çıkar. Hangi adımın ne kadar sürdüğü, hangi adımın sık hata verdiği, nerede darboğaz oluştuğu gibi sorular orkestrasyon katmanı üzerinden cevaplanır. Ayrıca idempotency ve backfill gibi gereksinimler için standart bir operasyon dili sağlar.

DAG yaklaşımı: Akışı parçalara bölmek
DAG (Directed Acyclic Graph) yaklaşımı, işleri küçük parçalara ayırıp bağımlılıklarını tanımlar. Örneğin önce kaynak tablosunu al, sonra staging oluştur, ardından mart tablosunu üret, en son kalite testlerini çalıştır. Bu sayede bir adım hatalandığında tüm sistemi yeniden çalıştırmak yerine sadece ilgili parçayı toparlayabilirsiniz.
Retry, timeout ve SLA: Operasyonel sözleşme
Üretimde her şey ideal gitmez. API geç cevap verir, warehouse bakım alır, ağ kısa süreli kopar. Orkestrasyon katmanında retry sayısı, backoff stratejisi, timeout ve SLA tanımı yapmak bu yüzden önemlidir. Ancak retry her zaman çözüm değildir; aynı hatayı tekrar tekrar denemek maliyeti artırır. Bu yüzden hataları sınıflandırmak (geçici mi kalıcı mı) ve alarmları doğru eşiklerle kurmak gerekir.
Örnek Airflow DAG: Ingestion + transform + kalite
Aşağıdaki örnek, günlük batch ingestion sonrası bir dönüşüm adımı ve basit bir kalite kontrolünü tek bir akışta gösterir. Gerçek hayatta bağlantılar, gizli anahtar yönetimi ve ortam değişkenleri daha detaylı ele alınmalıdır; burada amaç kavramı somutlaştırmaktır.
from datetime import datetime, timedelta
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.operators.bash import BashOperator
def ingest_orders(**context):
# Örnek: API'den veya kaynak DB'den günlük siparişleri çekip raw katmanına yazma
# Gerçekte burada watermark, sayfalama, rate limit ve yeniden deneme stratejileri olur.
run_date = context["ds"] # YYYY-MM-DD
print(f"Ingest orders for {run_date}")
return "ok"
def data_quality_check(**context):
# Örnek kalite kontrol: boş tarih, negatif tutar vb.
# Üretimde Great Expectations / Soda gibi araçlarla genişletilebilir.
print("Run basic data quality checks")
return "pass"
default_args = {
"owner": "data-platform",
"retries": 2,
"retry_delay": timedelta(minutes=10),
}
with DAG(
dag_id="daily_orders_pipeline",
start_date=datetime(2026, 1, 1),
schedule_interval="0 2 * * *",
catchup=True,
default_args=default_args,
max_active_runs=1,
dagrun_timeout=timedelta(hours=2),
) as dag:
t_ingest = PythonOperator(
task_id="ingest_orders_to_raw",
python_callable=ingest_orders,
)
t_transform = BashOperator(
task_id="run_transform_models",
bash_command="dbt run --select model_orders_daily",
)
t_quality = PythonOperator(
task_id="run_quality_checks",
python_callable=data_quality_check,
)
t_ingest >> t_transform >> t_qualityİzleme ve observability: “Çalışıyor” demek yetmez
Bir pipeline’ın en zor kısmı, ilk kez çalıştırmak değil; uzun süre sorunsuz işletmektir. İzleme (monitoring) ve observability, pipeline’ın sağlık durumunu ölçmeyi ve sorun çıktığında hızlı teşhis etmeyi sağlar. Buradaki amaç sadece “job failed” uyarısı almak değildir; gecikme artışlarını, veri hacmi anormalliklerini ve kalite bozulmalarını erken yakalamaktır.
İyi bir izleme yaklaşımı üç katmanı kapsar: sistem metrikleri (CPU, bellek, kuyruk gecikmesi), iş metrikleri (süre, başarılı/başarısız koşum sayısı) ve veri metrikleri (satır sayısı, null oranı, dağılım değişimi). Özellikle veri metrikleri, “pipeline çalıştı ama yanlış veri üretti” gibi en riskli durumları yakalamada etkilidir.

SLA ve tazelik: Analitik için zamanın anlamı
SLA, verinin hangi saat/dakikaya kadar hazır olması gerektiğini tanımlar. “Her gün 08:00’e kadar dünkü satışlar güncellenecek” gibi. Bu tanım net olmazsa, arıza anında kimin neyi beklediği belirsizleşir. Ayrıca tazelik sadece raporlama için değil; model eğitimleri, otomatik aksiyonlar ve alarmlar için de kritik olabilir.
Veri kalitesi kontrolleri: Satır sayısından dağılıma
En basit kalite kontrolü, satır sayısı karşılaştırmasıdır: “Dün 100 bin olan bugün 5 bin ise sorun var.” Ancak tek başına yeterli değildir. Null oranı, benzersizlik (unique), referential integrity, değer aralığı, kategorik dağılım gibi kontroller daha güçlü sinyaller üretir. Ayrıca belirli alanlar için “iş kuralı testleri” (örneğin net_amount negatif olamaz) en değerli kontroller arasındadır.
Lineage ve metadata: Hatanın kaynağını bulmak
Bir mart tablosu bozulduğunda, hangi ham tablolardan geldiğini, hangi dönüşümlerden geçtiğini ve hangi işlerin bunu ürettiğini bilmek önemlidir. Lineage ve metadata yönetimi, sorun çözme süresini ciddi biçimde azaltır. Ayrıca uyumluluk (compliance) ve erişim kontrolü için de temel sağlar.
Güvenilirlik pratikleri: İdempotency, backfill ve hata yönetimi
Pipeline tasarımında en pahalı hatalar, sessizce yanlış veri üretmektir. Bu yüzden güvenilirlik pratikleri, “hata olursa alarmla haber ver” yaklaşımından daha geniş bir alanı kapsar. İdempotency, aynı günün işini tekrar çalıştırdığınızda sonuçların değişmemesini hedefler. Backfill ise geçmiş veriyi, yeni kurallarla yeniden üretebilme ihtiyacını karşılar. Bu iki özellik, veri ürününün bakım maliyetini düşürür.
Idempotent yazma: Aynı işi iki kez çalıştırabilmek
Bir job yarıda kaldığında veya downstream bir adım bozulduğunda tekrar çalıştırmak istersiniz. Eğer job her seferinde hedefe “append” yapıyorsa, tekrar çalıştırma çift kayıt üretir. Bu yüzden partition bazlı overwrite, upsert (merge) veya hedef tabloyu koşum öncesi temizleme gibi stratejiler kullanılır. Hangi stratejinin uygun olduğu; hedef sistemin özelliklerine ve veri modeline bağlıdır.
Backfill stratejisi: Geçmişi güvenle yeniden üretmek
Backfill genellikle iki nedenle gerekir: geçmişte eksik kalan günler veya yeni dönüşüm kuralı. Orkestrasyon katmanında catchup özelliği, partition parametreleri ve kademeli backfill planı bu yüzden önemlidir. Büyük bir tarih aralığını tek seferde backfill etmek hem maliyeti hem de riski artırır; daha kontrollü bir yaklaşım, küçük dilimler halinde ilerlemektir.
Hata sınıflandırma ve uyarı gürültüsü
Her hata aynı önemde değildir. Geçici ağ sorunu ile şema kırılması farklı tepkiler gerektirir. Uyarı gürültüsü (alert fatigue) yaşamamak için; kritik tablolar için sıkı eşikler, düşük önemdeki işler için daha gevşek alarmlar tanımlamak gerekir. Ayrıca hata mesajlarının eylem odaklı olması önemlidir: “task failed” yerine “raw.orders kaynak tablosunda created_at null oranı %35’e çıktı” gibi.
Örnek uçtan uca mimari: Batch + streaming hibrit yaklaşım
Birçok gerçek sistem, saf batch veya saf streaming değildir. Örneğin sipariş event’leri streaming ile anlık izlenebilir; finansal kapanış raporları ise batch ile gece yeniden üretilebilir. Hibrit yaklaşım, “hız” ve “doğruluk” hedeflerini birlikte yönetmeyi sağlar: streaming hızlı sinyal üretir, batch ise doğrulama ve uzlaşma için referans olur.
Katmanlar: raw, curated ve mart
Hibrit mimaride katmanlar daha da anlam kazanır. Streaming akışında gelen event’ler önce raw katmana düşer, ardından kısa gecikmeli curated katmana dönüşür. Gün sonunda batch job, günün tamamını hesaplayıp mart katmanını “tek doğruluk kaynağı” olacak şekilde üretir. Böylece dashboard, hızlı göstergeler için curated katmanı; resmi raporlar için mart katmanını kullanabilir.
Operasyon planı: Runbook ve sahiplik
Pipeline olgunluğu, teknik mimarinin ötesinde operasyon pratikleriyle ölçülür. Runbook (olay müdahale rehberi) “hangi hata olursa ne yapılır” sorusunun yanıtını içerir. Ayrıca sahiplik (ownership) net olmalıdır: Hangi tablo hangi ekibin sorumluluğunda, hangi SLA hangi iş birimiyle anlaşılmış? Bu netlik yoksa sorun anında top birbirine atılır.
Eğitim ve yetkinlik: Araçtan önce prensip
Birçok ekip araç seçimine odaklanıp prensipleri ihmal eder. Oysa ingestion, transform, orkestrasyon ve izleme prensipleri oturmadan araç değişimi mucize yaratmaz. Eğer ekibiniz bu alanlarda sistematik bir bakış kazanmak istiyorsa Data Engineering Eğitimi sayfasındaki modül başlıkları size iyi bir yol haritası sunabilir.
Pipeline tasarlarken kontrol listesi: Hızlı karar rehberi
Yazının sonunda, bir data pipeline’ı tasarlarken en sık kaçırılan noktaları kısa bir kontrol listesiyle toparlayalım. Bu liste, yeni bir hattı sıfırdan kurarken de mevcut hattı iyileştirirken de işe yarar. Amacınız “çalıştırmak” değil; sürdürülebilir ve güvenilir bir veri ürünü üretmek olmalı.
- Kaynaklar: Hangi kaynaklar var, erişim yöntemi nedir (API, CDC, dosya, event)?
- Tazelik: Hangi tablolar için hangi SLA gerekli, gecikme toleransı nedir?
- Şema: Şema değişikliği nasıl yönetilecek, sözleşme yaklaşımı var mı?
- Dönüşüm: ETL/ELT kararı neye göre verildi, katmanlar net mi?
- Kalite: Hangi testler kritik, eşikler ve sorumlular belirlendi mi?
- Orkestrasyon: DAG bağımlılıkları, retry/timeout ve backfill planı hazır mı?
- İzleme: İş metrikleri ve veri metrikleri panoda mı, alarmlar eylem odaklı mı?
- Güvenlik: PII alanları, erişim rolleri ve audit ihtiyaçları ele alındı mı?
- Maliyet: Depolama, compute ve veri transfer maliyeti görünür mü, optimizasyon planı var mı?
Özetle; data pipeline, veri mühendisliğinin omurgasıdır ve doğru tasarlanmadığında tüm analitik ekosistemi etkiler. Ingestion ile veriyi güvenle alır, transform ile anlam kazandırır, orkestrasyon ile yönetir ve izleme ile sürdürülebilir kılarsınız. Bu dört başlığı bir arada düşündüğünüzde, “raporlar neden tutmuyor?” sorusunun yerini daha yapıcı sorular alır: “Hangi katmanda neyi iyileştirirsek güven ve hız artar?”
Doğru soruların peşinden gittiğinizde, araçlar daha kolay seçilir; ekipler arası iletişim daha netleşir; veri ürünleri ise daha uzun ömürlü olur. En önemlisi, karar vericiler veriye güvenmeye başlar ve veri ekibi sürekli “neden farklı çıktı” açıklaması yapmaktan kurtulur.


