Apache HBase-migrering till Azure

Apache HBase är ett Java-baserat, NoSQL-kolumnarkiv, distribuerat program som bygger på Hadoop Distributed File System (HDFS). Den modelleras efter Googles Bigtable och ger de flesta bigtable-funktionerna till Hadoop-ekosystemet.

HBase är ett distribuerat system. Ur ett CAP-satsperspektiv är det utformat för konsekvens och partitionering. När det gäller arbetsbelastningsprofilen är den utformad för att fungera som ett datalager för dataintensiva program som kräver låg svarstid och slumpmässiga läsningar och skrivningar i nära realtid.

I den här artikeln beskrivs komponenter och principer som spelar en roll i planeringen och skapandet av ett HBase-kluster i Azure för en migrering. Diskussionen är särskilt relevant för dessa migreringsmål:

• Apache HBase i Azure HDInsight
• Azure IaaS genom att göra en lift and shift till virtuella datorer (VM)
• Azure Cosmos DB.

Apache, Apache Spark®, Apache Hadoop®, Apache HBase, Apache Ranger®, Apache ZooKeeper®, Apache Sqoop®, Apache Kafka® 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.

HBase-komponenter, grundläggande begrepp och arkitektur

HBase följer en modell för ledare/följare. I det här avsnittet beskrivs de komponenter och noder som finns i en HBase-distribution.

Komponenter

De viktigaste HBase-komponenterna är huvudservern, ZooKeeper-noderna och RegionServers.

Huvudserver

Huvudservern ansvarar för alla metadataåtgärder för ett HBase-kluster. Detta omfattar skapande och borttagning av objekt, övervakning av RegionServers och andra åtgärder. Det finns vanligtvis två huvudservrar som distribueras för hög tillgänglighet.

ZooKeeper-noder

ZooKeeper är en centraliserad tjänst för att underhålla konfigurationsinformation, namnge, tillhandahålla distribuerad synkronisering och tillhandahålla grupptjänster. Dessa funktioner behövs för samordning i en distribuerad programmiljö, till exempel HBase.

RegionServers

RegionServers ansvarar för att hantera regioner eller partitioner. En RegionServer utför merparten av bearbetningen av en klients läs- eller skrivbegäran. I en distribuerad distribution av HBase körs en RegionServer på en HDFS DataNode.

Huvudkoncept

Det är viktigt att du förstår huvudbegreppen i HBase-arkitekturen och datamodellen så att du kan optimera en HBase-distribution.

• Datamodell
• Skrivsökväg
• Lässökväg
• Läs- och skrivvägar utanför heap

Datamodell

• Namnområde: En logisk gruppering av tabeller, till exempel en databas i ett relationsdatabassystem. Namnområden möjliggör flera funktioner som är relaterade till flera innehavare.
• Tabell: En gruppering eller samling rader. Tabeller lagras i regioner eller partitioner som är spridda över RegionServers.
• Rad: En rad består av en radnyckel och en gruppering av kolumner som kallas för en kolumnfamilj. Rader sorteras och lagras baserat på radnyckeln.
• Kolumnfamilj: En gruppering av kolumner som har samma prefix.
• Cell: En dataplats som unikt identifieras av en tuppeln {row, column, version}.
• Datamodellåtgärder: Det finns fyra primära datamodellåtgärder:
  • Hämta returnerar attribut för en angiven rad.
  • Placera lägger till nya rader i en tabell eller uppdaterar befintliga rader.
  • Genomsökning tillåter iteration över flera rader för angivna attribut.
  • Ta bort tar bort en rad från en tabell. En markör, kallad tombstone, placeras på poster för att markera dem för borttagning. Gravstenarna och borttagna raderna tas bort under större komprimeringar.

Följande diagram illustrerar dessa begrepp.

Skrivsökväg

HBase använder en kombination av datastrukturer som finns i minnet och i beständig lagring för att leverera snabba skrivningar. När en skrivning sker skrivs data först till en logg (WAL) som är en datastruktur som lagras på beständig lagring. WAL:s roll är att spåra ändringar så att loggarna kan spelas upp igen vid ett serverfel. WAL används endast för återhämtning. När data har checkats in på WAL skrivs de till MemStore, som är en minnesintern datastruktur. I det här skedet är en skrivning klar.

För långsiktig datapersistence använder HBase en datastruktur som kallas HBase-fil (HFile). En HFile lagras på HDFS. Beroende på MemStore-storlek och dataspolningsintervall skrivs data från MemStore till en HFile. Information om formatet för en HFile finns i Bilaga G: HFile-format.

Följande diagram visar stegen i en skrivåtgärd.

För att sammanfatta är komponenterna på skrivsökvägen:

• WAL är en datastruktur som lagras på beständig lagring.
• MemStore är en minnesintern datastruktur på heap.
• HFile är en HBase-fil som lagras på HDFS och används för datapersistence.

Lässökväg

HBase använder flera datastrukturer för att leverera snabba slumpmässiga och sekventiella läsningar. HBase försöker uppfylla läsbegäranden från data som cachelagras i BlockCache och, om så inte är det, från MemStore. Båda lagras på högen. Om data inte är tillgängliga från cachen hämtas de från en HFile och cachelagras i BlockCache.

Följande diagram visar stegen i en läsåtgärd.

Läs- och skrivvägar utanför heap

För att minska svarstiderna för läsning och skrivning har HBase version 2.x och senare en pool med buffertar utanför heap som används för att skriva och läsa. Arbetsflödet för att skriva och läsa data gör sitt bästa för att undvika minnesallokeringar på heap för att minska mängden arbete som skräpinsamling måste göra för att slutföra läsningar och skrivningar. Buffertarna måste optimeras eftersom deras användning beror mycket på faktorer som antalet regioner och RegionServrar, minnesstorlek och premiumlagring som är kopplat till HBase-klustret i Azure. Dessa parametrar är inte nödvändigtvis samma i det migrerade systemet som i källsystemet.

Utmaningar med att köra HBase lokalt

De här vanliga utmaningarna med lokala HBase-distributioner kan vara orsaker till att du vill eller behöver migrera HBase till molnet:

• Uppnå skalbarhet, vilket kan vara svårt beroende på maskinvaru- och datacenterkapacitet.
• Behöva ersätta maskinvara eller migrera program på grund av att stödet för åldrande infrastruktur upphör.
• Uppnå hög tillgänglighet och haveriberedskap av orsaker som:
  • Brist på datacenterwebbplatser
  • Fel i HBase-klustret när huvudservern, en felpunkt, misslyckas.
• Att uppnå hög produktivitet, eftersom ett lokalt Hadoop-ekosystem är komplext, svårt att hantera och utsatt för fel.
• Bristen på inbyggda verktyg för:
  • Kostnadstransparens
  • Övervakning
  • DevOps
  • Automation

Överväganden för en HBase-migrering

• Om migrering av HBase-infrastruktur som en tjänst (IaaS) är din första arbetsbelastning i Azure rekommenderar vi starkt att du investerar tid och arbete som krävs för att skapa en stark grund för att hantera arbetsbelastningar i Azure. Du gör detta med hjälp av vägledningen i Cloud Adoption Framework i företagsskala för landningszoner. Företagsskala är en arkitekturmetod och en referensimplementering som gör det möjligt att effektivt konstruera och operationalisera landningszoner i Azure i stor skala. Mer information finns i Vad är en Azure-landningszon?.
• Vi rekommenderar starkt att alla arbetsbelastningar som du kör i Azure utformas och distribueras enligt Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Ramverket består av fem grundpelare för arkitekturens excellens: kostnadsoptimering, driftseffektivitet, prestandaeffektivitet, tillförlitlighet och säkerhet.
• När du utformar och väljer Azure-beräkning och lagring bör du överväga tjänstbegränsningar. Beräkning och lagring har gränser som kan påverka storleken på infrastrukturen för ett dataintensivt program, till exempel HBase. Läs mer i Azure-prenumeration och tjänstbegränsningar, kvoter och begränsningar.
• En prenumeration ska användas som en skalningsenhet. Du lägger till fler instanser av en tjänst för att skala ut efter behov. Använd prenumerationen som en enhet för hantering och skalning med hjälp av designprinciper i Cloud Adoption Framework i företagsskala. Anpassa prenumerationer efter affärsbehov och prioriteringar samt stödja affärsområden och portföljägare för att uppmuntra migrering av aktuella program och utveckling av nya.
• En HBase-distribution i Azure kan använda olika typer av lagring för cachelagring och beständig lagring. Utvärdera alternativen när du distribuerar HBase-lösningar i Azure.
• När du har migrerat till Azure IaaS måste du optimera prestanda och rätt storlek på infrastrukturen. Det finns många faktorer som påverkar prestanda, inklusive storleken på infrastrukturen, lagringstyperna och fördelningen av regioner. Även om du minimerar programändringar när du migrerar skiljer sig en Azure-miljö i grunden från en lokal miljö. Det finns Azure-funktioner och -gränser att tänka på för att uppfylla prestandakraven.

Migreringsmetoder

Azure har flera landningsmål för Apache HBase. Beroende på krav och produktfunktioner kan du välja mellan Azure IaaS (lift and shift to VMs), HBase i HDInsight och Azure Cosmos DB (NoSQL API).

Här är ett beslutsflödesschema för att välja en målmiljö:

Dessa mål beskrivs i följande avsnitt:

• Migrera till Azure IaaS
• Migrera till HBase i HDInsight
• Migrera till Azure Cosmos DB (NoSQL API)

Migrera till Azure IaaS

Migrering av HBase till Azure IaaS kräver följande aktiviteter:

• Utvärdera den befintliga distributionen och besluta om krav
• Överväg alternativ för virtuella datorer
• Överväg lagringsalternativ
• Migrera data
• Upprätta säkerhet
• Övervaka HBase-distributionen

Utvärdera den befintliga distributionen och besluta om krav

Följande tabell innehåller vägledning om hur du utvärderar den befintliga distributionen av HBase och om hur du fastställer en uppsättning krav för en HBase-migrering till Azure.

Skikt	Characteristic	Bakgrund
Infrastruktur	Antal servrar för varje typ av roll: HBase Master, RegionServer, ZooKeeper-nod	Förstå skala och design för den befintliga lösningen.
	Antal kärnor per server	lscpu Använd kommandot eller cat /proc/cpuinfo för att lista kärnor per server.
	Minne per server	I Linux använder free -mg eller cat /proc/meminfo rapporterar du minne på varje server.
	Virtualiseras eller distribueras den befintliga miljön på servrar utan operativsystem?	Den här informationen används för att storleksanpassa och förstå prestandaegenskaperna för den lokala HBase-miljön.
	Konfiguration av nätverk	Förstå nätverksbandbredden som varje virtuell dator kan stödja och om en särskild nätverkskortskonfiguration används för att stödja hög bandbredd mellan HBase-servrar. Använd följande kommandon för att extrahera information om vm-nätverkskonfiguration: ifconfig -a eller ethtool <name of the interface>.
	Storage-konfiguration	Vilken är den totala storleken på data inklusive repliker? Standardkonfigurationen för HDFS replikerar vanligtvis data tre gånger. HDFS CLI kan användas för att extrahera den totala storleken på data som sparas av HBase: hdfs dfs -du -h hdfs://<data node address>/HBase Upprätta även mål för lagringsprestanda (IOPS och dataflöde). Den här informationen används för att etablera lagring och för att förstå den dataflödesnivå som krävs för att stödja Azure-distributionen.
Operativsystem	Version och distributionstyp	Följande kommando skriver ut information om Linux-distributionen och versionen: uname -a
	Kernelparametrar	Se anteckningen som följer den här tabellen.
Program	De versioner av HBase- och Hadoop-distributioner, till exempel Hortonworks och Cloudera, som används	Distributionen är vanligtvis något av följande: HortonWorks, Cloudera, MapR eller en version med öppen källkod av Hadoop och HBase. Använd följande kommandon för att ta reda på versionerna av HBase och Hadoop: hbase version och hdfs version.
	HBase-specifik information: antalet tabeller, metadata för varje tabell (regioner, kolumnfamilj)	Du kan extrahera information om HBase-distribution med hjälp av Ambari-användargränssnittet. Om det inte är tillgängligt kan du använda CLI: scan 'hbase:meta' {FILTER=>"PrefixFilter('tableName')", COLUMNS=>['info:regioninfo']}} Om du vill visa en lista över alla regioner som är associerade med en viss tabell använder du: list_regions '<table name>'
	JAVA-version (JDK)	java -version}
	Konfiguration av HBase-skräpinsamling	Vilken strategi för skräpinsamling används? De vanligaste är samtidig markeringssvepning (CMS) och skräp först (G1). Strategin anges i konfigurationsfilen hbase-env.sh . Ny forskning visar att G1 är mer effektivt för stora heapstorlekar.
Säkerhet och administration	Hur HBase används	Hur kommer användarna åt data i HBase? Är det genom att använda API:er eller direkt med hjälp av HBase-gränssnittet? Hur använder program data? Hur skrivs data till HBase och hur långt bort är HBase? Finns den i samma datacenter?
	Användaretablering	Hur autentiseras och auktoriseras användare? Här är några av möjligheterna: •Kommandosoldat •Knox • Kerberos
	Kryptering	Finns det ett krav på att kryptera data? Under transport? I vila? Vilka krypteringslösningar används?
	Tokenisering	Finns det ett krav på att tokenisera data? Och i så fall hur? Populära tokeniseringsprogram är Protegrity och Vormetric.
	Regelefterlevnad	Finns det några särskilda regelkrav som gäller för HBase-arbetsbelastningar, till exempel CI-DSS eller HIPAA?
	Hanteringsprinciper för nycklar, certifikat och hemligheter	Vilka principer och verktyg används för att hantera hemligheter?
Hög tillgänglighet och haveriberedskap	Vad är servicenivåavtalet (SLA) och vilka är mål för återställningspunkt (RPO) och återställningstid (RTO) för HBase-källdistributionen?	Svaren påverkar utformningen av måldistributionen i Azure. Ska det till exempel finnas ett aktivt vänteläge eller en aktiv-aktiv regional distribution?
	Vilka är strategierna för affärskontinuitet (BC) och dataåterställning (DR) för HBase-arbetsbelastningar?	Beskriv BC- och DR-strategier och effekten om HBase inte är tillgängligt.
Data	Datastorlek och tillväxt	Hur mycket data migreras till HBase från början? Vad är den förväntade tillväxten efter 6, 12 och 18 månader? Den här informationen används för kapacitetsplanering och för storleksändring av klustret. Slutligen används det också för att optimera distributionskostnaderna.
	Inmatning	Hur skrivs data till HBase?
	Förbrukning	Hur används HBase-data? Är det med hjälp av API:er eller av en beräkningsmotor som HDInsight Spark eller Databricks Spark?
	Åtkomstmönster	Är trafiken på HBase läsintensiv eller skrivintensiv? Detta påverkar finjusteringen av de HBase-konfigurationsparametrar som definieras i hbase-site.xml filerna och hdfs-site.xml .

Det finns flera partnerlösningar som kan hjälpa till med utvärderingen. Unravel har lösningar som kan hjälpa dig att snabbspåra utvärdering för datamigreringar till Azure.

Överväg alternativ för virtuella datorer

Azure Virtual Machines är en av flera typer av skalbara beräkningsresurser på begäran som Azure erbjuder. Vanligtvis väljer du en virtuell dator när du behöver mer kontroll över databehandlingsmiljön än vad andra alternativ erbjuder.

När du utformar migreringen och väljer virtuella datorer bör du tänka på följande:

• Programresursernas namn
• Lagringsplatsen för resurserna
• Den virtuella datorns storlek
• Det högsta antalet virtuella datorer som kan skapas
• Operativsystemet som körs på den virtuella datorn
• Konfigurationen av den virtuella datorn när den startats
• Relaterade resurser som krävs för den virtuella datorn

Mer information finns i Vad behöver jag tänka på innan jag skapar en virtuell dator?.

Azure VM-familjer är optimerade för att passa olika användningsfall och för att ge en balans mellan beräkning (virtuella kärnor) och minne.

Typ	Storlek	beskrivning
Startnivå	A, Av2	Virtuella datorer i A-serien har processorprestanda och minneskonfigurationer som passar bäst för arbetsbelastningar på startnivå, till exempel utveckling och testning. De är ett billigt alternativ för att komma igång med Azure.
Generell användning	D, DSv2, Dv2	Dessa virtuella datorer har balanserade cpu-till-minne-förhållanden. De är idealiska för testning och utveckling, för små till medelstora databaser och för webbservrar som har låg till medelhög trafik.
Beräkningsoptimerad	F	Dessa virtuella datorer har ett högt cpu-till-minne-förhållande. De är bra för webbservrar med medelhög trafik, nätverksinstallationer, batchprocesser och programservrar.
Minnesoptimerad	Esv3, Ev3	Dessa virtuella datorer har ett högt förhållande mellan minne och CPU. De är bra för relationsdatabasservrar, medelstora till stora cacheminnen och minnesintern analys.

Mer information finns i Virtuella datorer i Azure.

HBase är utformat för att använda minne och premiumlagring (till exempel SSD) för att optimera databasprestanda.

• Den levereras med funktioner som BucketCache, vilket avsevärt kan förbättra läsprestanda. BucketCache lagras utanför heapen, så vi rekommenderar virtuella datorer som har högre förhållande mellan minne och CPU.
• Skrivsökvägen HBase skriver ändringar i en WAL, som är en datastruktur som sparas på ett lagringsmedium. Lagring av WAL på ett snabbt lagringsmedium, till exempel SSD, förbättrar skrivprestandan.
• HBase är utformat för att skala ut allt eftersom prestanda- och lagringskraven ökar.

Mer information om hur du ändrar storlek på virtuella Azure-datorer finns i Storlekar för virtuella datorer i Azure.

Baserat på överväganden för beräknings- och minnesbehov rekommenderar vi att du använder följande Azure-beräkningsfamiljetyper för de olika HBase-nodtyperna:

• HBase Master – För företagsdistributioner rekommenderar vi minst två huvudservrar för hög tillgänglighet. För ett stort HBase-kluster bör en DS5_v2 virtuell Azure-dator med 16 virtuella processorer (vCPU:er) och 56 GiB minne räcka för de flesta distributioner. För medelstora kluster rekommenderar vi minst 8 vCPU:er och 20 till 30 GiB minne.
• HDFS NameNode – Vi rekommenderar att du är värd för HDFS NameNodes på andra virtuella datorer än de som mastererna använder. Två NameNodes ska distribueras för hög tillgänglighet. För huvudservrar rekommenderar vi DS5_v2 virtuella datorer för stora kluster i produktionsklass.
• HBase RegionServer – Vi rekommenderar att du använder virtuella Azure-datorer med ett högt förhållande mellan minne och CPU. HBase har flera funktioner som använder minne för att förbättra läs- och skrivtiderna. Virtuella datorer som DS14_v2 eller DS15_v2 är bra utgångspunkter. HBase är utformat för att skala ut genom att lägga till RegionServers för att förbättra prestanda.
• ZooKeeper – HBase förlitar sig på ZooKeeper för åtgärder. En virtuell Azure-dator med 4 till 8 vCPU:er och 4 till 8 GiB-minne är en bra utgångspunkt. Se till att det finns lokal lagring tillgänglig. ZooKeeper-noder bör distribueras på sina egna virtuella datorer.

Överväg lagringsalternativ

Azure erbjuder flera lagringsalternativ som passar för en IaaS-distribution av HBase. Följande flödesschema använder funktioner i olika alternativ för att välja ett lagringsalternativ. Varje lagringsalternativ i Azure har olika prestanda-, tillgänglighets- och kostnadsmål.

Mer information finns i de här artiklarna:

• Azure Managed Disks
• Azure Premium SSD
• Azure Disk Encryption

I en hybridlagringsmodell använder vi en blandning av lokal lagring och fjärrlagring för att hitta en balans mellan prestanda och kostnad. Det vanligaste mönstret är att placera HBase WAL, som är på skrivsökvägen, på lokalt ansluten Azure Premium SSD Managed Disk. Långsiktiga data eller HFiles lagras på Premium SSD eller Standard SSD beroende på kostnads- och prestandamål.

Det finns två viktiga faktorer som påverkar storleken på HBase-lagring: datavolym och dataflöde för läsningar och skrivningar. Dessa faktorer påverkar också valet av storlek och siffror för virtuella Azure-datorer och Azure Storage (Managed Disk eller Data Lake Storage).

• Datavolym

  Det här är de data som måste sparas på HBase. Data sparas i underliggande lagring. När vi refererar till mängden data, för storleks- och planeringsändamål, innehåller volymen rådata och 3x-replikering. Total lagringsstorlek är det mått som vi använder för att driva volymen.

• Dataflöde för läsningar och skrivningar

  Det här är den hastighet med vilken HBase skriver och läser data. IOPS- och I/O-storlek är de två mått som driver detta.

Om du planerar en greenfield-distribution av HBase på Azure IaaS och det inte finns någon referenspunkt när det gäller befintliga distributioner rekommenderar vi att du använder följande storleksändring och sedan lägger till RegionServers när datavolymen eller behovet av högre dataflöde växer. Virtuella datorer i Ds-serien och Es-serien passar bra för en HBase RegionServer. För HBase Master- och ZooKeeper-noder rekommenderar vi att du använder mindre virtuella datorer i Ds-serien.

För bättre storleksnoggrannhet och för att upprätta en prestandabaslinje rekommenderar vi att du kör tester på Azure IaaS med hjälp av mönstret HBase-datamängd, modell och arbetsbelastning. Om det inte går att flytta data rekommenderar vi att du använder benchmarkingverktyg som Yahoo! Cloud Serving Benchmark (YCSB) för att generera syntetiska data och simulera sekventiell och slumpmässig I/O-trafik. Avsikten med den här övningen är att få en förståelse för vilken prestandanivå du kan förvänta dig med hjälp av en kombination av Azure-beräkning och Premium SSD. Testerna bör innehålla dagliga arbetsbelastningsmönster och särskilda fall, till exempel arbetsbelastningar som kan orsaka en ökning av resursanvändningen, till exempel aktiviteter vid månadsslut och årsslut. Till exempel observerar en återförsäljare som använder HBase toppar i resursanvändningen under semesterperioder, medan en leverantör av finansiella tjänster observerar toppar under viktiga finansiella perioder.

Indata från utvärderingsaktiviteter och prestandabaslinjer bör ge en ganska exakt vy över storleksändring på Azure IaaS. På grund av arbetsbelastningarnas natur finns det utrymme för att optimera åtgärder genom att skala ut eller skala in kluster när de har gått live. Vi rekommenderar att du bekantar dig med olika tekniker för kostnadsoptimering för att optimera kostnader och åtgärder.

Migrera data

I följande tabell visas datamigreringsmetoder för olika situationer.

Mönster	Migreringsmetod	Överväganden
Massinläsningsscenarier där källdata inte läses från en HBase-instans. Källdata är till exempel i ett filformat som CSV, TSV eller Parquet, eller så är de i en databas eller ett egenutvecklat format.	Skapa en pipeline med verktyg som WANDisco och Databricks för att läsa källdata och skriva dem till HBase. Om data finns i ett filsystem eller i HDFS använder du verktyg som WANDisco, HDInsight Spark eller Databricks Spark för att läsa från källan och skriva till HBase i Azure. På hög nivå kan migreringspipelines skapas – en per måltabell på HBase – som extraherar data från källan och skriver dem först till Azure HDFS. Sedan kan en separat pipeline skapas för att läsa från Azure HDFS och skriva till Azure HBase.	Behov av separat infrastruktur för migreringsverktygets körning. Hantera krypterings- och tokeniseringskrav under datamigrering. Nätverksfördröjning mellan källa och mål (Azure HBase).
Källan är en HBase-instans, men den är inte samma HBase-version som för Azure-mål-HBase.	Eftersom källan också är ett HBase-datalager bör du överväga direkta datamigreringsalternativ för HBase från kluster till kluster, till exempel: • HBase CopyTable • Spark på HDInsight eller Databricks Spark • HBase Export Utility och HBase Import Utility • Verktyget HashTable/SyncTable Obs! CopyTable har stöd för fullständiga funktioner och funktioner för deltatabellkopiering.	Samma överväganden som för massinläsningar, plus några relaterade till specifika migreringsverktyg. För HBase CopyTable bör du överväga HBase-versionerna för käll- och måldistributionerna. Kluster måste vara online för både källan och målet. Ytterligare resurser krävs på källsidan för att stödja ytterligare lästrafik på HBase-källinstansen. Funktionen CopyTable kopierar som standard bara den senaste versionen av en radcell. Den kopierar också alla celler inom ett angivet tidsintervall. Det kan finnas ändringar på HBase-källan medan CopyTable körs. När detta inträffar kopieras eller ignoreras ändringarna helt eller helt. Spark i HDInsight och Databricks Spark kräver ytterligare resurser eller ett separat kluster för att migrera data, men det är en testad metod. Som standard kopierar HBase-exportverktyget alltid den senaste versionen av en cell till HBbase-målet. HashTable/SyncTable är effektivare än funktionen CopyTable.
Källan är en HBase-databas med samma HBase-version som HBase-målets.	Samma alternativ som används när versionerna skiljer sig åt HBase-ögonblicksbilder	De överväganden som redan nämnts för det fall där versionerna skiljer sig åt. För HBase-ögonblicksbilder är övervägandena följande. • Ögonblicksbilder skapar ingen kopia av data, men den skapar en referens tillbaka till HFiles. De refererade HFiles arkiveras separat om komprimering utlöses i den överordnade tabellen som refereras i en ögonblicksbild. • Fotavtrycket på käll- och mål-HBases när en ögonblicksbildsåterställning utlöses. • Hålla datakällan och HBase-målet synkroniserade under migreringen och planera sedan för den slutliga snabbningen. • Nätverksfördröjning mellan källan och målet.

Här är ett beslutsflödesschema som hjälper dig att välja datamigreringstekniker när du migrerar HBase till Azure:

Ytterligare läsning:

• Massinläsning (Apache HBase-referensguide)
• Import (Apache HBase-referensguide)
• CopyTable (Apache HBase-referensguide)
• HashTable/SyncTable (Apache HBase-referensguide)
• HBase-ögonblicksbilder (Apache HBase-referensguide)
• Core-API (SQL)
• Självstudie: Använda datamigreringsverktyget för att migrera dina data till Azure Cosmos DB
• Kopiera data från HBase med Azure Data Factory eller Synapse Analytics

Upprätta säkerhet

För att ett HBase-kluster ska fungera måste det kunna kommunicera med andra virtuella datorer i klustret. Detta inkluderar virtuella datorer som är värdar för Master, RegionServers och ZooKeeper.

Det finns olika sätt att göra det möjligt för servrar att autentisera mot varandra sömlöst. De vanligaste mönstren är:

• Kerberiserade Linux-servrar som är domänanslutna till en Windows-domänkontrollant
• En Kerberized Linux-miljö som använder Microsoft Entra Domain Services (Microsoft Entra Domain Services)
• En fristående MIT Kerberos-domänkontrollant
• Auktorisering med hjälp av Apache Ranger

Kerberized Linux-servrar som är domänanslutna till en Windows-domänkontrollant

Linux-servrar som är värdar för Apache Hadoop är domänanslutna till en Active Directory-domän. I den här konfigurationen ser vi att det inte finns något behov av att ha en separat värdbaserad Kerberos, eftersom den här funktionen finns i en Windows-domänkontrollant.

Överväganden:

• Plats för domänkontrollanten.
• Roller som tilldelats till domänkontrollanten.

Om domänkontrollanten finns lokalt eller utanför en Azure-region eller i ett icke-Azure-moln måste svarstiden beaktas för åtgärder som kräver interaktion med domänkontrollanten. Ett alternativ är att vara värd för en andra domänkontrollant i Azure. Den Azure-baserade domänkontrollanten används sedan för alla autentiserings- och auktoriseringsscenarier för arbetsbelastningar som körs i Azure. Vi rekommenderar att du inte tilldelar operations masters-roller till de domänkontrollanter som distribueras i Azure. I ett sådant scenario finns den primära domänkontrollanten lokalt.

En Kerberized Linux-miljö som använder Microsoft Entra Domain Services (Microsoft Entra Domain Services)

Microsoft Entra Domain Services tillhandahåller hanterade domäntjänster som domänanslutning, grupprincip, LDAP (Lightweight Directory Access Protocol) och Kerberos- och NTLM-autentisering. Du kan använda Microsoft Entra Domain Services utan att behöva distribuera, hantera och korrigera domänkontrollanter i molnet.

Överväganden:

• Regional tillgänglighet för Microsoft Entra Domain Services
• Nätverkskrav för Microsoft Entra Domain Services
• Hög tillgänglighet, haveriberedskap och serviceavtal för drifttid för Microsoft Entra Domain Services

En fristående MIT Kerberos-domänkontrollant

Det finns vissa distributioner av Hadoop som använder en fristående Kerberos-domänkontrollant, till exempel MIT Kerberos-domänkontrollanten, som distribueras på en separat uppsättning virtuella Azure-datorer för hög tillgänglighet. Information om distribution på Linux-servrar finns i Installera KDCs.

Överväganden för distribution av en MIT Kerberos-domänkontrollant:

• Hantera kontrollanten
• Hög tillgänglighet och haveriberedskap
• Riktlinjer för väldefinierade ramverk

Auktorisering med hjälp av Apache Ranger

Apache Ranger ger omfattande säkerhet i Apache Hadoop-ekosystemet. I samband med Apache HBase används Ranger för att skapa och distribuera principbaserad auktorisering.

Övervaka HBase-distributionen

För en lift and shift-migrering till Azure IaaS kan du använda samma övervakningstekniker som du använde i källsystemet. För andra migreringar finns det flera alternativ för övervakning av en fullständig HBase-stack i Azure IaaS:

• Apache Ambari för övervakning av Hadoop- och HBase-stacken
• Övervakning av Java Management Extensions (JMX) och Azure Monitor
• Loggning och mått för infrastruktur (VM, lagringsdiskar och nätverk)

Apache Ambari för övervakning av Hadoop- och HBase-stacken

Apache Ambari är ett projekt för att hantera distribuerade program som Hadoop och HBase. Den använder Ambari Metrics System för att tillhandahålla mått i Ambari-hanterade kluster. Ambari kan rapportera om mått som är specifika för HBase, till exempel klusterbelastning, nätverksanvändning, minnesanvändning och HBase Master-heap. Ambari-hanterade kluster levereras med instrumentpaneler för övervakningskluster.

Mer information finns i Apache Ambari. Detaljerad vägledning om hur du distribuerar Ambari-hanterade Hadoop- och HBase-kluster finns i 3. Installationsalternativ.

Övervakning av Java Management Extensions (JMX) och Azure Monitor

HBase- och Hadoop-processer körs på en virtuell Java-dator (JVM). En JVM har inbyggd instrumentering för att tillhandahålla övervakningsdata via JMX-API:et (Java Management Extensions). Du kan instrumentera program för att tillhandahålla data via JMX-API:et.

Förutom att exportera HBase-mått till standardutdataalternativen som Hadoop-måttpaketet stöder kan du även exportera via JMX-API:et. Detta gör det möjligt att visa HBase-statistik i JConsole och andra JMX-klienter.

Du kan använda en Log Analytics-agent för att samla in anpassade JSON-datakällor och lagra utdata i Log Analytics för rapportering av Azure Monitor:

• När Linux-servrar har distribuerats kan du installera och konfigurera Log Analytics-agenten för Linux. Mer information finns i Övervaka virtuella datorer med Azure Monitor.
• Konfigurera Log Analytics-agenten för att samla in anpassade JSON-data. Många JMX-slutpunkter tillhandahåller JSON som kan samlas in och parsas med hjälp av olika FluentD-plugin-program.
• Här är ett exempel på hur du konfigurerar plugin-program för indata och utdata för att samla in mått för skrivning till HBase RegionServer-WALs.

<source>
  type exec
  command 'curl -XGET http://<regionServerName>:16030/jmx?qry=Hadoop:service=hbase,name=RegionServer,sub=WAL'
  format json
  tag oms.api.metrics_regionserver
  run_interval 1m
</source>

<filter oms.api.metrics_regionserver>
  type filter_flatten
  select record['beans'][0]
</filter>

<match oms.api.metrics*>
  type out_oms_api
  log_level info

  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/state/out_oms_api*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 5s
  max_retry_wait 5m

  compress true
</match>

Med hjälp av exemplet ovan kan du skapa plugin-program för indata och utdata för listan nedan. Listan innehåller JMX-slutpunkter som du kan köra frågor mot för att extrahera mått för HBase Master och RegionServer.

curl -XGET http://<region_server>:16030/jmx?qry=Hadoop:service=hbase,name=RegionServer,sub=Server
curl -XGET http://<region_server>:16030/jmx?qry=Hadoop:service=hbase,name=RegionServer,sub=Replication
curl -XGET http://<rest_server>:8085/jmx?qry=Hadoop:service=hbase,name=REST
curl -XGET http://<rest_server>:8085/jmx?qry=Hadoop:service=hbase,name=JvmMetrics
curl -XGET http://<region_server>:16030/jmx?qry=Hadoop:service=hbase,name=RegionServer,sub=WAL
curl -XGET http://<region_server>:16030/jmx?qry=Hadoop:service=hbase,name=RegionServer,sub=IPC
curl -XGET http://<region_server>:16030/jmx?qry=Hadoop:service=hbase,name=JvmMetrics
curl -XGET http://<region_server>:16030/jmx?qry=java.lang:type=OperatingSystem
curl -XGET http://<HBase_master>:16010/jmx?qry=Hadoop:service=hbase,name=Master,sub=AssignmentManger
curl -XGET http://<HBase_master>:16010/jmx?qry=Hadoop:service=hbase,name=Master,sub=IPC
curl -XGET http://<HBase_master>:16010/jmx?qry=java.lang:type=OperatingSystem
curl -XGET http://<HBase_master>:16010/jmx?qry=Hadoop:service=hbase,name=Master,sub=Balancer
curl -XGET http://<HBase_master>:16010/jmx?qry=Hadoop:service=hbase,name=JvmMetrics
curl -XGET http://<HBase_master>:16010/jmx?qry=Hadoop:service=hbase,name=Master,sub=Server
curl -XGET http://<HBase_master>:16010/jmx?qry=Hadoop:service=hbase,name=Master,sub=FileSystem

När den har konfigurerats visas en källa under bladet Anpassade loggar. I kodfragmentet ovan använder vi namnet oms.api.metrics_regionservers på indata. Log Analytics använder följande format för att visa det anpassade tabellnamnet med en suffix_CL.

Loggning och mått för infrastruktur (VM, lagringsdiskar och nätverk)

Linux-distributioner levereras med flera verktyg, till exempel sar, för att samla in och rapportera mått. Även om de är bra för att övervaka hälsotillståndet för en enskild virtuell dator kan du inte förlita dig på dem för en stor distribution av Apache HBase i företagsklass. Vi rekommenderar att du använder Azure Monitor i stället. Den innehåller instrumentpaneler för övervakning av alla virtuella datorer.

Azure Monitor förlitar sig på Log Analytics-agenter. Det bör finnas en agent på varje virtuell dator. Agenten samlar in data som skrivs till Syslog och prestandadata från enskilda virtuella datorer. Den skickar data till Azure Log Analytics för lagring och indexering. Azure Monitor-instrumentpaneler hämtar sedan data från en konfigurerad Log Analytics-arbetsyta och visar administratörer en vy över övergripande hälsotillstånd för alla virtuella datorer. Det här är ett internt alternativ som kan aktiveras sömlöst för Linux-baserade virtuella Azure-datorer.

Anvisningar om hur du konfigurerar Azure Monitor för att samla in data från Linux finns i Övervaka virtuella datorer med Azure Monitor. När data har skrivits till Log Analytics kan du använda Kusto för att analysera dem. Mer information finns i Log Analytics-självstudien.

Migrera till HBase i HDInsight

Du kan ladda ned en detaljerad guide för att migrera HBase till ett HDInsight HBase-kluster. Nedladdningssidan är Guide to Migrating Big Data Workloads to Azure HDInsight (Migrera stordataarbetsbelastningar till Azure HDInsight).

Migrera till Azure Cosmos DB (NoSQL API)

Guiden för att migrera till Azure Cosmos NoSQL API är Migrera data från Apache HBase till Azure Cosmos DB NoSQL API-konto.

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 HDFS-migrering till Azure
• Apache Kafka-migrering till Azure
• Apache Sqoop-migrering till Azure