1. GİRİŞ: VERİNİN EVRENSEL DİLİ SQL'İN YENİDEN DOĞUŞU

Teknoloji dünyasında diller gelir ve geçer; ancak 1970'lerden beri sarsılmayan tek bir kale vardır: SQL (Structured Query Language). Veri mühendisliği (Data Engineering) dendiğinde akla gelen Python, Spark veya Kafka gibi popüler araçların merkezinde, veriyi anlamlandırma ve dönüştürme yükünü hala SQL omuzlamaktadır. Bugün SQL, sadece veri tabanlarından veri çekmek için kullanılan basit bir araç değil, modern veri ambarlarında (Cloud Data Warehouses) petabaytlarca veriyi işleyen devasa bir hesaplama motorudur.

2026 yılı perspektifinden baktığımızda, verinin demokratikleşmesi ve yapay zeka ajanlarının veri dünyasına girişi, SQL'in önemini azaltmak yerine artırmıştır. Çünkü SQL, verinin mantıksal yapısını tanımlayan en saf ve en standart dildir. Bir veri mühendisi için SQL bilmek, sadece "sorgu yazmak" değil, sistemin nasıl çalıştığını, verinin nasıl aktığını ve en düşük maliyetle en yüksek performansın nasıl alınacağını bilmek demektir.

Bu Teknoloji Neden Bugün Daha Çok Konuşuluyor?

Bulut tabanlı modern veri yığınlarının (Modern Data Stack) yükselişiyle birlikte ELT (Extract, Load, Transform) paradigması, geleneksel ETL'in yerini aldı. Bu değişim, verinin ham halde yüklenip "ambar içinde" dönüştürülmesi anlamına geliyor. Bu dönüşümün motoru ise SQL'dir. Snowflake, BigQuery ve Databricks gibi devlerin SQL yeteneklerini artırması, mühendislerin karmaşık mantıkları Java veya Scala yerine doğrudan SQL ile kurgulamasını sağladı.

Kimler İçin Önemli?

Yazılım dünyasından veri dünyasına geçiş yapan Backend Mühendisleri, veri modellerini optimize etmek isteyen Veri Mimarları ve veri hatlarını daha sürdürülebilir kılmaya çalışan Veri Mühendisleri için SQL uzmanlığı bir zorunluluktur.

Hangi Problemleri Çözüyor?

• Veri Dönüşüm Karmaşıklığı: Milyonlarca satırlık veriyi karmaşık döngüler yerine deklaratif (declarative) bir dille saniyeler içinde gruplar ve özetler.
• Ölçeklenebilirlik: SQL motorları, kodun nasıl paralelleştirileceğini otomatik olarak çözer (Query Optimizer), mühendisi düşük seviyeli paralellik hesaplarından kurtarır.
• Maliyet Yönetimi: İyi yazılmış bir SQL sorgusu, taranan veri miktarını azaltarak bulut harcamalarını binlerce dolar düşürebilir.
• Geliştirici İşbirliği: SQL evrensel bir dildir; bir mühendisin yazdığı mantığı bir veri analisti veya yönetici kolayca anlayabilir.

2. KAVRAMSAL TEMELLER: VERİ MÜHENDİSLİĞİNDE SQL TERMİNOLOJİSİ

Veri mühendisliğinde SQL, standart CRUD işlemlerinin çok ötesine geçer. İşte bilinmesi gereken temel mimari kavramlar:

2.1 Window Functions (Pencere Fonksiyonları)

Veriyi gruplamadan (group by yapmadan), her satırın etrafındaki bir "pencereye" bakarak hesaplama yapma yeteneğidir. Sıralama (RANK), kümülatif toplam (SUM OVER) ve önceki/sonraki değerlere erişim (LEAD/LAG) gibi karmaşık analitik işlemler bu fonksiyonlarla yapılır.

2.2 CTE (Common Table Expressions) ve Rekürsif Sorgular

Sorguları daha okunabilir ve modüler hale getiren geçici sonuç kümeleridir. `WITH` bloğu ile tanımlanırlar. Rekürsif CTE'ler ise hiyerarşik yapıları (organizasyon şemaları, kategori ağaçları) gezmek için kullanılan ileri düzey bir tekniktir.

2.3 ACID Prensipleri

Atomicity, Consistency, Isolation, Durability. Bir veri mühendisi için SQL tabanlı bir işlemin (transaction) veri bütünlüğünü nasıl koruduğunu anlamak, hatalı veri üretimini (data corruption) önlemenin ilk adımıdır.

2.4 Data Modeling (Star ve Snowflake Schemas)

SQL'in en verimli çalıştığı yapılar olan Star (Yıldız) ve Snowflake (Kar Tanesi) şemaları, verinin "Dimension" (Boyut) ve "Fact" (Gerçeklik) tablolarına ayrılmasını sağlar. Bu yapılar, JOIN maliyetlerini optimize eder.

3. NASIL ÇALIŞIR? SORGUNUN YOLCULUĞU VE ÇALIŞMA MANTIĞI

Bir SQL sorgusu yazdığınızda, motorun arkasında devasa bir mühendislik operasyonu döner. Veri mühendisi bu süreci "Query Tuning" yapmak için bilmek zorundadır.

3.1 Sistem Mimarisi: Parser, Optimizer ve Executor

1. Parser: Sorgunun sözdizimini kontrol eder ve bir "Query Tree" oluşturur.
2. Query Optimizer (En Önemli Parça): Sorguyu çalıştırmanın binlerce farklı yolunu (planını) hesaplar. İstatistiklere bakarak hangi tablonun önce okunacağına, hangi indexin kullanılacağına karar verir.
3. Executor: Optimizer'ın seçtiği planı kullanarak veriyi diskten (veya bulut depolamadan) çeker ve CPU/RAM üzerinde işler.

3.2 Veri Akışı ve Filtreleme (Predicate Pushdown)

Modern sistemlerde veri, sorgu motoruna gelmeden önce depolama katmanında (örneğin S3 üzerindeki Parquet dosyalarında) filtrelenir. SQL'deki `WHERE` koşulunun depolama katmanına indirilmesine Predicate Pushdown denir. Bu, ağ trafiğini ve bellek kullanımını dramatik şekilde azaltır.

3.3 Columnar vs. Row-based Processing

Veri mühendisliğinde kullanılan SQL motorları (Redshift, Snowflake) genellikle sütun bazlı (columnar) çalışır. Bu mimari, milyonlarca satır içinden sadece 3 sütunu çekmek istediğinizde, diskin geri kalan %90'ına dokunmadan sadece o 3 sütunu okumasını sağlar. SQL'deki `SELECT *` kullanımının "yasak" olmasının teknik nedeni budur.

4. GERÇEK DÜNYA KULLANIMLARI: DEVLER SQL'İ NASIL ÖLÇEKLİYOR?

Bugün dünyanın en büyük veri platformları, iş mantıklarını (business logic) SQL tabanlı katmanlarda yönetmektedir.

4.1 Netflix: Kişiselleştirme ve SQL Analitiği

Netflix, milyarlarca izleme olayını (events) Snowflake ve dahili SQL katmanlarında işler. Window fonksiyonlarını kullanarak kullanıcıların "izleme seanslarını" (sessions) tanımlarlar. Bir kullanıcının filmi ne zaman durdurduğunu, ne zaman geri sardığını SQL tabanlı analitik sorgularla belirleyip öneri motorlarına veri sağlarlar.

4.2 Uber: Dinamik Fiyatlandırma ve SQL Akışları

Uber, sürücü ve yolcu arz-talep dengesini izlemek için Presto ve Apache Pinot gibi SQL uyumlu motorlar kullanır. Coğrafi verileri (Geo-spatial SQL) kullanarak bölge bazlı surge (yoğunluk) fiyatlandırmalarını SQL üzerinden saniyeler içinde hesaplarlar.

4.3 dbt (Data Build Tool) Devrimi: SQL as Code

Pek çok şirket artık "pipeline" kodlamak yerine dbt kullanarak SQL modelleri yazıyor. dbt sayesinde SQL sorguları; versiyon kontrolü (Git), test etme ve dökümantasyon gibi yazılım mühendisliği disiplinlerine kavuşmuştur. Bu, veri mühendisliğinde "Software Engineering for Data" akımının temelidir.

4.4 OpenAI: Veri Hazırlama Boru Hatları

LLM modellerinin eğitimi için gereken devasa temizleme ve etiketleme işlemleri SQL katmanlarında başlar. Milyarlarca doküman içinden benzer olanların elenmesi, dil bazlı gruplandırma ve veri kalitesi kontrolleri SQL tabanlı boru hatları ile optimize edilir.

5. AVANTAJLAR VE SINIRLAMALAR: DÜRÜST BİR ANALİZ

SQL güçlüdür ancak her derde deva değildir. Mühendisin sınırları bilmesi gerekir.

Avantajlar

• Zaman Tasarrufu: Karmaşık veri birleştirme (JOIN) algoritmalarını kodlamanıza gerek yoktur; SQL motoru bunu sizin yerinize en iyi şekilde yapar.
• Bildirimsel Güç: "Nasıl yapılacağını" değil "Ne istendiğini" tanımlarsınız. Bu, kodun bakımını kolaylaştırır.
• Ekosistem: Hemen her veri aracı SQL ile konuşur. Entegrasyon maliyeti minimaldir.
• Yüksek Performans: Modern sorgu motorları (Query Optimizers), insan elinden çıkma pek çok koddan daha hızlı veri işleyebilir.

Sınırlamalar ve Dezavantajlar

• Karmaşıklık Yönetimi: Binlerce satırlık tek bir SQL sorgusu (Spaghetti SQL) okunamaz ve debug edilemez hale gelebilir.
• Hiyerarşik Veri Zorluğu: Çok derin ve karmaşık ağ (graph) yapılarını SQL ile gezmek (Recursive CTE) performans sorunlarına yol açabilir.
• Yazma Hızı: SQL tabanlı veritabanları (RDBMS), saniyede milyonlarca "yazma" işlemi (ingestion) için NoSQL sistemlere göre daha yavaş kalabilir.
• Birim Test (Unit Testing): Klasik yazılım dillerine göre SQL'i test etmek daha zordur ve özel araçlar (dbt, SQLFluff) gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA: SQL MI, PYTHON MI, NOSQL MI?

Veri mühendisliğinde doğru aracı seçmek için bu kıyaslamayı dikkate alın:

7. EN İYİ PRATİKLER: PRODUCTION SEVİYESİNDE SQL MÜHENDİSLİĞİ

Kodunuzun sadece "çalışması" yetmez; sürdürülebilir ve performanslı olması gerekir.

Üretim ve Tasarım Kuralları

• ASLA `SELECT *` Kullanmayın: Sadece ihtiyacınız olan sütunları belirtin. Bu, disk I/O ve memory kullanımını %90'a kadar azaltır.
• CTEs ile Modülerlik: Uzun sorguları mantıksal parçalara (CTE) bölün. Sorgunun en başında tanımlanan CTE'ler kodun okunabilirliğini artırır.
• Handle NULLs: SQL'de `NULL` ile yapılan karşılaştırmalar (`NULL = NULL`) her zaman `FALSE` veya `UNKNOWN` döner. `COALESCE` fonksiyonu ile default değerler atayın.
• SCD (Slowly Changing Dimensions) Yönetimi: Veri geçmişini saklamak için `MERGE` statement kullanarak UPSERT (Update or Insert) mantığını SQL seviyesinde kurgulayın.

Performans Optimizasyonu

• Filter Early (WHERE clause): JOIN yapmadan önce veriyi filtreleyin. Ne kadar az veri JOIN'e girerse sorgu o kadar hızlı biter.
• İndeksleme Stratejisi: Sık kullanılan filtre (WHERE) ve JOIN kolonlarına uygun indeksleri (B-Tree, Columnar, Bitmap) ekleyin.
• Partition Pruning: Tabloları tarih bazlı bölümleyin (Partition). Sorgunuzda tarih filtresi kullanarak motorun tüm tabloyu değil, sadece ilgili günü taramasını sağlayın.

Güvenlik

• SQL Injection Önleme: Dinamik SQL yazarken mutlaka parametreleştirilmiş (parameterized) sorgular kullanın.

8. SIK YAPILAN HATALAR: MÜHENDİSLERİN PERFORMANS KATİLLERİ

• Implicit Joins: Virgül ile tablo ayırıp WHERE içinde birleştirme yapmak (Oracle tarzı). Modern SQL'de mutlaka `JOIN ... ON` ifadesini kullanın.
• Cross Joins (Kartezyen Çarpım): JOIN koşulunu unutmak, tabloları birbiriyle çarpıp milyarlarca satır üretilmesine ve sistemin kilitlenmesine neden olur.
• Looping in SQL: SQL içinde "Cursor" veya döngü kullanmaya çalışmak. SQL set-based bir dildir; döngü yerine toplu işlem (set operations) mantığıyla düşünmelisiniz.
• İstatistikleri İhmal Etmek: Veritabanı istatistikleri güncel değilse, Optimizer yanlış kararlar verir ve sorgu süresi uzar. Periyodik `ANALYZE` komutlarını unutmayın.
• Aşırı İndeksleme: Her kolona indeks koymak, "Yazma" (Insert/Update) hızını dramatik şekilde düşürür.

9. GELECEK TRENDLER: SQL'İN GELECEĞİ VE AI ETKİSİ

SQL ölmedi, sadece şekil değiştiriyor.

9.1 AI-Generated SQL (Metinden SQL'e)

2026 ve sonrasında veri mühendisleri SQL kodunun iskeletini yazmakla uğraşmayacak. Doğal dilden SQL'e dönüşüm yapan modeller (GPT, CodeLlama), şema bilgisine bakarak karmaşık JOIN'leri otomatik kurgulayacak. Mühendisin rolü "kod yazmaktan" "kodu inceleyen ve optimize edene" evrilecek.

9.2 Streaming SQL (Canlı Sorgular)

Geleneksel SQL "statik" veriye bakar. Gelecekte, ksqlDB veya Flink SQL gibi teknolojilerle, sanki sabit bir tabloymuş gibi canlı veri akışları (Kafka topic'leri) üzerinde sürekli SQL sorguları çalışacak.

9.3 Serverless Data Warehousing

"Veritabanı sunucusu" kavramı tamamen yok oluyor. Sorgu başına ödeme yapılan, sadece sorgu anında ayağa kalkan devasa dağıtık sistemler SQL motorlarını her zamankinden daha güçlü ve ucuz hale getirecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Veri mühendisi olmak için sadece SQL yeterli mi?

   Hayır, SQL çekirdek yetenektir ancak yanına Python (ETL için) ve bulut altyapı bilgisi (AWS/Azure) mutlaka eklenmelidir.

2. HAVING ile WHERE arasındaki fark nedir?

   WHERE satırları gruplamadan önce eler, HAVING ise gruplama (GROUP BY) yapıldıktan sonra gruplar üzerinde filtreleme yapar.

3. NoSQL sistemlerde SQL kullanılır mı?

   Evet, pek çok NoSQL veritabanı (Cassandra - CQL, MongoDB - MongoDB Connector for BI) artık SQL benzeri sorgulama dillerini destekliyor.

4. Sorgu planı (Execution Plan) nasıl okunur?

   `EXPLAIN` komutunu kullanarak, motorun hangi adımları izlediğini, en maliyetli (costly) işlemin hangisi olduğunu görebilirsiniz.

5. UNION ile UNION ALL farkı nedir?

   UNION sonuçları birleştirir ve tekilleştirir (Daha yavaştır). UNION ALL ise her şeyi olduğu gibi birleştirir (Daha hızlıdır).

6. Modern veri ambarlarında neden Primary Key zorunlu değil?

   Dağıtık sistemlerde PK kontrolü performans yükü getirdiği için pek çok modern sistem (BigQuery vb.) PK bütünlüğünü kontrol etmez, bu işi mühendise bırakır.

7. SQL formatlamak neden önemli?

   SQL bir koddur. SQLFluff gibi araçlarla standart bir format kullanmak, takım çalışmasında hata yapma riskini azaltır.

8. Sütun bazlı (Columnar) depolama neden daha hızlıdır?

   Çünkü analitik sorgularda genellikle 50 kolonluk tablonun sadece 3 kolonu istenir; Columnar yapı sadece o 3 kolonu diskten okuyarak I/O tasarrufu sağlar.

Anahtar Kavramlar Sözlüğü

Normalization (Normalizasyon)

Veri tekrarını önlemek ve bütünlüğü sağlamak için veritabanını organize etme süreci.

Denormalization

Okuma performansını artırmak için veriyi bilerek tekrar etme (Data Warehousing için kritiktir).

OLAP vs OLTP

OLTP hızlı işlemler (banka havalesi), OLAP ise büyük veri analizi (yıllık satış raporu) için optimize edilmiş sistemlerdir.

Materialized View

Bir sorgunun sonucunun fiziksel olarak diske kaydedilmesi; her seferinde ağır hesaplama yapmayı engeller.

Joins (Inner, Left, Right, Full, Cross)

İki veya daha fazla tabloyu belirli bir anahtar (key) üzerinden birleştirme yöntemleri.

Öğrenme Yol Haritası (SQL Uzmanı Olma)

1. Adım 1: Temel Sorgulama. SELECT, JOIN, GROUP BY ve temel agregasyon fonksiyonlarını su gibi öğrenin.
2. Adım 2: Analitik Yetenekler. Window Functions (OVER, PARTITION BY) ve CTE yapılarını gerçek veri setlerinde uygulayın.
3. Adım 3: Veri Modelleme. Star Schema, Snowflake Schema ve normalizasyon kurallarını teorik ve pratik olarak kavrayın.
4. Adım 4: Query Optimization. İndeksleme türlerini, EXPLAIN planlarını okumayı ve sorgu performansını artırmayı öğrenin.
5. Adım 5: Modern Araçlar. dbt (Data Build Tool) kullanarak SQL projelerini profesyonel bir yazılım projesi gibi yönetmeyi öğrenin.