Modern Veri Mühendisliği Kapsamlı Rehberi: Sistem Mimarisi, Veri Yaşam Döngüsü ve Yapay Zekâ Çağında Veri Altyapısı Tasarımı

(TL;DR)

Veri mühendisliği (Data Engineering), ham verinin kaynaktan çıkarılmasından güvenli biçimde depolanmasına, temizlenip dönüştürülmesinden analitik sistemlere ve yapay zekâ modellerine beslenmesine kadar tüm veri yaşam döngüsünü tasarlayan, inşa eden ve işleten bir sistem mühendisliği disiplinidir. Günümüz teknoloji dünyasında ve 2026 yılı sektörel araştırmalarında açıkça görüldüğü üzere, üretken yapay zekânın (GenAI) yaygınlaşması veri mühendisliğini ortadan kaldırmamış; aksine veri kalitesi, üstveri (metadata^?), veri soykütüğü (lineage), veri yönetişimi^? (governance) ve bulut maliyet optimizasyonu (FinOps) gibi alanları sistemlerin merkezine yerleştirmiştir. Modern veri mimarileri; geleneksel ETL süreçlerinden modern ELT ve Medallion mimarisine (Bronze, Silver, Gold), Debezium tabanlı Değişiklik Verisi Yakalama (CDC) ve Apache Kafka ile gerçek zamanlı olay akışlarına, Apache Iceberg gibi açık tablo formatlarına ve dbt tabanlı yazılım mühendisliği pratiklerine evrilmiştir. Yapay zekâ, Büyük Dil Modelleri (LLM^?) ve RAG (Retrieval-Augmented Generation) sistemlerinin başarısı, doğrudan arkasındaki veri boru hatlarının güvenilirliğine ve şema bütünlüğüne bağlıdır. Türkiye perspektifinde ise bu mimarilerin 6698 sayılı KVKK^? ilkeleriyle (veri minimizasyonu, amaçla sınırlılık, erişim yetkilendirmesi, maskeleme ve imha) baştan uca uyumlu tasarlanması teknik ve yasal bir zorunluluktur.

Yazar: Avukat & Veri Sorumlusu Yusuf KILIÇKAN | Tarih: 30 Eylül 2026

Veri Mühendisliğinin Tanımı ve Sistem Mühendisliği Yaklaşımı

Veri mühendisliği en yalın tanımıyla; ham veriyi güvenilir, erişilebilir, ölçeklenebilir ve iş birimleri ile yapay zekâ sistemleri tarafından kullanılabilir veri ürünlerine dönüştüren sistemlerin tasarlanması ve işletilmesidir. Sektörde sıklıkla düşülen en büyük yanılgı, bu disiplini yalnızca bir kaynaktan CSV dosyası okuyup Python betiğiyle ilişkisel bir veritabanına aktarmaktan ibaret bir "ETL yazarlığı" olarak görmektir. Oysa bizzat veri boru hatlarının üretim (production) ortamlarını tasarlarken ve mimari kararları verirken tecrübe ettiğimiz üzere, veri mühendisliği özünde yüksek erişilebilirlik, hata toleransı ve veri tutarlılığı gerektiren bir dağıtık sistem mühendisliğidir.

Gerçek bir üretim ortamında veri mühendisliği; web ve mobil uygulamalardan, harici API servislerinden, operasyonel veritabanlarından ve telemetri sensörlerinden akan heterojen verilerin toplanmasıyla başlar. Bu zincir; ham verinin nesne depolama katmanlarına aktarılmasını, akış işleme mekanizmalarını, veri ambarı ve veri gölü mimarilerini, boyut modellemelerini, veri güvenliği protokollerini, veri soykütüğünü ve gözlemlenebilirlik araçlarını içeren devasa bir dağıtık omurgadır. Veri mühendisi, "Bu veri nihai kullanıcıya, analiste veya makine öğrenmesi modeline milisaniyeler ya da dakikalar mertebesinde en doğru, bozulmamış ve güvenli şekilde nasıl ulaştırılır?" sorusunun yanıtını veren altyapıyı inşa eder. Bu yönüyle veri mühendisliği, modern kurumsal yazılım mimarisinin en temel taşıyıcı kolonudur.

Veri Ekosistemindeki Rollerin Ayrışması ve Kesişim Noktaları

Veri odaklı organizasyonlarda unvanlar birbirine yakın görünse de odaklandıkları temel sorular, kullandıkları araçlar ve ortaya koydukları çıktılar köklü biçimde farklılaşır. Veri analisti geçmişe dönük iş sorularına cevap ararken, veri bilimci geleceğe yönelik istatistiksel tahmin modelleri geliştirir. Makine öğrenmesi mühendisi (ML Engineer) bu modelleri ölçeklenebilir biçimde canlı sistemlere entegre ederken, analitik mühendisi (Analytics Engineer) veri ambarı içerisindeki temizlenmiş verileri dbt gibi modelleme araçlarıyla iş birimlerinin doğrudan sorgulayabileceği analitik tablolara dönüştürür.

Veri mühendisi ise tüm bu uzmanlıkların üzerinde çalıştığı veri otobanını inşa eden aktördür. Veri bilimcinin bir restoranda malzemeleri işleyerek yemek sunan şefe benzetildiği analojide; veri mühendisi o mutfağın gazını, suyunu, elektrik altyapısını, soğuk hava deposunu ve kesintisiz tedarik zincirini kuran mühendistir. Altyapı güvenilir olmadığında en gelişmiş yapay zekâ modeli dahi işlevsiz kalır. Modern teknoloji ekiplerinde kıdemli bir veri mühendisi; ileri seviye SQL ve Python yetkinliğinin yanı sıra Terraform ile kod olarak altyapı (IaC) kurgulayan, Docker ve Kubernetes konteyner mimarilerini yönetebilen, Kafka ve Spark kümelerini optimize edebilen hibrit bir sistem mimarı kimliği taşır.

Büyük Veri Altyapılarının Tarihsel Evrimi

Veri mühendisliğinin evrimi, verinin hacmi, hızı ve çeşitliliğindeki devasa artışa paralel bir seyir izlemiştir. 2000'li yılların öncesinde yazılım dünyası, doğrudan ilişkisel veritabanları (RDBMS) üzerinde dönen operasyonel sistemlerle sınırlıydı. Ancak kurumsal şirketlerin büyümesiyle birlikte, operasyonel veritabanlarının ağır analitik sorgular altında kilitlenmesini önlemek amacıyla analitik veri ambarları (Data Warehouse) dönemi başladı. Bu dönemde ERP, CRM ve finans sistemlerinden alınan veriler geleneksel ETL yöntemleriyle merkezi ambarlara taşınarak ilk iş zekâsı raporlamaları hayata geçirildi.

2010'lu yıllara gelindiğinde tek bir sunucunun bellek veya disk kapasitesine sığmayan petabaytlarca verinin ortaya çıkması, Hadoop, MapReduce ve HDFS gibi dağıtık dosya sistemlerini merkeze alan Büyük Veri devrimini tetikledi. Ardından gelen bellek içi dağıtık hesaplama motoru Apache Spark, veri işleme hızlarını katbekat artırdı. 2015-2020 aralığında ise Snowflake ve Google Cloud BigQuery gibi bulut tabanlı veri ambarları, depolama ile hesaplama kaynaklarını birbirinden ayırarak sektöre yeni bir soluk getirdi.

Günümüzün ve 2026'nın en baskın mimari tercihi ise Lakehouse yaklaşımıdır. Veri ambarlarının katı şema yapısı ve yüksek maliyeti ile veri göllerinin (Data Lake) yapılandırılmamış verileri ucuz nesne depolamada tutma esnekliği, Lakehouse mimarisinde birleşmiştir. Apache Iceberg ve Delta Lake gibi açık tablo formatları sayesinde, nesne depolama üzerindeki açık veri dosyaları veri ambarı benzeri ACID işlem garantilerine, şema yönetimine ve doğrudan sorgu kabiliyetine kavuşmuştur.

ETL’den ELT’ye Dönüşüm ve dbt ile Artımlı Modelleme

Geleneksel veri mimarilerinde uzun yıllar uygulanan ETL (Extract-Transform-Load) yaklaşımında veriler kaynak sistemden çekilir, ambar dışındaki ayrı bir işleme sunucusunda (genellikle Python veya özel ETL araçları ile) işlenir, temizlenir ve ardından hedefe yazılırdı. Bu model, veri hacminin patladığı ve hesaplama gücünün sınırlı olduğu dönemlerin bir zorunluluğuydu. Ancak modern bulut veri ambarlarının dağıtık SQL çalıştırma kapasitelerinin muazzam boyutlara ulaşması, bu paradigmayı kökten değiştirerek yerini ELT (Extract-Load-Transform) modeline bırakmıştır.

ELT yaklaşımında ham veri hiçbir yapısal değişikliğe uğratılmaksızın doğrudan hedef veri gölüne veya ambarına yüklenir; tüm temizleme, zenginleştirme ve modelleme işlemleri doğrudan ambarın kendi işlem motoru üzerinde SQL çalıştırılarak gerçekleştirilir. Bu dönüşüm devriminin kalbinde yer alan dbt (data build tool), veri mühendisliğine modern yazılım geliştirme pratiklerini kazandırmıştır. dbt sayesinde SQL modelleri Git sürüm kontrolüne bağlanmakta, kodlar test edilmekte, dokümante edilmekte ve bağımlılık grafikleri (DAG) otomatik olarak oluşturulmaktadır.

Bizzat üretim modellerimizde uyguladığımız dbt artımlı yükleme (incremental modeling) stratejisi, milyarlarca satırlık tablolarda her çalıştırmada tablonun tamamını baştan oluşturmak yerine yalnızca son çalıştırmadan bu yana değişen veya eklenen kayıtları işleyerek işlem sürelerini ve bulut maliyetlerini ciddi oranda aşağı çekmektedir. Bu yöntem, hem veri tazeliğini dakikalar seviyesine indirir hem de gereksiz hesaplama kaynağı tüketiminin önüne geçer.

Toplu (Batch) ve Gerçek Zamanlı Akış (Streaming) Mimarileri

Veri mühendisliği pratiğinde verinin hangi sıklıkla işleneceği, maliyet ve iş ihtiyacı dengesinde belirlenen en stratejik kararlardan biridir. Belirli zaman aralıklarında (her gece, saat başı veya 15 dakikada bir) toplu olarak çalışan toplu işleme (batch processing) sistemleri, özellikle muhasebe mutabakatları ve günlük finansal kapanış tabloları için halen en kararlı ve maliyet-etkin çözümdür. Her veri akışını gereksiz yere gerçek zamanlı hale getirmeye çalışmak, mühendislik kaynaklarının ve altyapı bütçelerinin israf edilmesine yol açar.

Buna karşın dolandırıcılık tespiti (fraud detection), dinamik fiyatlandırma, anlık kullanıcı etkileşimleri ve IoT telemetri verileri gibi senaryolarda verinin üretildiği anda işlenmesi zorunludur. Dağıtık bir olay akış platformu olan Apache Kafka, modern gerçek zamanlı mimarilerin omurgasını oluşturur. Olay üreticileri (producers) tarafından üretilen JSON, Avro veya Protobuf formatındaki mesajlar, Kafka topic'lerine gönderilir; bu topic'ler paralelleştirme sağlamak amacıyla bölümlere (partitions) ayrılır ve tüketici grupları (consumer groups) tarafından ofset (offset) takibi yapılarak asenkron şekilde tüketilir.

Bu sürecin kaynak veritabanlarındaki en zarif uygulaması ise Değişiklik Verisi Yakalama (Change Data Capture - CDC) teknolojisidir. Geleneksel sistemlerde her gece üretim veritabanına gidip belirli bir zaman damgasına göre sorgu atmak, üretim veritabanının CPU ve bellek kaynaklarını tüketir. Debezium gibi gelişmiş CDC araçları ise PostgreSQL veya MySQL'in doğrudan önceden yazma günlüklerini (Write-Ahead Log / binlog) okuyarak veritabanında meydana gelen her bir ekleme, güncelleme ve silme işlemini milisaniyeler içinde birer olay olarak Kafka'ya fırlatır. Böylece operasyonel sistem yorulmadan tüm veri değişiklikleri anlık olarak analitik platforma replike edilir.

OLTP ve OLAP Ayrımı ile Dağıtık Analitik Motorlar

Veritabanı mimarilerini tasarlarken gözettiğimiz en temel ayrım, operasyonel iş yükleri (OLTP) ile analitik iş yükleri (OLAP) arasındaki yapısal uyumsuzluktur. Çevrimiçi İşlem İşleme (OLTP) veritabanları (PostgreSQL, MySQL, Oracle); satır tabanlı çalışan, ACID prensiplerine sıkı sıkıya bağlı, binlerce eşzamanlı kullanıcının anlık kayıt ekleme, güncelleme ve tekil sorgulama yapması için optimize edilmiş sistemlerdir. Bir bankacılık transferi veya e-ticaret sipariş oluşturma işlemi klasik bir OLTP senaryosudur.

Çevrimiçi Analitik İşleme (OLAP) sistemleri (BigQuery, ClickHouse, Snowflake, Redshift) ise sütun tabanlı (columnar) mimariye sahiptir. Milyonlarca satır üzerinde matematiksel toplulaştırma sorgularının saniyeler içinde koşması için tasarlanmışlardır. Bir analistin son beş yıldaki bölgesel ciro dağılımını doğrudan operasyonel PostgreSQL veritabanında hesaplamaya kalkışması, tablonun kilitlenmesine, disk I/O kapasitesinin tükenmesine ve canlı uygulamanın çökmesine yol açar. Bu nedenle veri mühendisleri, üretim veritabanı ile analitik ambarı kesin çizgilerle izole ederek CDC ve ELT boru hatlarıyla beslenen bağımsız OLAP ortamları kurgularlar.

Lakehouse Mimarisi ve Apache Iceberg Açık Tablo Formatı

Geleneksel veri göllerinde verilerin nesne depolama üzerinde salt Parquet formatında tutulması, ACID işlem garantilerinin bulunmaması nedeniyle eşzamanlı yazma ve okumalarda veri tutarsızlıklarına yol açmaktaydı. İşte Apache Iceberg, Delta Lake ve Apache Hudi gibi açık tablo formatları bu krizi çözmek amacıyla doğmuştur. 2026 yılı itibarıyla kurumsal veri platformlarında benimsenme oranı hızla artan Apache Iceberg, büyük veri tablolarını yüksek performansla yönetmek için tasarlanmış açık kaynaklı bir spesifikasyondur.

Apache Iceberg'in veri mühendisliği mimarilerine kazandırdığı en devrimsel yetenekler şunlardır:

• Tabloya yeni bir kolon eklendiğinde veya kolon silindiğinde mevcut veri dosyalarını yeniden yazmaya gerek kalmaksızın metaveri düzeyinde anında değişiklik yapılabilmesini sağlayan şema evrimi (schema evolution),
• Tablonun bölümleme mantığı değiştirildiğinde geçmiş verileri fiziksel olarak taşımadan yeni düzenin uygulanmasını mümkün kılan bölümleme evrimi (partition evolution),
• Kullanıcıların sorgularında fiziksel dizin yapısını bilmek zorunda kalmadan doğrudan tarih alanları üzerinden sorgu atabilmesini sağlayan gizli bölümleme (hidden partitioning),
• Tablonun geçmiş anlık görüntülerine (snapshots) dönülerek verinin dünkü veya geçen haftaki hali üzerinden denetim ve hata ayıklama yapılabilmesini sağlayan zaman yolculuğu (time travel),
• Aynı tabloya Spark, Trino, Flink veya DuckDB gibi birbirinden tamamen bağımsız motorların eşzamanlı ve tutarlı biçimde erişebilmesidir.

Medallion Mimarisi ve Veri Rafinasyon Katmanları

Modern veri platformlarında ve Lakehouse tasarımlarında en yaygın kabul gören mimari desen, verinin kalitesini adım adım artıran Medallion (Madalyon) mimarisidir. Bu mimari, ham veriden nihai raporlama katmanına kadar verinin hangi aşamalardan geçeceğini net bir standarda bağlar:

Bronze katmanı, kaynak sistemlerden (API, Kafka, veritabanı dökümleri) gelen verinin hiçbir filtreleme veya işleme tabi tutulmaksızın, orijinal formatında ve geçmişe dönük tam izlenebilirlik sağlayacak şekilde nesne depolamaya yazıldığı ham katmandır. Buradaki amaç, kaynak sistemde bir sorun olsa dahi verinin orijinal halinin sistemlerimizde güvenle saklanmasıdır.

Silver katmanı, Bronze katmanındaki verilerin şema doğrulamalarından geçirildiği, yinelenen kayıtların ayıklandığı, tip dönüşümlerinin yapıldığı, geçersiz boş değerlerin kontrol edildiği ve zenginleştirildiği temizlenmiş kurumsal hafızadır. Veri bilimciler ve analistler keşifsel çalışmalarını güvenle bu katman üzerinde yürütür.

Gold katmanı ise Silver katmanındaki tabloların belirli iş hedefleri doğrultusunda birleştirildiği, toplulaştırıldığı ve boyut modellerine dönüştürüldüğü nihai iş katmandır. Müşteri yaşam boyu değeri, günlük ciro metrikleri ve finansal risk tabloları bu katmanda yer alır ve doğrudan iş zekâsı araçlarına ya da makine öğrenmesi modellerine servis edilir.

Boyutsal Modelleme, Star Schema ve Yavaş Değişen Boyutlar (SCD)

Veri ambarlarının kalbinde Ralph Kimball tarafından temelleri atılan boyutsal modelleme (dimensional modeling) yatar. Boyutsal modelleme, analitik sorguların hızla çalışması ve iş kullanıcılarının veriyi sezgisel olarak anlayabilmesi için tabloları "Fact" ve "Dimension" olarak ikiye ayırır. Fact tabloları ölçülebilir sayısal olayları (satış tutarı, işlem adedi, bekleme süresi) barındırırken; Dimension tabloları bu olayların bağlamını tanımlayan nitelikleri (müşteri adı, ürün kategorisi, mağaza lokasyonu, takvim tarihi) içerir.

Bu modellemenin en popüler biçimi olan Star Schema (Yıldız Şema) tasarımında, merkezde devasa bir Fact tablosu ve etrafında bu tabloya yabancı anahtarlarla bağlı Dimension tabloları yer alır. Boyutsal modellemede veri mühendisinin karşısına çıkan en klasik problem ise zaman içinde değişen verilerin nasıl yönetileceğidir (Slowly Changing Dimensions - SCD):

• SCD Type 1 yaklaşımında, boyuttaki eski bilginin üzerine doğrudan yeni bilgi yazılır. Örneğin İzmir'de ikamet eden bir müşterinin İstanbul'a taşınması halinde şehir kolonu güncellenir; müşterinin geçmişte İzmir'de yaşadığı bilgisi kaybolur. Geçmiş analizi gerektirmeyen durumlarda tercih edilir.
• SCD Type 2 yaklaşımında ise, boyuttaki değişikliklerin geçmiş tarihçesini korumak amacıyla yeni bir satır açılır. Müşterinin eski satırına bir bitiş tarihi ve pasif bayrağı eklenirken, İstanbul adresini içeren yeni bir satır oluşturularak başlangıç tarihi atanır. Böylece müşterinin İzmir'de yaşadığı dönemde yaptığı harcamalar doğru lokasyonla analiz edilebilir. Bu yapı, veri bütünlüğü ve geçmişe dönük raporlama açısından kritik önem taşır.

Programlama Dilleri ve İşlem Motorları: SQL, Python, Spark ve DuckDB

Veri mühendisliği araçları hızla çeşitlense de programlama dili cephesinde SQL ve Python tahtını korumaya devam etmektedir. SQL, veri ambarlarında ve ilişkisel sistemlerde veriyi dönüştürmenin evrensel standardıdır. Yetkin bir veri mühendisi yalnızca basit sorgular yazmakla kalmaz; analitik pencereler açan Window Functions (SUM OVER PARTITION BY), Common Table Expressions (CTE), karmaşık JOIN algoritmaları, sorgu yürütme planları ve indeksleme stratejileri üzerinde tam hakimiyet kurar.

Python ise API entegrasyonlarından otomasyona, veri doğrulama kütüphanelerinden büyük veri çerçevelerine kadar geniş bir yelpazede orkestrasyonun omurgasını oluşturur. Ancak burada veri hacmine göre doğru işlem motorunu seçmek hayati bir mühendislik refleksidir. Veri bilimi eğitimlerinde yaygın olarak kullanılan Pandas kütüphanesi, veriyi tek bir sunucunun geçici belleğinde (RAM) işler. Veri boyutu birkaç gigabaytı aştığında Pandas bellek yetersizliği hatası vererek çöker.

Yüzlerce gigabayt veya terabaytlarca dağıtık veri söz konusu olduğunda devreye giren Apache Spark, veriyi bir ana sunucu (driver) ve onlarca işçi sunucu (worker) arasında paylaştırarak bellek içi paralel işleme tabi tutar. Ancak modern veri mühendisliğinde her soruna Spark ile yaklaşma yanılgısından kaçınmak gerekir. Küçük ve orta ölçekli veri setlerinde küme ayağa kaldırmanın getirdiği gecikme ve maliyet gereksizdir. Son yıllarda yükselen DuckDB gibi süreç içi (in-process) sütun tabanlı SQL motorları, tek bir makinenin tüm çekirdeklerini ve diskini son derece verimli kullanarak gigabaytlarca veriyi Spark'a ihtiyaç duymadan saniyeler içinde işleyebilmektedir.

İş Akışı Orkestrasyonu: Apache Airflow ve Dagster

Onlarca farklı kaynaktan gelen, birbirine bağımlı yüzlerce veri boru hattının hangi sırayla çalışacağını, bir adım başarısız olduğunda ne yapılacağını ve sistemin nasıl izleneceğini belirleyen katman orkestrasyondur. Sektör standardı haline gelen Apache Airflow, iş akışlarını Python koduyla tanımlanan Yönlü Döngüsüz Grafikler (Directed Acyclic Graph - DAG) olarak modeller.

Burada bilinmesi gereken en kritik ayrım şudur: Airflow bir veri işleme motoru değil, bir orkestratördür. Airflow'un görevi terabaytlarca veriyi kendi belleğinden geçirmek değil; "Spark işini başlat", "dbt modelini çalıştır", "S3'e dosya geldi mi kontrol et", "Veri kalitesi testini tetikle" ve "İşlem bittiğinde ilgili kanala bildirim gönder" talimatlarını yönetmektir.

Airflow'un görev tabanlı (task-oriented) yaklaşımına alternatif olarak son dönemde öne çıkan Dagster ise varlık tabanlı (asset-oriented) bir orkestrasyon felsefesi sunar. Dagster, çalıştırılan adımlardan ziyade üretilen nihai veri varlığının (tablo, dosya, model) durumunu, tazeliğini ve veri soykütüğünü merkeze alarak modern veri ekiplerine operasyonel şeffaflık kazandırır.

Veri Kalitesi, Gözlemlenebilirlik ve Veri Soykütüğü

Bir veri boru hattının teknik olarak yeşil yanması ve başarılı tamamlanması, üretilen verinin doğru olduğu anlamına gelmez. Bizzat altyapı operasyonlarımızda karşılaştığımız en tehlikeli senaryo; boru hattının hatasız çalışmasına rağmen kaynak API'deki bir değişiklik sebebiyle ciro kolonuna fazladan basamak eklenmesi ya da müşteri kimliklerinin boş gelmesidir. Teknik olarak başarılı ancak anlamsal olarak hatalı bu durumları önlemek için proaktif veri kalitesi kontrolleri şarttır.

Modern mimarilerde Great Expectations veya Soda gibi araçlarla boru hatlarının arasına şu testler yerleştirilir:

• Birincil anahtarların ve kritik alanların asla boş kalmamasını güvenceye alan boş değer kontrolleri (null checks),
• İşlem kimliklerinin tekilliğini doğrulayan benzersizlik (uniqueness) testleri,
• Satış tablosundaki müşteri kodunun müşteri ana tablosunda varlığını denetleyen referans bütünlüğü testleri,
• Beklenen verinin zamanında gelip gelmediğini ve günlük satır sayısındaki olağan dışı sapmaları yakalayan tazelik ve hacim kontrolleri,
• Ortalama sipariş tutarı gibi metriklerdeki ani sıçramaları tespit eden dağılım anomalisi testleridir.

Veri gözlemlenebilirliği (data observability) ise sistem çöktüğünde hatanın hangi tabloda, hangi bölümde ve hangi kaynak değişikliğinden ötürü gerçekleştiğini loglar, metrikler ve izler üzerinden açıklar. Bu yapının ayrılmaz parçası olan veri soykütüğü (data lineage), bir verinin doğduğu operasyonel tablodan nihai yönetim raporuna kadar hangi dönüşümlerden geçtiğini gösteren yol haritasıdır. OpenLineage gibi açık standartlar, metadata ve soykütüğü bilgilerini otomatik toplayarak kurumsal şeffaflık sağlar.

Şema Yönetimi, Veri Sözleşmeleri ve Parquet Depolama Formatı

Yazılım geliştiricilerin operasyonel veritabanında yaptığı plansız bir değişiklik (örneğin bir kolonun adını değiştirmek veya tamsayı olan alanı metin formatına çevirmek), alt akıştaki tüm veri ambarı boru hatlarının ve makine öğrenmesi modellerinin çökmesine neden olur. Bu iletişim kopukluğunu gidermek için modern veri mühendisliğinde Veri Sözleşmeleri (Data Contracts) kavramı doğmuştur. Veri sözleşmesi; veriyi üreten yazılım ekibi ile veriyi tüketen veri ekibi arasında şemanın yapısını, alan tiplerini, izin verilen boşluk oranlarını ve hizmet seviyesi taahhütlerini (SLA) kod düzeyinde bağlayan resmi bir mutabakattır. Üretici sistem sözleşmeye aykırı bir veri göndermeye çalıştığında boru hattı kontrollü olarak durdurulur veya veri karantina tablosuna alınır.

Depolama formatı tarafında ise analitik iş yüklerinin tartışmasız lideri Apache Parquet formatıdır. CSV veya JSON gibi satır tabanlı metin dosyaları, her sorguda diskin tamamının taranmasını gerektirdiği için analitik dünyada son derece verimsizdir. Parquet ise sütun tabanlı, kendi şemasını içinde barındıran ve ileri düzey sıkıştırma algoritmaları (Snappy, ZSTD) kullanan bir ikili formattır. Yalnızca birkaç kolonu toplayan bir analitik sorgu çalıştığında, Parquet motoru diskten diğer kolonları hiç okumaksızın atlar; bu da I/O maliyetini ve sorgu süresini dramatik biçimde düşürür.

Bölümleme (partitioning) stratejilerinde ise yüksek kardinaliteli alanlara göre aşırı bölümleme yapıldığında nesne depolama üzerinde her biri birkaç kilobaytlık milyonlarca dosya oluşur. Büyük veri literatüründe buna "Küçük Dosya Problemi" (Small Files Problem) denir. Sorgu motorları bu milyonlarca dosyanın metaverisini okumaktan kilitlenir. Çözüm; optimize edilmiş dosya boyutlarının (128 MB - 512 MB) hedeflenmesi ve arka planda çalışan sıkıştırma (compaction) süreçleriyle küçük Parquet parçacıklarının düzenli aralıklarla birleştirilmesidir.

Dağıtık Sistemlerde Darboğazlar ve İdempotency İlkesi

Apache Spark gibi dağıtık hesaplama kümelerinde kod yazan bir mühendis, yazdığı fonksiyonların küme donanımında nasıl bir fiziksel iş yükü yarattığını bilmek zorundadır. Bu bağlamda karşılaşılan en ağır iki performans darboğazı şunlardır:

• Veri Çarpıklığı (Data Skew): Dağıtık kümedeki verilerin eşit dağılmaması durumudur. Örneğin yüz milyon satırlık bir e-ticaret verisinde işlemlerin büyük kısmı tek bir kurumsal müşteriye aitse, Spark bu veriyi bölüştürdüğünde diğer işçi sunucular işini saniyeler içinde bitirip boşta beklerken, o tek müşterinin verisini alan işçi sunucu saatlerce çalışır ve bellek yetersizliğinden çökebilir. Bu durum tuzlama (salting) teknikleriyle anahtar alanlara rastgele önekler eklenerek çözülür.
• Shuffle Operasyonları: JOIN, GROUP BY ve DISTINCT gibi işlemler, verilerin ağ üzerinden sunucular arasında yer değiştirmesini gerektirir. Ağ üzerinden veri taşımak en pahalı işlemdir. İyi bir veri mühendisi, gereksiz shuffle adımlarından kaçınacak şekilde yayınlama birleştirmeleri (broadcast join) ve uygun önceden bölümleme stratejileri kurar.

Tüm bu dağıtık boru hatlarının taşıması gereken en hayati mimari nitelik ise İdempotency (Tekrarlanabilirlik) ilkesidir. Bir veri boru hattı aynı parametrelerle bir kez de çalışsa, ağ hatası yüzünden on kez de yeniden çalıştırılsa hedef tabloda her zaman aynı doğru sonucu üretmelidir. Eğer bir boru hattı ikinci kez çalıştığında toplam ciroyu mükerrer kayıtlarla ikiye katlıyorsa o boru hattı üretim ortamına hazır değildir. Bu güvence, salt ekleme yerine MERGE ve UPSERT mantıkları, işlem bazlı tekil anahtarlar ve geçici aşama tabloları (staging) kullanılarak inşa edilir.

DataOps Kültürü, CI/CD ve Kod Olarak Altyapı (Terraform)

Geleneksel yazılım mühendisliğinde yıllardır olgunlaşan DevOps kültürü, modern veri dünyasına DataOps olarak uyarlanmıştır. Bir veri mühendisi asla canlı veritabanına bağlanıp arayüzden tablo oluşturmaz veya sunucu üzerinde elle betik çalıştırmaz. Tüm veri altyapısı sürüm kontrollü kod olarak yönetilmelidir.

Modern bir DataOps döngüsünde:

• Boru hattı kodları, dbt modelleri ve SQL dönüşümleri Git depolarında dallanma stratejileriyle geliştirilir ve Pull Request süreçleriyle akran denetiminden geçer.
• Sürekli Entegrasyon (CI) hatlarında otomatik birim testleri, kod formatı denetimleri ve test ortamları üzerinde veri bütünlüğü testleri koşturulur.
• Altyapı kurulumları; nesne depolama alanları, IAM yetkilendirmeleri, Kafka topic'leri ve veri ambarı kaynakları Terraform gibi Kod Olarak Altyapı (IaC) araçlarıyla şablonlaştırılır; böylece tüm ortam tek bir komutla sıfırdan ve hatasız biçimde yeniden ayağa kaldırılabilir.
• Orkestrasyon servisleri, veri dönüştürücüler ve mikroservisler Docker konteynerleri içine paketlenerek Kubernetes kümeleri üzerinde izole, taşınabilir ve yatayda otomatik ölçeklenebilir şekilde konuşlandırılır.

Bulut Mimarilerinde FinOps ve Maliyet Mühendisliği

Bulut bilişim, veri mühendislerine sınırsız depolama ve hesaplama esnekliği sunarken, kontrolsüz tasarlandığında şirketleri çok yüksek faturalarla baş başa bırakabilir. dbt Labs'ın 2026 sektörel araştırmasında veri liderlerinin yüzde elli yedisinin bulut ambarı ve işlem harcamalarının kontrolsüzce arttığını bildirmesi, FinOps (Finansal Operasyonlar) ve maliyet mühendisliğini veri ekiplerinin birincil gündemi haline getirmiştir.

Bir veri ambarında tek bir analistin yanlış yazılmış bir sorguyla tüm tabloyu baştan taraması (full table scan) tek bir çalıştırmada çok yüksek maliyetler yaratabilir. Veri mühendisi, sistemleri maliyet bilinciyle tasarlamak zorundadır. Bu optimizasyon; doğru bölümleme (partitioning) ve kümeleme (clustering) yaparak taranan veri miktarını terabaytlardan gigabaytlara indirmek, artımlı veri işleme modelleri kurmak, sonuçları önbelleğe almak, kullanılmayan geliştirme sunucularını otomatik kapatmak ve iş yüklerini kritiklik derecelerine göre farklı işlem havuzlarına ayırmak suretiyle sağlanır.

Yapay Zekâ, Büyük Dil Modelleri ve RAG Sistemlerinde Veri Mühendisliği

2026 yılı itibarıyla yapay zekâ ve Büyük Dil Modellerinin yükselişi, veri mühendisliğine olan ihtiyacı azaltmamış; tam aksine kaliteli veriye duyulan ihtiyacı artırmıştır. Bilgisayar biliminin en temel aksiyomlarından olan "Çöp Girerse Çöp Çıkar" (Garbage In, Garbage Out) ilkesi, üretken yapay zekâ çağında katı bir gerçekliktir. Dünyanın en gelişmiş dil modelini kullansanız dahi, modele beslediğiniz veri bayat, hatalı, mükerrer veya bağlamdan yoksunsa sistem kaçınılmaz olarak halüsinasyon görecek ve yanlış çıktılar üretecektir.

Özellikle şirket içi belgelerle yapay zekâyı konuşturan RAG (Retrieval-Augmented Generation) mimarileri, özünde karmaşık bir veri mühendisliği problemidir. Örneğin kurumsal bir platformda mevzuat metinlerinin, mahkeme içtihatlarının, sözleşmelerin ve teknik dokümanların yapay zekâya açılması sürecini ele alalım. Bu zincir; belgelerin OCR ve doğal dil işleme araçlarıyla taranmasını, temizlenmesini, anlamsal parçalara (chunking) bölünmesini, üstverilerinin etiketlenmesini, embedding modelleriyle sayısal vektörlere dönüştürülmesini ve pgvector, Qdrant veya Milvus gibi vektör veritabanlarına yazılmasını gerektirir.

Vektör veritabanlarının varlığı klasik veri mühendisliği sorunlarını ortadan kaldırmaz. Verinin ne zaman güncelleneceği, eskiyen vektörlerin nasıl silineceği, dokümana kimlerin erişim yetkisi bulunduğu ve kaynak veri değiştiğinde vektör indeksinin nasıl tazeleneceği doğrudan veri mühendisinin kurgulayacağı boru hatlarına bağlıdır.

Veri Güvenliği, Yönetişim ve KVKK Uyumlu Sistem Tasarımı

Bir veri mühendisi için güvenlik ve yasal uyum artık işin sonunda kontrol edilen bir detay değil, mimarinin temel taşıdır. Ham veriden analitik çıktılara ve yapay zekâ sistemlerine uzanan hatta, hassas kişisel verilerin kontrolsüzce dolaşması telafisi imkansız hukuki ve mali yaptırımlar doğurur.

Türkiye'de faaliyet gösteren sistemler açısından 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), veri boru hatlarının tasarımında katı normatif kısıtlar getirmektedir:

• Veri Minimizasyonu ve Amaçla Sınırlılık: Analitik ambarlara veya yapay zekâ vektör veritabanlarına veri aktarılırken, modelin veya raporun ihtiyaç duymadığı kimlik numarası, açık telefon veya adres gibi kişisel veriler boru hattının ilk aşamasında ayıklanmalı veya anonimleştirilmelidir.
• Şifreleme ve Maskeleme: Durağan veriler ve ağ üzerinden akan veriler en üst kriptografik standartlarla korunmalı; geliştirme ve test ortamlarına üretim veritabanından veri kopyalanırken dinamik veri maskeleme ve tokenizasyon teknikleri uygulanmalıdır.
• Erişim Kontrolü ve Loglama: Kimin hangi veriye hangi amaçla eriştiği rol tabanlı (RBAC) yetkilendirmelerle sınırlandırılmalı; KVKK m. 12 kapsamındaki veri güvenliği yükümlülüğü gereğince tüm veri erişim logları geriye dönük değiştirilemez biçimde saklanmalıdır.
• İmha ve Anonimleştirme: Saklama süresi dolan veya ilgili kişinin talebi üzerine silinmesi gereken veriler, yalnızca operasyonel veritabanından değil; veri gölündeki tüm Parquet dosyalarından, Iceberg anlık görüntülerinden ve analitik katmanlardan da eksiksiz şekilde imha edilebilecek bir mimariyle kurgulanmalıdır.

2026 Trendleri, Platform Mühendisliği ve Sektörel Gelecek

2026 yılı teknoloji ekosistemi, veri mühendisliğinin sınırlarını genişleterek onu bir "Veri Platformu Mühendisliği" (Data Platform Engineering) seviyesine taşımıştır. Günümüzde başarılı bir veri mühendisi, yalnızca münferit veri hatları yazan kişi değil; şirketteki diğer yazılımcıların, analistlerin ve yapay zekâ ajanlarının kendi kendine veri hattı kurabileceği iç veri platformlarını inşa eden uzmandır.

Veri mühendisliği mesleği araçların ötesinde bir problem çözme disiplinidir. Araçlar Airflow'dan Dagster'a, Snowflake'ten ClickHouse'a değişebilir; ancak verinin fiziksel depolanması, ağ üzerinden verimli taşınması, şema bütünlüğünün korunması, hata toleransı ve yasal uyum ilkeleri kalıcıdır.

Avukat & Veri Mühendisi Yusuf KILIÇKAN

30 Eylül 2026

Sıkça Sorulan Sorular

1. Veri mühendisliği ile veri bilimi arasındaki temel fark nedir?

Veri mühendisi verinin toplanması, temizlenmesi, depolanması ve güvenilir biçimde akmasını sağlayan büyük veri altyapılarını tasarlar; veri bilimci ise bu hazırlanmış temiz veri üzerinde istatistiksel modeller ve makine öğrenmesi algoritmaları koşturarak tahminler ve iş içgörüleri üretir.

2. Modern veri mimarilerinde neden ETL yerine ELT yaklaşımı tercih ediliyor?

Bulut veri ambarlarının dağıtık SQL çalıştırma kapasiteleri çok güçlendiği için, veriyi ambar dışında dönüştürmek yerine ham halde doğrudan ambara yükleyip dönüşümleri ambarın kendi motoruyla (örneğin dbt kullanarak) yapmak çok daha hızlı, esnek ve maliyet-etkindir.

3. Apache Iceberg gibi açık tablo formatları veri göllerine ne kazandırır?

Iceberg; nesne depolama alanları üzerinde tutulan Parquet dosyalarına ACID işlem garantisi, şema ve bölümleme evrimi, zaman yolculuğu (time travel) ve sorgularda gereksiz dosya taramalarını engelleyen gizli bölümleme yetenekleri kazandırarak veri ambarı konforu sağlar.

4. Gerçek zamanlı veri akışlarında Debezium (CDC) kullanmanın avantajı nedir?

CDC, üretim veritabanına ağır sorgular atmak yerine doğrudan veritabanının işlem günlüklerini (WAL/binlog) okur; böylece canlı sistemi yormadan her kayıt değişikliğini milisaniyeler içinde birer olay olarak Kafka'ya fırlatarak analitik sistemlere kesintisiz replike eder.

5. Küçük dosya problemi (Small Files Problem) nedir ve nasıl önlenir?

Yüksek kardinaliteli alanlara göre aşırı bölümleme yapıldığında oluşan kilobaytlık milyonlarca dosya, sorgu motorlarının metaveri okuma yükünden kilitlenmesine yol açar; bu durum optimize edilmiş dosya boyutları (128-512 MB) hedeflenerek ve arka planda çalışan sıkıştırma (compaction) süreçleriyle önlenir.

6. Apache Airflow bir veri işleme motoru mudur?

Hayır. Airflow terabaytlarca veriyi kendi belleğinde işlemez; o yalnızca görevlerin sırasını, bağımlılıklarını, zamanlamasını ve hata durumundaki yeniden deneme (retry) kurallarını yöneten bir iş akışı orkestratörüdür.

7. Büyük dil modelleri (LLM) ve RAG sistemleri için veri mühendisliği neden gereklidir?

Bir yapay zekâ modeli ne kadar yetenekli olursa olsun kalitesiz veriyle beslendiğinde halüsinasyon üretir; dokümanların ayıklanması, parçalanması (chunking), vektörleştirilmesi ve vektör veritabanlarının tazelenmesi uçtan uca bir veri mühendisliği altyapısı gerektirir.

8. Dağıtık sistemlerde veri çarpıklığı (Data Skew) nasıl çözülür?

Verinin belirli bir anahtarda aşırı yoğunlaşarak tek bir işçi sunucuyu kilitlemesi problemi, ilgili anahtarlara rastgele önekler ekleyen tuzlama (salting) teknikleri ve uygun yeniden bölümleme stratejileriyle verinin kümeye dengeli dağıtılmasıyla çözülür.

9. Türkiye'de bir veri boru hattı tasarlarken KVKK açısından nelere dikkat edilmelidir?

Veri minimizasyonu gereği gereksiz kişisel veriler ham katmanda elenmeli, dinamik veri maskeleme uygulanmalı, erişimler rol tabanlı olarak sınırlandırılıp değiştirilemez biçimde loglanmalı ve imha politikaları veri gölü dosyalarını da kapsayacak şekilde işletilmelidir.

10. Veri mühendisliğinde maliyet optimizasyonu (FinOps) neden bir zorunluluktur?

Bulut ambarlarında taranan veri miktarı ve tüketilen işlem gücü doğrudan faturalandırılır; bölümleme, kümeleme, artımlı veri işleme ve sorgu optimizasyonu yapılmadığında bulut maliyetleri öngörülemez biçimde katlanarak bütçeleri tüketebilir.

Yazar Hakkında

Av. Yusuf Kılıçkan | Avukat, Hukuki Danışman & Veri Sorumlusu

Hukuk ve mühendislik disiplinlerini bir araya getiren multidisipliner bir yaklaşımla serbest avukatlık, hukuki danışmanlık ve veri mühendisliği faaliyetlerini eşzamanlı olarak sürdürmektedir. Mesleki ve teknik çalışmalarında; kurumsal dava süreçleri, sözleşme tasarımı ve regülasyon uyumunun yanı sıra modern veri ambarı mimarileri, dağıtık sistemler, büyük veri boru hatları (data pipelines), açık tablo formatları ve yapay zekâ veri altyapıları (RAG/LLM sistemleri) üzerine uçtan uca sistemler geliştirmektedir. Hukuk teknolojileri (LegalTech) ve KVKK/GDPR uyumlu veri yönetişimi alanlarında analitik, veri temelli ve mühendislik odaklı yayınlar kaleme almaktadır. Hukuki ve teknik yazılarına yusufkilickan.av.tr adresinden ulaşabilirsiniz.

📧 av.yusufkilickan@gmail.com

Yasal Uyarı

Bu makale ve inceleme yazısı yalnızca genel teknik ve hukuki bilgilendirme amacıyla kaleme alınmıştır; somut bir teknik altyapı taahhüdü, sistem garantisi ya da bireysel hukuki danışmanlık/avukatlık hizmeti niteliği taşımaz. Veri mimarisi tasarımları, dağıtık sistem performansları, bulut bilişim maliyetleri ve veri güvenliği gereksinimleri; her kurumun kendi veri hacmine, teknoloji yığınına, kurumsal iş hedeflerine ve tâbi olduğu sektörel regülasyonlara göre köklü farklılıklar gösterir. Şirketlerin kendi veri platformlarını kurgularken veya kişisel verilerin korunması mevzuatına uyum sağlarken telafisi güç teknik ve hukuki risklerle karşılaşmamaları adına, alanında yetkin veri mühendisleri, sistem mimarları ve bilişim alanında uzman avukatlarla çalışmaları tavsiye edilir.