Big Data und Hadoop im Enterprise-Umfeld

„Big Data” — ein Begriff, der 2014 auf jeder Konferenz, in jedem Vorstandszimmer und in jedem Verkaufspitch zu hören ist. Aber zwischen dem Marketing-Buzzword und einem realen Enterprise-Einsatz klafft ein Abgrund. Wir haben ihn überquert. Hier ist, was wir gelernt haben.

Warum überhaupt Hadoop?¶

Unser Kunde — eine große tschechische Versicherungsgesellschaft — hatte ein wohlbekanntes Problem: Terabytes an Logs von Webanwendungen, zehn Jahre Transaktionsdaten, Call-Center-Aufzeichnungen und Daten aus Filialen. All das lag in einem Oracle Data Warehouse, das pro Monat mehr kostete als das gesamte IT-Team. Analytische Abfragen liefen stundenlang. Und neue Analysten wollten mit Daten auf eine Weise arbeiten, für die eine relationale Datenbank schlicht nicht gebaut war.

Apache Hadoop bot eine attraktive Alternative: ein verteiltes Dateisystem (HDFS) auf Commodity-Hardware, ein MapReduce-Framework für parallele Verarbeitung und ein wachsendes Ökosystem von Tools darüber. Kosten pro Terabyte Speicher: ein Bruchteil einer Oracle-Lizenz.

Architektur — Wie es in der Praxis aussieht¶

Wir setzten Cloudera CDH 5 auf einem 12-Server-Cluster ein. Nichts Exotisches — Standard-Rack-Server mit 64 GB RAM, 12 SATA-Festplatten und einem Gigabit-Netzwerk. Gesamter Rohspeicher: etwa 500 TB. Nach dreifacher HDFS-Replikation rund 160 TB nutzbarer Speicherplatz.

# Big Data und Hadoop im Enterprise-Umfeld
NameNode (2x HA)  → metadata, HDFS namespace
DataNode (10x)     → block storage
ResourceManager    → YARN, MapReduce job scheduling
Hive Metastore     → SQL-like access to data
Oozie              → workflow orchestration

Die Schlüsselentscheidung war, Hive als primäres Analysetool einzusetzen. Die Analysten konnten SQL — sie wollten und mussten keine Java-MapReduce-Jobs schreiben. HiveQL gab ihnen eine vertraute Schnittstelle über unbekannter Infrastruktur.

ETL-Pipeline — Daten hineinbekommen¶

Die größte Herausforderung war nicht, Hadoop zum Laufen zu bringen. Es war, Daten aus Dutzenden verschiedener Quellen in HDFS in einem sinnvollen Format zu bekommen. Unsere ETL-Pipeline sah so aus:

• Apache Sqoop — Import von Daten aus Oracle in HDFS im Avro-Format
• Flume — Echtzeit-Ingestion von Web-Logs
• Custom Java Jobs — Datentransformation und -bereinigung
• Oozie Coordinator — tägliche und stündliche Workflows

Ein vollständiger Sqoop-Import einer Tabelle mit 200 Millionen Zeilen dauerte 45 Minuten. Ein inkrementeller Import der letzten 24 Stunden weniger als eine Minute. Im Vergleich zum bisherigen ETL in Informatica war das eine Größenordnung besser.

Was hervorragend funktioniert¶

Ad-hoc-Analytik. Ein Analyst schreibt eine HiveQL-Abfrage, sendet sie ab und hat in wenigen Minuten Ergebnisse aus der gesamten Datenhistorie. Kein Warten auf die IT, kein Anfordern neuer Dimensionen im Data Warehouse.

Skalierbarkeit. Mehr Speicherplatz nötig? Fügen Sie einen DataNode hinzu. Hadoop kümmert sich selbst um das Rebalancing. Keine Ausfallzeit, keine Migrationen. Ein Luxus, den wir von Oracle nicht gewohnt waren.

Fehlertoleranz. Ein Server von zwölf fiel aus. Der Cluster lief weiter, als wäre nichts passiert. Die Daten lagen auf zwei weiteren Replikas. Automatische Re-Replikation lief im Hintergrund. Bei Oracle RAC wäre das ein nächtlicher Vorfall gewesen.

Was wehtut¶

Latenz. Hadoop ist nicht für interaktive Abfragen gedacht. Ein MapReduce-Job hat einen Startup-Overhead von 30–60 Sekunden. Selbst ein einfaches SELECT COUNT(*) dauert eine Minute. Für ein Echtzeit-Dashboard nicht geeignet. Wir beobachten Apache Spark und Impala — beide versprechen eine Verbesserung um Größenordnungen, sind aber noch zu jung für den Produktivbetrieb.

Betriebskomplexität. Ein Hadoop-Cluster ist kein „Einrichten und Vergessen”. HDFS-Balancing, YARN-Tuning, Hive-Optimierung, Sicherheit (Kerberos!) — all das erfordert ein erfahrenes Ops-Team. Und davon gibt es in Tschechien noch wenige.

Java-Ökosystem. Alles ist Java. Classpath-Hölle, JAR-Versionierung, Hadoop-Version vs. Hive-Version vs. Sqoop-Version — Dependency Management ist ein Alptraum. Maven hilft nicht, wenn jede Komponente eine andere Version von Guava mitbringt.

Lehren für das Enterprise-Umfeld¶

Nach sechs Monaten Betrieb haben wir mehrere wichtige Erkenntnisse gewonnen:

• Hadoop ersetzt kein Data Warehouse — es ergänzt es. OLTP bleibt in Oracle, Cold Data und Exploration gehen nach Hadoop.
• Investitionen in Data Governance von Anfang an zahlen sich aus. Ohne Katalog und Lineage verliert man sich in Petabytes von Daten.
• Cloudera Manager (oder Ambari) ist eine Notwendigkeit. Manuelle Cluster-Verwaltung ist der Weg in die Hölle.
• Die Schulung des Analyseteams ist die halbe Miete. Technologie ohne Nutzer ist teures Mobiliar.
• Unterschätzen Sie nicht die Netzwerkinfrastruktur. MapReduce Shuffle erzeugt enormen Netzwerkverkehr.

Zahlen, die das Management überzeugt haben¶

TCO für das erste Jahr des Hadoop-Clusters (Hardware + Cloudera-Lizenz + interner Betrieb): etwa ein Drittel der jährlichen Oracle-DWH-Kosten. Bei dreifacher Datenkapazität. Das Analyseteam hat in sechs Monaten mehr Ad-hoc-Analysen durchgeführt als in den beiden Vorjahren zusammen. Der ROI hat sich von selbst berechnet.

Big Data ist mehr als ein Buzzword¶

Hadoop funktioniert im Enterprise-Umfeld — aber es erfordert realistische Erwartungen, Investitionen in Menschen und einen pragmatischen Ansatz bei der Architektur. Ersetzen Sie Oracle nicht aus Prinzip. Nutzen Sie Hadoop dort, wo Oracle an seine Grenzen stößt. Und vor allem: Beginnen Sie mit einem konkreten Geschäftsproblem, nicht mit der Technologie.