Data pipeline ile ETL aynı şey mi?

Aynı değil ama iç içe kavramlardır. ETL bir veri işleme örüntüsünün adıdır — Extract, Transform, Load adımlarının sırasını anlatır. Pipeline ise bu adımları otomatik biçimde yürüten daha geniş yazılım sistemidir. Her ETL bir pipeline'dır; ama her pipeline ETL değildir — ELT, streaming akış, reverse-ETL pipeline'ları da vardır.

Veri mühendisliğine başlarken hangi pipeline aracını öğrenmek gerekir?

İlk durak SQL ve Python olmalıdır; bu ikisi olmadan hiçbir pipeline aracı işe yaramaz. Sonrasında Airflow sektörde en yaygın kullanılan orkestratördür ve iş ilanlarında en sık geçen isimdir. dbt transform tarafında yerleşik standart hâline geldi. Bu üçü iyi öğrenildiğinde modern pipeline işlerinin çoğuna giriş yapılır.

Pipeline'ı her zaman bir araçla mı kurmak gerek?

Hayır. Küçük ölçekte cron job ile tetiklenen Python script'leri pipeline işini görebilir. Ama bağımlılık, retry, alerting, geçmiş çalıştırma görünürlüğü gerekli olduğunda bir orkestratör (Airflow, Dagster, Prefect) eklenir. Karar ölçeğe ve karmaşıklığa bağlıdır; küçük setup'lar için fazla araç tam tersi yük getirir.

ELT, ETL'in yerini tamamen alacak mı?

Tamamen değil. Modern bulut ambar projelerinde ELT baskındır çünkü ambarın compute kapasitesi transform için yeterli. Ama on-premise sistemler, regülasyon nedeniyle ham verinin ambara konamayacağı senaryolar, veri maskeleme zorunluluğu olan durumlar ETL'i hâlâ tercih ettirir. İkisi birlikte yaşayacak.

Streaming pipeline'a ne zaman geçmeli?

Use case'in saniyelik tazelik gerektirdiğinde. Fraud detection, canlı öneri sistemleri, IoT telemetri, anlık dashboard'lar bu sınıfta. Karar saatlik veya günlük tazelikle yeterli olabiliyorsa batch yapı her zaman daha sade, daha ucuz, daha az operasyonel yüklüdür. Streaming'i moda olduğu için seçmek tipik bir tasarım hatasıdır.

Pipeline idempotent olmazsa ne olur?

Bir job başarısız olduğunda yeniden tetiklendiğinde duplicate kayıt üretilir, kümülatif metrikler yanlış toplanır, müşteriye iki kez bildirim gider. Failure yeniden çalıştırması data engineering'in gündelik gerçeğidir; idempotency'i baştan tasarlamak (upsert, merge, deterministik primary key) sonradan ekleyemeyeceğiniz bir özelliktir.

Veri kalitesi kontrolü pipeline'ın neresine girer?

Birden çok noktaya. Ingest sonrası kayıt sayısı, kolon NULL oranı, beklenen değer aralığı gibi kontroller yapılır. Transform sonrası birleştirilmiş tablonun bütünlüğü doğrulanır. Modern pratikte dbt testleri ve Soda, Great Expectations, Monte Carlo gibi araçlar bu kontrolleri pipeline'a entegre eder. Eşik ihlali olduğunda pipeline ya durdurulur ya alarm üretir.

Junior bir veri mühendisi pipeline projesinde nereye odaklanmalı?

Önce SQL'i çok iyi yazmak ve okumak; veri mühendisinin günlük dili budur. Sonra bir orkestratörde basit bir DAG kurmayı pratik etmek — küçük bir API'den veri çekip dönüşüm yapıp tabloya yazan üç adımlı bir pipeline çok şey öğretir. Bunun üstüne git, basit alerting, idempotency mantığı eklenir. Stack genişliği değil, döngüyü tamamlama deneyimi önemlidir.

DATA ENGINEERING PIPELINE NEDİR?

Endüstriyel veri pipeline segmenti yön oklu akış ve birleştirici flanş data engineering pipeline kavram sembolü

Cuma gecesi 02:47. Slack'te alarm: #data-platform kanalında bir pipeline kırılmış, sabah BI ekibinin günlük raporu boş çıkıyor. Veri mühendisi telefonu eline alır, neyin patladığını anlamak için log'ların peşine düşer. Bu sahnenin nadirlik değeri sıfırdır; data engineering tarafında çalışan herkes bu sahneyi yaşar. Pipeline, popüler kullanımda zannedildiği gibi sadece bir veri taşıma scripti değildir; üretim sistemi gibi davranan, izlenmesi, yeniden başlatılabilmesi, idempotent çalışması ve başarısızlığa dayanıklı olması gereken bir yazılım katmanıdır. Bu yazı, kavramı sıfırdan tanımak ve modern data stack'in parçalarının nasıl bir araya geldiğini görmek isteyen herkes için pratik bir başlangıç noktasıdır.

Data Pipeline Tanımı ve Görevi

Data pipeline, bir veya birden çok kaynaktan gelen veriyi alıp, sırayla bir dizi işlemden geçirerek bir hedef sisteme — çoğunlukla bir veri ambarı, veri gölü veya analitik katmana — ulaştıran otomatik akıştır. Tek bir SQL sorgusu, tek bir Python script'i veya tek bir araç değil; bu üçünün bağımlılık ve zamanlama kuralları içinde orkestrasyonudur.

Bir pipeline'ın varlık sebebi şudur: ham veri analitik için kullanılabilir değildir. Web sunucu loglarındaki JSON satırları doğrudan satış raporuna dönüşmez; CRM'den çekilen müşteri tablosu data warehouse'taki kullanıcı modeline aynen oturmaz. Veri, anlamlı olmadan önce taşınmalı, temizlenmeli, birleştirilmeli, doğrulanmalı ve doğru biçime sokulmalıdır. Pipeline bu işin endüstrileşmiş halidir — bir kişinin elle yaptığı işin, her gün, her saat, otomatik ve denetlenebilir biçimde yapılmasıdır.

Pipeline'ın Temel Aşamaları

Mimarisi farklı görünse de pratikte her data pipeline dört temel aşamadan geçer:

Ingest (Veri Alma): Kaynak sistemlerden veriyi pipeline'a sokar. Kaynak; OLTP veritabanı, üçüncü taraf API, dosya bırakılan SFTP, Kafka topic, webhook olabilir.
Transform (Dönüşüm): Veriyi hedef şemaya uyumlu hale getirir. Tip dönüşümü, kolon yeniden adlandırma, birleştirme, denormalizasyon, türetilmiş alan üretme, kalite kontrol burada yapılır.
Store (Depolama): Sonuç veriyi kalıcı depoya yazar — Snowflake, BigQuery, Redshift, Databricks Delta Lake, S3 parquet dosyaları gibi.
Serve (Sunma): Veriyi tüketici katmana açar: BI dashboard'u, makine öğrenmesi feature store'u, ürün backend'i için API, dış paydaşa veri ihracı.

Bu dört adım birbirini takip etmek zorunda değildir; modern mimarilerde transform store'dan sonra gelebilir (ELT yaklaşımı), veya akışlı pipeline'larda ingest ve transform iç içe örülür. Ama mantıksal işlevler aynı kalır.

ETL ve ELT — İki Farklı Yaklaşım

Pipeline dünyasında en sık karşılaşacağınız iki kısaltma ETL ve ELT'dir. Sıralama farkı küçük gibi görünür ama mimari sonuçları büyüktür.

ETL (Extract — Transform — Load) klasik yaklaşımdır. Veri kaynaktan çekilir, ayrı bir transform katmanında (genelde dedike ETL sunucusunda veya Spark cluster'ında) işlenir, sonra hedef depoya yüklenir. On-premise data warehouse dönemi bu modeli zorunlu kıldı — disk ve compute pahalıydı, ambar içinde ağır dönüşüm yapmak imkânsızdı. Kavramın kökeni ve ETL süreç tanımı hâlâ enterprise dünyasında referans noktasıdır.

ELT (Extract — Load — Transform) modern bulut ambar dönemi yaklaşımıdır. Veri kaynaktan çekilir, ham haliyle önce depoya yüklenir, transform işlemi ambarın kendi compute gücüyle SQL üzerinden yapılır. Snowflake, BigQuery, Databricks gibi sistemlerin yatay ölçeklenen compute kapasitesi bu modeli mümkün kıldı. Avantajı: ham veri her zaman ambarda durur, sonradan farklı dönüşümler için yeniden işlenebilir.

Pratikte günümüzde yeni kurulan veri platformlarının çoğu ELT'ye yakındır. dbt aracının yükselişi büyük ölçüde bu kaymanın sonucudur — transform katmanı artık SQL ve versiyonlanmış model dosyalarıyla yönetiliyor.

ETL ve ELT yaklaşımları yan yana karşılaştırma diyagramı dönüşüm sırası ve hedef ambar konumu farkı

Batch ve Streaming İşleme

Pipeline'ın zaman ekseninde iki ana çalışma modeli vardır:

Batch işleme, veriyi belirli aralıklarla — saatte bir, günde bir, ayda bir — toplu olarak işler. Çoğu raporlama, finansal kapanış, analitik beslemesi batch ile yürür. Avantajı basitlik ve maliyettir; dezavantajı tazelik gecikmesidir. Gün sonu kapanan rapor 24 saatlik veriye dayanır, anlık karar için yetmez.

Streaming (akış) işleme, veriyi geldiği an, kayıt kayıt veya küçük mikro-batch'ler halinde işler. Fraud detection, anlık öneri sistemleri, IoT telemetri, gerçek zamanlı dashboard'lar streaming gerektirir. Apache Kafka, Apache Flink, Spark Structured Streaming bu tarafın klasik araçlarıdır.

Yaygın bir mit, "modern pipeline streaming olmalı" iddiasıdır. Yanlıştır. Streaming maliyetli, karmaşık ve operasyonel yüke sahip bir modeldir. İhtiyaç yoksa batch yapısı sade ve güvenlidir. Doğru soru "batch mı streaming mi" değil, "bu use case için kabul edilebilir veri tazeliği nedir" sorusudur. Cevap saat cinsindense batch yeter; saniye cinsindense streaming gerekir.

Orkestrasyon ve Bağımlılık Yönetimi

Bir pipeline genelde tek bir adımdan ibaret değildir. Onlarca, hatta yüzlerce iş birbirine bağlıdır: kaynak A'dan veri çekilmeden tablo B üretilemez, tablo B hazır olmadan dashboard C güncellenemez. Bu bağımlılıkları yönetmek orkestrasyon katmanının işidir.

Modern data engineering dünyasında üç ana orkestrasyon aracı baskındır:

Apache Airflow: Sektör standardı kabul edilir. Python ile DAG (Directed Acyclic Graph) tanımlarsınız, her node bir task'tır. Geniş ekosistem, olgun arayüz.
Dagster: Asset-based modeli ile öne çıkar — task değil, üretilen veri varlığını birinci sınıf vatandaş yapar. Veri sözleşmesi ve test entegrasyonu güçlüdür.
Prefect: Modern API, hızlı geliştirme deneyimi, esnek hibrit yürütme modeli.

Cloud tarafında AWS Step Functions, Azure Data Factory, Google Cloud Composer da benzer rolü üstlenir. Genel mimari tasarım kararları için veri mimarisi referans kılavuzu sektörde ölçütlenmiş örüntüler sunar.

Orkestratör olmadan da pipeline çalışır — cron job ile bash script tetikleyebilirsiniz. Ama bağımlılık karmaşıklaştıkça (10+ iş, retry politikası, alerting, geriye dönük dolum), cron ile yönetmek üretimde sürdürülemez.

Modern Data Stack Bileşenleri

Son beş yılda "modern data stack" terimi yerleşti. Tek bir ürün değildir; pipeline'ı oluşturan SaaS ve açık kaynak araçların yaygın kompozisyonudur:

Ingest: Fivetran, Airbyte, Stitch — yüzlerce kaynak için hazır connector sunar.
Storage: Snowflake, BigQuery, Databricks, Redshift — ayrışmış compute ve storage mimarisiyle bulut ambarlar.
Transform: dbt — SQL tabanlı, versiyonlanmış, test edilebilir dönüşüm modelleri.
Orchestration: Airflow, Dagster, Prefect.
BI/Analytics: Looker, Tableau, Power BI, Metabase.
Observability: Monte Carlo, Datafold, Soda — veri kalitesi izleme ve anomali tespiti.

Bu yapıyı uçtan uca tasarlamak ve operasyonel hâle getirmek tek başına bir uzmanlık alanıdır. Veri mühendisliğinin pratik tarafına geçmek isteyenler için kapsamlı data engineering eğitimi bu stack'in temel araçlarını birlikte ele alan yapılandırılmış bir başlangıç olur.

Airflow DAG benzeri task düğümleri ve yönlü oklarla pipeline bağımlılık grafiği orkestrasyon diyagramı

İyi Bir Pipeline'ın Karakteristikleri

Çalışan pipeline ile iyi pipeline arasındaki fark, üretimde bir yıl geçince ortaya çıkar. Olgun pipeline'larda dört özellik aranır:

Idempotency: Aynı pipeline aynı girdiyle iki kez çalıştırıldığında sonuç değişmemelidir. "Failed olmuş job'u yeniden tetikle" senaryosu her gün gerçekleşir; non-idempotent pipeline'da bu duplicate kayıt anlamına gelir.

Observability: Pipeline çalıştığında, durduğunda, geciktiğinde haber alabilmelisiniz. Log'lar yapılandırılmış, metrikler dashboard'a düşmüş, alarm eşikleri tanımlı olmalı. "Sabah BI raporu boştu, fark ettik" pipeline'a karşı en yüksek hakaret budur.

Data quality kontrolleri: NULL beklemediğin kolonda NULL geldiğinde, kayıt sayısı %50 düştüğünde, foreign key kırıldığında pipeline ya durmalı ya kalitatif alarm üretmelidir. Sessiz veri bozulması, en pahalı veri hatasıdır — çünkü aylar sonra fark edilir.

Versiyon kontrolü ve test: Pipeline kodu bir yazılım ürünüdür. Git'te durmalı, kod review'dan geçmeli, mümkünse staging ortamda test edilmelidir. dbt, Dagster gibi araçlar bu pratiği kolaylaştırır.

Yaygın Tuzaklar

Pipeline tasarımında sık karşılaşılan hatalar tipik bir örüntü izler:

Tek dev tek pipeline: Tüm dönüşümü tek dev SQL veya tek monolit Python script'inde toplamak. Debug ve değiştirilebilirlik kaybolur. Küçük, sorumluluk ayrılmış adımlara böl.
Schema değişimine kırılganlık: Kaynak tablosuna kolon eklendiğinde pipeline patlar. Schema evolution toleransı baştan tasarlanmalı.
"Sadece çalışsın yeter" zihniyeti: İlk versiyonda yeterli; ama dokümantasyon, test ve alerting eklenmedikçe pipeline bir teknik borç çuvalına döner.
Streaming gerekmediği halde streaming seçmek: Karmaşıklığı, maliyeti, operasyonel yükü kat ve kat artırır. Önce ihtiyacı tartış.
Backfill düşünmemek: Pipeline'ı geriye dönük yeniden çalıştırma ihtiyacı kaçınılmazdır. Mimari buna uygun tasarlanmalı, yoksa her hata bir kâbus olur.

Pipeline işi başlangıçta basit görünür, üretimde ölçeklendikçe yazılım mühendisliğinin tüm disiplinlerini gerektiren bir alana dönüşür. Asıl uzmanlık SQL bilmek değil, kırılganlığı baştan tasarımla azaltabilmektir.