Hadoop ve Spark ile Büyük Veri Analitiği

Hadoop ve Spark ile Büyük Veri Analitiği: Tanılama, Mimari ve Çözüm Yaklaşımı

Giriş

Büyük veri iş yüklerinin endüstriyel ortamlarda yönetilmesi, yalnızca veri hacmiyle değil operasyonel güvenilirlik, gecikme toleransı ve ölçeklenebilirlik gereksinimleriyle de ilgilidir. Üretim hatlarında, enerji santrallerinde veya IoT tabanlı saha uygulamalarında yük değişimleri saniyeler içinde olur; bu da analiz boru hattının anlık tepki vermesini şart koşar. Operasyonel risk, gecikmiş analiz veya veri kaybı olarak doğrudan üretim kaybına dönüşebilir ve servis seviye anlaşmalarında (SLA) hedef dışı sonuçlar doğurur.

Bir mühendis perspektifinden bakıldığında, Hadoop ve Spark tabanlı çözümlerin sahada uygulanması, belirsizlikleri sistematik olarak okumayı gerektirir: hangi düğümlerde bellek baskısı vardır, hangi ağ segmentleri geçici tıkanıklık üretir, hangi I/O profilleri disk kuyruğunu tetikler. Unutmayın, mimari seçimleriniz saha koşullarına göre test edilmeden varsayımsal kalır; gerçek dünya yükleriyle doğrulama yapmak zorunludur.

Bu yazıda teknik kapsam, ölçülebilir metrikler ve çözüm önerileriyle ilerleyeceğiz. Hedefimiz, geliştirici, mühendis ve araştırmacıların sahada karşılaştığı belirgin problemlere uygulanabilir tanılama adımları sunmak ve Bella Binary yaklaşımının pratik farklılaştırmalarını ortaya koymaktır.

Yazıda kullanılan örnekler Türkiye ve çevresindeki üretim sahalarından edinilmiş gözlemlerle zenginleştirilmiştir; saha içgörüsü ve ölçülebilir iyileşme oranları yerinde belirtilmiştir.

Kavramın Net Çerçevesi

Büyük veri analitiğinde Hadoop genellikle kalıcı veri depolama ve dağıtık dosya erişimi için, Spark ise hızlı bellek-içi işlem ve gerçek zamanlı akış işleme için kullanılır. Bu iki teknoloji birlikte veri alma, temizleme, toplu işlem ve interaktif sorgulama zincirini kurar. Sistem bileşenleri arasında veri replikasyonu, görev planlayıcıları ve ağ topolojisi arasındaki gecikmeler doğrudan iş akışı verimliliğini etkiler.

Ölçülebilir sınırlar şunlardır: görev başına maksimum beklenen gecikme (ör. 200 ms), iş başına hedef throughput (ör. 5.000 TPS), ve veri gecikmesi (end-to-end 30 saniye). Bu sınırlar, SLA ve yerel operasyon parametrelerine göre uyarlanmalıdır. Örneğin, sahada yaptığımız bir gözlemde kampanya analizinde bellek-yetersizliği giderildiğinde sorgu süreleri ortalama %42 azaldı ve TPS 1.8 katına çıktı.

Tanım: Dağıtık veri işleme rutini, iki ana süreçten oluşur: kalıcı depolama yönetimi ve hesaplama işlerinin düşük gecikme ile dağıtımı. Bu süreçler arasındaki bekleme süreleri ve kaynak rekabeti, sistem davranışını belirler. Örneğin, veri yerleşimi stratejisindeki 1%’lik gecikme artışı, yoğun yapılan sorgularda toplam CPU kullanımını %8-12 artırabilir.

Tanım: Gerçek zamanlı akış (stream) ve toplu işleme (batch) arasındaki koordinasyon, I/O ve bellek tahsisine doğrudan etki eder. Bunu izlemek için hem anlık (ms) hem de zaman serisi (% değişim, TPS) metrikleri tutulmalıdır.

Kritik Teknik Davranışlar ve Risk Noktaları

Düğüm bellek baskısı ve GC gecikmeleri

Spark uygulamaları bellek içi çalıştıkları için JVM bellek yönetimi kritik hale gelir. Yetersiz bellek tahsisi veya yanlış GC politikası, uzun stop-the-world duraklamalarına yol açar; bu da batch işlerinin tamamlanma süresini doğrudan uzatır. Tipik gözlem: GC pencereleri 200–600 ms arası sıklıkla ortaya çıkabilir ve toplam iş süresini %15–60 uzatabilir.

Ölçülebilir parametreler: GC duraklama süresi (ms), maksimum heap kullanım yüzdesi (%). Ölçüm yöntemi: JVM GC log korelasyonu ve histogram analizi; zaman damgalarını görev logu ile eşleştirerek gecikme kaynakları belirlenir.

Saha davranışı örneği: Bir üretim hattında gecikmeye bağlı alarm oluşurken, GC spike'ları ile aynı zaman etiketinde CPU kuyruğu artışı tespit edildi.

• Heap sınırlarını uygulamaya göre segmentlere ayırın ve off-heap kullanımını değerlendirin.
• G1 veya ZGC gibi düşük durma süresi hedefleyen GC seçeneklerini test edin.
• Her job için bellek profili çıkarın; bellek gereksinimini ölçün (ör. p95 bellek tüketimi).
• Yetersiz bellek durumları için otomatik yeniden başlatma eşiklerini belirleyin (ör. %90 heap kullanımı).
• Bellek baskısını çoğaltmak için simülasyon yük testleri (load test) yapın ve sonuçları % değişim olarak kaydedin.

Ağ tıkanmaları ve veri yerleştirme gecikmesi

Hadoop veri bloklarının yerleşimi ve Spark shuffle işlemleri yoğun ağ trafiği üretir. Ağ bant genişliği veya paket kaybı, shuffle sürelerini katlayabilir. Ölçülen örnek: shuffle transferlerinde RTT 5 ms'den 50 ms'ye çıktığında görev süresi ortalama %120 artış gösterdi.

Ölçülebilir parametreler: ortalama RTT (ms), paket kayıp oranı (%). Ölçüm yöntemi: packet capture ve flow histogram analizi; shuffle pencereleri sırasında ağ trafiğini segmentlere ayırın.

Saha davranışı örneği: İstanbul'daki bir tesisin kampüs ağı segmentinde, yedekleme trafiği saat 03:00'te yoğunlaşınca veri işleme job'larında p95 gecikme iki katına çıktı.

• Ağ QoS ile kritik veri yollarına öncelik verin ve shuffle-replicas konfigürasyonu optimize edin.
• Veri yerleşimini uygulama mantığına göre (lokaliteyle) yeniden düzenleyin.
• Paket kaybını izlemek için sürekli packet capture ve korelasyon eşiği kurun.
• Bant genişliği yetersizse throttling veya küçük partisyon stratejileri uygulayın.
• Yedekleme/replication pencere zamanlarını yoğun işlem saatlerinden uzaklaştırın.

I/O darboğazları: Disk kuyruğu ve küçük dosya sorunu

HDFS veya yerel disk I/O'su yoğun küçük dosya işlemlerinde performansı düşürür; metadataya bağlı beklemeler artar. Disk kuyruğu uzunlukları 5-20 arasında değiştiğinde I/O gecikmesi 4-6 kat artabilir. Bu durum özellikle ETL işlerinde tamamlanma sürelerini etkiler.

Ölçülebilir parametreler: ortalama disk queue length, IOPS düşüşü (%). Ölçüm yöntemi: sistem metrikleri + histogram; read/write latencies histogram ile izlenir.

Saha davranışı örneği: Bir lojistik firmasının gece ETL penceresinde küçük JSON dosyaları nedeniyle HDFS namenode CPU'su %70'ten %95'e çıktı ve job süreleri %54 uzadı.

• Dosya birleştirme (compaction) stratejisi uygulayın; küçük dosyaları paketleyin.
• SSD ile kritik I/O yollarını hızlandırın ve hot data için tiering kullanın.
• Paralel I/O yerine batch I/O pencereleri planlayın.
• IOPS eşiği belirleyin ve izleme ile otomatik uyarı kurun.
• Veri formatlarını kolon bazlı (Parquet/ORC) kullanarak I/O'yu azaltın.

Kaynak planlama ve görev çakışmaları

Yetersiz kaynak izleme ve yanlış planlama, birbirine çakışan yoğun job'ların aynı anda çalışmasına neden olur. Bu durum CPU kuyruğu ve bellek takası gibi zincirleme etkilere yol açar. Gözlem: aynı fiziksel sunucuda art arda başlatılan iki büyük job, p95 tamamlanma süresini %70 artırdı.

Ölçülebilir parametreler: CPU kullanım zirve yüzdesi (%), job throughput (TPS). Ölçüm yöntemi: log korelasyonu ve zaman eşleme; job başlatma zamanları ile altyapı metriklerini ilişkilendirin.

Saha davranışı örneği: Enerji sektöründe iki analitik job aynı gece çalıştırıldığında I/O kuyruğu nedeniyle her iki iş de SLA dışı kaldı.

• Kaynak kuyruklarını ve öncelikleri (fair scheduler) iş yüküne göre ayarlayın.
• Zamanlanmış pencereler ile ağır job'ları izole edin.
• Dinamik kaynak tahsisi için otomatik ölçeklendirme (autoscaling) kuralları oluşturun.
• Job başlatma bağımlılıklarını açıkça tanımlayıp çakışma kontrolü ekleyin.
• Planlama değişikliklerini yük testi ile doğrulayın ve % amaçlı iyileşme raporlayın.

Teknik Durum Tablosu

Kod	Belirti	Olası Neden	Ölçüm
GC-01	Periyodik uzun sorgu gecikmesi	JVM GC stop-the-world	GC log (ms), iş süreleri (s)
NET-02	Shuffle sırasında artan görev süreleri	Ağ paket kaybı / yüksek RTT	Packet capture, RTT (ms), paket kaybı (%)
IO-03	ETL penceresi tamamlanmıyor	Küçük dosya I/O ve disk kuyruğu	IOPS, disk queue length

Sorunu Sahada Sistematik Daraltma

Saha tespitlerinde önce fiziksel altyapıdan uygulama davranışına kadar sistematik bir sırayla daraltma yapmak en hızlı sonuç verir. Analiz sürecinde ölçümlerin zaman damgası senkronizasyonu kritik önem taşır.

• Adım 1: Altyapı kontrolü — ağ, disk ve sunucu sağlık metriklerini (RTT, IOPS, CPU) alın.
• Adım 2: Yığın korelasyonu — uygulama loglarını altyapı metrikleriyle zaman damgasına göre eşleştirin (log korelasyonu).
• Adım 3: İzole test — belirgin job'ı izole ederek yük testi (load test) ve histogram analizi yapın.
• Adım 4: Kalıcı çözüm — konfigürasyon / kod / donanım değişikliğini aşamalı dağıtın ve % iyileşmeyi raporlayın.

Bu adımlar fiziksel düğümden uygulama katmanına kadar ilerler; örneğin önce switch loglarını kontrol eder, ardından Spark iş planlarını incelersiniz. Bu yaklaşım İstanbul'daki bir saha kurulumunda vakit kaybını %60 azalttı.

Gerçekçi saha senaryosu: Bir üretim veri hattında işlerin sürekli zaman aşımına uğramasıyla karşılaşıldı. İlk yanlış varsayım, disk I/O kaynaklı olduğu yönündeydi; ekip diskleri yükseltti ancak sorun devam etti. Analiz log korelasyonu ve packet capture ile yapıldığında root neden shuffle sırasında paket kaybı olduğu belirlenmiş, ağ üstündeki yedekleme trafiğinin çakıştığı tespit edildi. Kalıcı çözüm olarak QoS uygulanıp shuffle zamanları yeniden planlandı; iş süreleri %47 kısaldı ve başarılı job oranı %93'e yükseldi.

Uzun Vadeli Dayanıklılık ve Ölçüm Disiplini

Sistem dayanıklılığı, tek seferlik düzeltmelerle değil sürekli ölçüm, uyarı ve yineleme disipliniyle sağlanır. Ölçüm kültürü, saha ekiplerinin hızlı müdahalesine olanak verir ve Bella Binary projelerinde öncelikli uygulama alanıdır.

• Her kritik iş için p50/p95/p99 gecikme zaman serilerini tutun ve haftalık eğilim raporu oluşturun.
• Otomatik uyarı eşikleri belirleyin: GC duraklamaları (ms), RTT (ms), IOPS sınırları.
• Değişiklikleri A/B testiyle aşamalı dağıtın ve % iyileşmeyi ölçün.
• Periyodik yük testleri ile gerçek trafik profillerini simüle edin.
• Saha içgörülerini düzenli geribildirim toplantılarına taşıyın ve lokal optimizasyonları belgeleyin.

Doğru ölçüm olmadan optimizasyon, varsayımdan öteye geçemez; saha verisi, karar süreçlerinin merkezinde olmalıdır.

Sonuç

Hadoop ve Spark ile kurulan büyük veri platformlarında başarılı uygulamalar çok katmanlı yaklaşım, ölçülebilir metrikler ve saha testleri gerektirir. Ölçüm ve izleme kültürü, bellek, ağ ve I/O kaynaklarının etkin yönetimiyle birleştiğinde performans ve güvenilirlik artırılabilir. Bella Binary olarak uyguladığımız veri yerleşimi optimizasyonu ve QoS temelli ağ düzenlemeleri, sahadaki pilot projelerde ortalama %35–%60 arası performans kazancı sağladı.

Uzun vadede, operasyonel başarı ancak sürekli izleme, otomatik uyarı ve periyodik yeniden test döngüleriyle mümkün olur. Bella Binary proje ekibi gerçek dünya senaryolarında birlikte çalışmaya hazır; bilgi paylaşımı ve saha testlerine davet ediyoruz. İş birliği için teknik ekiplerinizle bir araya gelmekten memnuniyet duyarız.