Kommandozeilen-Tools können 235-mal schneller sein als ein Hadoop-Cluster (2014)

• Die Verarbeitung von rund 1,75 GB Schachpartie-Daten mit Kommandozeilen-Tools statt mit Hadoop war in nur 12 Sekunden abgeschlossen und damit mehr als 235-mal schneller als Hadoop mit 26 Minuten
• Durch die Kombination grundlegender Shell-Befehle wie grep, sort, uniq, awk, xargs, mawk wurde eine Streaming-Verarbeitungspipeline aufgebaut, die den Speicherverbrauch nahezu bei null hielt
• Durch Parallelisierung mit xargs und Optimierung mit mawk wurde die CPU-Kernauslastung erhöht und IO-Engpässe minimiert
• Im Vergleich zur Verarbeitung desselben Datensatzes auf einem Hadoop-Cluster (7 c1.medium-Instanzen) lagen Kosten und Wartungsaufwand deutlich niedriger
• Der Beitrag zeigt, dass auch auf einer einzelnen Maschine effiziente Datenanalyse möglich ist, und mahnt zu mehr Vorsicht beim unnötigen Einsatz von Big-Data-Tools

---

Einleitung: Schnellere Kommandozeilen-Verarbeitung als Hadoop

• Nach einem Beispiel zur Analyse von rund 2 Millionen Schachpartien mit Amazon EMR und mrjob wurde dieselbe Datenanalyse mit Streaming-Verarbeitung auf Kommandozeilenbasis nachgebaut
  • Auf einem Hadoop-Cluster (7 c1.medium) dauerte es 26 Minuten, Durchsatz 1,14 MB/sec
  • Auf einem lokalen Notebook war die Verarbeitung in 12 Sekunden abgeschlossen, Durchsatz 270 MB/sec
• Es wird gezeigt, dass einfache Aggregationsaufgaben mit einer Shell-Pipeline wesentlich effizienter als mit Hadoop ausgeführt werden können
• Durch die Kombination von Shell-Befehlen lässt sich auf einer einzelnen Maschine eine parallele Stream-Verarbeitungsstruktur ähnlich Storm umsetzen

Datenstruktur und Vorbereitung

• Die Daten liegen im Format PGN (Portable Game Notation) vor; das Ergebnis jeder Partie steht in der Zeile "Result"
  • "1-0" bedeutet Sieg für Weiß, "0-1" Sieg für Schwarz, "1/2-1/2" ein Unentschieden
• Aus dem GitHub-Repository rozim/ChessData wurde ein Datensatz von rund 3,46 GB bezogen
  • Etwa doppelt so groß wie die Versuchsdaten von Tom Hayden (1,75 GB)

Aufbau der Basispipeline

• Zur Messung der IO-Grenze wurde cat *.pgn > /dev/null ausgeführt; das dauerte rund 13 Sekunden (272 MB/sec)
• Basispipeline für die Analyse:

  cat *.pgn | grep "Result" | sort | uniq -c
  

  • Laufzeit rund 70 Sekunden, etwa 47-mal schneller als Hadoop
• AWK wurde anstelle von sort | uniq verwendet, um die Ergebnisse direkt zu aggregieren
  • Laufzeit 65 Sekunden, nahezu kein Speicherverbrauch
  • grep belegte einen einzelnen CPU-Kern und wurde zum Engpass

Parallelisierung und Optimierung

• xargs wurde zur Parallelisierung von grep genutzt

  find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
  

  • Laufzeit 38 Sekunden, etwa 77-mal schneller
• grep wurde entfernt und der Ablauf auf reines Filtern mit AWK vereinfacht
  • Zur Zusammenführung der Ergebnisse je Datei wurde eine doppelte AWK-Pipeline aufgebaut
  • Laufzeit 18 Sekunden, etwa 174-mal schneller
• Durch den Wechsel zu mawk wurde weiter optimiert

  find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
  

  • Laufzeit 12 Sekunden, 235-mal schneller als Hadoop, Durchsatz 270 MB/sec

Fazit: Die Effizienz der Einfachheit

• Außer in Fällen, in denen wirklich groß angelegte verteilte Verarbeitung nötig ist, ist die Kombination von Shell-Tools auf einer einzelnen Maschine schneller und wirtschaftlicher
• Hadoop wird oft übermäßig eingesetzt, obwohl für viele Aufgaben relationale Datenbanken oder einfache Skripte ausreichen
• Streaming-Analyse auf Kommandozeilenbasis ist eine starke Alternative in Bezug auf Leistung, Implementierungskosten und Wartbarkeit