1. GİRİŞ

Veri mühendisliği, modern veri odaklı ürün ve hizmetlerin omurgasını oluşturur. Veri hacimleri, gerçek zamanlı işleme ihtiyaçları ve makine öğrenmesi uygulamalarının yaygınlaşmasıyla birlikte; veriyi güvenilir, ölçeklenebilir ve yeniden kullanılabilir hale getirebilen mühendisler her organizasyon için stratejik öneme sahiptir. Bu rehber, veri mühendisliğini öğrenmek isteyen yazılımcılar ve mühendisler için adım adım bir yol haritası sunar: hangi kavramlar önce, hangi araçlar nasıl öğrenilmeli ve gerçek dünyada hangi problemler çözülür.

Bu teknoloji neden konuşuluyor?

• Veri ürünleri (analytics, ML) rekabet avantajı sağlıyor; doğru mühendislikle veri güvenilir olur.
• Gerçek zamanlı veri akışları ve ETL/ELT boru hatlarının yönetimi kritik operasyonel ihtiyaç haline geldi.
• Veri yönetimi, veri yönetişimi ve veri kalitesi kurumsal riskleri azaltıyor.

Kimler için önemli?

Backend geliştiriciler, veri bilimciler, DevOps/Platform mühendisleri ve teknik liderler için veri mühendisliği temel bir yetkinlik alanıdır. Ayrıca analitik takımları ve ML ekipleri için verinin hazırlanması ve erişilebilir olması hayati önemdedir.

Hangi problemleri çözüyor?

• Veri entegrasyonu ve temizliği
• Veri depolama ve modelleme
• Gerçek zamanlı ve toplu (batch) veri işleme
• Veri kalitesi, lineage ve governance

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Veri mühendisliği temel olarak verinin toplanması, taşınması, temizlenmesi, depolanması ve üretime hazır hale getirilmesini kapsar. Bu süreçlerin her birinde farklı araçlar ve paradigmal ar devreye girer: ETL/ELT boru hatları, veri gölleri (data lakes), veri ambarları (data warehouses), akış işleme (stream processing) ve veri kalitesi/lineage çözümleri.

2.2 Mimari bileşenler

• Kaynak sistemler: Uygulamalar, veritabanları, loglar, üçüncü parti API'ler.
• Ingestion: Verinin sistemlere sokulması (batch/stream).
• Processing: ETL/ELT, transformasyonlar, temizleme, enrich işlemleri.
• Storage: Data lake (objekt depolama), data warehouse (columnar), OLAP/OLTP ayrımı.
• Serving: Veri modelinin analitik sorgular veya ML için sunulması.
• Orchestration: Pipeline zamanlaması, retry, dependency yönetimi (Airflow/Prefect).
• Observability & Governance: Lineage, data quality checks, access control.

2.3 Önemli terminoloji

• ETL vs ELT: Verinin önce transform edilip sonra yüklendiği (ETL) veya önce yüklendiği sonra hedef sistemde transform edildiği (ELT) yaklaşımlar.
• Schema on read vs schema on write: Esneklik vs veri kalitesi takası.
• CDC (Change Data Capture): Kaynak DB'deki değişiklikleri akış olarak yakalama.
• Data contracts: Producer ve consumer arasındaki veri anlaşmaları.

3. NASIL ÇALIŞIR?

3.1 Tipik bir veri boru hattı mimarisi

Temel akış: kaynak → ingestion → raw zone (data lake) → processed zone → serving layer (warehouse) → consumption (BI/ML). Ingestion genellikle Kafka, Kinesis veya bulut servisleriyle gerçekleştirilir. Raw zone verinin ham haliyle saklandığı alandır; burada ham veri uzun süre tutulur ve gerektiğinde yeniden işlenir.

3.2 Ingestion ve CDC

CDC yaklaşımları veri senkronizasyonunu gerçek zamanlıya yakın hale getirir. Debezium gibi araçlar ilişkisel veritabanlarındaki değişiklikleri event olarak yayınlayıp stream platformuna iletir. Bu model, geleneksel batch ETL'lere göre daha düşük gecikme ile veri tazeliği sağlar.

3.3 Transformasyon stratejileri

• Batch transforms: Büyük veri kümeleri üzerinde toplu işlemler (Spark, Databricks).
• Stream transforms: Event bazlı veya micro‑batch yaklaşımlar (Flink, Kafka Streams).
• ELT yaklaşımı: Ham veriyi önce data lake'e yükleyip, SQL tabanlı transformlar ile analitik tablolar inşa etmek (dbt vb.).

3.4 Depolama ve sorgulama

Veri depolama kararları erişim kalıplarına göre verilir: yüksek gecikmeli arşivler, analitik sorgular için columnar formatlar (Parquet/ORC), OLAP için MPP veri ambarları (BigQuery, Snowflake, Redshift). Partitioning, compaction ve clustering stratejileri performans ve maliyet dengesi kurmada kritik rol oynar.

3.5 Orchestration ve idempotency

Orchestration katmanı (Airflow/Prefect) görev bağımlılıkları, yeniden deneme ve izleme sağlar. Veri işlerinde idempotency ve at‑least‑once/at‑most‑once semantics konuları hataya açık noktalardır; bu yüzden unique keys, deduplication ve watermarking gibi teknikler kullanılır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Örnek: E‑ticaret analitiği

Sipariş, envanter ve kullanıcı etkinlikleri gerçek zamanlı olarak Kafka'ya yazılır; CDC ile stok verileri senkronize edilir. Stream processing ile temel metrikler (revenue, conversion) anlık hesaplanır; toplu dönüşümler ile günlük rapor tabloları üretilir. ML için feature store'lar beslenir.

4.2 Örnek: Finans ve ödemeler

Düşük gecikmeli fraud detection için stream‑first mimari gerekir. Yüksek veri gizliliği gereklilikleri nedeniyle encryption, tokenization ve sıkı erişim kontrolleri uygulanır.

4.3 Örnek: IoT ve telemetri

Cihazlardan gelen veriler edge katmanında ön filtrelenip, batch veya stream olarak merkeze iletilir. Edge preprocess sayesinde veri transfer maliyetleri düşürülür.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Veri temelli kararlar için güvenilir altyapı sağlar.
• ML ve analitik iş akışlarını üretime taşımayı kolaylaştırır.
• Ölçeklenebilir ve yeniden kullanılabilir veri modelleri oluşturur.

Sınırlamalar

• Başlangıçta yüksek yatırım maliyeti ve karmaşıklık.
• Veri kalitesi ve metadata yönetimi ihmal edilirse sistemin değeri düşer.
• Organizasyonel değişim gerektirir: producer‑consumer anlaşmaları ve ownership netleştirilmeli.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Basit bir karşılaştırma tablosu:

7. EN İYİ PRATİKLER

Production tavsiyeleri

• Veri sözleşmeleri (data contracts) kurun ve değişiklik yönetimi sağlayın.
• Lineage ve data catalog kullanarak veri sahipliğini açıkça tanımlayın.
• Test‑driven data pipelines: unit/integration test, schema validation, contract tests uygulayın.

Performans ve maliyet

• Partitioning ve clustering ile sorgu maliyetlerini azaltın.
• Incremental processing kullanarak tekrar iş yükünü minimize edin.
• Spot/commit kombinasyonlarını planlayın ve storage lifecycle yönetimi uygulayın.

Güvenlik

• Encryption at rest/in transit, RBAC ve least privilege politikaları uygulayın.
• PII için masking/tokenization ve erişim logging zorunlu olsun.

8. SIK YAPILAN HATALAR

• Veriyi hantal şekilde saklamak: ham veri ve işlenmiş veri ayrımı yapılmadan tek katmanda yönetmek.
• Lineage ve ownership eksikliği: kimin hangi veriyi ürettiği belirsizse hatalar uzar.
• Monitoring ihmal edilmesi: pipeline health ve data quality metrikleri takip edilmezse sorunlar geç fark edilir.

9. GELECEK TRENDLER

• Feature stores ve real‑time feature serving daha yaygın kullanılacak.
• Data contracts otomasyonuyla değişiklik yönetimi hızlanacak.
• Serverless stream processing ve sorgu motorları maliyet‑verim odaklı gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Veri mühendisi olmak için hangi programlama dillerini bilmeliyim?

   Python ve SQL en kritik diller. Scala veya Java büyük veri ekosistemlerinde avantaj sağlar; ancak modern veri platformlarında SQL ve Python çoğu işi çözer.

2. ETL mi yoksa ELT mi tercih etmeliyim?

   Kaynak ve hedef sistemlere göre karar verin: modern cloud data warehouse'lar ELT'i kolaylaştırır; legacy veri kaynaklarında ETL tercih edilebilir.

3. Hangi veri depolama formatı en iyisidir?

   Analitik için Parquet/ORC columnar formatlar performans sağlar; ham veri için objekt storage (CSV/JSON/Avro) uygun olabilir.

4. Gerçek zamanlı işleme her zaman gerekli mi?

   Hayır; gereksinimlere göre karar verin. Raporlama için batch yeterliyken fraud detection gibi senaryolarda stream gerekli olabilir.

5. Data quality nasıl sağlanır?

   Schema validation, unit test'ler, anomaly detection ve monitoring ile sürekli kontrol sağlanır.

6. Feature store nedir ve neden önemli?

   Feature store, ML için feature'ları merkezi olarak saklayan, yeniden kullanılabilir ve doğrulanabilir bir katmandır; model reproducibility ve servis sürekliliği sağlar.

7. Pipeline'ları nasıl test etmeliyim?

   Unit test, integration test, end‑to‑end smoke test ve data quality assertions kombinasyonu kullanın.

8. Veri gizliliği için nelere dikkat etmeliyim?

   PII tanımlama, masking/tokenization, erişim kontrolleri ve audit log uygulamalarını zorunlu hale getirin.

Anahtar Kavramlar

CDC

Change Data Capture: veri tabanındaki değişiklikleri event olarak yakalama.

Feature Store

ML feature'larının merkezi yönetimi ve servis edilmesi.

Data Lake

Ham veri setlerinin tutulduğu, esnek depolama katmanı.

Data Warehouse

Analitik sorgular için optimize edilmiş kolon bazlı depolama.

Öğrenme Yol Haritası

Aşağıdaki plan, sıfırdan başlayıp profesyonel seviyeye ulaşmak isteyenler için önerilmiştir.

1. 0–1 ay (Temel): Git, Linux temel komutları, Python ve SQL çalışın. Basit ETL örnekleri yapın.
2. 1–3 ay (İnşa): Docker, temel Kubernetes kavramları, veri depolama formatları (Parquet), temel bir pipeline oluşturun (Airflow veya Prefect ile).
3. 3–6 ay (Derinleşme): Streaming (Kafka), Spark/Flink ile batch ve stream transformasyonlar, dbt ile ELT pratikleri öğrenin.
4. 6–12 ay (Olgunluk): Data modeling, performance tuning, data governance, lineage araçları, feature store ve MLOps entegrasyonları üzerinde projeler yapın.
5. 12+ ay (Uzmanlık): Platform Engineering, observability for data pipelines, advanced streaming patterns, cost optimization ve güvenlik odaklı uygulamalar geliştirin.

1. GİRİŞ: VERİ ÇAĞINDA YOLUNUZU BULMAK

Veri dünyasında kariyer yapmak isteyenlerin karşısına çıkan en büyük engel, bilgi eksikliği değil, "bilgi enflasyonu"dur. Her gün yeni bir aracın çıktığı, her hafta bir kütüphanenin güncellendiği bu dinamik alanda, hangi sırayla ve neye odaklanarak öğrenileceğini bilmek, teknik becerinin kendisinden daha kritiktir. Data Engineering (Veri Mühendisliği), bugün sadece veriyi taşımak değil; veriyi bir ürün (Data Product) olarak tasarlamak, ölçeklemek ve yapay zeka sistemlerine güvenilir bir temel oluşturmak demektir.

2026 yılına doğru ilerlerken, "sadece kod yazan" veri mühendisi devri kapanmaktadır. Artık aranan yetkinlik; mimari bakış açısına sahip, maliyet (FinOps) ve güvenlik odaklı çalışan, AI asistanlarını (Copilots) verimli kullanan hibrit mühendislerdir. Bu makale, sizi modern veri dünyasında kaybolmaktan kurtaracak, akademik derinliği olan ama mühendis pratikliğiyle harmanlanmış en güncel öğrenme yol haritasını sunar.

Bu Yol Haritası Neden Önemli?

Teknoloji devleri (Google, Netflix, Amazon) artık araçlardan bağımsız, prensiplere hakim mühendisler arıyor. Bu yol haritası, sizi sadece bir aracın (örn: Airflow) uzmanı yapmak yerine, veri yaşam döngüsünün (Data Lifecycle) her aşamasını yönetebilen bir "mimar" haline getirmeyi amaçlar.

Hangi Problemleri Çözüyor?

• Öğrenme Felci: Onlarca teknoloji arasından hangisine öncelik verileceği konusundaki kafa karışıklığını giderir.
• Eksik Temeller: Sadece araç öğrenip temel teoriyi (algoritmalar, veri yapıları, dağıtık sistemler) atlayanların yaşadığı "tavan yapma" sorununu çözer.
• Geleceğe Hazırlık: Yapay zekanın veri mühendisliği üzerindeki etkisini (AI-powered ETL) müfredatın içine entegre eder.

2. KAVRAMSAL TEMELLER: VERİ MÜHENDİSLİĞİNİN ABC'Sİ

Araçlara (tools) dalmadan önce, bu binanın temel direklerini bilmek zorundasınız.

2.1 Veri Mühendisliği Yaşam Döngüsü (Lifecycle)

Veri mühendisliği beş ana aşamadan oluşur: 1. Generation: Kaynak sistemlerin veriyi üretmesi (API, Database, Events). 2. Ingestion: Verinin kaynaklardan toplanarak merkeze aktarılması. 3. Storage: Verinin uzun süreli ve performanslı saklanması (Data Lake, Warehouse). 4. Transformation: Verinin ham halden analiz edilebilir hale getirilmesi (SQL, Python). 5. Serving: Verinin son kullanıcıya veya AI modeline sunulması.

2.2 Mimari Yaklaşımlar

- Monolitik vs Modüler: Her şeyi tek bir scriptte yapmak yerine, birleşebilen küçük modüller tasarlamak. - Transactional vs Analytical: OLTP (uygulama veritabanları) ile OLAP (analitik ambarlar) arasındaki farkı anlamak. - Schema-on-read vs Schema-on-write: Verinin kaydedilirken mi yoksa okunurken mi yapılandırılacağına karar vermek.

2.3 Temel Terminoloji

- Idempotency: Hata durumunda yeniden çalıştırılan bir işin sonuçları bozmaması ilkesi. - ACID ve BASE: Veritabanı tutarlılık modelleri. - Data Observability: Verinin sağlığını (tazelik, kalite, hacim) izleme disiplini.

3. NASIL ÇALIŞIR? TEKNİK BİLEŞENLER VE MİMARİ KATMANLAR

Öğrenme yolculuğunuzda karşılaşacağınız teknik katmanlar ve bunların birbirine nasıl bağlandığı aşağıda detaylandırılmıştır.

3.1 Programlama ve SQL: Dilin Alfabesi

- SQL Mastery: Bir veri mühendisinin ana dilidir. Window functions, CTEs (Common Table Expressions) ve karmaşık JOIN optimizasyonlarını su gibi içmeniz gerekir. - Python: Veri mühendisliği ekosisteminin merkezidir. Pandas, Polars ve PySpark ile veri manipülasyonu, API istekleri ve otomasyon scriptleri yazmayı öğrenmelisiniz.

3.2 Depolama Katmanı (The Storage Layer)

- Cloud Data Warehouses: Snowflake, BigQuery veya Databricks gibi sistemlerin çalışma mantığını, partitioning ve clustering konseptlerini öğrenmelisiniz. - Data Lakehouse: Nesne depolama (S3, GCS) ile atomik transaction'ların (Delta Lake, Apache Iceberg) birleştiği modern yapıyı kavramalısınız.

3.3 İşleme ve Orkestrasyon (The Brain)

- Apache Spark: Dağıtık veri işlemede endüstri standardıdır. In-memory processing nasıl çalışır? Shuffle nedir? Bu soruların cevabını pratikle vermelisiniz. - Airflow veya Dagster: Veri boru hatlarının (pipelines) "orkestra şefi"dir. Bağımlılık yönetimi, hata durumunda yeniden deneme (retry) ve scheduling mantığı burada öğrenilir. - dbt (data build tool): SQL yazarken versiyon kontrolü, test ve dökümantasyon yapmanızı sağlayan "yazılım disiplini" katmanıdır.

3.4 Veri Gözlemlenebilirliği (DataOps)

Veri mühendisliği sadece "boru hattı kurmak" değildir, o hattın sürekli çalışmasını sağlamaktır. Prometheus, Grafana veya Great Expectations gibi araçlarla veri kalitesini ve sistem sağlığını izlemeyi öğrenmelisiniz.

4. GERÇEK DÜNYA KULLANIMLARI: VERİ DEVLERİNİN ÖĞRETİLERİ

Öğrendiğiniz bu araçların dev ölçekte nasıl uygulandığını anlamak, vizyonunuzu genişletir.

4.1 Netflix: Kaos Mühendisliği ve Veri

Netflix, veri mühendisliğini "ölçek" üzerine kurar. Kendi geliştirdikleri Apache Iceberg formatı, petabaytlarca veri üzerinde SQL çalıştırılabilmesini sağlar. Buradaki öğrenilecek ders: "Veriyi sadece saklamayın, kolayca ulaşılabilir kılın."

4.2 Uber: Gerçek Zamanlılık ve Hudi

Uber, sürücü ve yolcu verilerini saniyeler içinde işlemek zorundadır. **Apache Hudi** ile "incremental data processing" (artımlı veri işleme) devrimini yaptılar. Öğrenilecek ders: "Batch işlemenin yetmediği yerde streaming (Kafka, Flink) devreye girer."

4.3 Stripe: Güvenilirlik ve Değişim Yönetimi

Finansal veri hatlarında bir virgül bile hayati önem taşır. Stripe, veri mühendisliğinde "Yazılım Testi" kültürünü en üst seviyede uygular. Öğrenilecek ders: "Test edilmeyen kod, veri mühendisliği dünyasında bomba gibidir."

4.4 OpenAI: AI-Native Pipelines

ChatGPT'nin eğitimi için milyarlarca web sayfasının temizlenmesi, normalize edilmesi ve vektörize edilmesi gerekir. Buradaki veri mühendisliği, modelin zekasını belirleyen ana faktördür. Öğrenilecek ders: "AI döneminde veri mühendisi, yapay zekanın veri küratörüdür."

5. AVANTAJLAR VE SINIRLAMALAR: YOLUN ZORLUKLARINI ANLAMAK

Bu meslek size yüksek maaş ve prestij sunar ancak bedeli ağır olabilir.

Avantajlar

• Geleceğin Mesleği: Veri var olduğu sürece mühendisine ihtiyaç duyulacak.
• Mimari Güç: Şirketlerin karar alma zekasını bizzat siz inşa edersiniz.
• Yüksek Kazanç: Yazılım dünyasında tecrübeli veri mühendisleri en çok kazanan gruplar arasındadır.

Sınırlamalar ve Zorluklar

• Yüksek Teknik Bariyer: Sadece kod bilmek yetmez; sistem mimarisi, ağ bilgisi ve bulut maliyetleri gibi çok geniş bir yelpazeyi bilmek gerekir.
• On-Call Sorumluluğu: Gece 3'te hata veren bir boru hattı, sizi yataktan kaldırabilir.
• Maliyet Baskısı (FinOps): Yanlış yazılan bir SQL sorgusu, bulut faturasını dakikalar içinde binlerce dolar artırabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA: ARAÇ SEÇİM REHBERİ

Öğrenme yolculuğunuzda hangi durumlarda hangi teknolojiyi seçeceğinize dair bir karşılaştırma tablosu:

7. EN İYİ PRATİKLER: KIDEMLİ MÜHENDİS TAVSİYELERİ

Kod yazmaktan daha önemli olan şey, sürdürülebilir bir sistem tasarlamaktır.

Production Kalitesi ve Mimari

• Stateless Tasarım yapın: Pipline'larınız herhangi bir aşamada durup tekrar başladığında, veri kaybı veya mükerrer veri üretmemelidir (Idempotency).
• Data Contracts Kullanın: Kaynak sistemlerle veri formatı konusunda "sözleşmeler" yapın ki kaynak tarafındaki bir değişiklik pipeline'ınızı bozmasın.
• FinOps Kültürünü Benimseyin: Her query'nin maliyetini hesaplayın. Veri mühendisliği artık "sadece çalıştırmak" değil, "en ucuz şekilde çalıştırmak"tır.

Güvenlik ve Gizlilik

• Least Privilege: Veritabanı erişimlerinde minimum yetki kuralını uygulayın. Pipeline'ların üretim verisine sınırsız erişimi olmamalıdır.
• PII Maskeleme: Hassas kullanıcı verileri ambarlara girmeden önce anonimleştirilmelidir.
• Immutable Data: Ham veriyi asla değiştirmeyin. Her zaman üzerine ekleme (append-only) yapın ki hata durumunda en başa dönebilin.

8. SIK YAPILAN HATALAR: ÖĞRENME SÜRECİNİ BALTALAYANLAR

• Araç Odaklılık (Tool-Only Thinking): Sadece Python öğrenip SQL’i küçümsemek veya sadece dbt öğrenip veri mimarisini (modeling) atlamak.
• Over-Engineering: Günde 10 bin satır veri gelen küçük bir iş için devasa Spark cluster’ları kurmaya çalışmak. Problemi çözebilecek "en sade" aracı seçin.
• Test Yazmamak: "Burası veri dünyası, yazılım değil" diyerek unit ve integration testlerini ihmal etmek. Veri hataları sessizce gelir ve aylar sonra fark edildiğinde felaket yaratır.
• Dökümantasyonu İhmal Etmek: Bir kolonun neden eklendiğini veya o oranın nasıl hesaplandığını dökümante etmeyen mühendis, geleceğe teknik borç bırakır.
• Cloud Maliyetlerini Takip Etmemek: Bedava deneme kredileri bittiğinde gelen 10 bin dolarlık fatura, birçok junior mühendisin kabusudur.

9. GELECEK TRENDLER: 2026 VE SONRASI

Veri mühendisliğinin geleceği "otomasyon" ve "zekâ" üzerine kurgulanıyor.

9.1 AI-Driven Data Engineering

2026'da veriyi temizleyen veya şema mapping'lerini yapan manuel işler neredeyse kalmayacak. AI modelleri, verideki anormallikleri otomatik tespit edip düzeltecek (Self-healing pipelines). Mühendisin işi "yaratıcılık" ve "strateji" düzeyine çıkacak.

9.2 Real-time by Default

Artık "günlük rapor" devri kapandı. Şirketler her şeyi canlı istiyor. Bu yüzden Kafka ve Flink gibi teknolojiler "lüks" olmaktan çıkıp her veri mühendisi için temel "ekmek su" haline gelecek.

9.3 Data Mesh and Decentralization

Veri yönetimi merkezi bir "Data Team"den çıkıp, o veriyi üreten iş birimlerine dağılacak. Veri mühendisi, bu birimlere "altyapı" ve "standart" sağlayan bir platform mühendisi gibi çalışacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Öğrenmeye hangisinden başlamalıyım? Python mı SQL mi?

   Önce SQL. Veri dünyasının ana dili SQL'dir. SQL bilmeyen biri asla gerçek bir veri mühendisi olamaz. Ardından Python'a geçmelisiniz.

2. İyi bir veri mühendisi olmak için bilgisayar mühendisliği mezunu olmak şart mı?

   Şart değil ancak yazılım temellerini (algoritmalar, CPU/Memory yönetimi) bağımsız olarak öğrenmeniz gerekir. Mühendislik bir "unvan" değil, bir "düşünme biçimidir".

3. Hangi Cloud platformuna odaklanmalıyım (AWS, GCP, Azure)?

   Genellikle AWS pazar payı olarak liderdir ancak GCP veri analitiği (BigQuery) tarafında çok güçlüdür. Birine hakim olursanız diğerlerine geçişiniz çok hızlı olur.

4. Data engineering için en iyi kitaplar hangileridir?

   Fundamentals of Data Engineering (Joe Reis) ve Designing Data-Intensive Applications (Martin Kleppmann) kesinlikle okunması gereken iki kutsal kitaptır.

5. Excel bilmek işe yarar mı?

   İş birimleriyle konuşurken ortak diliniz Excel olacaktır ancak bir veri mühendisi Excel sınırlarını aşan büyük hacimli sistemlerin insanıdır.

6. Portfolyomda ne tür projeler olmalı?

   API'dan veri çeken, bunu bir ambara atan (ETL), dbt ile temizleyen ve sonrasında dashboard'a bağlayan "uç uç (end-to-end)" projeler en değerlisidir.

7. Docker ve Kubernetes bilmek zorunda mıyım?

   Orkestrasyon araçlarını (Airflow gibi) kurmak ve pipeline'ları izole çalıştırmak için Docker bilgisi artık temel bir gereksinimdir.

8. AI işimizi elimizden alacak mı?

   Hayır, işimizi "değiştirecek". AI sıkıcı ve tekrarlı işleri yapacak, biz ise sistem tasarımı ve karmaşık iş problemlerini çözmeye daha çok vakit ayıracağız.

Anahtar Kavramlar Sözlüğü

ETL vs ELT

ETL veriyi çekip dönüştürüp yüklerken; ELT veriyi önce yükleyip (raw), dönüşümü bulut ambarın işlem gücüyle ambarın içinde yapma modern yaklaşımıdır.

Vector Database

Yapay zeka modellerinin (LLM) veriye ulaşabilmesi için veriyi sayılar (vökterler) olarak saklayan özel veritabanları.

Data Catalog

Şirket içindeki tüm veri varlıklarının dökümante edildiği ve aranabildiği "veri Google'ı".

Delta Lake / Iceberg

Data Lake üzerinde veriyi tablo gibi (Update, Delete yapabilir şekilde) yönetmemizi sağlayan açık kaynak formatlar.

Partitioning

Devasa tabloları tarih veya kategori bazlı daha küçük parçalara bölerek sorgu performansını artırma tekniği.

Öğrenme Yol Haritası (Step-by-Step)

1. Aşama 1: Temel Silahlanma (1-3 Ay). SQL (ileri seviye), Python (programlama temelleri), Git ve Linux terminal komutları.
2. Aşama 2: Veri Saklama ve Modelleme (3-5 Ay). İlişkisel veritabanları (PostgreSQL), Cloud Data Warehouse (BigQuery/Snowflake) ve Boyutsal Modelleme (Star Schema).
3. Aşama 3: Transformation ve Pipelines (5-8 Ay). dbt (data build tool) ile SQL transformasyonları, Airflow ile orkestrasyon ve veri kalitesi testleri.
4. Aşama 4: Big Data ve Cloud (8-12 Ay). Apache Spark (PySpark), Cloud servisleri (AWS S3, Lambda, Glue) ve Nesne Depolama.
5. Aşama 5: İleri Seviye ve Mastery (12+ Ay). Real-time streaming (Kafka, Flink), DataOps/FinOps disiplini ve AI entegrasyonları.