2026'da En Çok Sorulan 25 Veri Mühendisliği Mülakat Sorusu

2026 yılında veri mühendisliği mülakatları, SQL temellerinin çok ötesine geçmiş durumda. İşe alım ekipleri artık sistem tasarımı, gerçek zamanlı mimariler, maliyet optimizasyonu ve yapay zeka hazırlığı konularını derinlemesine sorguluyor. Bu rehber, start-up'lardan FAANG şirketlerine kadar veri mühendisliği mülakatlarında en sık karşılaşılan 25 soruyu ve uygulayıcılar için hazırlanmış detaylı cevaplarını içermektedir.

SQL ve Sorgu Optimizasyonu

SQL, her veri mühendisliği mülakatının temel taşı olmaya devam etmektedir. Kıdemli adaylar bile SQL sorularıyla karşılaşır; ancak odak noktası söz diziminden çok performans üzerinedir.

1. Window function ile GROUP BY arasındaki fark nedir?

GROUP BY satırları toplayarak satır sayısını azaltır. Window function ise mevcut satırla ilişkili bir satır kümesi üzerinde hesaplama yapar ancak satırları daraltmaz. Çıktıda orijinal her satır korunur.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Window function versiyonu, sorgunun hem satır düzeyinde detay hem de toplu bağlam gerektirdiği durumlarda vazgeçilmezdir. Veri kalitesi kontrolleri ve raporlama hatlarında bu ihtiyaç sıkça karşılaşılır.

2. 500 milyon satırlık bir fact tablosunda yavaş bir sorgu nasıl optimize edilir?

Yapılandırılmış bir yaklaşım en iyi sonucu verir:

1. Yürütme planını inceleyin (EXPLAIN ANALYZE) - tam tablo taramaları, indekslenmemiş sütunlarda hash join veya diske taşma durumlarını tespit edin.
2. Tabloyu bölümleyin - sorgu filtrelerine uygun yüksek kardinaliteli bir sütuna (genellikle tarih) göre partitioning uygulayın.
3. Hedefli indeksler ekleyin - sık filtrelenen sütunlara indeks ekleyin, ancak aşırı indekslemeden kaçının (her indeks yazma yükü ekler).
4. Ara sonuçları materyalize edin - aynı alt sorgu birden fazla panoda tekrar tekrar çalışıyorsa materialized view kullanın.
5. Filtreleri erkene alın - aşamalar arasında taşınan veri miktarını azaltmak için predicate pushdown uygulayın.

Mülakatçıların aradığı temel sinyal: optimizasyonun bağlama bağlı ve yinelemeli bir süreç olduğunun anlaşılmasıdır, bir kontrol listesi değil.

3. CTE, alt sorgu ve geçici tablolar arasındaki farkları açıklayın. Her birini ne zaman kullanırsınız?

CTE'ler (Common Table Expressions) okunabilirliği artırır ve özyinelemeli sorgulara olanak tanır. Çoğu sorgu motoru CTE'leri inline eder, bu nedenle performans alt sorgularla eşdeğerdir. Geçici tablolar veriyi fiziksel olarak materyalize eder; aynı ara sonucun bir oturum içinde birden fazla aşağı akış sorgusunu beslediği durumlarda faydalıdır. Alt sorgular basit, tek seferlik dönüşümler için uygundur.

Kural: okunabilirlik için CTE, yeniden kullanım için geçici tablo, basit satır içi filtreler için alt sorgu.

İleri düzey SQL kalıpları hakkında detaylı bilgi için Veri analistleri için SQL: Window Functions, CTE ve ileri düzey sorgular yazısına göz atın.

ETL vs ELT ve Veri Hattı Mimarisi

Veri hattı tasarımı soruları, mimari düşünme yetkinliğini test eder. Mülakatçılar araç savunuculuğu değil, ödünleşim analizi görmek ister.

4. ETL vs ELT: Birini diğerine ne zaman tercih edersiniz?

| Kriter | ETL | ELT | |--------|-----|-----| | Dönüşüm yeri | Yüklemeden önce (harici hesaplama) | Yüklemeden sonra (warehouse hesaplaması) | | En uygun | Eski sistemler, katı şemalar | Bulut veri ambarları (BigQuery, Snowflake) | | Şema esnekliği | Düşük (dönüşüm şemayı erken kilitler) | Yüksek (ham veri yeniden dönüşüm için erişilebilir) | | Maliyet modeli | Warehouse dışında hesaplama | Warehouse hesaplama maliyetleri dönüşümlerle ölçeklenir | | Veri tazeliği | Daha yüksek gecikme (dönüşüm adımı) | Daha düşük gecikme (önce yükle, ihtiyaç halinde dönüştür) |

ELT, modern bulut-yerel mimarilerde baskındır çünkü depolama ucuzdur, hesaplama elastik olarak ölçeklenir ve ham verinin korunması şema evrimini mümkün kılar. ETL ise düzenleyici gereksinimler verinin ambara girmeden önce dönüştürülmesini zorunlu kıldığında (örneğin kişisel verilerin temizlenmesi) hala geçerlidir.

5. İdempotent bir veri hattı tasarlayın. İdempotans neden önemlidir?

İdempotans, bir hattın aynı girdiyle birden fazla kez çalıştırılmasının, veri çoğaltmadan aynı sonucu üretmesini garanti eder. Bu önemlidir çünkü hatlar başarısız olur ve yeniden denenir.

Uygulama stratejileri:

• Upsert kalıpları (MERGE veya INSERT ... ON CONFLICT) - doğal veya bileşik anahtarlarla
• Bölüm üzerine yazma: ekleme yerine tarih bölümlerinin tamamını değiştirme
• Yazma sırasında tekilleştirme: deterministik ID'ler atama (iş anahtarı + olay zaman damgasının hash'i)

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Bu yaklaşım, 11 Nisan çalışmasının yeniden denenmesi durumunda 11 Nisan bölümünün yinelenen satırlar eklenmesi yerine tamamen değiştirilmesini sağlar.

6. Veri soyu (data lineage) nedir ve üretim hatlarında neden kritiktir?

Veri soyu, verinin hat boyunca kaynağını, hareketini ve dönüşümünü izler. Şu soruları yanıtlar: bu rakam nereden geldi, hangi dönüşümler uygulandı ve hangi aşağı akış sistemleri buna bağımlı?

Pratik değeri: bir panoda beklenmedik değerler göründüğünde, veri soyu kök neden analizini saatler yerine dakikalar içinde mümkün kılar. OpenLineage, dbt docs ve bulut-yerel veri soyu araçları (BigQuery sütun düzeyinde lineage) bu süreci otomatikleştirir.

Akış ve Gerçek Zamanlı Veri İşleme

Akış soruları artık "Kafka nedir" seviyesinden mimari kararlara, yani akışın ne zaman ve nasıl kullanılacağına evrilmiştir.

7. Batch vs streaming: Hangisini kullanacağınıza nasıl karar verirsiniz?

Karar, teknoloji tercihine değil gecikme gereksinimlerine bağlıdır:

• Batch: veri tüketicileri dakikalardan saatlere kadar gecikmeyi tolere edebildiğinde uygundur. Oluşturması, test etmesi ve hata ayıklaması daha basittir. Çoğu iş yükü için operasyonel maliyeti daha düşüktür.
• Streaming: iş mantığı dakika altı tazeliğe bağlı olduğunda gereklidir: dolandırıcılık tespiti, gerçek zamanlı fiyatlandırma, canlı panolar.
• Mikro-batch: batch benzeri basitlikle neredeyse gerçek zamanlı sonuçlar sunan pragmatik bir orta yol (örneğin Spark Structured Streaming).

En güçlü cevap, çoğu hattın batch olarak başlaması ve yalnızca somut bir gecikme SLA'sı gerektirdiğinde streaming'e geçilmesi gerektiğini kabul eder.

8. Kafka mimarisini açıklayın: topic, partition, consumer group

Kafka verileri topic'ler (mantıksal kanallar) halinde düzenler. Her topic, broker'lar arasında dağıtılan partition'lara (sıralı, değiştirilemez loglar) ayrılır. Producer'lar kayıtları partition'lara yazar (round-robin veya anahtar tabanlı). Consumer group'lar okumayı paralelleştirir: her partition, bir grup içinde tam olarak bir consumer'a atanır, bu da yatay ölçeklemeyi mümkün kılar.

Temel ödünleşim: daha fazla partition paralelliği artırır ancak broker'a ek yük getirir (dosya tanıtıcıları, replikasyon). Tipik başlangıç noktası topic başına 6-12 partition'dır ve verim gereksinimlerine göre ölçeklendirilir.

9. Bir akış hattında geç gelen veriyi nasıl yönetirsiniz?

Dağıtık sistemlerde geç veri kaçınılmazdır. Üç yaklaşım mevcuttur:

1. Watermark'lar: belirli bir eşiğin (ör. 10 dakika) ötesinde geç gelen verinin düşürüleceği bir sınır tanımlanır. Apache Flink ve Spark Structured Streaming bunu doğal olarak destekler.
2. Yeniden işleme pencereleri: gecikmeli kayıtları yakalamak için yakın zaman dilimleri periyodik olarak yeniden hesaplanır.
3. Delta/upsert hedefleri: güncellemeleri destekleyen değiştirilebilir bir depoya (Delta Lake, Apache Iceberg) yazılır; böylece geç kayıtlar önceki sonuçları düzeltebilir.

Doğru yaklaşım, aşağı akış tüketicilerinin tam olarak bir kez (exactly-once) semantiğine ihtiyaç duyup duymadığına veya nihai tutarlılığa (eventual consistency) tolerans gösterip gösteremeyeceğine bağlıdır.

Veri Modelleme ve Şema Tasarımı

Veri modelleme soruları, adayın verinin yalnızca nasıl depolandığını değil, nasıl tüketileceğini düşünüp düşünmediğini ortaya koyar.

10. Star schema vs snowflake schema: ödünleşimleri nelerdir?

Star schema boyut tablolarını düz ve geniş tablolar halinde denormalize ederek merkezi bir fact tablosuna bağlar. Snowflake schema ise boyutları alt boyutlara normalize eder.

| Özellik | Star | Snowflake | |---------|------|-----------| | Sorgu performansı | Daha hızlı (daha az join) | Daha yavaş (daha fazla join) | | Depolama | Daha yüksek (tekrarlanan veri) | Daha düşük (normalize) | | Karmaşıklık | Anlaması basit | Daha karmaşık ilişkiler | | Bakım | Boyutları güncellemek daha zor | Alt boyutları güncellemek daha kolay | | En uygun | BI/raporlama (okuma ağırlıklı) | Sıkı normalizasyon gerektiren durumlar |

Pratikte, analitik veri ambarlarında (BigQuery, Snowflake, Redshift) star schema hakimdir çünkü sorgu performansı ve basitlik, depolama tasarrufundan ağır basar. Daha fazla bilgi için veri modelleme mülakatı modülü incelenebilir.

11. Yavaş değişen boyut (SCD) nedir? Tip 1, 2 ve 3'ü açıklayın.

SCD'ler boyut niteliklerinin zaman içinde nasıl değiştiğini izler:

• Tip 1: Eski değeri üzerine yaz. Geçmiş tutulmaz. Basit ama kayıplı.
• Tip 2: Sürüm takibiyle yeni satır ekle (valid_from, valid_to, is_current). Tam geçmiş korunur. Üretim veri ambarlarında en yaygın kullanılan tiptir.
• Tip 3: Önceki değer için bir sütun ekle (current_city, previous_city). Sınırlı geçmiş (yalnızca bir değişiklik izlenir).

Tip 2, çoğu iş boyutu (müşteri adresi, ürün kategorisi, çalışan departmanı) için varsayılan tercihtir çünkü denetim izleri ve geçmişe dönük raporlama bunu gerektirir.

12. Hem gerçek zamanlı analitik hem de uzun vadeli depolama için olay verisini nasıl modellersiniz?

Çift katmanlı bir yaklaşım uygulanır:

1. Sıcak katman: olaylar, düşük gecikmeli toplamalar için optimize edilmiş gerçek zamanlı bir depoya (Apache Druid, ClickHouse veya warehouse'da Materialized View) akıtılır.
2. Soğuk katman: ham olaylar, tarih bazında bölümlenmiş bir lakehouse'a (Delta Lake, Iceberg) indirilir ve ad-hoc analiz ile ML özellik mühendisliği için süresiz olarak saklanır.

Sıcak katman hız için önceden toplanmış veya denormalize şemalar kullanır. Soğuk katman tam ayrıntıyı korur. Periyodik bir doğrulama işi, her iki katmanın tutarlı olduğunu kontrol eder.

Apache Spark ve Dağıtık İşleme

Spark soruları, yalnızca API çağrılarını değil, paralellik ve performans anlayışını test eder.

13. Spark'ta veri çarpıklığına (data skew) ne sebep olur ve nasıl düzeltilir?

Veri çarpıklığı, bir partition'ın diğerlerinden orantısız biçimde daha fazla veri tutması durumunda oluşur ve tek bir görevin tüm aşamayı darboğaza sokmasına neden olur.

Yaygın nedenler: birkaç baskın değere sahip bir anahtar üzerinde join yapma (null anahtarlar, tek bir popüler ürün ID'si) veya düşük kardinaliteli bir sütuna göre bölümleme.

Çözümler:

• Salting: çarpık anahtara rastgele bir sonek ekleyip, tuzlanmış anahtar üzerinde join yapıp ardından tuzu kaldırmak.
• Broadcast join: bir taraf yeterince küçükse (genellikle <200MB), shuffle'ı tamamen önlemek için broadcast etmek.
• AQE (Adaptive Query Execution): Spark 3.x+ sürümleri çarpık partition'ları çalışma zamanında otomatik algılayıp bölebilir.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Bu teknik iş yükünü executor'lar arasında eşit biçimde dağıtarak darboğazı ortadan kaldırır.

14. Spark'ta transformation ve action arasındaki farkı açıklayın.

Transformation'lar (map, filter, select, join) tembel (lazy) çalışır: mantıksal bir plan oluşturur ancak hiçbir şey yürütmez. Action'lar (count, collect, write) ise planı kümeye göndererek gerçek hesaplamayı tetikler.

Bu tembel değerlendirme, Spark'ın Catalyst optimizer'ının herhangi bir veri taşınmadan önce işlemleri yeniden sıralamasını, filtreleri aşağı itmesini ve gereksiz shuffle'ları elemesini sağlar. Bu ayrımı anlamak hata ayıklama için esastır: yavaş görünen bir transformation aslında sorunsuz olabilir; darboğaz onu tetikleyen action'dadır.

15. repartition() ve coalesce() arasındaki fark nedir?

repartition(n) tam bir shuffle gerçekleştirerek verileri eşit dağıtan tam olarak n partition oluşturur. Paralelliği artırmak veya çarpık partition'ları dengelemek için kullanılır.

coalesce(n) komşu partition'ları birleştirerek shuffle olmadan partition sayısını azaltır. Yazma öncesinde partition sayısını düşürmek (çok sayıda küçük dosya oluşmasını önlemek) için kullanılır.

Kural: azaltmak için coalesce, artırmak veya yeniden dengelemek için repartition.

Orkestrasyon ve Hat Yönetimi

Orkestrasyon soruları, operasyonel olgunluğu test eder: hatlar üretimde nasıl çalışır, nasıl başarısız olur ve nasıl kurtarılır.

16. Airflow, Dagster ve Prefect'i karşılaştırın. Her birini ne zaman tercih edersiniz?

| Özellik | Airflow | Dagster | Prefect | |---------|---------|---------|--------| | Olgunluk | En olgun, en geniş topluluk | Büyüyen, ML/veri ekiplerinde güçlü | Bulut öncelikli, güçlü geliştirici deneyimi | | Temel soyutlama | Görev DAG'leri | Varlıklar (veri merkezli) | Akışlar ve görevler | | Test | Daha zor (DAG düzeyinde) | Yerleşik varlık testi | İyi görev düzeyinde test | | Yerel geliştirme | Docker/container gerektirir | Yerel doğal çalışma | Yerel doğal çalışma | | En uygun | Karmaşık, uzun süren ETL | Veri mesh / varlık odaklı ekipler | Minimum altyapı isteyen ekipler |

Airflow, olgun veri platformları için endüstri standardı olmaya devam etmektedir. Dagster, görev dizileri yerine veri varlıkları olarak düşünen ekipler için uygundur. Prefect, Airflow benzeri orkestrasyonu daha az operasyonel yük ile isteyen ekiplere hitap eder. Airflow'a özel mülakat hazırlığı için Airflow temelleri modülü incelenebilir.

17. Üretimde hat hatalarını ve uyarıları nasıl yönetirsiniz?

Üretim düzeyinde bir hata stratejisi şunları içerir:

1. Geri çekilmeli yeniden deneme: geçici hatalar (ağ zaman aşımları, API hız sınırları) üstel geri çekilme ile çözülür.
2. Ölü mektup kuyrukları (Dead-letter queues): zehirli mesajlar, hattı engellemeden manuel inceleme için ayrı bir kuyruğa yönlendirilir.
3. Devre kesiciler (Circuit breakers): art arda N başarısızlıktan sonra, aşağı akış sistemlerini bozuk veriyle doldurmak yerine hattı duraklatır ve uyarı gönderir.
4. Gözlemlenebilirlik: yapılandırılmış loglar, metrikler (görev süresi, satır sayıları, hata oranları) ve her hat aşamasında veri kalitesi kontrolleri (Great Expectations, dbt testleri).
5. Uyarı katmanları: P1 (hat çöktü, veri eksik) nöbetçiye sayfa gönderir. P2 (veri kalitesi sapması) sonraki iş günü için Slack bildirimi gönderir.

18. Bir hattı "üretime hazır" yapan nedir? Prototipten farkı nelerdir?

Üretime hazırlık şu unsurları gerektirir: idempotent çalışma, otomatik yeniden denemeler, izleme ve uyarı, veri alımı ve dönüşüm aşamalarında veri doğrulama, veri sözleşmelerinin belgelenmesi, sürüm kontrollü hat tanımları ve test edilmiş bir geri alma yolu. Bir prototip bunların hiçbirine sahip değildir. İkisi arasındaki boşluk, çoğu hat teknik borcunun biriktiği noktadır.

Bulut Veri Platformları ve Lakehouse Mimarisi

Bulut platform soruları, adayların satıcıya özgü söz diziminin ötesinde maliyet, ölçek ve mimari ödünleşimleri anlayıp anlamadığını değerlendirir.

19. Lakehouse nedir ve neden baskın mimari haline gelmiştir?

Lakehouse, bir veri gölünün esnekliğini (schema-on-read, ham veri depolama, çoklu dosya formatları) bir veri ambarının güvenilirliğiyle (ACID işlemleri, şema zorlama, sorgu optimizasyonu) birleştirir. Delta Lake, Apache Iceberg ve Apache Hudi gibi teknolojiler, nesne depolama (S3, GCS, ADLS) üzerine bir meta veri/işlem katmanı ekleyerek bunu mümkün kılar.

Lakehouse kazanır çünkü göl ile ambar arasındaki maliyetli ETL katmanını ortadan kaldırır, hem BI sorguları hem de ML iş yüklerini aynı veri üzerinde destekler ve ucuz nesne depolamadan yararlanır.

20. Bulut veri ambarı maliyetleri (BigQuery, Snowflake, Redshift) nasıl optimize edilir?

Maliyet optimizasyon stratejileri:

• Tabloları bölümleme ve kümeleme ile sorgu başına taranan bayt miktarını azaltma
• Uygun warehouse boyutları belirleme (Snowflake) veya slot rezervasyonları (BigQuery) iş yükü kalıplarına göre ayarlama
• Boşta kaynakları otomatik askıya alma: Snowflake warehouse'ları 1-5 dakika hareketsizlik sonrası otomatik askıya alınmalı
• Sorgu başına maliyetleri izleme: BigQuery'nin INFORMATION_SCHEMA.JOBS görünümü pahalı sorguları ortaya çıkarır
• Tekrar hesaplanan toplamalar için materialized view kullanma
• Soğuk veriyi yaşam döngüsü politikalarıyla daha ucuz depolama katmanlarına arşivleme

Mülakat sinyali: maliyeti sonradan düşünülecek bir konu olarak değil, birincil bir mühendislik kısıtı olarak ele alan adaylar.

Veri Kalitesi ve Yönetişim

Veri kalitesi soruları, yalnızca hat kuran mühendisleri güvenilir veri platformları sürdüren mühendislerden ayırır.

21. Bir hatta veri kalitesi kontrolleri nasıl uygulanır?

Veri kalitesi kontrolleri üç aşamada yer alır:

1. Alım: şema uyumluluğunu doğrulama, null birincil anahtarları kontrol etme, kaynak ile satır sayısı eşiklerini karşılaştırma.
2. Dönüşüm: iş kurallarını doğrulama (ör. gelir > 0, tarihler geçerli aralıkta), tablolar arası referans bütünlüğünü kontrol etme.
3. Sunum: metrik sapmasını izleme (günlük aktif kullanıcılarda ani %50 düşüş muhtemelen bir hat sorununa işaret eder, iş değişikliğine değil).

Araçlar: dbt testleri (şema ve özel), Great Expectations, Soda Core, Monte Carlo (veri gözlemlenebilirliği). En iyi yaklaşım, kontrolleri doğrudan hat DAG'ına entegre ederek başarısızlıkların aşağı akış işlemlerini engellemesini sağlar.

22. Veri sözleşmesi nedir ve hat kırılmalarını nasıl önler?

Veri sözleşmesi, bir veri üreticisi ile tüketicileri arasında şunları belirleyen resmi bir anlaşmadır: şema (sütun adları, tipler, null olabilirlik), tazelik SLA'sı (veri UTC 06:00'a kadar hazır), hacim beklentileri (günlük 1M ile 10M satır arası) ve semantik kurallar (durum alanı yalnızca ACTIVE, INACTIVE, SUSPENDED içerir).

Üreticiler sözleşmeyi güncellemeden şemalarını değiştirdiklerinde, otomatik doğrulama uyumsuzluğu aşağı akışa yayılmadan yakalar. Bu, hat hatalarını sessiz veri bozulmasından açık ve eyleme dönüştürülebilir hatalara dönüştürür.

Sistem Tasarımı ve Mimari

Sistem tasarımı turları, orta ve kıdemli veri mühendisliği rolleri için standarttır. Uçtan uca düşünme yetkinliğini test ederler.

23. Bir e-ticaret platformu için gerçek zamanlı analitik hattı tasarlayın.

Sağlam bir tasarım şunları ele alır:

Alım: tıklama akışı olayları ve işlem olayları, kullanıcı oturumu içinde sıralama garantisi sağlamak için user_id bazında bölümlenmiş Kafka topic'lerine akar.

İşleme: bir Flink veya Spark Structured Streaming işi Kafka'dan tüketir, olayları ürün kataloğu verileriyle zenginleştirir (bir boyut tablosundan broadcast join), oturum düzeyinde ve 5 dakikalık toplamları hesaplar.

Sunum: toplu metrikler, milisaniye altı gecikmeyle panel sorguları için gerçek zamanlı bir OLAP deposuna (ClickHouse veya Apache Druid) iner. Ham olaylar, geçmişe dönük analiz için Delta Lake/Iceberg'e iner.

Veri kalitesi: şema kayıt defteri (Confluent veya AWS Glue) olay şemalarını alımda doğrular. Akış veri kalitesi kontrolleri anomalileri (olay hacminde ani düşüş) işaretler ve ölü mektup topic'ine yönlendirir.

Hata yönetimi: Kafka'nın consumer offset'leri checkpoint ile tam olarak bir kez (exactly-once) işlemeyi mümkün kılar. Akış işi, bir hata durumunda son checkpoint'ten otomatik yeniden başlar.

24. Eski bir ETL hattını modern bir mimariye nasıl taşırsınız?

Geçiş, boğucu incir (strangler fig) kalıbını izler:

1. Denetim: tüm mevcut hatları, kaynaklarını, dönüşümlerini ve tüketicilerini kataloglayın. Bağımlılıkları ve SLA'ları belirleyin.
2. Paralel çalışma: yeni hattı eskisinin yanında kurun. Her ikisi de aynı kaynaklardan tüketir ve ayrı hedeflere yazar.
3. Doğrulama: eski ve yeni hatların çıktılarını karşılaştırın. Otomatik uzlaştırma sorguları tutarsızlıkları işaretler.
4. Geçiş: çıktılar 2+ hafta boyunca tolerans dahilinde eşleştikten sonra tüketicileri yeni hedefe yönlendirin. Eski hattı geri dönüş için salt okunur modda tutun.
5. Devre dışı bırakma: kararlılık süresinin ardından eski hattı kapatın.

Temel içgörü: toptan geçiş (big-bang migration) asla yapılmamalıdır. Güven oluşana kadar her iki sistem paralel çalıştırılmalıdır.

25. Kritik bir panoda yanlış rakamlar görünüyor. Hata ayıklama sürecinizi anlatın.

Sistematik bir yaklaşım:

1. Sorunu kapsamlayın: hangi metrikler yanlış? Ne zamandan beri? Tüm boyutlarda mı yoksa belirli filtrelerle mi?
2. Sunum katmanını kontrol edin: sorunun pano aracında mı (önbellek, filtre mantığı) yoksa verinin kendisinde mi olduğunu doğrulamak için doğrudan veri ambarını sorgulayın.
3. Soyu yukarı doğru izleyin: veriyi pano tablosundan geriye doğru her dönüşüm adımı boyunca takip edin. Her aşamada satır sayılarını ve temel metrikleri kontrol edin.
4. Kırılma noktasını belirleyin: beklenen değerlerin gerçek değerlerden saptığı aşama, kök nedenin konumudur.
5. Yaygın nedenleri kontrol edin: kaynak sistemlerdeki şema değişiklikleri, uyarısız başarısız olan hat çalışmaları, işleme penceresini kaçıran geç gelen veri veya dönüşüm mantığını değiştiren bir dağıtım.
6. Düzeltin ve önleyin: acil sorunu yamalayın, bunu yakalayacak bir veri kalitesi kontrolü ekleyin ve çalıştırma kitabını güncelleyin.

Bu soru olay müdahale olgunluğunu test eder. Mülakatçılar rastgele tahmin değil, yapılandırılmış düşünce görmek ister.

Veri Mühendisliği Mülakatına Hazırlık

SharpSkill'deki veri mühendisliği mülakat hazırlık programı, ETL/ELT kalıpları, veri modelleme, Airflow, BigQuery ve daha fazlası üzerinde interaktif pratik ile bu konuları kapsar.

Sonuç

• SQL window function'ları, CTE'ler ve sorgu optimizasyonu kıdem düzeyinden bağımsız olarak temel olmaya devam etmektedir
• ETL vs ELT kararları, trend takibi yerine gecikme gereksinimleri, veri yönetişim ihtiyaçları ve altyapı maliyetleri tarafından yönlendirilmelidir
• İdempotans, veri sözleşmeleri ve veri kalitesi kontrolleri, üretim düzeyinde hatları prototiplerden ayırır
• Akış mimarisi soruları, araca özgü bilgiden ziyade ödünleşimlere (batch vs streaming vs mikro-batch) odaklanır
• Veri modelleme tercihleri (star vs snowflake, SCD tipleri) teorik en iyi uygulamalar değil, tüketim kalıplarıyla uyumlu olmalıdır
• Sistem tasarımı cevapları, mutlu yolun yanı sıra hata yönetimi, maliyet optimizasyonu ve gözlemlenebilirliği ele almalıdır
• En güçlü adaylar, yapılandırılmış problem çözme ve ödünleşimler hakkında dürüst muhakeme sergiler