Furkan İkkan English
Yazılara geri dön

Büyük Veri Projeleri Neden Hâlâ Başarısız Oluyor: Beklenti vs Operasyon Uçurumu

Büyük veri yatırımları, operasyonel gerçekler satıcı vaatleriyle karşılaşınca çöküyor. Sahada gördüklerim: depolama yayılması, kırık pipeline'lar, sessiz veri kaybı.

Big DataSparkData EngineeringHadoopData PipelineData QualityDevOps

Büyük veri birçok şirket için hâlâ başarısız bir yatırım çünkü beklenti ile operasyon arasındaki uçurum devasa. Yöneticiler gerçek zamanlı analiz ve AI odaklı kararlar vizyonuna alınıyorlar ama asıl iş — cluster provisioning, Spark job tuning, schema drift fixleme, backup bakımı — neredeyse hiç konuşulmuyor. Benim ortamımda bu pattern'i sürekli görüyorum: ekipler Hadoop veya Kafka cluster'ları kuruyor, birkaç POC çalıştırıyor, sonra sistem gerçek production yükü altında performans göstermesi gerektiğinde duvara çarpıyorlar. Büyük veri vaadi operasyonel gerçekle uyuşmuyor.

Büyük Veri Deployment'larında Beklenti vs Operasyon Uçurumu

Tipik olarak şöyle oluyor. Liderlik şık bir vendor demo'sundan sonra büyük veri bütçesini onaylıyor. Demo'da dashboard'lar saniyeler içinde güncelleniyor, predictive model'lar sorunsuz çalışıyor, veri sistemler arasında zahmetsizce akıyor. Kimse demo'nun belki 50.000 satırlık özenle seçilmiş bir dataset üzerinde çalıştığını mention etmiyor.

Sonra production geliyor. Aniden şunlarla uğraşıyorsunuz:

  • POC'taki 50GB yerine günlük 2TB ingest
  • Upstream kaynaklardan gelen schema değişiklikleri gece 3'te ETL pipeline'ınızı bozuyor
  • Test sırasında 30 saniyede çalışan Spark job'ları artık 45 dakika sürüyor
  • Veri ekibi ve ops ekibi birbirini işaret ettiği için sahibi olmayan veri kalitesi sorunları

Ben bu işin iki tarafında da bulundum. Beklenti şu: bir tool takıyorsun ve insight'lar akıyor. Gerçek şu: büyük veri altyapısı, herhangi bir production sistemi gibi dikkatli capacity planning, monitoring ve incident response gerektiriyor — ama dağıtık hesaplamanın getirdiği ekstra karmaşılıkla birlikte.

Spark Job'ları Production'da Neden Başarısız Oluyor (Ve Nasıl Debug Edilir)

Ekiplerin en çok zorlandığı yer burası. Küçük bir dataset üzerinde mükemmel çalışan bir Spark job'u ölçeklenince dağılıyor. Olağan şüpheliler: memory sorunları, data skew ve kötü yapılandırılmış executor'lar.

Tuning için bir başlangıç noktası. Önce executor memory ve core'larınızı kontrol edin:

spark-submit \
  --executor-memory 8g \
  --executor-cores 4 \
  --num-executors 20 \
  --driver-memory 4g \
  --conf spark.sql.shuffle.partitions=400 \
  your_job.py

O spark.sql.shuffle.partitions ayarı sürekli tune ettiğim bir şey. Default 200 neredeyse hiçbir zaman doğru değil. 1TB veri işliyorsanız, 200 partition roughly 5GB per partition demek — çok fazla. 10GB işliyorsanız, 200 partition, task scheduling'dan devasa overhead'i olan küçük partition'lar demek.

Asıl debugging Spark UI ile başlar. Ben hep şunları kontrol ederim:

  • Stage timeline: Bazı task'lar diğerlerinden 10x daha uzun sürüyor mu? O data skew'dir.
  • Shuffle read/write: Devasa shuffle sayıları, operasyonlarınızın ağ üzerinden çok fazla veri taşıdığı anlamına gelir.
  • Executor page: Executor'lar OOM nedeniyle cluster manager tarafından kill ediliyor mu?

Storage Sprawl ve Data Lake'lerin Gizli Maliyeti

Bu yavaş yavaş üstünüze gelir. Bir data lake başlangıçta temiz, düzenli bir repository olarak başlar. Altı ay sonra, data swamp'a dönüşür — binlerce tutarsız formatta dosya, documentation yok, ownership yok ve neyin hâlâ kullanıldığını kimse bilmiyor.

Storage growth'u dikkatlice takip ederim. HDFS cluster'larımızda en kötü suçluları bulmak için çalıştırdığım hızlı bir komut:

hdfs fs -du -s -h /warehouse/* | sort -rh | head -20

S3 tabanlı lake'ler için, aws s3 ls --recursive --summarize ile biraz scripting kombinasyonu yaparak benzer bir yaklaşım kullanıyorum.

Sorun sadece maliyet değil. Stale veri bir liability'ye dönüşüyor. Artık kimse referans vermediği PII içeren eski partition'lar yine de geçerli veri koruma regülasyonlarına uygun olmak zorunda. Compliance ekiplerine açıklamak zorunda kaldım: evet, üç yıl önce yazılmış ve o günden beri kimse erişmemiş bir Parquet dosyasında verimiz var.

İpucu: Birinci günden data retention policy implement edin. Basit bir tane bile olsa. "Raw veri 90 gün, aggregated veri 2 yıl saklanır", "belki lazım olur diye her şeyi sonsuza kadar sakla"dan daha iyidir.

Büyük Veri Pipeline'larında Sessiz Veri Kaybı

Bu, önceki yazımda sessiz veri kaybı senaryoları hakkında backup'larla ilgili yazdıklarımla bağlantılı (https://furkanikkan.com/urun/geri-yuklemede-basarisiz-olan-yedekler-sessiz-veri-kaybi-senaryosu-27). Aynı prensip büyük veri pipeline'ları için de geçerli ama daha kötü çünkü hacim manuel doğrulamayı imkansız kılıyor.

Bir pipeline günde 50 milyon satır ingest ediyor. Bir gün, upstream'de bir schema değişikliği bir kolonu drop ediyor. Pipeline'ınız sessizce o kolon için NULL değerler yazmaya başlıyor. Dashboard'lar hâlâ render edildiği için iki hafta kimse fark etmiyor — sadece o alan için boş veri gösteriyorlar.

Bunu yakalamak için şunları implement ediyorum:

  1. Row count check'leri her aşamada. Bugünün count'u 7 günlük rolling average'dan %20'den fazla sapıyorsa, alert.
  2. Schema validation — Great Expectations gibi bir tool veya kolon varlığını ve type'larini kontrol eden basit bir Python script'i.
  3. Veri kalitesi metrikleri — null oranları, unique count'lar, değer aralıkları — zaman içinde takip edilen.
# Simple row count anomaly check
import pandas as pd

def check_row_count(df, table_name, threshold=0.2):
    today_count = len(df)
    # historical_avg pulled from your metrics store
    if abs(today_count - historical_avg) / historical_avg > threshold:
        send_alert(f"{table_name}: {today_count} rows vs avg {historical_avg}")

Monitoring ve Alerting: Eksik Katman

Büyük veri sistemleri, yönettiğim herhangi bir altyapı gibi monitoring'e ihtiyaç duyar. Ama metrikler farklıdır. Cluster node'larında CPU ve memory yeterli değil. Pipeline seviyesinde observability'e ihtiyacınız var.

Bu temel metrikleri takip ederim:

  • Pipeline latency: Veri gelişinden warehouse'ta kullanılabilir olmasına kadar geçen süre
  • Job success rate: Schedule edilmiş job'lardan hatasız tamamlananların yüzdesi
  • Data freshness: Her kritik tabloya en son başarılı write ne zaman yapıldı?
  • Queue depth: Scheduler'da kaç job bekliyor?

Monitoring için cluster metrikleri için Prometheus ve Grafana kullanıyorum, artı pipeline metrikleri için custom bir dashboard. Pipeline dashboard'ı basit — her pipeline'ı, son run zamanını, status'ünü ve row count'larını gösteren bir tablo. Ama bir şeyler yanlış hissettirdiğinde ilk kontrol ettiğim şey bu.

Başta mention ettiğim beklenti uçurumu? Monitoring'de en görünür hale geliyor. Liderlik gerçek zamanlı insight bekliyor. Ops ekipleri gece batch'i sabah raporu çalışmadan önce bitse mutlu. Bunlar çok farklı SLA'lar ve kimse önden align etmiyor.

Gerçekte Ne İşe Yarıyor: Küçük Başlayın, Ops'a Sahip Çıkın

Büyük veri ile başarılı olduğunu gördüğüm şirketler devasa bir Hadoop cluster'ıyla başlamıyor. Belirli bir problemle, sınırlı bir dataset'le ve ingest'ten dashboard'a operasyon'a kadar tam lifecycle'a sahip olan bir ekiple başlıyorlar.

İşte benim pratik checklist'im:

  • Altyapıya dokunmadan önce ölçülebilir ROI'ya sahip somut bir use case tanımlayın
  • Mantıklı yerlerde managed service'lerle başlayın (EMR, Databricks, BigQuery) — 2024'te dedicated bir platform ekibiniz yoksa Hadoop'u kendiniz manage etmeyin
  • Veri kalitesi check'lerini pipeline'a afterthought olarak değil, içine inşa edin
  • Data lineage'i başından document edin — hangi tablo hangi dashboard'u feed ediyor, hangi job hangi partition'a write ediyor
  • İlk incident'ten sonra değil, ihtiyaç olmadan önce alerting kurun

Büyük veri kötü bir yatırım değil. Operasyonel disiplin gerektiren bir yatırım ve çoğu şirket burada eksik kalıyor. Teknoloji çalışıyor. Beklentiler çalışmıyor.

Kapak görseli: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/52786101642