Migrera lokala Apache Hadoop-kluster till Azure HDInsight

Den här artikeln ger rekommendationer för datalagring i Azure HDInsight-system. Det är en del av en serie som innehåller metodtips för att migrera lokala Apache Hadoop-system till Azure HDInsight.

Välj rätt lagringssystem för HDInsight-kluster

Den lokala katalogstrukturen för Apache Hadoop File System (HDFS) kan återskapas i Azure Blob Storage eller Azure Data Lake Storage. Du kan sedan ta bort HDInsight-kluster som används för beräkning utan att förlora användardata. Båda tjänsterna kan användas både som standardfilsystem och ytterligare ett filsystem för ett HDInsight-kluster. HDInsight-klustret och lagringskontot måste finnas i samma region.

Azure Storage

HDInsight-kluster kan använda blobcontainern i Azure Storage som antingen standardfilsystemet eller ett ytterligare filsystem. Lagringskontot på standardnivå stöds för användning med HDInsight-kluster. Premier-nivån stöds inte. Standardcontainern lagrar klusterspecifik information, till exempel jobbhistorik och loggar. Det går inte att dela en blobcontainer som standardfilsystem för flera kluster.

De lagringskonton som definieras i skapandeprocessen och deras respektive nycklar lagras i %HADOOP_HOME%/conf/core-site.xml på klusternoderna. De kan också nås under avsnittet "Anpassad kärnwebbplats" i HDFS-konfigurationen i Ambari-användargränssnittet. Lagringskontonyckeln krypteras som standard och ett anpassat dekrypteringsskript används för att dekryptera nycklarna innan de skickas vidare till Hadoop-daemoner. Jobben, inklusive Hive, MapReduce, Hadoop-strömning och Pig, har en beskrivning av lagringskonton och metadata med sig.

Azure Storage kan geo-replikeras. Även om geo-replikering ger geografisk återställning och dataredundans, påverkar en redundansväxling till den geo-replikerade platsen prestandan kraftigt, och det kan medföra ytterligare kostnader. Rekommendationen är att välja geo-replikering klokt och endast om värdet på data är värt den extra kostnaden.

Ett av följande format kan användas för att komma åt data som lagras i Azure Storage:

Dataåtkomstformat Description
wasb:/// Få åtkomst till standardlagring med okrypterad kommunikation.
wasbs:/// Få åtkomst till standardlagring med krypterad kommunikation.
wasb://<container-name>@<account-name>.blob.core.windows.net/ Används vid kommunikation med ett lagringskonto som inte är standard. 

Skalbarhetsmål för standardlagringskonton visar de aktuella gränserna för Azure Storage-konton. Om programmets behov överskrider skalbarhetsmålen för ett enda lagringskonto kan programmet skapas för att använda flera lagringskonton och sedan partitioneras dataobjekt över dessa lagringskonton.

Azure Storage Analytics tillhandahåller mått för alla lagringstjänster och Azure-portalen kan konfigureras för att samla in mått som ska visualiseras via diagram. Aviseringar kan skapas för att meddela när tröskelvärden har uppnåtts för lagringsresursmått.

Azure Storage erbjuder mjuk borttagning för blobobjekt som hjälper till att återställa data när de oavsiktligt ändras eller tas bort av ett program eller en annan lagringskontoanvändare.

Du kan skapa ögonblicksbilder av blobar. En ögonblicksbild är en skrivskyddad version av en blob som tas vid en tidpunkt och ger ett sätt att säkerhetskopiera en blob. När en ögonblicksbild har skapats kan den läsas, kopieras eller tas bort, men inte ändras.

Anteckning

För äldre versioner av lokala Hadoop-distributioner som inte har certifikatet "wasbs" måste de importeras till Java-förtroendearkivet.

Följande metoder kan användas för att importera certifikat till Java-förtroendearkivet:

Ladda ned TLS/SSL-certifikatet för Azure Blob till en fil

echo -n | openssl s_client -connect <storage-account>.blob.core.windows.net:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > Azure_Storage.cer

Importera filen ovan till Java-förtroendearkivet på alla noder

keytool -import -trustcacerts -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -alias blobtrust -file Azure_Storage.cer

Kontrollera att det tillagda certifikatet finns i förtroendearkivet

keytool -list -v -keystore /path/to/jre/lib/security/cacerts

Mer information finns i följande artiklar:

Azure Data Lake Storage Gen1

Azure Data Lake Storage Gen1 implementerar en åtkomstkontrollmodell i HDFS- och POSIX-format. Den ger förstklassig integrering med Azure AD för detaljerad åtkomstkontroll. Det finns inga gränser för storleken på data som den kan lagra, eller dess möjlighet att köra massivt parallella analyser.

Mer information finns i följande artiklar:

Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 är det senaste lagringserbjudandet. Den förenar kärnfunktionerna från den första generationen av Azure Data Lake Storage Gen1 med en Hadoop-kompatibel filsystemslutpunkt direkt integrerad i Azure Blob Storage. Den här förbättringen kombinerar skalnings- och kostnadsfördelarna med objektlagring med den tillförlitlighet och prestanda som vanligtvis endast associeras med lokala filsystem.

Azure Data Lake Storage Gen 2 bygger på Azure Blob Storage och gör att du kan interagera med data med hjälp av både filsystem och objektlagringsparadigm. Funktioner från Azure Data Lake Storage Gen1, till exempel filsystemssemantik, säkerhet på filnivå och skalning kombineras med låg kostnad, nivåindelad lagring, funktioner för hög tillgänglighet/haveriberedskap och ett stort SDK/verktygsekosystem från Azure Blob Storage. I Data Lake Storage Gen2 finns alla egenskaper för objektlagring kvar samtidigt som du lägger till fördelarna med ett filsystemgränssnitt som är optimerat för analysarbetsbelastningar.

En grundläggande funktion i Data Lake Storage Gen2 är tillägget av ett hierarkiskt namnområde i Blob Storage-tjänsten, som organiserar objekt/filer i en hierarki med kataloger för högpresterande dataåtkomst. Den hierarkiska strukturen gör att åtgärder som att byta namn på eller ta bort en katalog kan vara åtgärder för enskilda atomiska metadata i katalogen i stället för att räkna upp och bearbeta alla objekt som delar katalogens namnprefix.

Tidigare var molnbaserad analys tvungen att kompromissa när det gäller prestanda, hantering och säkerhet. De viktigaste funktionerna i Azure Data Lake Storage (ADLS) Gen2 är följande:

  • Hadoop-kompatibel åtkomst: Med Azure Data Lake Storage Gen2 kan du hantera och komma åt data precis som med ett Hadoop Distributed File System (HDFS). Den nya ABFS-drivrutinen är tillgänglig i alla Apache Hadoop-miljöer som ingår i Azure HDInsight. Med den här drivrutinen kan du komma åt data som lagras i Data Lake Storage Gen2.

  • En supermängd POSIX-behörigheter: Säkerhetsmodellen för Data Lake Gen2 har fullständigt stöd för ACL- och POSIX-behörigheter tillsammans med viss extra kornighet som är specifik för Data Lake Storage Gen2. Inställningar kan konfigureras via administratörsverktyg eller via ramverk som Hive och Spark.

  • Kostnadseffektivt: Data Lake Storage Gen2 har lagringskapacitet och transaktioner till låg kostnad. När data övergår genom hela livscykeln ändras faktureringspriserna för att minimera kostnaderna via inbyggda funktioner som Livscykel för Azure Blob Storage.

  • Fungerar med Blob Storage-verktyg, ramverk och appar: Data Lake Storage Gen2 fortsätter att fungera med en mängd olika verktyg, ramverk och program som finns i dag för Blob Storage.

  • Optimerad drivrutin: Drivrutinen för Azure Blob Filesystem (ABFS) är optimerad specifikt för stordataanalys. Motsvarande REST-API:er visas via dfs-slutpunkten dfs.core.windows.net.

Ett av följande format kan användas för att komma åt data som lagras i ADLS Gen2:

  • abfs:///: Få åtkomst till Data Lake Storage som är standard för klustret.
  • abfs://file_system@account_name.dfs.core.windows.net: Används vid kommunikation med en Data Lake Storage som inte är standard.

Mer information finns i följande artiklar:

Skydda Azure Storage-nycklar i lokal Hadoop-klusterkonfiguration

Azure Storage-nycklarna som läggs till i Hadoop-konfigurationsfilerna upprättar anslutningen mellan lokal HDFS och Azure Blob Storage. Dessa nycklar kan skyddas genom att de krypteras med Hadoop-ramverket för autentiseringsuppgifter. När de har krypterats kan de lagras och nås på ett säkert sätt.

Så här etablerar du autentiseringsuppgifterna:

hadoop credential create fs.azure.account.key.account.blob.core.windows.net -value <storage key> -provider jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks/file

Så här lägger du till providersökvägen ovan till core-site.xml eller till Ambari-konfigurationen under custom core-site:

<property>
    <name>hadoop.security.credential.provider.path</name>
        <value>
        jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks
        </value>
    <description>Path to interrogate for protected credentials.</description>
</property>

Anteckning

Egenskapen providersökväg kan också läggas till i distcp-kommandoraden i stället för att lagra nyckeln på klusternivå på core-site.xml enligt följande:

hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks /user/user1/ wasb:<//yourcontainer@youraccount.blob.core.windows.net/>user1

Begränsa Åtkomst till Azure Storage-data med hjälp av SAS

HDInsight har som standard fullständig åtkomst till data i De Azure Storage-konton som är associerade med klustret. Signaturer för delad åtkomst (SAS) i blobcontainern kan användas för att begränsa åtkomsten till data, till exempel ge användare skrivskyddad åtkomst till data.

Använda SAS-token som skapats med Python

  1. Öppna filen SASToken.py och ändra följande värden:

    Tokenegenskap Description
    policy_name Det namn som ska användas för den lagrade principen som ska skapas.
    storage_account_name Namnet på ditt lagringskonto.
    storage_account_key Nyckeln för lagringskontot.
    storage_container_name Containern i lagringskontot som du vill begränsa åtkomsten till.
    example_file_path Sökvägen till en fil som laddas upp till containern.
  2. Den SASToken.py filen innehåller behörigheterna ContainerPermissions.READ + ContainerPermissions.LIST och kan justeras baserat på användningsfallet.

  3. Kör skriptet på följande sätt: python SASToken.py

  4. Den visar SAS-token som liknar följande text när skriptet har slutförts: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Om du vill begränsa åtkomsten till en container med signatur för delad åtkomst lägger du till en anpassad post i kärnplatskonfigurationen för klustret under egenskapen Ambari HDFS Configs Advanced Custom core-site Add .

  6. Använd följande värden för fälten Nyckel och Värde :

    Nyckel: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netVärde: SAS-nyckeln som returneras av Python-programmet FRÅN steg 4 ovan.

  7. Klicka på knappen Lägg till för att spara den här nyckeln och värdet och klicka sedan på knappen Spara för att spara konfigurationsändringarna. När du uppmanas till det lägger du till en beskrivning av ändringen (t.ex. lägger till SAS-lagringsåtkomst) och klickar sedan på Spara.

  8. I Ambari-webbgränssnittet väljer du HDFS i listan till vänster och väljer sedan Starta om alla som påverkas i listrutan Tjänståtgärder till höger. När du uppmanas väljer du Bekräfta starta om alla.

  9. Upprepa den här processen för MapReduce2 och YARN.

Det finns tre viktiga saker att komma ihåg när du använder SAS-token i Azure:

  1. När SAS-token skapas med behörigheterna "READ + LIST" kan användare som har åtkomst till blobcontainern med den SAS-token inte "skriva och ta bort" data. Användare som har åtkomst till blobcontainern med den SAS-token och provar en skrivnings- eller borttagningsåtgärd får ett meddelande som "This request is not authorized to perform this operation".

  2. När SAS-token genereras med READ + LIST + WRITE behörigheter (endast för att begränsa DELETE ), skriver kommandon som hadoop fs -put först till en \_COPYING\_ fil och försöker sedan byta namn på filen. Den här HDFS-åtgärden mappar till en copy+delete för WASB. Eftersom behörigheten DELETE inte angavs skulle "put" misslyckas. Åtgärden \_COPYING\_ är en Hadoop-funktion som är avsedd att ge viss samtidighetskontroll. För närvarande finns det inget sätt att begränsa bara åtgärden "DELETE" utan att påverka "WRITE"-åtgärder också.

  3. Tyvärr fungerar inte providern för hadoop-autentiseringsuppgifter och dekrypteringsnyckelprovidern (ShellDecryptionKeyProvider) för närvarande inte med SAS-token och kan för närvarande inte skyddas från synlighet.

Mer information finns i Använda Signaturer för delad åtkomst i Azure Storage för att begränsa åtkomsten till data i HDInsight.

Använda datakryptering och replikering

Alla data som skrivs till Azure Storage krypteras automatiskt med hjälp av Kryptering för lagringstjänst (SSE). Data i Azure Storage-kontot replikeras alltid för hög tillgänglighet. När du skapar ett lagringskonto kan du välja något av följande replikeringsalternativ:

Azure Storage tillhandahåller lokalt redundant lagring (LRS), men du bör också kopiera kritiska data till ett annat Azure Storage-konto i en annan region med en frekvens som är anpassad efter behoven i haveriberedskapsplanen. Det finns olika metoder för att kopiera data, inklusive ADLCopy, DistCp, Azure PowerShell eller Azure Data Factory. Vi rekommenderar också att du framtvingar åtkomstprinciper för Azure Storage-kontot för att förhindra oavsiktlig borttagning.

Mer information finns i följande artiklar:

Koppla ytterligare Azure Storage-konton till klustret

När HDInsight skapas väljs ett Azure Storage-konto, Azure Data Lake Storage Gen1 eller Azure Data Lake Storage Gen2 som standardfilsystem. Utöver det här standardlagringskontot kan ytterligare lagringskonton läggas till från samma Azure-prenumeration eller olika Azure-prenumerationer när klustret skapas eller när ett kluster har skapats.

Ytterligare lagringskonto kan läggas till på ett på följande sätt:

  • Ambari HDFS Config Advanced Custom Core-site Lägg till lagringskontots namn och nyckel Starta om tjänsterna
  • Använda skriptåtgärden genom att skicka lagringskontots namn och nyckel

Anteckning

I giltiga användningsfall kan gränserna för Azure Storage ökas via en begäran till Azure-supporten.

Mer information finns i Add additional storage accounts to HDInsight (Lägga till fler lagringskonton till HDInsight).

Nästa steg

Läs nästa artikel i den här serien: Metodtips för datamigrering för migrering lokalt till Azure HDInsight Hadoop-migrering.