Hadoop migreren naar de cloud: 2X opslagcapaciteit en minder operationele kosten

Yimian is een toonaangevend leverancier van AI-gestuurde gegevensanalyse, gespecialiseerd in digitale handelsgegevens. We bieden realtime inzichten op het gebied van bedrijfsstrategie, productontwikkeling en digitale handelsoperaties. Veel van onze klanten zijn industrieleden op het gebied van persoonlijke verzorging, make-up, F&B, huisdieren en auto, zoals Procter and Gamble, Unilever en Mars.

Onze oorspronkelijke technologiearchitectuur was een big data-cluster dat werd gebouwd met behulp van CDH (Cloudera Distributed Hadoop) in een eigen datacenter. Naarmate ons bedrijf groeide, nam het gegevensvolume explosief toe.

Om uitdagingen te aanpakken zoals lange schaalcycli, ongecoördineerde reken- en opslagbronnen en hoge onderhoudskosten, besloten we onze gegevensarchitectuur te transformeren en naar de cloud te migreren, door een opslag-rekenontbinding aan te nemen. Na een nauwkeurige evaluatie kozen we voor Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Alibaba Cloud Object Storage Service (OSS).

Op dit moment hebben we met JuiceFS een gedecoupleerde architectuur voor berekeningen en opslag geïmplementeerd, waardoor onze totale opslagcapaciteit is verdubbeld. Opmerkelijk is dat we geen significante prestatievermindering hebben waargenomen en onze operationele kosten aanzienlijk zijn verminderd.

In deze artikel delen we ons architectuurontwerp voor het migreren van Hadoop naar de cloud, waarom we JuiceFS+EMR+OSS hebben gekozen, en hoe we voordeel halen uit de nieuwe architectuur. Ons doel is om waardevolle inzichten te bieden voor degenen die met soortgelijke uitdagingen worden geconfronteerd via deze post.

Onze Oude Architectuur en Uitdagingen

Om aan onze groeiende toepassingsbehoeften te voldoen, zijn we bezig met het verzamelen van gegevens van honderden grote websites, met het huidige aantal dat 500 overschrijdt. In de loop van de tijd hebben we aanzienlijke hoeveelheden ruwe, tussenliggende en resultaatgegevens verzameld. Toen we ons website-crawls en klantenbestand verder uitbreidden, nam onze gegevensvolume snel toe. Daarom besloten we onze hardware uit te breiden om de groeiende eisen te accommoderen.

De Originele Architectuur

Het volgende figuur toont onze vorige architectuur, die een CDH-gebaseerde big data-cluster in een datacenter omvatte:

• De belangrijkste onderdelen omvatten Hive, Spark en HDFS.
• Verschillende gegevensproductiesystemen, met Kafka als een van hen, voedden gegevens in het cluster.
• We gebruikten andere opslagoplossingen, zoals TiDB, HBase en MySQL, naast Kafka.

Original architecture at Yimian

Gegevens stroomden van bovenliggende toepassingssystemen en gegevensverzamelsystemen, waar ze naar Kafka werden geschreven. We gebruikten een Kafka Connect-cluster om de gegevens naar HDFS te synchroniseren.

Op deze architectuur ontwikkelden we een aangepaste gegevensontwikkelingsplatform genaamd OneWork om verschillende taken te beheren. Deze taken werden via Airflow gepland en verwerkt in taakwachtrijen.

Onze Pijnpunten

De uitdagingen waarmee we werden geconfronteerd, waren als volgt:

• Snelgroei van toepassingsgegevens en lange schaalcycli: Ons CDH-cluster, geïmplementeerd in 2016, verwerkte al petabytes aan gegevens in 2021. Echter, groei van gegevens overschreed vaak de hardwareplanning, wat leidde tot regelmatige schaalbeurten om de zes maanden. Dit kostte aanzienlijke middelen en tijd.
• Koppeling van opslag en rekenkracht en moeilijkheid bij capaciteitsplanning: De traditionele Hadoop-architectuur met de strakke koppeling van opslag en rekenkracht maakt het moeilijk om onafhankelijk te schalen en te plannen op basis van opslag of rekenvereisten. Bijvoorbeeld, het uitbreiden van opslag vereist ook het aankopen van onnodige rekenbronnen. Dit leidde tot inefficiënte middelenallocatie.
• Bang voor upgraden vanwege onze CDH-versie: Onze CDH-versie was oud, en we twijfelden aan een upgrade vanwege zorgen over stabiliteit en compatibiliteit.
• Hoge operationele kosten: Met ongeveer 200 werknemers, hadden we slechts één voltijdse operationele medewerker. Dit bracht een zware werkdruk met zich mee. Om dit te verlichten, zochten we naar een stabielere en eenvoudigere architectuur.
• Eén datacenter punt van falen: Alle gegevens die in één datacenter worden opgeslagen, vormen een langetermijnrisk. In het geval van kabelbeschadigingen of andere problemen, schept een enkel datacenter een enkele punt van falen.

Onze vereisten voor de nieuwe architectuur

Om onze uitdagingen aan te pakken en de groeiende eisen te voldoen, besloten we enkele architectuurveranderingen door te voeren. De belangrijkste aspecten die we voor de upgrade overwogen, zijn de volgende:

• Cloudadopting, elastische schaalbaarheid en operationele flexibiliteit: Het omarmen van cloudservices zou de bedrijfsvoering vereenvoudigen. Bijvoorbeeld, het inzetten van cloudgebaseerde opslag stelt ons in staat zich te concentreren op de applicatie terwijl onderhoudstaken worden vermeden. Bovendien stelt cloudbronnen ons in staat tot elastische schaalbaarheid zonder lange hardware-implementaties en systeemconfiguraties.
• Opslag-compute ontbinding: We hebben het doel gehad om opslag en compute te scheiden om betere flexibiliteit en prestaties te bereiken.
• Voorkeur voor open-source componenten, vermijden van leveranciersafhankelijkheid: Hoewel we cloudservices gebruiken, hebben we geprobeerd afhankelijkheid van specifieke leveranciers te minimaliseren. Hoewel we AWS Redshift gebruiken voor klantenservices, kozen we toch voor open-source componenten voor interne operaties.
• Compatibiliteit met bestaande oplossingen, kosten en risico’s beheersen: Ons doel was compatibiliteit te waarborgen met huidige oplossingen om ontwikkelingskosten en impact op onze applicatie te minimaliseren.

Waarom We JuiceFS+EMR+OSS Kozen

Na het evalueren van verschillende oplossingen kozen we EMR+JuiceFS+OSS om een opslag-compute gescheiden big data platform te bouwen en onze on-premises datacenter geleidelijk te migreren naar de cloud.

New architecture at Yimian

In deze setup vervangt object storage HDFS en fungeert JuiceFS als protocollagen vanwege zijn ondersteuning voor POSIX en HDFS protocollen. Aan de top gebruiken we een semi-beheerde Hadoop-oplossing, EMR. Het omvat Hive, Impala, Spark, Presto/Trino en andere componenten.

Alibaba Cloud versus Andere Publieke Clouds

Na onze zorgvuldige evaluatie kozen we Alibaba Cloud boven AWS en Azure vanwege de volgende factoren:

• Nabijheid: De beschikbaarheidszone van Alibaba Cloud in dezelfde stad als ons datacenter zorgt voor lage latentie en verminderde netwerkkosten.
• Uitgebreide open-source componenten: Alibaba Cloud EMR biedt een breed scala aan Hadoop-gerelateerde open-source componenten. Naast onze intensieve gebruik van Hive, Impala, Spark en Hue, biedt het ook soepele integratie met Presto, Hudi, Iceberg en meer. Tijdens ons onderzoek ontdekten we dat alleen EMR Impala standaard bevat, terwijl AWS en Azure lagere versies aanbieden of handmatige installatie en implementatie vereisen.

JuiceFS vs. JindoFS

Wat is JuiceFS?

JuiceFS is een open-source, cloud-native, gedistribueerd bestandssysteem met hoge prestaties. Het biedt volledige POSIX-compatibiliteit, waardoor objectopslag kan worden gebruikt als een uitgebreide lokale schijf over verschillende platforms en regio’s.

JuiceFS heeft een gescheiden architectuur voor gegevens en metadata, wat een ontwerp van gedistribueerde bestandssystemen mogelijk maakt. Wanneer u JuiceFS gebruikt om gegevens op te slaan, worden de gegevens persistent gehouden in objectopslag zoals Amazon S3, terwijl metadata kan worden opgeslagen in databases zoals Redis, MySQL, TiKV, SQLite, en andere.

Naast POSIX is JuiceFS volledig compatibel met de HDFS SDK, waardoor HDFS naadloos kan worden vervangen voor opslag-reken scheiding.

The JuiceFS architecture

Waarom we JuiceFS boven JindoFS kozen

We kozen voor JuiceFS boven JindoFS op basis van de volgende overwegingen:

• Opslagontwerp: JuiceFS hanteert een opslagarchitectuur waarbij gegevens en metadata gescheiden worden opgeslagen, waardoor een gedistribueerd bestandssysteem kan worden ontworpen. De gegevens worden persistent opgeslagen in object storage, terwijl metadata kan worden opgeslagen in verschillende databases zoals Redis, MySQL, TiKV en SQLite, waardoor er meer flexibiliteit wordt geboden. In tegenstelling daarmee wordt de metadata van JindoFS opgeslagen op de lokale harde schijf van de EMR-cluster, waardoor onderhoud, upgrades en migraties minder gemakkelijk zijn.
• Opslagflexibiliteit: JuiceFS biedt verschillende opslagoplossingen, waaronder de mogelijkheid om online te migreren tussen verschillende schema’s en het verhogen van draagbaarheid. JindoFS blokgegevens ondersteunen enkel OSS.
• Ondersteuning van open-source gemeenschap: JuiceFS is gebaseerd op een open-source gemeenschap, die alle publieke cloudomgevingen ondersteunt. Dit faciliteert toekomstige uitbreiding naar een multi-cloud architectuur.

Het Gehele Architectuurontwerp

Aangezien sommige toepassingen nog steeds in de Hadoop-cluster van de datacenter worden bewaard, gebruiken we feitelijk een hybride cloudarchitectuur, zoals weergegeven in de onderstaande figuur.

A hybrid cloud architecture

In de architectuurfiguur:

• Bovenaan bevinden zich Airflow en OneWork, die beide ondersteuning bieden voor gedistribueerde implementatie, zodat ze gemakkelijk horizontaal kunnen worden geschaald.
• Links bevindt zich de IDC, die gebruikmaakt van het traditionele CDH-architectuur en enkele Kafka-clusters.
• Rechts bevindt zich de EMR-cluster die is geïmplementeerd op Alibaba Cloud.

De IDC en de EMR-cluster zijn verbonden via een snelle, gespecialiseerde lijn.

Hoe We Voordeel Hebben van de Nieuwe Architectuur

Voordelen van Opslag-Compute Scheiding

Met de implementatie van opslag-rekenontbinding is onze totale opslagcapaciteit verdubbeld terwijl de rekenbronnen stabiel blijven. Soms schakelen we tijdelijke taakknooppunten in als dat nodig is. In ons scenario ondervindt de gegevensvolume snelle groei terwijl query-eisen stabiel blijven. Sinds 2021 is onze gegevensvolume verdubbeld. We hebben de rekenbronnen vanaf het begin tot nu slechts minimale wijzigingen aangebracht, behalve soms het inschakelen van elastische bronnen en tijdelijke taakknooppunten om specifieke applicatievereisten te behandelen.

Prestatiewijzigingen

Voor ons applicatiescenario, dat voornamelijk grote schaal batchverwerking voor offline berekeningen omvat, is er geen significante impact op de prestaties. Erger, tijdens de PoC-fase, merkten we verbeteringen in de reactietijden voor ad-hoc Impala-query’s.

Tijdens de PoC-fase voerden we enkele eenvoudige tests uit. Echter, het nauwkeurig interpreteren van de resultaten is uitdagend vanwege verschillende invloedsfactoren:

• De overgang van HDFS naar JuiceFS
• Componentversie-upgrades
• Wijzigingen in de Hive-engine
• Wijzigingen in de clusterbelasting

Al deze factoren maken het moeilijk om conclusies te trekken over prestatieverschillen in vergelijking met onze vorige implementatie van CDH op bare metal servers.

Gebruiksvriendelijkheid en stabiliteit

We hebben geen problemen ondervonden met JuiceFS.

Bij het gebruik van EMR hadden we enkele kleine problemen. Over het algemeen wordt CDH gezien als stabieler en gebruiksvriendelijker.

Implementatiecomplexiteit

In ons scenario zijn de meest tijdrovende processen incrementele dual-write en gegevensverificatie. Terugkijkend hebben we te veel in verificatie geïnvesteerd en kunnen we het vereenvoudigen.

Meerdere factoren beïnvloeden de complexiteit:

• Toepassingsscenario’s (offline/real-time, aantal tabellen/taken, bovenliggende toepassingen)
• Componentversies
• Ondersteunende tools en reserves

Toekomstplannen

Onze toekomstplannen omvatten:

• Doorgaan met de migratie van de resterende toepassingen naar de cloud.
• Een koud/warm gelaagde opslagstrategie onderzoeken met behulp van JuiceFS+OSS. JuiceFS-bestanden worden volledig ontleed op OSS, waardoor het moeilijk is om bestandsniveau-tiering te implementeren. Ons huidige aanpak is het migreren van koude gegevens van JuiceFS naar OSS, het instellen als archiefopslag en het wijzigen van de LOCATION van Hive-tabellen of -partities zonder gebruiksimpact.
• Als het gegevensvolume toeneemt en er druk is op het gebruik van Redis, kunnen we in de toekomst overwegen over te stappen op TiKV of andere motoren.
• EMR’s elastische rekeninstanties onderzoeken om gebruikskosten te verlagen terwijl de toepassingsserviceovereenkomsten worden gehaald.