Veri Pipeline ETL Tasarımı için Claude Promptu

Sen kıdemli bir veri mühendisisin (5+ yıl ETL/ELT pipeline deneyimi). {şirket_adı} için aşağıdaki gereksinimleri karşılayan, production-ready bir veri pipeline mimarisi tasarla ve belgele.

## GİRDİLER

- **Kaynak sistemler:** {kaynak_sistemler}
  (Örn: "PostgreSQL prod DB + Shopify REST API + günlük CSV dosyaları")
- **Hedef veri ambarı:** {hedef_sistem}
  (Örn: "Google BigQuery", "Snowflake", "AWS Redshift")
- **Günlük veri hacmi:** {gunluk_hacim}
  (Örn: "3 milyon sipariş satırı, ~15 GB/gün")
- **Güncelleme sıklığı:** {guncelleme_sikligi}
  (Örn: "her 30 dakikada bir incremental", "gece 02:00 full batch")
- **Teknoloji tercihi/kısıtı:** {teknoloji_tercih}
  (Örn: "Apache Airflow + dbt zorunlu", "sadece AWS managed servisleri")
- **Programlama dili:** {programlama_dili} (Python veya SQL)
- **Ekip büyüklüğü:** {ekip_buyuklugu} (Örn: "2 veri mühendisi")

---

## ADIM 1 — Mimari Karar

Aşağıdaki 4 yaklaşımı karşılaştır, ardından bağlama göre seçtiğini gerekçelendir:

| Mimari | Güçlü Yönler | Zayıf Yönler | Uygun Olduğu Durum |
|--------|-------------|-------------|-------------------|
| Full Batch | Basit, olgun araçlar | Yüksek gecikme (1-24 saat) | Günlük raporlama |
| Micro-batch (5-30 dk) | Denge: basitlik + tazelik | Orchestration karmaşıklığı | Operasyonel BI |
| Streaming (Kafka+Flink) | Anlık, sıralı | Yüksek maliyet ve karmaşıklık | Fraud, real-time |
| Lambda (batch + stream) | Her ikisinin avantajı | Her ikisinin karmaşıklığı | Kritik fintech |

**Seçilen mimari:** [seçim] — **Gerekçe:** [neden bu bağlam için doğru?]

---

## ADIM 2 — Extract Katmanı

Her kaynak için şunları belirle:

1. **Bağlantı ve auth yönetimi** — credentials nerede saklanır? (AWS Secrets Manager, HashiCorp Vault, env var?)
2. **Incremental vs Full Load stratejisi:**
   - Veritabanı için: `updated_at` watermark mı, Debezium CDC mı, yoksa snapshot mı? Neden?
   - API için: cursor-based sayfalama nasıl yönetilir? Rate limit aşılırsa ne olur?
3. **İdempotency:** aynı extract iki kez çalışırsa veri duplikasyonu nasıl önlenir?
4. **Retry politikası:** exponential backoff parametreleri ve max retry sayısı
5. **Gerçek kod örneği** (Python: bağlanma + watermark okuma + incremental çekme — iş mantığı içeren, boilerplate olmayan)

---

## ADIM 3 — Transform Katmanı (Medallion Mimarisi)

Bronze (ham) → Silver (temiz) → Gold (iş metrikleri)

**Bronze katmanı:**
- Ham veri olduğu gibi saklanır, hiç dokunulmaz
- Schema evolution nasıl yönetilir? (yeni kolon eklenirse mevcut pipeline bozulur mu?)
- Partition stratejisi: tarih bazlı mı?

**Silver katmanı:**
- Dedup kuralı: `DISTINCT` yeterli mi, yoksa deterministic row hash key mi?
- Null handling politikası: kritik alanlar boşsa satır düşürülür mü, doldurulur mu?
- Tip dönüşümleri ve validasyon kontrolleri
- Gerçek SQL/dbt model örneği ({is_metrigi} hesapla)

**Gold katmanı:**
- Aggregate tabloları ve iş metrikleri
- SCD (Slowly Changing Dimension) — Type 1 mi, Type 2 mi, Type 3 mü? Gerekçeyle açıkla
- Downstream BI aracına hangi tablolar expose edilir?

---

## ADIM 4 — Load Katmanı

- **Upsert stratejisi:** `MERGE INTO` mu, `INSERT ... ON CONFLICT DO UPDATE` mu, yoksa COPY + TABLE SWAP mi? {hedef_sistem} için en uygun yöntemi gerekçesiyle seç
- **Partition ve cluster tasarımı:** query pattern'lerine göre önerilen partition kolonları
- **Index önerileri:** en sık çalışacak sorgu tipleri için
- **Bulk load optimizasyonu:** ideal batch size, parallel worker sayısı

---

## ADIM 5 — Orchestration ve Bağımlılık Yönetimi

- {teknoloji_tercih} için örnek DAG/workflow yapısı (pseudo-code veya gerçek kod)
- Task bağımlılıkları: extract tamamlanmadan transform başlamaz — nasıl garanti edilir?
- SLA yönetimi: pipeline {guncelleme_sikligi} sürede bitmezse ne olur?
- **Backfill senaryosu:** geçmiş 30 günün yeniden işlenmesi nasıl yapılır?

---

## ADIM 6 — Gözlemlenebilirlik (Observability)

İzlenecek metrikler ve alarm eşikleri:

| Metrik | Beklenen Aralık | Alarm Eşiği | Aksiyon |
|--------|----------------|-------------|--------|
| Yüklenen satır sayısı değişimi | ±%10 | >%30 sapma | Pipeline durdur + alert |
| Pipeline toplam süresi | <{guncelleme_sikligi}/2 | Süre aşımı | Slack + eskalasyon |
| Hata oranı | <%0.1 | >%1 | Dead-letter queue + alert |
| Kaynak → hedef satır farkı | 0 | >100 satır | Veri kalite raporu |

- **Audit log şeması:** her pipeline çalışması için hangi metadatayı kaydet?
- **PII maskeleme:** {kaynak_sistemler}'den gelen hangi kolonlar hassas? Nasıl anonymize edilmeli?
- **Data lineage:** bir gold metriğin hangi ham kaynaktan geldiğini nasıl izlenir?

---

## ADIM 7 — Teknik Tasarım Belgesi Çıktısı

Aşağıdaki bölümlerle eksiksiz bir belge yaz:

**a) Mimari Diyagram** (Mermaid.js — copy-paste çalışabilir olsun)

**b) Tablo Envanteri** — kaynak tablo/endpoint → hedef tablo mapping tablosu (en az 5 satır)

**c) Deployment Checklist** — production'a almadan önce kontrol edilecek en az 10 madde

**d) Hata Senaryoları ve Recovery Playbook:**
- Senaryo 1: Kaynak DB'ye bağlantı kesildi → adım adım recovery
- Senaryo 2: Hedef ambar kota doldu → bekleme/eskalasyon
- Senaryo 3: Yüklenen satır sayısı anormal → veri kalite alarm akışı

**e) Tahmini Aylık Maliyet** — {hedef_sistem} için compute + storage + egress tahmini

---

## KISITLAR

- Tüm öneriler bugün production'da kullanılan gerçek araçlara dayalı olsun
- Her mimari kararın tradeoff'unu açıkça belirt; "en iyisi budur" deme
- Kod örnekleri {programlama_dili} ile yazılsın, {şirket_adı} bağlamına uyarlanmış olsun
- Çıktı markdown formatında, H2/H3 başlıklı, tablolar gerçek MD tablosu, kod blokları dil etiketli

**Hedef uzunluk:** 1.500–2.500 kelime — bu bir danışmanlık raporu; gerçekten kapsamlı ol.