Migrering av Apache Hadoop Distributed File System (HDFS) till Azure

Hadoop Distributed File System (HDFS) är ett Java-baserat distribuerat filsystem som tillhandahåller tillförlitlig, skalbar datalagring som kan sträcka sig över stora kluster av råvaruservrar. Den här artikeln innehåller en översikt över HDFS och en guide för att migrera den till Azure.

Apache®, Apache Spark®, Apache Hadoop®, Apache Hive och flamlogotypen är antingen registrerade varumärken eller varumärken som tillhör Apache Software Foundation i USA och/eller andra länder. Inget godkännande från Apache Software Foundation underförstås av användningen av dessa märken.

HDFS-arkitektur och -komponenter

HDFS har en primär/sekundär design. I följande diagram är NameNode den primära och DataNodes är sekundärfilerna.

• NameNode hanterar åtkomsten till filer och filsystemets namnområde, som är en hierarki med kataloger.
  • Filer och kataloger är noder på NameNode. De har attribut som behörigheter, ändrings- och åtkomsttider samt storlekskvoter för namnrymd och diskutrymme.
  • En fil består av flera block. Standardblockstorleken är 128 megabyte. En blockstorlek som inte är standard kan anges för ett kluster genom att ändra hdfs-site.xml-filen.
  • Varje block i filen replikeras separat vid flera DataNodes. Standardvärdet för replikeringsfaktorn är tre, men varje kluster kan ha ett eget värde som inte är standard. Replikeringsfaktorn kan ändras när som helst. En ändring gör att ett kluster balanseras om.
  • NameNode underhåller namnområdesträdet och mappningen av filblock till DataNodes (de fysiska platserna för fildata).
  • När en HDFS-klient läser en fil:
    1. Den kontaktar NameNode för platserna för datablocken i filen.
    2. Den läser blockinnehåll från närmaste DataNode.
  • HDFS behåller hela namnområdet i RAM-minnet.
• DataNodes är de sekundära noder som utför läs- och skrivåtgärder i filsystemet och utför blockeringsåtgärder som skapande, replikering och borttagning.
  • En DataNode innehåller metadatafiler som innehåller kontrollsummorna för de lagrade filerna. För varje blockreplik som hanteras av en DataNode finns det en motsvarande metadatafil som innehåller metadata om repliken, inklusive dess kontrollsummainformation. Metadatafilen har samma basnamn som blockfilen och filnamnstillägget .meta.
  • DataNoden innehåller datafilen som innehåller blockets data.
  • När en DataNode läser en fil hämtar den blockplatserna och replikplatserna från Namnnoden och försöker läsa från närmaste plats.
  • Ett HDFS-kluster kan ha tusentals DataNodes- och tiotusentals HDFS-klienter per kluster. Varje DataNode kan köra flera programaktiviteter samtidigt.
  • En kontrollsummaberäkning från slutpunkt till slutpunkt utförs som en del av HDFS-skrivpipelinen när ett block skrivs till DataNodes.
• HDFS-klienten är den klient som program använder för att komma åt filer.
  • Det är ett kodbibliotek som exporterar HDFS-filsystemgränssnittet.
  • Den stöder åtgärder för att läsa, skriva och ta bort filer och åtgärder för att skapa och ta bort kataloger.
  • Den utför följande steg när ett program läser en fil:
    • Den hämtas från NameNode en lista över DataNoder och platser som innehåller filblocken. Listan innehåller replikerna.
    • Den använder listan för att hämta de begärda blocken från DataNodes.
  • HDFS tillhandahåller ett API som exponerar filblockens platser. På så sätt kan program som MapReduce-ramverket schemalägga en uppgift att köras där data finns, för att optimera läsprestanda.

Funktionskarta

Drivrutinen för Azure Blob Filesystem (ABFS) tillhandahåller ett gränssnitt som gör det möjligt för Azure Data Lake Storage att fungera som ett HDFS-filsystem. I följande tabell jämförs kärnfunktionerna för ABFS-drivrutinen och Data Lake Storage med HDFS.

Vanliga utmaningar för en lokal HDFS

De många utmaningar som en lokal HDFS-implementering medför kan vara skäl att överväga fördelarna med att migrera till molnet:

• Frekventa uppgraderingar av HDFS-version
• Öka mängden data
• Det finns många små filer som ökar trycket på NameNode, som styr metadata för alla filer i klustret. Fler filer innebär ofta mer lästrafik på NameNode när klienter läser filerna och fler anrop när klienter skriver.
• Om flera team i organisationen kräver olika datauppsättningar är det inte möjligt att dela upp HDFS-klustren efter användningsfall eller organisation. Resultatet är att datadupliceringen ökar, vilket ökar kostnaderna och minskar effektiviteten.
• NameNode kan bli en flaskhals för prestanda när HDFS-klustret skalas upp eller ut.
• Före Hadoop 2.0 passerar alla klientbegäranden till ett HDFS-kluster först genom NameNode, eftersom alla metadata lagras i en enda Namnnod. Den här designen gör NameNode till en möjlig flaskhals och en felpunkt. Om NameNode misslyckas är klustret inte tillgängligt.

Överväganden vid migrering

Här följer några saker som är viktiga att tänka på när du planerar en migrering av HDFS till Data Lake Storage:

• Överväg att aggregera data som finns i små filer till en enda fil på Data Lake Storage.
• Visa en lista över alla katalogstrukturer i HDFS och replikera liknande zonindelning i Data Lake Storage. Du kan hämta katalogstrukturen för HDFS med hjälp hdfs -ls av kommandot .
• Visa en lista över alla roller som har definierats i HDFS-klustret så att du kan replikera dem i målmiljön.
• Observera datalivscykelpolicyn för de filer som lagras i HDFS.
• Tänk på att vissa systemfunktioner i HDFS inte är tillgängliga på Data Lake Storage, inklusive:
  • Strikt atomisk namnbyte av kataloger
  • Detaljerade HDFS-behörigheter
  • HDFS-symlänkar
• Azure Storage har geo-redundant replikering, men det är inte alltid klokt att använda den. Den tillhandahåller dataredundans och geografisk återställning, men en redundansväxling till en mer avlägsen plats kan allvarligt försämra prestanda och medföra ytterligare kostnader. Fundera på om den högre tillgängligheten för data är värd det.
• Om filer har namn med samma prefix behandlar HDFS dem som en enda partition. Om du använder Azure Data Factory skriver därför alla dataförflyttningsenheter (DMUs) till en enda partition.

• Om du använder Data Factory för dataöverföring söker du igenom varje katalog, exklusive ögonblicksbilder, och kontrollerar katalogstorleken hdfs du med hjälp av kommandot . Om det finns flera underkataloger och stora mängder data initierar du flera kopieringsaktiviteter i Data Factory. Använd till exempel en kopia per underkatalog i stället för att överföra hela katalogen med hjälp av en enda kopieringsaktivitet.

• Dataplattformar används ofta för långsiktig kvarhållning av information som kan ha tagits bort från arkivhandlingssystem. Du bör planera att skapa bandsäkerhetskopior eller ögonblicksbilder av arkiverade data. Överväg att replikera informationen till en återställningswebbplats. Vanligtvis arkiveras data antingen för kompatibilitet eller för historiska dataändamål. Innan du arkiverar data bör du ha en tydlig anledning att behålla dem. Bestäm också när arkiverade data ska tas bort och upprätta processer för att ta bort dem vid den tidpunkten.
• Den låga kostnaden för arkivåtkomstnivån för Data Lake Storage gör det till ett attraktivt alternativ för arkivering av data. Mer information finns i Arkivåtkomstnivå.
• När en HDFS-klient använder ABFS-drivrutinen för att komma åt Blob Storage kan det finnas instanser där metoden som används av klienten inte stöds och AzureNativeFileSystem genererar en UnsupportedOperationException. Till exempel append(Path f, int bufferSize, Progressable progress) stöds inte för närvarande. Information om problem som rör ABFS-drivrutinen finns i Hadoop-funktioner och korrigeringar.
• Det finns en bakåtporterad version av ABFS-drivrutinen för användning i äldre Hadoop-kluster. Mer information finns i Backport för ABFS-drivrutin.
• I en virtuell Azure-nätverksmiljö stöder distCp-verktyget inte privat Peering i Azure ExpressRoute med en slutpunkt för ett virtuellt Azure Storage-nätverk. Mer information finns i Använda Azure Data Factory för att migrera data från ett lokalt Hadoop-kluster till Azure Storage.

Migreringsmetod

Den vanliga metoden för att migrera HDFS till Data Lake Storage använder följande steg:

HDFS-utvärdering

Lokala utvärderingsskript innehåller information som hjälper dig att avgöra vilka arbetsbelastningar som kan migreras till Azure och om data ska migreras på en gång eller en bit i taget. Verktyg från tredje part som Unravel kan tillhandahålla mått och stödja automatisk utvärdering av den lokala HDFS. Några viktiga faktorer att tänka på när du planerar är:

• Datavolym
• Påverkan på verksamheten
• Ägarskap för data
• Bearbetningskomplexitet
• Extrahera, överföra och läsa in (ETL) komplexitet
• Personligt identifierbar information (PII) och andra känsliga data

Baserat på sådana faktorer kan du formulera en plan för att flytta data till Azure som minimerar stilleståndstid och avbrott i verksamheten. Kanske kan känsliga data förbli lokala. Historiska data kan flyttas och testas innan du flyttar en inkrementell belastning.

Följande beslutsflöde hjälper dig att bestämma vilka kriterier och kommandon som ska köras för att få rätt information.

HDFS-kommandon för att hämta utvärderingsmått från HDFS är:

• Visa en lista över alla kataloger på en plats:

  hdfs dfs -ls books

• Rekursivt lista alla filer på en plats:

  hdfs dfs -ls -R books

• Hämta storleken på HDFS-katalogen och filerna:

  hadoop fs -du -s -h command

  Kommandot hadoop fs -du -s -h visar storleken på HDFS-filer och -katalogen. Eftersom Hadoop-filsystemet replikerar varje fil är den faktiska fysiska storleken på filen antalet filrepliker multiplicerat med storleken på en replik.

• Avgör om ACL:er är aktiverade. Det gör du genom att hämta värdet dfs.namenode.acls.enabled för i Hdfs-site.xml. Att känna till värdet hjälper dig att planera åtkomstkontroll på Azure Storage-kontot. Information om innehållet i den här filen finns i Standardfilinställningar.

Partnerverktyg som Unravel tillhandahåller utvärderingsrapporter för planering av datamigrering. Verktygen måste köras i den lokala miljön eller ansluta till Hadoop-klustret för att generera rapporter.

• Följande Unravel-rapport innehåller statistik, per katalog, om de små filerna i katalogen:

  

• Följande rapport innehåller statistik, per katalog, om filerna i katalogen:

  

Överföra data

Data måste överföras till Azure enligt beskrivningen i din migreringsplan. Överföring kräver följande aktiviteter:

1. Identifiera alla inmatningspunkter.

   Om data på grund av säkerhetskrav inte kan landas direkt i molnet kan lokala enheter fungera som en mellanliggande landningszon. Du kan skapa pipelines i Data Factory för att hämta data från lokala system eller använda AZCopy-skript för att skicka data till Azure Storage-kontot.

   Vanliga inmatningskällor är:

   1. SFTP-server
   2. Filinmatning
   3. Databasinmatning
   4. Databasdumpning
   5. Registrering av ändringsdata
   6. Strömningsinmatning

2. Planera antalet lagringskonton som krävs.

   Om du vill planera antalet lagringskonton som krävs förstår du den totala belastningen på den aktuella HDFS. Du kan använda måttet TotalLoad, som är det aktuella antalet samtidiga filåtkomster för alla DataNodes. Ange gränsen för lagringskontot i regionen enligt TotalLoad-värdet lokalt och den förväntade tillväxten i Azure. Om det går att öka gränsen kan det räcka med ett enda lagringskonto. Men för en datasjö är det bäst att ha ett separat lagringskonto för varje zon för att förbereda för framtida datavolymtillväxt. Andra orsaker till att behålla ett separat lagringskonto är:

   • Åtkomstkontroll
   • Återhämtningskrav
   • Krav för datareplikering
   • Exponera data för offentlig användning

   När du aktiverar ett hierarkiskt namnområde på ett lagringskonto kan du inte ändra tillbaka det till ett platt namnområde. Arbetsbelastningar som säkerhetskopieringar och VM-avbildningsfiler drar ingen nytta av ett hierarkiskt namnområde.

   

   Information om hur du skyddar trafiken mellan ditt virtuella nätverk och lagringskontot via en privat länk finns i Skydda lagringskonton.

   Information om standardgränser för Azure Storage-konton finns i Skalbarhets- och prestandamål för standardlagringskonton. Ingressgränsen gäller för de data som skickas till ett lagringskonto. Gränsen för utgående trafik gäller för data som tas emot från ett lagringskonto

3. Besluta om tillgänglighetskrav.

   Du kan ange replikeringsfaktorn för Hadoop-plattformar i hdfs-site.xml eller ange den per fil. Du kan konfigurera replikering på Data Lake Storage enligt datatypen. Om ett program kräver att data rekonstrueras vid förlust är zonredundant lagring (ZRS) ett alternativ. I Data Lake Storage ZRS kopieras data synkront över tre tillgänglighetszoner i den primära regionen. För program som kräver hög tillgänglighet och som kan köras i mer än en region kopierar du data till en sekundär region. Det här är geo-redundant replikering.

   

4. Sök efter skadade eller saknade block.

   Kontrollera blockskannerrapporten för skadade eller saknade block. Om det finns några väntar du på att filen ska återställas innan du överför den.

   

5. Kontrollera om NFS är aktiverat.

   Kontrollera om NFS är aktiverat på den lokala Hadoop-plattformen genom att kontrollera core-site.xml-filen. Den har egenskaperna nfsserver.groups och nfsserver.hosts.

   Funktionen NFS 3.0 är en förhandsversion i Data Lake Storage. Några funktioner kanske inte stöds ännu. Mer information finns i Nätverksfilsystem (NFS) 3.0-protokollstöd för Azure Blob Storage.

   

6. Kontrollera Hadoop-filformat.

   Använd följande beslutsflödesdiagram för vägledning om hur du hanterar filformat.

7. Välj en Azure-lösning för dataöverföring.

   Dataöverföring kan vara online via nätverket eller offline med hjälp av fysiska enheter. Vilken metod som ska användas beror på datavolym, nätverksbandbredd och dataöverföringens frekvens. Historiska data måste bara överföras en gång. Inkrementella belastningar kräver upprepade pågående överföringar.

   Dataöverföringsmetoder beskrivs i listan som följer. Mer information om hur du väljer typer av dataöverföring finns i Välj en Azure-lösning för dataöverföring.

   1. Azcopy

      Azcopy är ett kommandoradsverktyg som kan kopiera filer från HDFS till ett lagringskonto. Det här är ett alternativ för överföringar med hög bandbredd (över 1 GBPS).

      Här är ett exempelkommando för att flytta en HDFS-katalog:

      *azcopy copy "C:\local\path" "https://account.blob.core.windows.net/mycontainer1/?sv=2018-03-28&ss=bjqt&srt=sco&sp=rwddgcup&se=2019-05-01T05:01:17Z&st=2019-04-30T21:01:17Z&spr=https&sig=MGCXiyEzbtttkr3ewJIh2AR8KrghSy1DGM9ovN734bQF4%3D" --recursive=true*
      

   2. DistCp

      DistCp är ett kommandoradsverktyg i Hadoop som kan utföra distribuerade kopieringsåtgärder i ett Hadoop-kluster. DistCp skapar flera kartuppgifter i Hadoop-klustret för att kopiera data från källan till mottagaren. Den här push-metoden är bra när det finns tillräcklig nätverksbandbredd och det inte kräver att extra beräkningsresurser etableras för datamigrering. Men om HDFS-källklustret redan har slut på kapacitet och ytterligare beräkning inte kan läggas till kan du överväga att använda Data Factory med DistCp-kopieringsaktiviteten för att hämta i stället för att push-överföra filerna.

      *hadoop distcp -D fs.azure.account.key.<account name>.blob.core.windows.net=<Key> wasb://<container>@<account>.blob.core.windows.net<path to wasb file> hdfs://<hdfs path>*
      

   3. Azure Data Box för stora dataöverföringar

      Azure Data Box är en fysisk enhet som har beställts från Microsoft. Den tillhandahåller storskaliga dataöverföringar och är ett alternativ för dataöverföring offline när nätverksbandbredden är begränsad och datavolymen är hög (till exempel när volymen är mellan några terabyte och en petabyte).

      Du ansluter en Data Box till LAN för att överföra data till den. Sedan skickar du tillbaka dem till Microsofts datacenter, där data överförs av Microsoft-tekniker till det konfigurerade lagringskontot.

      Det finns flera Data Box-alternativ som skiljer sig mellan de datavolymer som de kan hantera. Mer information om Data Box-metoden finns i Dokumentation om Azure Data Box – offlineöverföring.

   4. Data Factory

      Data Factory är en dataintegreringstjänst som hjälper till att skapa datadrivna arbetsflöden som samordnar och automatiserar dataflytt och datatransformering. Du kan använda den när det finns tillräckligt med tillgänglig nätverksbandbredd och det finns ett krav på att samordna och övervaka datamigrering. Du kan använda Data Factory för regelbundna inkrementella inläsningar av data när inkrementella data kommer till det lokala systemet som ett första hopp och inte kan överföras direkt till Azure Storage-kontot på grund av säkerhetsbegränsningar.

      Mer information om de olika överföringsmetoderna finns i Dataöverföring för stora datamängder med måttlig till hög nätverksbandbredd.

      Information om hur du använder Data Factory för att kopiera data från HDFS finns i Kopiera data från HDFS-servern med Hjälp av Azure Data Factory eller Synapse Analytics

   5. Partnerlösningar som WANdisco LiveData-migrering

      WANdisco LiveData Platform för Azure är en av Microsofts föredragna lösningar för migreringar från Hadoop till Azure. Du kommer åt dess funktioner med hjälp av Azure-portalen och Azure CLI. Mer information finns i Migrera dina Hadoop-datasjöar med WANdisco LiveData Platform för Azure.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Namrata Maheshwary | Senior Cloud Solution Architect
• Raja N | Direktör, kundframgång
• Hideo Takagi | Molnlösningsarkitekt
• Ram Yerrabotu | Senior Cloud Solution Architect

Övriga medarbetare:

• Ram Baskaran | Senior Cloud Solution Architect
• Jason Bouska | Senior programvarutekniker
• Eugene Chung | Senior Cloud Solution Architect
• Pawan Hosatti | Senior Cloud Solution Architect – Teknik
• Daman Kaur | Molnlösningsarkitekt
• Danny Liu | Senior Cloud Solution Architect – Teknik
• Jose Mendez Senior Cloud Solution Architect
• Ben Sadeghi | Senior Specialist
• Sunil Sattiraju | Senior Cloud Solution Architect
• Amanjeet Singh | Programhanteraren för huvudnamn
• Nagaraj Seeplapudur Venkatesan | Senior Cloud Solution Architect – Teknik

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Introduktion till Azure-produkter

• Introduktion till Azure Data Lake Storage Gen2
• Vad är Apache Spark i Azure HDInsight
• Vad är Apache Hadoop i Azure HDInsight?
• Vad är Apache HBase i Azure HDInsight
• Vad är Apache Kafka i Azure HDInsight

Produktreferens för Azure

• Microsoft Entra-dokumentation.
• Dokumentation om Azure Cosmos DB
• Dokumentation om Azure Data Factory
• Dokumentation om Azure Databricks
• Dokumentation om Azure Event Hubs
• Azure Functions-dokumentation
• Dokumentation om Azure HDInsight
• Dokumentation om Datastyrning i Microsoft Purview
• Dokumentation om Azure Stream Analytics
• Azure Synapse Analytics

Övrigt

• Enterprise Security Package för Azure HDInsight
• Utveckla Java MapReduce-program för Apache Hadoop i HDInsight
• Använda Apache Sqoop med Hadoop i HDInsight
• Översikt över Apache Spark Streaming
• Självstudier för strukturerad direktuppspelning
• Använda Azure Event Hubs från Apache Kafka-program

Relaterade resurser

• Hadoop-migrering till Azure
• Apache HBase-migrering till Azure
• Apache Kafka-migrering till Azure
• Apache Sqoop-migrering till Azure