Big-Data-Analysen auf Bare-Metal-Servern

Hadoop oder Spark auf einer Cloud-Infrastruktur zu nutzen, macht Sinn, wenn du Prototypen entwickelst. Wenn du aber täglich Terabytes an Produktionsdaten verarbeitest, sieht die Sache finanziell anders aus. Cloud-Spot-Instanzen werden mitten im Job unterbrochen. Verwaltete EMR-Cluster werden sekundengenau abgerechnet, aber bei anhaltenden Analyseaufgaben summieren sich die Kosten auf Hunderte oder Tausende pro Monat.

Dedizierte Bare-Metal-Server bieten für Big-Data-Workloads etwas, was Cloud-VMs nicht garantieren können: direkten Hardwarezugriff ohne Hypervisor-Overhead, vorhersehbaren E/A-Durchsatz von NVMe und feste monatliche Kosten, die nicht in die Höhe schnellen, wenn deine ETL-Jobs länger als erwartet laufen.

Was macht Bare Metal für Big Data so besonders?

Die Hypervisor-Steuer ist echt. Cloud-VMs, die auf gemeinsam genutzter physischer Hardware laufen, haben mit CPU-Diebstahlzeit, Speicherballondruck von benachbarten Mietern und Netzwerk-E/A-Schwankungen zu kämpfen, die auf API-Ebene nicht sichtbar sind, sich aber deutlich in der Schwankungsbreite der Spark-Auftragsdauer zeigen. Eine Spark-Phase, die am Montag in 4 Minuten abgeschlossen ist, kann am Donnerstag ohne ersichtlichen Grund 7 Minuten dauern.

Auf Bare-Metal-Systemen sind die CPU, der Speicherbus und NVMe komplett für deine Workload da. Spark-Shuffle-Operationen, die einen anhaltend hohen Durchsatz beim Lesen und Schreiben auf den lokalen Speicher brauchen, laufen mit der vollen Nenngeschwindigkeit der Laufwerke, statt sich durch eine Virtualisierungsschicht kämpfen zu müssen.

Dann ist da noch die Frage nach dem Speicher. Die meisten verwalteten Cloud-Instanztypen mit 192 GB RAM kosten zwischen 800 und 1.400 US-Dollar pro Monat. Der Extreme Dedicated ServerInMotion Hosting bietet 192 GB DDR5 ECC RAM zusammen mit einem AMD EPYC 4545P-Prozessor für 349,99 US-Dollar pro Monat in einem verwalteten Rechenzentrum.

Hadoop auf dedizierter Hardware

Hadoop mit einem Knoten vs. Hadoop mit mehreren Knoten

Multi-Node-HDFS-Cluster sind immer noch die beste Lösung für Datensätze, die echt die Kapazität eines einzelnen Servers sprengen, normalerweise über 50–100 TB Rohdaten. Für Analyseteams, die mit Datensätzen im Bereich von 1–20 TB arbeiten, reicht ein einzelner dedizierter Server mit viel Speicher, auf dem HDFS im pseudoverteilten Modus läuft, oder, was praktischer ist, Spark direkt auf lokalem NVMe läuft. So vermeidet man den Replikationsaufwand und die Netzwerk-Shuffle-Kosten eines verteilten Clusters.

Die zwei 3,84 TB NVMe auf der Extreme-Stufe von InMotion bieten dir 7,68 TB Rohspeicherplatz, wobei RAID 1 (mdadm) 3,84 TB fehlertoleranten nutzbaren Speicherplatz bereitstellt. Für temporären Speicherplatz und zwischengespeicherte Daten kannst du das zweite Laufwerk außerhalb von RAID als dediziertes Spark-Scratch-Volume konfigurieren, wodurch deine permanenten Daten geschützt bleiben und Schreibkonflikte bei intensiven Aufgaben vermieden werden.

HDFS-Konfiguration für Einsätze mit einem einzigen Server

Wenn du HDFS auf einem einzelnen Rechner laufen lässt, musst du den Replikationsfaktor auf 1 setzen. Dadurch sparst du dir den dreifachen Speicheraufwand der normalen HDFS-Replikation, was okay ist, wenn du RAID zum Schutz der zugrunde liegenden Laufwerke hast. Wichtige Konfigurationsparameter, die du auf einem 192-GB-System anpassen solltest:

• Stell dfs.datanode.data.dir auf den NVMe ein, um schnellen Blockspeicher zu kriegen.
• Stell dfs.blocksize auf 256 MB oder 512 MB für große Analysedateien ein, um den Metadaten-Overhead von NameNode zu reduzieren.
• Stell mapreduce.task.io.sort.mb auf 512 MB pro Mapper ein, um die Häufigkeit von Überläufen auf Hardware mit viel Speicher zu reduzieren.
• Weise 120–140 GB der verfügbaren 192 GB der YARN-Ressourcenverwaltung zu und lass dabei Platz für das Betriebssystem und den NameNode.

Apache Spark: Wo Bare Metal sich am meisten lohnt

Speicherzuweisung auf 192-GB-Systemen

Die Leistung von Spark hängt echt stark vom Arbeitsspeicher ab. Der Teil eines Jobs, der auf die Festplatte ausgelagert wird, anstatt im Arbeitsspeicher fertiggestellt zu werden, entscheidet, ob ein Job 3 Minuten oder 30 Minuten dauert. Auf Cloud-Instanzen mit 32 oder 64 GB RAM ist das Auslagern ganz normal. Auf einem System mit 192 GB werden die meisten analytischen Workloads komplett im Arbeitsspeicher erledigt.

Eine praktische Zuweisung auf einem 192 GB Extreme-Server mit 16 Kernen:

• Spark-Treiber-Speicher: 8 GB (reicht für die meisten analytischen Aufgaben aus)
• Spark-Executor-Speicher: 160 GB verteilt auf die Executors (24 GB bleiben für das Betriebssystem, den Shuffle-Dienst und Overhead übrig)
• spark.memory.fraction: 0 ,8 (belegt 80 % des Executor-Heaps für Ausführung und Speicherspeicher)
• Executor-Kerne: 4 Kerne pro Executor, 4 Executors = insgesamt 16 genutzte Kerne

Mit dieser Konfiguration kann ein einzelner Executor einen 100 GB großen DataFrame im Speicher halten, ohne dass Daten ausgelagert werden müssen. Das verändert das Leistungsprofil von Multi-Pass-Algorithmen wie iterativem maschinellem Lernen und Graphenanalyse.

NVMe -Leistung

Die Sort-Merge-Join- und Wide-Transformationen von Spark schreiben Shuffle-Daten auf die lokale Festplatte. Auf SATA-SSDs erreichen Shuffle-Schreibvorgänge Spitzenwerte von etwa 500 MB/s. NVMe schaffen einen sequenziellen Schreibdurchsatz von 3.000 bis 5.000 MB/s. Bei einem Job, der 200 GB Shuffle-Daten schreibt, beträgt der Unterschied etwa 40 Sekunden auf NVMe 6 Minuten auf SATA. Dieser Unterschied summiert sich bei Dutzenden von täglichen Jobs.

Stell spark.local.dir so ein, dass es auf den NVMe für Shuffle-Schreibvorgänge zeigt. Wenn du ein zweites NVMe außerhalb von RAID hast, nutze es komplett für das Spark-Shuffle-Verzeichnis, um Konflikte zwischen Shuffle-E/A und Datenlesungen vom primären Volume zu vermeiden.

Echtzeit-Analysen: Kafka und Spark Streaming

Spark Structured Streaming, das Daten aus Kafka nutzt, braucht eine Mikro-Batch-Verarbeitung mit geringer Latenz. In einer Cloud-Infrastruktur kann die Kombination aus Netzwerklatenz zu einem verwalteten Kafka-Cluster und VM-CPU-Jitter die Mikro-Batch-Verarbeitungszeiten selbst bei geringem Durchsatz auf über 5 Sekunden erhöhen. Wenn man Kafka und Spark auf demselben Bare-Metal-Server oder auf gemeinsam genutzten dedizierten Servern laufen lässt, wird die Netzwerkvariable eliminiert.

Ein AMD EPYC-System mit 16 Kernen kann über Kafka 50.000 bis 200.000 Nachrichten pro Sekunde verarbeiten, ohne die CPU zu überlasten. So bleibt genug Spielraum für Spark Structured Streaming-Nutzer, um parallel zu verarbeiten und zu aggregieren.

Säulenspeicher und NVMe

Parquet- und ORC-Dateien profitieren echt stark von NVMe. Beide Formate nutzen Prädikat-Pushdown und Spaltenbeschneidung, was bedeutet, dass eine Abfrage, die 5 % der Spalten in einem 1-TB-Datensatz liest, vielleicht nur 50 GB tatsächliche E/A-Leistung braucht. Auf NVMe mit 5 GB/s sequentieller Lesegeschwindigkeit dauert dieser 50-GB-Scan nur etwa 10 Sekunden. Auf einem mit 1 Gbit/s verbundenen Cloud-Volume mit einer Begrenzung von 125 MB/s dauert derselbe Scan fast 7 Minuten.

Für Analyse-Workloads, die auf Parquet oder ORC basieren, ist NVMe auf Bare-Metal-Servern kein kleines Upgrade. Es verändert, welche Abfragen interaktiv und welche im Batch-Modus laufen.

Kostenvergleich: Bare Metal vs. Cloud für Big Data

Konfiguration	Monatliche Kosten	RAM	Lagerung	Anmerkungen
AWS EMR (r5.4xlarge x2 Knoten)	~980 $/Monat	Insgesamt 256 GB	EBS (zusätzliche Kosten)	Spotpreise bringen das Risiko von Unterbrechungen mit sich.
AWS EC2 r6i.4xlarge (dediziert)	~780 $/Monat	128 GB	EBS (zusätzliche Kosten)	Kein Management dabei
InMotion Extreme Dedicated	349,99 $ pro Monat	192 GB DDR5 ECC	3,84 TB NVMe RAID 1)	Fixkosten
InMotion Advanced Dedicated	149,99 $ pro Monat	64GB DDR4	1,92 TB NVMe RAID 1)	Geeignet für Datensätze unter 500 GB im Arbeitsspeicher

Der Kostenvorteil ist echt groß, aber noch wichtiger ist die Vorhersehbarkeit. ETL-Jobs, die länger laufen als erwartet, sorgen nicht für überraschende Rechnungen auf Bare-Metal-Systemen.

Wann sollte man mehrere Server statt eines Servers mit viel Speicher nutzen?

Ein leistungsstarker Server kann die meisten Analyseaufgaben mit weniger als 3 TB aktiver Daten erledigen. Hier brauchst du eine Architektur mit mehreren Servern:

• Die Größe des Rohdatensatzes ist echt größer als NVMe eines einzelnen Servers (über 7 TB Quelldaten).
• Die Anzahl der gleichzeitigen analytischen Nutzer ist höher, als ein einzelner Spark-Server ohne Warteschlange verarbeiten kann.
• Hohe Verfügbarkeitsanforderungen bedeuten, dass ein einzelner Server ein inakzeptables Ausfallrisiko für Produktionspipelines darstellt.
• Die Trennung der Aufgaben zwischen Kafka-Erfassung, Spark-Verarbeitung und Serving-Ebenen braucht eine physische Isolierung.

Für die meisten Analyseteams im mittleren Marktsegment reicht ein einziger Extreme Dedicated Server aus, um die Arbeitslast zu bewältigen, und bietet sogar noch Platz für Wachstum. Wenn du einen zweiten Server brauchst, kann dir das APS-Team von InMotion dabei helfen, die Multi-Node-Konfiguration zu entwerfen.

Verwaltete Infrastruktur für Datenverarbeitungsteams

Data-Engineering-Teams sollten Pipelines schreiben und nicht um 3 Uhr morgens auf Warnmeldungen über Server-Speicherplatz oder OOM-Kills reagieren müssen. Das Advanced Product Support-Team von InMotion kümmert sich um Probleme auf Betriebssystemebene auf dedizierten Servern, was bedeutet, dass dein Team eine Warnmeldung und eine Lösung erhält und nicht ein Ticket zur Bearbeitung.

Premier Care bietet 500 GB automatisierten Backup-Speicherplatz für Pipeline-Konfigurationen, Daten-Snapshots und Spark-Anwendungs-Jars sowie Monarx-Malware-Schutz für die Serverumgebung. Für Datenteams, die geschäftlich sensible Daten speichern, ist dieser Schutz echt wichtig.

Die in Premier Care enthaltene einstündige monatliche Beratung durch InMotion Solutions lohnt sich besonders für die Optimierung von Spark und Hadoop. Konfigurationsfehler wie zu kleine Shuffle-Verzeichnisse oder falsch konfigurierte YARN-Speichergrenzen kommen häufig vor und sind in Bezug auf die Arbeitszeit kostspielig.

Erste Schritte

Der richtige erste Schritt ist, die Dauer deiner aktuellen Jobs auf der Cloud-Infrastruktur zu messen und dann die gleichen Jobs auf einer InMotion Extreme-Testkonfiguration laufen zu lassen. Der Leistungsunterschied bei shuffle-lastigen Spark-Jobs macht die Migration normalerweise schon im ersten Monat lohnenswert.

Für Teams, die täglich mehrere Spark-Jobs mit Datensätzen von über 100 GB laufen lassen, sind die monatlichen Einsparungen gegenüber einer vergleichbaren Cloud-Infrastruktur in der Regel um ein Vielfaches höher als die Serverkosten. Die Leistungskonstanz ist schwerer zu beziffern, zeigt sich aber jeden Tag in der Zuverlässigkeit der Pipeline-SLA.