Classifying, Evaluating and Advancing Big Data Benchmarks Dissertation zur Erlangung des Doktorgrades der Naturwissenschaften vorgelegt beim Fachbereich 12 Informatik der Johann Wolfgang Goethe-Universität in Frankfurt am Main von Todor Ivanov aus Stara Zagora Frankfurt am Main 2019 (D 30) vom Fachbereich 12 Informatik der Johann Wolfgang Goethe-Universität als Dissertation angenommen. Dekan: Prof. Dr. Andreas Bernig Gutachter: Prof. Dott. -Ing. Roberto V. Zicari Prof. Dr. Carsten Binnig Datum der Disputation: 23.07.2019 Abstract The main contribution of the thesis is in helping to understand which software system parameters mostly affect the performance of Big Data Platforms under realistic workloads. In detail, the main research contributions of the thesis are: 1. Definition of the new concept of heterogeneity for Big Data Architectures (Chapter 2); 2. Investigation of the performance of Big Data systems (e.g. Hadoop) in virtual- ized environments (Section 3.1); 3. Investigation of the performance of NoSQL databases versus Hadoop distribu- tions (Section 3.2); 4. Execution and evaluation of the TPCx-HS benchmark (Section 3.3); 5. Evaluation and comparison of Hive and Spark SQL engines using benchmark queries (Section 3.4); 6. Evaluation of the impact of compression techniques on SQL-on-Hadoop engine performance (Section 3.5); 7. Extensions of the standardized Big Data benchmark BigBench (TPCx-BB) (Section 4.1 and 4.3); 8. Definition of a new benchmark, called ABench (Big Data Architecture Stack Benchmark), that takes into account the heterogeneity of Big Data architectures (Section 4.5). The thesis is an attempt to re-define system benchmarking taking into account the new requirements posed by the Big Data applications. With the explosion of Artificial Intelligence (AI) and new hardware computing power, this is a first step towards a more holistic approach to benchmarking. iii Zusammenfassung Motivation Im Zeitalter von Big Data, beschrieben oft durch die so genannten 3Vs (Volume, Velocity and Variety) [Lan01; ZE+11], ist es unerlässlich, die richtigen Werkzeuge und bewährte Verfahren bei der Entwicklung von Big Data-Anwendungen einzuset- zen. Traditionell werden Benchmarking-Tools und -Methoden verwendet, um ver- schiedene Technologien sowohl in Bezug auf Leistung als auch auf Funktionalität zu vergleichen [Gra92]. Mit der wachsenden Anzahl von Open-Source- und Enterprise- Tools im Big Data-Ecosystem [Gre18] ist der Bedarf an standardisierten Big Data Benchmarks, die einen detailliert Vergleich zwischen diesen neuen Technologien ermöglichen, stark gestiegen [Che+12]. Gleichzeitig deuten die Fortschritte in der Hardwareentwicklung, wie neue Hardwarebeschleuniger und konfigurierbare Kom- ponenten [Ozd18] (z.B. NVMs (Non-Volatile Memory) [Bou+18], GPUs (Graphics Processing Unit) [Shi+18], FPGAs (Field Programmable Gate Array) [VF18; VPK18], TPUs (Tensor Processing Units) [Jou+17] und mehr), auf eine vollständige Überar- beitung des bestehenden Software-Stacks [KFS18] hin. Solche großen Änderungen in den Backend-Systemen betreffen sowohl die Verarbeitungs- als auch die Speicher- schicht. Künstliche Intelligenz [BAM19], Maschinelles Lernen [PAC18] und Deep Learning [Zha+18] nutzen die Vorteile der neuen Hardwarebeschleuniger [KFS18] und werden mit sehr hohem Tempo entwickelt und in Produktion genommen. Um die Vorteile eines neuen Software-Stacks zu optimieren und zu validieren, sind geeignete und standardisierte Big Data-Benchmarks erforderlich, die Maschinelles Lernen beinhalten. Das Ziel dieser Arbeit ist es, den Softwareentwicklern und Systemarchitekten zu helfen die effektivste Big Data-Plattform auszuwählen, die den besten Job für die Klasse der gewählten Big Data-Anwendungen leistet. Die wichtigsten Beiträge decken verschiedene relevante Aspekte ab: vom Verständnis der aktuellen Heraus- forderungen in den Big Data Plattformen über die Auswahl des am besten geeigneten Benchmarks für Stresstests der ausgewählten Big Data Technologien, bis hin zur Abstimmung der relevanten Plattformkomponenten zur effizienteren Verarbeitung und Speicherung von Daten. Vorgehensweise Die Arbeit verwendet eine neuartige Hybride Benchmark-Methodik (Kapitel 3) beste- hend aus einem Mix aus Best Practices und bestehenden Benchmark-Methoden, die in Kombination mit beliebten standardisierten Benchmarks verwendet werden. Ins- v besondere ist der Ansatz von den TPC-Benchmark-Methoden inspiriert, versucht aber zeitgleich flexibel und anpassungsfähig an die neuen Arten von Big Data-Benchmarks zu bleiben weil diese in den meisten Fällen keine systematische Methodik zur Durchführung von Experimenten bieten. Abbildung 0.1 veranschaulicht die vier Hauptphasen der Hybriden Benchmark-Methodik. Jede Phase wird im folgenden erläutert: Fig. 0.1.: Generalisierte Hybride Benchmark-Methodik (Iterativer experimenteller Ansatz), verwendet im Kapitel 3. • Phase 1 - Platform Setup: Im dieser Phase werden alle Hard- und Soft- warekomponenten installiert und konfiguriert. Dazu gehören die Installation und Konfiguration des Betriebssystems, des Netzwerks, der Programmier- Frameworks, z.B. der Java-Umgebung, und des zu testenden Big Data Systems. • Phase 2 - Workload Preparation: Der Benchmark, der zum Stresstest der Komponenten des zugrunde liegenden Big Data Systems verwendet wird, wird installiert und konfiguriert. Gleichzeitig werden die zu testenden Plat- tformkomponenten konfiguriert und für das geplante Benchmarking-Szenario vorbereitet. Alle Workload-Parameter werden definiert und die Testdaten wer- den vom Benchmark-Datengenerator erzeugt. Die erzeugten Daten werden zusammen mit den definierten Parametern als Input zur Ausführung der Arbeit- slast in Phase 3 verwendet. Zusätzlich werden Werkzeuge zur Datenerfassung von Metriken und Ressourcenauslastungsstatistiken eingesetzt. • Phase 3 - Workload-Ausführung: In Phase 3 werden die Benchmark-Exp- erimente durchgeführt. In der Regel wird jedes Experiment drei (oder mehr) Mal wiederholt, um die Repräsentativität der Ergebnisse zu gewährleisten und sicherzustellen, dass es keine Cache-Effekte oder unerwünschte Einflüsse zwischen den aufeinanderfolgenden Testdurchführungen gibt. Die durchschnit- tliche Ausführungszeit zwischen den drei Durchgängen wird zusammen mit der Standardabweichung von den drei Durchgängen als Endwert erfasst. Typischer- weise deutet ein höherer Standardabweichungsprozentsatz auf einen Fehler oder eine Fehlkonfiguration in einer Systemkomponente hin, was zu einer vi insgesamt instabilen Systemleistung führt. Vor jedem Workload-Experiment müssen die Testdaten in ihren Ausgangszustand zurückgesetzt werden, typis- cherweise durch Löschen der Daten und Erzeugen neuer in Phase 2. In einigen Fällen müssen die Plattform-Caches gelöscht werden, um einen konsistenten Zustand in jedem Experiment zu gewährleisten. • Phase 4 - Bewertung: In dieser Phase werden die Benchmark-Ergebnisse validiert, um die Korrektheit des Benchmark zu gewährleisten. Anschließend werden die Benchmark-Metriken (typischerweise Ausführungszeit und Durch- satz) und die Ressourcenauslastungsstatistik (CPU, Netzwerk, I/O und Spei- cher) ausgewertet. Grafische Darstellungen (Diagramme) der verschiedenen Metriken werden für die weitere Ergebnisermittlung und -analyse verwendet. Die vorstehend beschriebene Hybride Benchmark-Methodik kann, wie in Abbildung 0.1 dargestellt, iterativ ausgeführt werden, wobei jede Testausführung mindestens dreimal wiederholt wird (Wechsel zwischen Phase 2 und Phase 4). Neben den obligatorischen drei Testläufen bestehen weitere Gründe, bestimmte Testausführun- gen zu wiederholen. Zum Beispiel durch Variation der Komponentenparameter und Konfigurationen oder durch Bewertung der Plattformleistung unter verschiedenen Datengrößen. Variationen der oben beschriebenen Hybriden Benchmark-Methodik wurden verwendet, um die verschiedenen experimentellen Bewertungen und Vergle- iche im Kapitel 3 durchzuführen. Wichtigste Forschungsbeiträge und Zusammenfassung der Ergebnisse Der wichtigste Beitrag der Dissertation ist es, Methoden und Werkzeuge bere- itzustellen, um zu verstehen welche Softwaresysteme und welche Parameter die Leistung von Big Data Plattformen unter bestimmten Workloads am meisten beein- flussen. Im Detail sind die wichtigsten Forschungsbeiträge der Arbeit wie folgt: 1. Definition des neuen Konzepts der Heterogeneity für Big Data Architek- turen (Kapitel 2) - Dieses Kapitel stellt das Konzept der Heterogeneity in Big Data-Architekturen vor, das als interne Eigenschaft großer Datensysteme ange- sehen werden kann, die sowohl auf vertikale als auch auf generische Workloads abzielen. Es diskutiert, wie dies mit dem bestehenden Hadoop-Ökosystem verknüpft werden kann. 2. Untersuchung der Leistung von Big-Data-Systemen (z.B. Hadoop) in vir- tualisierten Umgebungen (Abschnitt 3.1) - Diese Studie untersucht die Leis- tung typischer Big Data-Anwendungen, die auf einem virtualisierten Hadoop- Cluster mit getrennten Daten- und Berechnungsschichten laufen, im Vergleich zur Standard Hadoop-Cluster-Installation. Die Experimente zeigen, dass ver- schiedene Hadoop-Konfigurationen, die die gleichen virtualisierten Ressourcen verwenden, zu einer unterschiedlichen Leistung führen können. Basierend auf den experimentellen Ergebnissen werden drei wichtige Einflussfaktoren identifiziert. vii 3. Untersuchung der Performance von NoSQL-Datenbanken im Vergleich zu Hadoop Distributionen (Abschnitt 3.2) - Diese experimentelle Arbeit ver- gleicht Hadoop mit einer repräsentativen NoSQL-Datenbank (Cassandra), die eine ähnliche Speicherschnittstelle wie das