Hadoop-Migration in die Cloud: 2-fache Speicherkapazität und geringere Betriebskosten

Yimian ist ein führender Anbieter von datengetriebenen Analysen, der auf künstliche Intelligenz spezialisiert ist und sich auf digitale Handelsdaten konzentriert. Wir bieten Echtzeit-Einblicke in Geschäftsstrategie, Produktentwicklung und digitale Handelsprozesse. Viele unserer Kunden sind Branchenführer in den Bereichen Körperpflege, Make-up, Lebensmittel und Getränke, Tierbedarf und Automobil, wie Procter and Gamble, Unilever und Mars.

Unser ursprüngliches Technologie-Architektur war ein Big-Data-Cluster, der mit CDH (Cloudera Distributed Hadoop) in einem eigenen Rechenzentrum aufgebaut wurde. Mit wachsendem Geschäft stieg das Datenvolumen stark an.

Um Herausforderungen wie lange Skalierungszyklen, unterschiedliche Rechen- und Speicherressourcen und hohe Wartungskosten zu bewältigen, entschieden wir uns für eine Transformation unserer Datenarchitektur und die Migration in die Cloud, indem wir einen Ansatz der Trennung von Speicher und Rechenleistung verfolgten. Nach sorgfältiger Bewertung entschieden wir uns für Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Alibaba Cloud Object Storage Service (OSS).

Momentan haben wir mit JuiceFS ein Architekturmodell mit getrenntem Speicher und Rechenleistung implementiert und unser Gesamtspeichervolumen verdoppelt. Insbesondere haben wir keine signifikanten Leistungseinbußen festgestellt, und unsere Betriebskosten wurden erheblich reduziert.

In diesem Artikel werden wir unser Architekturdesign zur Migration von Hadoop in die Cloud teilen, warum wir JuiceFS+EMR+OSS gewählt haben und wie wir von der neuen Architektur profitieren. Unser Ziel ist es, wertvolle Einblicke für diejenigen zu bieten, die ähnliche Herausforderungen gegenüberstehen.

Unsere alte Architektur und Herausforderungen

Um unseren wachsenden Anwendungsbedürfnissen gerecht zu werden, haben wir Daten von Hunderten von großen Websites gefiltert, wobei die aktuelle Zahl über 500 liegt. Im Laufe der Zeit haben wir beträchtliche Mengen an Roh-, Zwischen- und Ergebnisdaten angesammelt. Da wir unsere Website-Crawls und Kundenbasis weiter ausgedehnt haben, stieg unser Datenvolumen schnell an. Daher haben wir uns entschieden, unsere Hardware zu skalieren, um den wachsenden Anforderungen gerecht zu werden.

Die ursprüngliche Architektur

Die folgende Abbildung zeigt unsere vorherige Architektur, die ein in einem Rechenzentrum bereitgestelltes CDH-basiertes Big-Data-Cluster umfasste:

• Die wichtigsten Komponenten waren Hive, Spark und HDFS.
• Mehrere Datenproduktionssysteme, wobei Kafka eines von ihnen war, speisten Daten in den Cluster.
• Wir verwendeten weitere Speichersysteme wie TiDB, HBase und MySQL neben Kafka.

Original architecture at Yimian

Daten flossen von den oberen Anwendungssystemen und Datenerfassungssystemen, wo sie in Kafka geschrieben wurden. Wir setzten ein Kafka Connect-Cluster ein, um die Daten in HDFS zu synchronisieren.

Auf dieser Architektur aufbauend haben wir eine benutzerdefinierte Datenentwicklungsplattform namens OneWork entwickelt, um verschiedene Aufgaben zu verwalten. Diese Aufgaben wurden über Airflow gesteuert und in Aufgabenwarteschlangen verarbeitet.

Unsere Problempunkte

Die Herausforderungen, mit denen wir konfrontiert waren, waren wie folgt:

• Schnelles Wachstum der Anwendungsdaten und lange Skalierungszyklen: Unser CDH-Cluster, der im Jahr 2016 bereits Petabytes an Daten verarbeitete, musste bis 2021 häufig alle sechs Monate skaliert werden, da das Datenwachstum oft den Hardwareplanungen überstieg. Dies verbrauchte erhebliche Ressourcen und Zeit.
• Kopplung von Speicher und Compute sowie Schwierigkeiten bei der Kapazitätsplanung: Die enge Kopplung von Speicher und Compute in der traditionellen Hadoop-Architektur erschwert es, diese jeweils unabhängig zu skalieren und zu planen. Beispielsweise erfordert die Erweiterung des Speichers auch den Kauf unnötiger Rechenressourcen, was zu ineffizienter Ressourcenallokation führt.
• Angst vor dem Upgrade aufgrund unserer CDH-Version: Unsere alte CDH-Version verhinderte ein Upgrade aufgrund von Bedenken bezüglich Stabilität und Kompatibilität.
• Hohe Betriebskosten: Mit rund 200 Mitarbeitern stand nur ein Vollzeit-Betriebsmitarbeiter zur Verfügung, was zu einem hohen Arbeitsaufwand führte. Um dies zu lindern, suchten wir nach einer stabileren und einfacheren Architektur.
• Einzelner Datenzentrums-Ausfallpunkt: Die Speicherung aller Daten in einem einzigen Datenzentrum birgt ein langfristiges Risiko. Bei Kabelschäden oder anderen Problemen führt ein einzelnes Datenzentrum zu einem einzelnen Ausfallpunkt.

Unsere Anforderungen an die neue Architektur

Um unsere Herausforderungen zu bewältigen und den wachsenden Anforderungen gerecht zu werden, entschieden wir uns für architektonische Veränderungen. Die Hauptpunkte, die wir für das Upgrade in Betracht zogen, umfassen Folgendes:

• Cloud-Nutzung, elastische Skalierbarkeit und betriebliche Flexibilität: Die Nutzung von Cloud-Diensten würde den Betrieb vereinfachen. Beispielsweise ermöglicht die Nutzung von cloudbasiertem Speicher, sich auf die Anwendung zu konzentrieren, während Wartungsaufgaben vermieden werden. Darüber hinaus ermöglichen Cloud-Ressourcen eine elastische Skalierung ohne lange Hardware-Beschaffungen und Systemkonfigurationen.
• Trennung von Speicher und Berechnung: Ziel war es, Speicher und Berechnung zu trennen, um eine bessere Flexibilität und Leistung zu erzielen.
• Präferenz für Open-Source-Komponenten, Vermeidung von Lieferantenbindung: Obwohl wir Cloud-Dienste nutzen, haben wir versucht, die Abhängigkeit von bestimmten Anbietern zu minimieren. Während wir AWS Redshift für Kundendienste verwenden, tendieren wir für die internen Operationen zu Open-Source-Komponenten.
• Kompatibilität mit bestehenden Lösungen, Kosten- und Risikokontrolle: Unser Ziel war es, Kompatibilität mit den aktuellen Lösungen sicherzustellen, um Entwicklungskosten und Auswirkungen auf unsere Anwendung zu minimieren.

Warum wir JuiceFS+EMR+OSS gewählt haben

Nachdem wir verschiedene Lösungen evaluiert hatten, entschieden wir uns für EMR+JuiceFS+OSS, um eine speicher-berechnung getrennte Big-Data-Plattform zu erstellen und unseren On-Premises-Rechenzentrum schrittweise in die Cloud zu migrieren.

New architecture at Yimian

In dieser Konfiguration ersetzt das Objektspeicher HDFS und JuiceFS fungiert aufgrund seiner Unterstützung für POSIX- und HDFS-Protokolle als Protokollschicht. Obenauf setzen wir eine semi-verwaltete Hadoop-Lösung, EMR, ein. Diese beinhaltet Hive, Impala, Spark, Presto/Trino und andere Komponenten.

Alibaba Cloud im Vergleich zu anderen Public Clouds

Nach sorgfältiger Bewertung entschieden wir uns für Alibaba Cloud gegenüber AWS und Azure aufgrund der folgenden Faktoren:

• Nähe: Die Verfügbarkeitszone von Alibaba Cloud in derselben Stadt wie unser Rechenzentrum sorgt für geringe Latenz und reduzierte Netzwerkkosten.
• Komplexe Open-Source-Komponenten: Alibaba Cloud EMR bietet eine breite Palette von Hadoop-bezogenen Open-Source-Komponenten. Neben unserer intensiven Nutzung von Hive, Impala, Spark und Hue ermöglicht es auch nahtlose Integration mit Presto, Hudi, Iceberg und mehr. Bei unserer Recherche stellten wir fest, dass nur EMR Impala nativ enthält, während AWS und Azure entweder niedrigere Versionen anbieten oder eine manuelle Installation und Bereitstellung erfordern.

JuiceFS vs. JindoFS

Was ist JuiceFS?

JuiceFS ist eine Open-Source, cloud-native, verteilte Dateisystem mit hoher Leistungsfähigkeit. Es bietet volle POSIX-Kompatibilität und ermöglicht die Nutzung von Objektspeicher als riesiger lokaler Datenträger über verschiedene Plattformen und Regionen hinweg.

JuiceFS verfolgt ein getrenntes Architektur von Daten und Metadaten, was eine verteilte Dateisystemgestaltung ermöglicht. Bei der Nutzung von JuiceFS zur Datenspeicherung werden die Daten in Objektspeicher wie Amazon S3 persistent gehalten, während die Metadaten in Datenbanken wie Redis, MySQL, TiKV, SQLite usw. gespeichert werden können.

Neben POSIX ist JuiceFS voll kompatibel mit dem HDFS SDK, was eine nahtlose Ersetzung von HDFS für getrennte Speicher- und Rechenaufgaben ermöglicht.

The JuiceFS architecture

Warum wir JuiceFS gegenüber JindoFS bevorzugten

Wir entschieden uns für JuiceFS gegenüber JindoFS aufgrund der folgenden Überlegungen:

• Speicherdesign: JuiceFS nutzt ein Architekturkonzept, bei dem Daten und Metadaten getrennt gespeichert werden, was eine verteilte Dateisystemarchitektur ermöglicht. Die Daten werden in Objektspeicher persistiert, während die Metadaten in verschiedenen Datenbanken wie Redis, MySQL, TiKV und SQLite gespeichert werden können, was eine höhere Flexibilität bietet. Im Gegensatz dazu werden die Metadaten von JindoFS auf dem lokalen Festplattenlaufwerk des EMR-Clusters gespeichert, was die Wartung, Aktualisierung und Migration weniger bequem gestaltet.
• Speicherflexibilität: JuiceFS bietet verschiedene Speicherlösungen und unterstützt die Online-Migration zwischen unterschiedlichen Schemata, was die Portabilität erhöht. JindoFS unterstützt als Block-Datenspeicher lediglich OSS.
• Unterstützung der Open-Source-Community: JuiceFS basiert auf einer Open-Source-Community und unterstützt alle öffentlichen Cloud-Umgebungen. Dies erleichtert die zukünftige Erweiterung auf eine Architektur mit mehreren Clouds.

Die gesamte Architekturdesign

Angesichts der Tatsache, dass einige Anwendungen weiterhin im Hadoop-Cluster des Rechenzentrums verbleiben, verwenden wir tatsächlich eine hybride Cloud-Architektur, wie in der Abbildung unten gezeigt.

A hybrid cloud architecture

In der Architekturbild:

• Oben befinden sich Airflow und OneWork, die beide die Möglichkeit zur verteilten Bereitstellung bieten und daher leicht horizontal skaliert werden können.
• Links befindet sich das Rechenzentrum (IDC), das das traditionelle CDH-Architektur und einige Kafka-Cluster verwendet.
• Rechts befindet sich der auf Alibaba Cloud bereitgestellte EMR-Cluster.

Das IDC und der EMR-Cluster sind über eine hochgeschwindigkeitsverbindung verbunden.

Wie wir von der neuen Architektur profitieren

Vorteile der Trennung von Speicher und Berechnung

Mit der Implementierung der Entkopplung von Speicher und Rechenleistung hat sich unsere gesamte Speicherkapazität verdoppelt, während die Rechenressourcen stabil bleiben. Gelegentlich aktivieren wir temporäre Aufgabenknoten nach Bedarf. In unserem Szenario wächst das Datenvolumen rapide, während die Abfragedemanden stabil bleiben. Seit 2021 hat sich unser Datenvolumen verdoppelt. Wir haben die Rechenressourcen seit dem Anfangsstadium bis heute kaum verändert, außer gelegentlich elastische Ressourcen und temporäre Aufgabenknoten zu aktivieren, um spezifische Anwendungsbedürfnisse zu adressieren.

Leistungsänderungen

Für unser Anwendungsszenario, das hauptsächlich aus groß angelegten Batch-Verarbeitungen für Offline-Berechnungen besteht, hat dies keinen signifikanten Einfluss auf die Leistung. Während der PoC-Phase (Proof of Concept) haben wir jedoch Verbesserungen bei den Antwortzeiten für ad-hoc Impala-Abfragen beobachtet.

Während der PoC-Phase haben wir einige einfache Tests durchgeführt. Die genauen Auswertungen der Ergebnisse sind jedoch schwierig, da verschiedene Einflussfaktoren vorliegen:

• Der Übergang von HDFS zu JuiceFS
• Komponenten-Versionsupgrades
• Änderungen am Hive-Motor
• Änderungen der Clusterlast

All dies erschwert es, endgültige Schlussfolgerungen über die Leistungsdifferenzen im Vergleich zu unserer vorherigen CDH-Bereitstellung auf physischen Servern zu ziehen.

Benutzerfreundlichkeit und Stabilität

Bei JuiceFS sind keine Probleme aufgetreten.

Bei der Verwendung von EMR gab es leichte Probleme. Insgesamt wird CDH als stabiler und benutzerfreundlicher empfunden.

Implementierungs Komplexität

In unserem Szenario sind die zeitaufwändigsten Prozesse der inkrementelle Dual-Write und die Datenüberprüfung. Im Rückblick haben wir übermäßig in die Überprüfung investiert und könnten diese vereinfachen.

Mehrere Faktoren beeinflussen die Komplexität:

• Anwendungsszenarien (Offline/Echtzeit, Anzahl der Tabellen/Aufgaben, höhere Anwendungen)
• Komponentenversionen
• Unterstützungstools und Reserven

Zukunftspläne

Unsere zukünftigen Pläne umfassen:

• Fortsetzen der Migration der verbleibenden Anwendungen in die Cloud.
• Erkunden einer kalten/heißen geschichteten Speicherstrategie mit JuiceFS+OSS. JuiceFS-Dateien werden auf OSS vollständig zerlegt, was die Implementierung einer dateibasierten Schichtung erschwert. Unser derzeitiger Ansatz besteht darin, kaltes Daten von JuiceFS nach OSS zu migrieren, es als Archivspeicher einzustellen und den LOCATION von Hive-Tabellen oder -Partitionen zu ändern, ohne die Verwendung zu beeinflussen.
• Wenn das Datenvolumen zunimmt und es Druck gibt, Redis zu verwenden, könnten wir zukünftig auf TiKV oder andere Engines umsteigen.
• Erkunden von EMRs elastischen Recheninstanzen zur Reduzierung der Nutzungskosten bei gleichzeitiger Erfüllung der Anwendungs-Service-Level-Agreements.