Veri Mühendisliği Nedir? Veri Mühendisi Ne İş Yapar?

Veri mühendisliği, farklı kaynak sistemlerdeki verinin toplanması, temizlenmesi ve raporlama ile analiz için zamanında hazır tutulması amacıyla veri hatlarını kurma ve işletme işi. Kavramın doğru anlaşılması için önce hangi verinin, hangi kullanıcı veya süreç tarafından ve hangi karar sorusu için kullanılacağının netleşmesi gerekir. Aynı terim, farklı kurumlarda farklı teknik düzenekleri anlatabilir.

Veri mühendisliği için tanımı yalnızca bir araç adı veya kısa teknik etiket olarak ele almak yeterli değildir. Veri kaynağı, hedef kullanım, veri sahibi, güncellik beklentisi ve erişim kuralları birlikte değerlendirildiğinde kapsam daha sağlıklı belirlenir.

Microsoft Learn veri mühendisini, farklı veri sistemlerindeki veriyi analize uygun yapılara getiren ve bunun için güvenilir veri işlem hatları ile veri depoları tasarlayıp destekleyen kişi olarak tanımlar. Günlük işte bu tanım altı somut göreve dağılır.

Veriyi almak: Sipariş sisteminin veritabanından, bir muhasebe programının dosya çıktısından ya da bir API'den veriyi belirli aralıklarla çeker. Örnek: her gece yeni ve değişen siparişleri okumak.

Dönüştürmek: Tarih biçimini düzeltir, tutar alanını sayıya çevirir, aynı kaydın tekrarını eler. Örnek: iki sistemden gelen müşteri kodlarını tek koda eşlemek.

Veriyi modellemek: Verinin hedefte hangi tablolarda ve hangi anahtarlarla duracağını tasarlar. Örnek: sipariş satırları için bir olgu tablosu, ürün ve müşteri için ayrı boyut tabloları.

Zamanlamak: İşlerin sırasını ve saatini belirler. Örnek: müşteri tablosu yüklenmeden sipariş tablosunu yüklememek ve hepsini sabah yedide raporlar açılmadan bitirmek.

İzlemek ve doğrulamak: Satır sayısı, boş alan ve tutar toplamı gibi kontrolleri çalıştırır, sorun olursa uyarı üretir. Örnek: dünkü sipariş sayısı kaynakta ve hedefte farklıysa hattı hatalı işaretlemek.

Erişimi yönetmek: Kimin hangi tabloyu okuyacağını belirler, kişisel veri içeren alanları ayırır ya da maskeler. Örnek: analistin müşteri adını değil müşteri numarasını görmesi.

Üç rolü ayırmanın en kolay yolu aynı sipariş tablosuna bakmaktır. Tabloda sipariş numarası, müşteri, tarih, tutar, durum ve iade tarihi olsun.

Veri mühendisi: Siparişleri kaynaktan alır, tekilleştirir, tutarı sayıya çevirir ve her sabah raporlama tablosuna yükler. Cevapladığı soru, verinin doğru, eksiksiz ve zamanında gelip gelmediğidir. Ana araçları SQL, bir programlama dili ve bir zamanlama aracıdır; çıktısı güvenilir tablodur.

Veri analisti: O tabloyu sorgular ve iş sorusuna cevap verir. Örneğin geçen ay iade oranının hangi ürün grubunda yükseldiğini bulur. Çıktısı bir rapor ya da panodur; araçları SQL ve bir raporlama aracıdır.

Veri bilimci: Aynı verinin geçmişinden henüz olmamış bir şeyi tahmin etmeye çalışır. Örneğin gelecek hafta hangi üründen kaç adet satılacağını öngören bir model kurar. Çıktısı modeldir; araçları genellikle Python ile istatistik ve makine öğrenmesi kütüphaneleridir.

Tablo yanlış ya da geç gelirse analistin raporu da bilimcinin modeli de yanlış çıkar; veri mühendisliği ikisinin altında durur. Küçük ekiplerde bu üç iş aynı kişide toplanabilir.

Sipariş örneğinde hat altı katmandan geçer. Her katman için örnek araç ve en sık bozulma noktası aşağıda; hattın iç ayrıntısı için ilgili bağlantılardaki data pipeline rehberine bakabilirsiniz.

Kaynak: Sipariş uygulamasının veritabanı, ERP dosyaları, bir API. Bozulur: kaynakta alan adı ya da tipi değişir, sistem bakım nedeniyle o gece kapalı kalır.

Alım: Veri kaynaktan hatta alınır. Gece toplu çekim yeterliyse zamanlanmış bir SQL sorgusu ya da dosya aktarımı kullanılır; olaylar anında akacaksa Apache Kafka gibi bir olay akışı platformu kullanılır. Kafka belgeleri onu olayları yazan üreticilerle bu olayları okuyan tüketicileri birbirinden bağımsız tutan bir olay akışı platformu olarak anlatır. Bozulur: aynı kayıt iki kez gelir, bağlantı yarıda kesilir, dosya eksik gelir.

Dönüştürme: Tip düzeltme, tekilleştirme, birleştirme ve iş kuralları burada uygulanır; araç olarak SQL, Python ya da bir ETL aracı kullanılır. Bozulur: iş kuralı değişir ama koda yansımaz, boş değerler sessizce sıfır sayılır.

Depolama: Düzenlenmiş veri için veri ambarı, ham dosyalar için data lake kullanılır. Bozulur: yükleme yeniden çalışınca çift kayıt oluşur, ham ve temiz veri karışır ve hangisinin güncel olduğu belli olmaz.

Sunum: Raporlama aracı ya da analistin sorguları. Bozulur: aynı ölçüt, örneğin net satış, iki raporda farklı formülle hesaplanır.

Orkestrasyon ve izleme: Adımların sırasını, saatini ve yeniden denemesini yönetir. Apache Airflow belgeleri onu, zamana ya da olaya bağlı çalışan toplu (batch) iş akışlarını geliştirmek, zamanlamak ve izlemek için bir platform olarak anlatır; iş akışları Python koduyla tanımlanır ve en çok başı ile sonu belli, zamanlanmış işlere uygundur. Dönüştürme işi Airflow'un kendisinde değil, görevlerin içindeki kodda ya da çağrılan araçta yapılır. Bozulur: bir adım sessizce başarısız olur, kimseye haber gitmez ve sonraki adımlar eski veriyle çalışır.

Kafka veriyi akıtır, Airflow işlerin sırasını yönetir; ikisi farklı iş görür. Ayrıntıları ilgili bağlantılardaki rehberlerde var. Ambar ile data lake arasındaki seçim için aynı bağlantılardaki blog yazısına bakabilirsiniz.

Fark tek noktada: dönüşümün nerede yapıldığı. ETL'de veri hedefe yüklenmeden önce ayrı bir dönüştürme aşamasında, çoğunlukla ara tablolarda temizlenir. ELT'de ham veri önce hedefe yüklenir ve dönüşüm hedef sistemin kendi işlem gücüyle, örneğin ambar içinde SQL ile yapılır.

ELT, hedef sistem dönüşümü verimli yapabilecek kadar güçlüyse iyi çalışır. ETL ise hedefi ağır dönüşümlerle yormak istemediğinizde ya da veriyi hedefe girmeden önce denetimden geçirmeniz gerektiğinde öne çıkar. Karşılaştırma ayrıntısı için ilgili bağlantılardaki ETL rehberine bakabilirsiniz.

Tekrar eden kayıt. Belirti: Aynı sipariş raporda iki kez sayılır, toplam ciro şişer. Neden: Kaynak aynı kaydı iki kez göndermiştir ya da iki aktarım aynı veriyi yüklemiştir. Çözüm: Sipariş numarası gibi bir anahtarla yüklemeden önce tekilleştirin ve hedef tabloda bu anahtar için benzersizlik kuralı tanımlayın.

Geç gelen veri. Belirti: Dünün raporu sabah bir rakam, öğleden sonra başka rakam gösterir. Neden: İptal ya da iade gibi güncellemeler kaynağa bir gün sonra işlenmiştir. Çözüm: Yalnız dünü değil son birkaç günü yeniden yükleyin. Bu, yükleme tekrar çalışınca sonucu bozmayacak biçimde yazılmışsa güvenlidir; sonraki bölüm bunu anlatıyor.

Kaynakta şema değişikliği. Belirti: Hat hata verir ya da bir sütun bir anda boş gelmeye başlar. Neden: Kaynak ekibi bir sütunu yeniden adlandırmış ya da tipini değiştirmiştir. Çözüm: Alım adımında beklenen sütunları ve tipleri kontrol edin, uyuşmazlık varsa hattı durdurup uyarı üretin ve kaynak ekibinden değişiklik öncesi haber isteyin.

Yeniden çalıştırmada çift yazma. Belirti: Hata sonrası hattı elle yeniden çalıştırdınız ve o günün satırları iki katına çıktı. Neden: Yükleme her çalışmada yalnızca INSERT yapıyor. Çözüm: Yüklemeyi idempotent yapın; yani aynı veriyle kaç kez çalışırsa çalışsın hedefte aynı sonuç kalsın.

Örneklerde stg_siparis günlük çekilen ham verinin durduğu ara tablo, fact_siparis raporlama tablosudur. İkisinde de siparis_id, siparis_tarihi, durum ve tutar sütunları var; fact_siparis içinde siparis_id birincil anahtardır. Örnekleri canlı veriye uygulamadan önce kopya tablolarda deneyin.

Yöntem 1, PostgreSQL, tarihi silip yeniden yükleme: BEGIN; DELETE FROM fact_siparis WHERE siparis_tarihi = DATE '2026-09-30'; INSERT INTO fact_siparis (siparis_id, siparis_tarihi, durum, tutar) SELECT siparis_id, siparis_tarihi, durum, tutar FROM stg_siparis WHERE siparis_tarihi = DATE '2026-09-30'; COMMIT; Silme ve yükleme aynı işlemde olduğu için hat yarıda kesilirse o gün yarım kalmaz. Kaynakta silinen kayıtlar da hedeften kalkar.

Yöntem 2, PostgreSQL, ON CONFLICT: INSERT INTO fact_siparis (siparis_id, siparis_tarihi, durum, tutar) SELECT siparis_id, siparis_tarihi, durum, tutar FROM stg_siparis ON CONFLICT (siparis_id) DO UPDATE SET durum = EXCLUDED.durum, tutar = EXCLUDED.tutar; PostgreSQL belgelerine göre ON CONFLICT için çakışmanın belirlendiği sütunlarda benzersiz indeks ya da kısıt gerekir; burada birincil anahtar bunu sağlar. Aynı siparis_id yeniden gelirse satır eklenmez, güncellenir. Aynı komutta stg_siparis içinde aynı siparis_id iki kez varsa PostgreSQL hata verir; belgeler komutun aynı satırı birden fazla kez etkilemesine izin verilmediğini söyler. Bu yüzden ara tabloyu önce tekilleştirin. Kaynakta silinen kayıtlar hedefte kalır.

Yöntem 3, SQL Server (MSSQL), MERGE: MERGE fact_siparis AS hedef USING stg_siparis AS kaynak ON hedef.siparis_id = kaynak.siparis_id WHEN MATCHED THEN UPDATE SET durum = kaynak.durum, tutar = kaynak.tutar WHEN NOT MATCHED BY TARGET THEN INSERT (siparis_id, siparis_tarihi, durum, tutar) VALUES (kaynak.siparis_id, kaynak.siparis_tarihi, kaynak.durum, kaynak.tutar); Microsoft belgeleri MERGE ifadesinin noktalı virgülle bitmesini şart koşar; unutulursa hata verir.

Söz dizimi sistemden sisteme değişir: ON CONFLICT ve DATE '...' biçimi PostgreSQL'e, MERGE ise SQL Server'a göredir. Hangi yöntemi seçeceğiniz, kaynakta silinen kayıtların hedeften de kalkıp kalkmayacağına bağlı.

Aşağıdaki soruların birkaçına evet diyorsanız raporlarınız el emeğine ve bir kişinin hafızasına dayanıyor olabilir.

Raporlar her hafta Excel'de elle derlenip birleştiriliyor mu?

Aynı bilgi birden çok sistemde mi duruyor, örneğin sipariş, muhasebe ve müşteri kayıtları ayrı mı?

Aynı ölçüt, örneğin ciro ya da aktif müşteri, farklı raporlarda farklı mı çıkıyor?

Verinin ne kadar güncel olması gerektiğini söyleyebiliyor musunuz: günlük, saatlik, anlık? Günlük yetiyorsa zamanlanmış basit bir hat çoğu zaman yeter; anlık gerekiyorsa olay akışı konuşulur.

Bir veri bozulduğunda kimin bakacağı ve sorunu kaç saatte fark edeceğiniz belli mi?

İhtiyacınızı netleştirmek için sayfanın altındaki bağlantılardan danışmanlık sayfasına bakabilirsiniz.

Bu sayfadaki işlerden çıkan beceri alanları şunlar: SQL (tabloları sorgulamak, birleştirmek, yüklemek), bir programlama dili (Airflow iş akışları Python ile yazıldığı için Python sık tercih edilir), veri modelleme, bir orkestrasyon aracını kullanabilmek ve verinin saklandığı ortamı (veritabanı, veri ambarı ya da bir bulut servisi) tanımak.

Microsoft Learn, bu mesleğe çevrimiçi ve kendi hızınızda ilerleyebileceğiniz bir eğitim planı sunuyor; Veri Mühendisi için eğitim sayfası başlangıç noktası olabilir.

Bu yaklaşımın amacı analiz ve raporlamanın dayandığı verinin tutarlı, güncel ve izlenebilir biçimde hazır tutulması. Ekipler aynı bilgi üzerinde çalışırken hangi verinin güvenilir kabul edildiği, ne zaman güncellendiği ve hangi koşulda kullanılacağı daha görünür hale gelir.

Veri mühendisliği değerlendirmesinde beklenen fayda yalnızca teknik hız değildir. İş birimleri ve teknik ekipler, veriyle ilgili sorumlulukları, kontrol noktalarını ve istisna durumlarını ortak bir dilde değerlendirebildiğinde karar süreci de daha anlaşılır olur.

Bir veri hattı kaynaktan alım, dönüştürme, depolama, sunum ve izleme katmanlarından geçer; her katmanın girdisi, çıktısı ve hata anında kimin bakacağı ayrı ayrı tanımlanır. İlk adımda mevcut kaynaklar ve hedefler envanterlenir. Ardından verinin anlamı, gerekli dönüşümler, çalışma sıklığı, yetkiler ve hata halinde izlenecek yol yazılı hale getirilir.

Veri mühendisliği uygulaması sırasında örnek veriyle doğrulama yapmak, beklenen sonuç ile gerçekleşen sonucu karşılaştırmak ve değişikliklerin kaydını tutmak önemlidir. Bu adımlar, sürecin daha sonra bakımını üstlenecek ekiplerin de aynı bağlamı görmesini sağlar.

Doğru kapsamda ele alındığında veri mühendisliği için yapılan çalışma; belirsizliği azaltmaya, sorumlulukları görünür kılmaya ve veriyle ilgili kararların daha tutarlı verilmesine yardımcı olabilir. Hangi yararın öncelikli olduğu kullanım senaryosuna göre değişir.

analiz ve raporlamanın dayandığı verinin tutarlı, güncel ve izlenebilir biçimde hazır tutulması hedefi; raporlama, analitik, operasyon veya uyum ihtiyacında farklı beklentiler oluşturabilir. Bu nedenle veri sürecini tasarlarken yalnızca bugünkü ihtiyacı değil, değişikliklerin ve yeni kullanıcıların nasıl yönetileceğini de düşünmek gerekir.

Veri hattı bir kez kurulup bırakılan bir iş değildir; kaynak sisteme yeni bir alanın eklenmesi ya da bir dosyanın geç gelmesi, hat çalışmaya devam ederken bile raporlardaki rakamı sessizce bozabilir. Ayrıca veri güvenliği, gizlilik, erişim yetkisi ve saklama gereksinimleri yalnızca projenin son aşamasına bırakılmamalıdır.

Veri mühendisliği için başarı ölçütü başlangıçta tanımlanmalıdır: hangi kayıtların işlendiği, hangi kontrolün geçerli sayıldığı, gecikmenin nasıl ölçüldüğü ve istisnaların kim tarafından incelendiği açıklanmadığında teknik olarak çalışan bir süreç iş açısından yeterli olmayabilir.

Veri mühendisliği için çalışmaya başlamadan önce kararın kapsamı yazılı hale getirilmelidir. Hangi kaynakların dahil olduğu, hangi kullanıcıların sonucu tüketeceği, verinin ne kadar güncel olması gerektiği ve hangi koşulda yeniden çalışma yapılacağı netleştiğinde teknik seçenekler daha sağlıklı karşılaştırılabilir.

farklı kaynak sistemlerdeki verinin toplanması, temizlenmesi ve raporlama ile analiz için zamanında hazır tutulması amacıyla veri hatlarını kurma ve işletme işi bağlamında güvenlik, erişim yetkisi, saklama süresi ve değişiklik yönetimi de aynı değerlendirmeye dahil edilmelidir. Bu soruların yanıtı her kurumda farklı olabilir; bu nedenle rehberdeki açıklamalar bir uygulama veya entegrasyon taahhüdü değil, değerlendirme çerçevesidir.

Veri mühendisliği ile ilgili kararların sürdürülebilir olması için veri sözlüğü, sorumluluklar ve kabul ölçütleri erişilebilir biçimde kayda alınmalıdır. Kaynakta veya iş kuralında gerçekleşen bir değişikliğin hangi raporu, akışı ya da kullanıcıyı etkileyebileceğini bilmek; yalnızca ilk kurulumda değil, günlük işletimde de belirsizliği azaltır. Kapsam, geçici istisnalar ve bu istisnaların sona erme koşulları da kayıt altında tutulmalıdır.

Bir veri hattı kaynaktan alım, dönüştürme, depolama, sunum ve izleme katmanlarından geçer; her katmanın girdisi, çıktısı ve hata anında kimin bakacağı ayrı ayrı tanımlanır. Bu kayıtların düzenli gözden geçirilmesi, hataların nedenini daha hızlı incelemeyi ve sonraki iyileştirmeleri gerçek kullanım bilgisine dayandırmayı destekler. Böylece veri mühendisliği konusu tek seferlik bir teknik iş olarak değil; veri sahipleri, teknik ekipler ve kullanıcılar arasında sürdürülen ortak bir çalışma düzeni olarak ele alınabilir.

Bu konu araştırılırken Veri mühendisliği danışmanlığı sayfası, ürün ve çözüm bağlamını incelemek için kullanılabilir. Bu bağlantı belirli bir teknoloji için doğrulanmamış entegrasyon, performans veya uyumluluk iddiası taşımaz; uygunluk gerçek gereksinimlerle değerlendirilmelidir.

Kavramsal ayrıntı için Data pipeline rehberi içeriğine de göz atabilirsiniz. Bilgi rehberi ile ticari çözüm sayfasının niyeti farklı tutulduğundan, kullanıcı ihtiyacına göre doğru sayfadan ilerlemek cannibalization riskini azaltır.