Komut satırı araçları bir Hadoop kümesinden 235 kat daha hızlı olabilir (2014)

 (adamdrake.com)
9 puan yazan GN⁺ 2026-01-19 | 2 yorum | WhatsApp'ta paylaş
  • Yaklaşık 1,75 GB satranç maçı verisi, Hadoop yerine komut satırı araçlarıyla işlendiğinde yalnızca 12 saniyede tamamlandı; bu da Hadoop’un 26 dakikasına kıyasla 235 kattan fazla daha hızlı performans gösterdi.
  • grep, sort, uniq, awk, xargs, mawk gibi temel kabuk komutları birleştirilerek akış tabanlı işleme hattı kuruldu ve bellek kullanımı neredeyse sıfırda tutuldu.
  • xargs ile paralel işleme ve mawk optimizasyonu sayesinde CPU çekirdeklerinin kullanım oranı artırılırken IO darboğazı en aza indirildi.
  • Aynı veri kümesini Hadoop kümesiyle (7 adet c1.medium instance) işlemeye kıyasla maliyet ve bakım yükü belirgin biçimde daha düşüktü.
  • Tek bir makinede de verimli veri analizi yapılabileceğini gösterirken, gereksiz Big Data araçları kullanımına karşı bir uyarı sunuyor.

Giriş: Hadoop’tan daha hızlı komut satırı işleme

  • Amazon EMR ve mrjob ile yaklaşık 2 milyon satranç maçını analiz eden bir örnekten yola çıkılarak, aynı veri komut satırı tabanlı akış işleme ile yeniden üretildi.
    • Hadoop kümesinde (7 adet c1.medium) 26 dakika sürdü, 1.14MB/sec işlem hızı elde edildi.
    • Yerel dizüstü bilgisayarda ise 12 saniyede tamamlandı ve 270MB/sec işlem hızı görüldü.
  • Basit sonuç toplama işleri için kabuk boru hatlarının Hadoop’tan çok daha verimli olduğu gösterildi.
  • Kabuk komutları birleştirilerek Storm’a benzer paralel akış işleme yapısı tek makinede kurulabildi.

Veri yapısı ve hazırlık

  • Veri, PGN (Portable Game Notation) biçimindeki satranç maçı kayıtlarından oluşuyor ve her oyunun sonucu "Result" satırında belirtiliyor.
    • "1-0" beyazın galibiyeti, "0-1" siyahın galibiyeti, "1/2-1/2" ise beraberlik anlamına geliyor.
  • GitHub’daki rozim/ChessData deposundan yaklaşık 3.46GB veri kümesi alındı.
    • Bu, Tom Hayden’ın deneyinde kullandığı 1,75 GB verinin yaklaşık iki katı büyüklüğünde.

Temel boru hattının kurulması

  • IO sınırını ölçmek için cat *.pgn > /dev/null çalıştırıldığında yaklaşık 13 saniye (272MB/sec) sürdü.
  • Temel analiz boru hattı: 
    cat *.pgn | grep "Result" | sort | uniq -c
    • Çalışma süresi yaklaşık 70 saniyeydi; bu da Hadoop’a göre yaklaşık 47 kat daha hızlıydı.
  • sort | uniq yerine AWK kullanılarak sonuçlar doğrudan toplandı.
    • Çalışma süresi 65 saniyeydi ve bellek kullanımı neredeyse sıfırdı.
    • Darboğaz, tek bir CPU çekirdeğini kullanan grep idi.

Paralelleştirme ve optimizasyon

  • xargs kullanılarak grep paralelleştirildi. 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
    • Çalışma süresi 38 saniyeye düştü, yaklaşık 77 kat hızlanma sağlandı.
  • grep kaldırılıp yalnızca AWK ile filtreleme yapılarak aşamalar sadeleştirildi.
    • Her dosyanın sonucunu birleştirmek için çift AWK boru hattı kuruldu.
    • Çalışma süresi 18 saniye oldu; yaklaşık 174 kat daha hızlıydı.
  • mawk ile değiştirildiğinde ek optimizasyon sağlandı. 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
    • Çalışma süresi 12 saniyeye indi, Hadoop’a kıyasla 235 kat daha hızlı oldu ve işlem hızı 270MB/sec seviyesine ulaştı.

Sonuç: Basitliğin verimliliği

  • Büyük ölçekli dağıtık işleme gerçekten gerekli değilse, tek makinedeki kabuk araçlarının birleşimi daha hızlı ve daha ekonomik olabilir.
  • Hadoop, çoğu zaman ilişkisel veritabanı ya da basit betiklerle yeterince çözülebilecek işler için bile gereğinden fazla kullanılıyor.
  • Komut satırı tabanlı akış analizi, performans, uygulama maliyeti ve bakım kolaylığı açısından güçlü bir alternatif sunuyor.

İlgili okumalar

2 yorum

 
dongho42 2026-01-20

Eskiden Taco Bell programlama diye bir ifade vardı; sanki benzer bir felsefe gibi.
 
GN⁺ 2026-01-19
Hacker News yorumları

  • Bu yazının 2014'ten olması en üzücü tarafı.
    Şimdi Airflow, dbt, Snowflake gibi daha da fazla soyutlama katmanı var ve fiilen tamamen RAM'e sığan veri kümelerinin üstüne bile bunlar bindiriliyor.
    Startup'lar günde 10GB bile etmeyen logları işlemek için dağıtık kümelere ayda 5 bin dolar yakıyor. Sebebi de şu: “Modern Data Stack” kullanırsan terfi alıyorsun, ama bash scripti ile çözersen “ölçeklenmez” diye küçümseniyorsun. Verimlilikle teşvikler tamamen birbirinden kopmuş durumda

    • Son görüşmelerimde sürekli “ölçekleme problemi” diye anlatıyorlardı ama gerçekte çoğu tek bir makineye rahatça sığıyordu.
      Günde 1GB JSON ingest eden bir örnek bile vardı; ben de “tek makine yeter” diye açıklayınca “teknik olarak doğru ama duymak istediğimiz cevap bu değil” deyip beni elemişlerdi.
      Günümüz makinelerinde TB düzeyinde RAM ve yüzlerce çekirdek var. Tek bir makine zaten inanılmaz büyük
    • Bu sadece terfi meselesi değil, aynı zamanda işe alım yapısının da sorunu.
      DevOps geçmişi olan insanları alırken gösterişli framework deneyimini öne çıkarınca, onlar da şirkete gelip aynı şeyi tekrar ediyor.
      Karşı çıkan kimse olmayınca, masaüstü bir bilgisayarın tek başına halledebileceği işler gereksiz yere karmaşıklaşıyor
    • Son 20 yıldır “havalı görünen teknoloji” yerine “doğru teknoloji” kullandım, sonunda da işten çıkarıldım.
      Özgeçmişimde neredeyse hiç en yeni framework olmadığı için bir yılı aşkın süredir iş arıyorum ve kendimi aptal gibi hissetmeye başladım
    • Şirketlerde benzerini ben de görüyorum. Günde birkaç GB veriyi bir sürü sistemden geçirirken, eskiden Python scriptiyle bir haftada biten işler şimdi aylar sürüyor ve sık sık bozuluyor
    • Artık 128GB RAM'li dizüstü bilgisayarlar bile yaygın, sunucular ise çok daha büyük.
      2014'te 4GB olağandı ama şimdi SSD üzerinden streaming hızları da çok arttı; yerel SSD'den okumak bazen kümeden daha iyi olabiliyor

  • Yazının yazarı benim!
    Eski yazının hâlâ işe yaradığını görmek sevindirici.
    Durumun daha da kötüleştiği görüşüne katılıyorum ama bir yandan da microservices saplantısından uzaklaşan bir hareket görmek umut verici.
    Performansı iyileştirmek için uğraşan herkese destek olsun. Hâlâ umut var

    • Adam, teşekkürler!
      Yazıyı birkaç kez yeniden okudum ve ilham alıp Waters-Series'i JavaScript'e port ederek stream pipeline'ı kurdum

  • Bugün sektörde Spark ya da dağıtık araçların veri mühendisliğinin tek doğru cevabı olduğu yönünde aşırı güçlü bir algı var.
    Bu, web geliştirmede SPA framework'lerinin gereğinden fazla kullanılmasına benziyor.
    Benim tavsiyem şu:

    • Yöneticiler belirli bir teknoloji (Spark, React) dayatmasın; işi problem çözme becerisi olan mühendislere bıraksın
    • Teknik liderler dürüstçe “bizim pipeline 20GB'a kadar işleyebiliyor, daha büyürse X/Y/Z ile ölçeklemeyi planlıyoruz” diyebilsin
      Yöneticilerin duymak istediği şey “her şey sonsuza kadar ölçeklenir” değil, “sistem güvenilir şekilde çalışıyor” güvencesi
    • Şirketlerin çoğu küçük ölçekli veri ile çalışıyor.
      Veri boyutu güç yasasına uyduğu için petabayt ölçeğinde veriyle çalışan mühendis sayısı çok az.
      Ama maaş artışı için bu tür deneyimleri CV'ye koymaya çalışınca aşırı mühendislik ortaya çıkıyor
    • Bir zamanlar ünlü bir unicorn'da çalışırken yöneticim “gelecek çeyrekte Spark kullanmamız gerekiyor” demişti.
      Sebebini sorunca cevap “öyle yapmamız gerekiyor” oldu. Muhtemelen özgeçmişe yazmak için ya da birilerinin politik hesabı içindi

  • Yazıyla ilgili tarihsel bir not:
    mrjob adlı araç, Hadoop olmadan yerel modda da çalışabiliyordu.
    Küçük veri kümelerinde kümeden çok daha hızlıydı. Özellikle AWS EMR gibi geçici kümelerden bile daha çabuk bitiyordu.
    Yine de yazarın yaklaşımı muhtemelen bundan da verimliydi.
    MapReduce büyük ölçekte genişlemeyi kolaylaştırıyordu ama küçük veride verimsiz kısıtlar da getiriyordu.
    2010'ların başında mrjob ile petabayt ölçeğinde veri işledim ama bugün neredeyse hiç kullanılmıyor

  • Veri mühendisi olarak çalışırken Bash/Python scriptlerini C# ile yeniden yazarak JSON işleme hızını 1GB/s'ye kadar çıkarmıştım.
    Sadece streaming parse gibi optimizasyonlar bile büyük fark yarattı.
    O yüzden merak ediyorum — hangi veri boyutundan sonra kümeleme gerçekten anlamlı olmaya başlıyor?

    • Tersine, 15 yıl önce karmaşık bir C# sistemini bash + Python ile değiştirip çok daha hızlı hale getirmiştim.
      Bana göre bir iş bir günden uzun sürüyorsa dağıtık işlemeyi düşünmeye değer
    • Bir zamanlar PyCon panelinde ünlü bir veri bilimci “Excel, Pandas'tan daha iyidir” demişti.
      Veri büyükse örnekleme yapıp Excel'de analiz ettiğini söylemişti. Bugünlerde LLM sayesinde basit Python/Bash scriptleri yazmak da kolaylaştı
    • İşleme süresinin dışında, yerel diske sığmayan veri de başka bir ölçüt.
      S3 gibi object storage üzerinden doğrudan okuma yazma yapılabiliyor ve bugün 100GB/s hızlar bile mümkün
    • Şu yorumda bahsedilen satranç veri kümesi yaklaşık 14TB.
      Diske sığar ama sıradan bir dizüstü için imkânsız bir boyut
    • JSON'u streaming olarak parse etmenin nasıl yapıldığını merak ediyorum. Çoğu parser sözdizimi doğrulaması için her şeyi baştan sona okumak zorunda; bunu nasıl çözdüklerini öğrenmek isterim

  • Verinin “büyüklüğü”, ne yapmaya çalıştığınıza göre değişir.
    Örneğin ameliyat verilerinde basit istatistikler için bash yeterli olabilir ama doktor deneyimiyle başarı oranı arasındaki korelasyonu hesaplamak istediğinizde karmaşıklık hızla artar.
    Bu yüzden şirket açısından “biz Spark kullanıyoruz” demek, “her soru için özel motor kuruyoruz” demekten çok daha kolay

    • Ama tek başına SQLite bile 50GB ile 2TB arasındaki veriyi işleyebilir.
      Bahsedilen bütün sorunlar tek bir sunucuda basit araçlarla çözülebilir

  • Bu yazı daha önce HN'de birkaç kez paylaşılmıştı.
    2018 versiyonu, 2022 versiyonu, 2024 versiyonu aynı gönderici tarafından paylaşılmıştı

  • Eski Shakti web sitesindeki tanıtım cümlesini hatırlattı:
    “1K satır: Excel / 1M satır: Pandas / 1B satır: Shakti / 1T satır: Only Shakti”
    Kaynak

  • Pek çok geliştirici Windows ortamında yetiştiği için CLI araçlarına alışık değil.
    Oysa CLI; örtük döngüler, alanları otomatik ayırma, regex'leri paralel uygulama gibi güçlü özellikler sunuyor.
    Bu sayede hızlıca ad-hoc çözümler üretilebiliyor ve büyük sistemlere geçmeden önce iyi bir başlangıç noktası oluyor

  • Satranç verisini çok daha büyütüp benchmark'ı yeniden yapmak ilginç olabilir diye düşünüyorum.
    Bugün Lichess veri kümesi yaklaşık 7B oyun, 2.34TB sıkıştırılmış (14TB sıkıştırılmamış).
    Bu ölçekte Hadoop kazanabilir mi diye merak ediyorum

    • Bir sunucuya birkaç hızlı SSD takılırsa yine de EMR+S3'ten daha hızlı olabilir gibi geliyor.
      Ama bunun karşılığında özel sunucu yönetimi gerekiyor.
      EMR, veriye seyrek erişildiğinde (günde 1-10 kez) paralel işleme için tasarlanmış bir model
    • Sıkıştırılmış veri yerel SSD'ye rahatça sığar ve streaming olarak açmak da mümkün
    • Bu veriyle ne hesaplanacağını da merak ediyorum. NVL72 üzerinde denemek eğlenceli olabilir