"Hangi aracı seçmeliyim?" karar ağacı
Tool selection decision tree
Bu derste neler öğreneceksin
- Ölçeğe göre araç seçer (startup vs enterprise)
- Bütçe + ekip becerisi + mevcut stack analiz eder
- Karar matrisini doldurur
Araç Seçimi Mühendislik Kararıdır
Yeni başlayanlar “hangi araç en iyi?” diye sorar. Deneyimli ekipler “bu bağlamda hangi araç en az toplam maliyet?” diye sorar. Toplam maliyet = lisans + kurulum + bakım + öğrenme + değişim (switching). Çoğu zaman en ucuz araç en pahalı toplam sahip olma maliyetine (TCO) sahiptir.
Bu dersin sonunda bir mühendislik kararı verme pratiğin olacak: trade-off analizi, alternatif değerlendirme, gerekçe yazımı.
Karar Çerçevesi: 5 Boyut
1. Ölçek (Volume)
| Günlük veri | Pik | Mimari |
|---|---|---|
| < 1 GB | < 10 GB | Postgres / DuckDB + Bruin local |
| 1-100 GB | < 1 TB | BigQuery / Snowflake + dbt + Bruin Cloud |
| 100 GB - 1 TB | < 10 TB | + Spark (Dataproc / EMR) |
| > 1 TB | > 10 TB | Kafka/Flink + Lakehouse (Iceberg) + Spark |
Trade-off: Büyük araçlar elastik ama cold start maliyetli; küçük araçlar basit ama ölçeklenmiyor.
2. Gecikme (Latency)
| SLA | Mimari |
|---|---|
| Günlük batch | dbt + Bruin yeterli |
| Saatlik near-real-time | dbt + incremental + schedule |
| Dakikalar | Materialized view + streaming (Kafka + Flink) |
| Saniyeler | Pure streaming, OLAP (Druid, Pinot) |
3. Ekip Becerisi
| Yetkinlik | Düşün |
|---|---|
| Sadece Python | Bruin + dbt Python models + DuckDB |
| SQL güçlü | dbt + Postgres / BigQuery |
| DevOps / SRE | Airflow / Dagster + K8s |
| Çok disiplinli | Her şey açık; mimari seçim serbest |
Trade-off: “En iyi” araç, ekibin öğrenme eğrisini gerçekçi hesaba katmazsan felaket olur.
4. Mevcut Stack
Şirket AWS kullanıyorsa yeni bir GCP projesi açmak iki bulut yönetimi demek. Mevcut stack:
- Identity (IAM, RBAC)
- Networking (VPC, peering)
- Monitoring (CloudWatch, Datadog)
- Cost management
Her yenisi bunlara ek yük bindirir. Brownfield projede “yeni araç seç” kararı sadece teknoloji değil, organizasyonel karar.
5. Toplam Maliyet (TCO)
| Maliyet kalemi | Örnek |
|---|---|
| Direkt lisans | Snowflake credit, dbt Cloud seat |
| Altyapı | BigQuery slot, S3 storage |
| Kurulum | Mühendis saati (haftalar) |
| Öğrenme | Ekip eğitimi (günler) |
| Bakım | Versiyon yükseltme, incident |
| Değişim (switching) | Veri taşıma, sorgu rewrite |
Açık kaynak TCO’su sıfır değildir — bakım ve operasyonu hesaba kat.
Karar Matrisi (Örnek)
Senaryo: Bir startup, 50 GB/gün, 1 Python mühendisi, AWS zaten kullanıyor.
Ölçek Latency Ekip Stack TCO Skor
Bruin + DuckDB local 3/5 3/5 5/5 4/5 5/5 20
dbt Cloud + BigQuery 4/5 4/5 4/5 3/5 3/5 18
Snowflake + Airflow 5/5 5/5 2/5 2/5 2/5 16Bruin + DuckDB kazanır — çünkü ekip yetkinliği ve TCO baskın. Skor farkı küçükse ikinciyi de değerlendir (yedek plan).
3 Klasik Hata
- Resume-driven development: LinkedIn’de gördüm diye Databricks seçmek. Şirket ihtiyacıyla değil, CV ile karar.
- Vendor lock-in görmezden gelmek: Snowflake’a veri gömen ekip, çıkışın 6 ay + milyon dolar maliyet olduğunu hesaplamaz.
- Ölçek tahminini 10x şişirmek: “5 yıl sonra 100 TB olur” diye baştan Kafka kurmak. Bugünün problemini bugünün aracıyla çöz.
Capstone İçin Şablon
Capstone README’sine şu bölümü ekle (zorunlu):
## Araç Seçimi Gerekçesi
**Bağlam:** [veri hacmi, ekip, kısıt]
**Değerlendirilen alternatifler:** [en az 2]
**Seçim:** [araç X]
**Gerekçe:** [ölçek + ekip + TCO özeti]
**Trade-off:** [neyi feda ettin]
**Çıkış planı:** [1 yıl sonra değiştirmek gerekirse nasıl]Bu format profesyonel bir RFC (request for comments) taslağıdır. İş görüşmelerinde aynı formatı kullanırsın.
Hands-on
- Capstone projen için 5 boyutu tek cümleyle cevapla.
- 3 alternatif belirle, yukarıdaki matrisi doldur.
- README’ye “Araç Seçimi Gerekçesi” bölümü yaz (yukarıdaki şablonla).
- Bir senior mühendisle (varsa) 15 dakika konuş, gerekçeni savun.
- Capstone defterine “1 yıl sonra neyi farklı yapardım?” notu düş.
Sıradaki
Karar net. W2’de dlt + AI Copilot ile pipeline geliştirmeyi hızlandırıyoruz →