Dela via

Migrera data från Apache HBase till Azure Cosmos DB för NoSQL-konto

  • Artikel

GÄLLER FÖR: NoSQL

Azure Cosmos DB är en skalbar, globalt distribuerad, fullständigt hanterad databas. Det ger garanterad åtkomst till dina data med låg latens. Mer information om Azure Cosmos DB finns i översiktsartikeln. Den här artikeln beskriver hur du migrerar dina data från HBase till Azure Cosmos DB för NoSQL-konto.

Skillnader mellan Azure Cosmos DB och HBase

Innan du migrerar måste du förstå skillnaderna mellan Azure Cosmos DB och HBase.

Resursmodell

Azure Cosmos DB har följande resursmodell: Azure Cosmos DB-resursmodell med konto, databaser, containrar och objekt.

HBase har följande resursmodell: HBase-resursmodell med namnområde, tabeller, rader och kolumner.

Resursmappning

I följande tabell visas en konceptuell mappning mellan Apache HBase, Apache Phoenix och Azure Cosmos DB.

HBase Phoenix Azure Cosmos DB
Kluster Kluster Konto
Namnområde Schema (om aktiverat) Databas
Register Register Container/samling
Kolumnfamilj Kolumnfamilj Ej tillämpligt
Rad Rad Objekt/dokument
Version (tidsstämpel) Version (tidsstämpel) Saknas
Saknas Primärnyckel Partition Key (Partitionsnyckel)
Ej tillämpligt Index Index
Ej tillämpligt Sekundärt index Sekundärt index
Ej tillämpligt Visa Saknas
Saknas Sequence Ej tillämpligt

Jämförelse och skillnader i datastruktur

De viktigaste skillnaderna mellan datastrukturen i Azure Cosmos DB och HBase är följande:

RowKey

  • I HBase lagras data av RowKey och partitioneras vågrätt i regioner efter det radnyckelintervall som angavs när tabellen skapades.

  • Azure Cosmos DB på andra sidan distribuerar data till partitioner baserat på hash-värdet för en angiven partitionsnyckel.

Kolumnfamilj

  • I HBase grupperas kolumner inom en kolumnfamilj (CF).

  • Azure Cosmos DB (API för NoSQL) lagrar data som JSON-dokument . Därför gäller alla egenskaper som är associerade med en JSON-datastruktur.

Tidsstämpel

  • HBase använder tidsstämpel för att version flera instanser av en viss cell. Du kan köra frågor mot olika versioner av en cell med hjälp av tidsstämpel.

  • Azure Cosmos DB levereras med funktionen Ändringsflöde som spårar beständiga poster med ändringar i en container i den ordning de inträffar. Funktionen returnerar sedan den sorterade listan över dokument som ändrats i den ordning de ändrades.

Dataformat

  • HBase-dataformat består av RowKey, Kolumnfamilj: Kolumnnamn, Tidsstämpel, Värde. Följande är ett exempel på en HBase-tabellrad:

    ROW                                COLUMN+CELL
1000                              column=Office:Address, timestamp=1611408732448, value=1111 San Gabriel Dr.
1000                              column=Office:Phone, timestamp=1611408732418, value=1-425-000-0002
1000                              column=Personal:Name, timestamp=1611408732340, value=John Dole
1000                              column=Personal:Phone, timestamp=1611408732385, value=1-425-000-0001

  • I Azure Cosmos DB för NoSQL representerar JSON-objektet dataformatet. Partitionsnyckeln finns i ett fält i dokumentet och anger vilket fält som är partitionsnyckeln för samlingen. Azure Cosmos DB har inte begreppet tidsstämpel som används för kolumnfamilj eller -version. Som tidigare har markerats har den stöd för ändringsflöde där man kan spåra/registrera ändringar som utförts på en container. Följande är ett exempel på ett dokument.

    {
    "RowId": "1000",
    "OfficeAddress": "1111 San Gabriel Dr.",
    "OfficePhone": "1-425-000-0002",
    "PersonalName": "John Dole",
    "PersonalPhone": "1-425-000-0001",
}

Dricks

HBase lagrar data i bytematris, så om du vill migrera data som innehåller tecken med dubbla byte till Azure Cosmos DB måste data vara UTF-8-kodade.

Konsekvensmodell

HBase erbjuder strikt konsekventa läsningar och skrivningar.

Azure Cosmos DB erbjuder fem väldefinierade konsekvensnivåer. Varje nivå ger avvägningar för tillgänglighet och prestanda. Från starkast till svagaste är de konsekvensnivåer som stöds:

  • Stark
  • Begränsad föråldring
  • Session
  • Konsekvent prefix
  • Eventuell

Beräkning

HBase

För en distribution i företagsskala av HBase, Master; Regionservrar; och ZooKeeper kör huvuddelen av storleksändringen. Liksom alla distribuerade program är HBase utformat för att skala ut. HBase-prestanda drivs främst av storleken på HBase RegionServers. Storleksändringen drivs främst av två viktiga krav – dataflöde och storlek på den datauppsättning som måste lagras på HBase.

Azure Cosmos DB

Azure Cosmos DB är ett PaaS-erbjudande från Microsoft och information om underliggande infrastrukturdistribution abstraheras från slutanvändarna. När en Azure Cosmos DB-container etableras etablerar Azure-plattformen automatiskt underliggande infrastruktur (beräkning, lagring, minne, nätverksstacken) för att stödja prestandakraven för en viss arbetsbelastning. Kostnaden för alla databasåtgärder normaliseras av Azure Cosmos DB och uttrycks av enheter för begäran (eller RU:er, för kort).

Tänk på följande faktorer för att uppskatta RU:er som förbrukas av din arbetsbelastning:

Det finns en kapacitetskalkylator som hjälper dig med storleksträning för RU:er.

Du kan också använda dataflödet för automatisk skalningsetablering i Azure Cosmos DB för att automatiskt och omedelbart skala databasen eller containerdataflödet (RU/s). Dataflödet skalas baserat på användning utan att påverka arbetsbelastningens tillgänglighet, svarstid, dataflöde eller prestanda.

Datadistribution

HBase HBase sorterar data enligt RowKey. Data partitioneras sedan i regioner och lagras i RegionServers. Den automatiska partitioneringen delar upp regioner vågrätt enligt partitioneringsprincipen. Detta styrs av värdet som tilldelats till HBase-parametern hbase.hregion.max.filesize (standardvärdet är 10 GB). En rad i HBase med en viss RowKey tillhör alltid en region. Dessutom avgränsas data på disken för varje kolumnfamilj. Detta möjliggör filtrering vid tidpunkten för läsning och isolering av I/O på HFile.

Azure Cosmos DB Azure Cosmos DB använder partitionering för att skala enskilda containrar i databasen. Partitionering delar upp objekten i en container i specifika delmängder som kallas "logiska partitioner". Logiska partitioner skapas baserat på värdet för den "partitionsnyckel" som är associerad med varje objekt i containern. Alla objekt i en logisk partition har samma partitionsnyckelvärde. Varje logisk partition kan innehålla upp till 20 GB data.

Fysiska partitioner innehåller var och en en replik av dina data och en instans av Azure Cosmos DB-databasmotorn. Den här strukturen gör dina data hållbara och mycket tillgängliga och dataflödet delas lika mellan de lokala fysiska partitionerna. Fysiska partitioner skapas och konfigureras automatiskt och det går inte att styra storlek, plats eller vilka logiska partitioner de innehåller. Logiska partitioner delas inte mellan fysiska partitioner.

Precis som med HBase RowKey är partitionsnyckeldesign viktigt för Azure Cosmos DB. HBase-radnyckeln fungerar genom att sortera data och lagra kontinuerliga data, och Partitionsnyckeln för Azure Cosmos DB är en annan mekanism eftersom den hash-distribuerar data. Förutsatt att ditt program som använder HBase är optimerat för dataåtkomstmönster till HBase, ger inte samma RowKey för partitionsnyckeln bra prestandaresultat. Med tanke på att det är sorterade data på HBase kan det sammansatta Azure Cosmos DB-indexet vara användbart. Det krävs om du vill använda ORDER BY-satsen i mer än ett fält. Du kan också förbättra prestandan för många lika och intervallfrågor genom att definiera ett sammansatt index.

Tillgänglighet

HBase HBase består av Master; Regionserver; och ZooKeeper. Hög tillgänglighet i ett enda kluster kan uppnås genom att göra varje komponent redundant. När du konfigurerar geo-redundans kan man distribuera HBase-kluster över olika fysiska datacenter och använda replikering för att hålla flera kluster synkroniserade.

Azure Cosmos DB Azure Cosmos DB kräver ingen konfiguration, till exempel redundans för klusterkomponenter. Det ger ett omfattande serviceavtal för hög tillgänglighet, konsekvens och svarstid. Mer information finns i Serviceavtal för Azure Cosmos DB .

Datatillförlitlighet

HBase HBase bygger på Hadoop Distributed File System (HDFS) och data som lagras på HDFS replikeras tre gånger.

Azure Cosmos DB Azure Cosmos DB ger främst hög tillgänglighet på två sätt. Först replikerar Azure Cosmos DB data mellan regioner som konfigurerats i ditt Azure Cosmos DB-konto. För det andra behåller Azure Cosmos DB fyra repliker av data i regionen.

Överväganden innan du migrerar

Systemberoenden

Den här aspekten av planeringen fokuserar på att förstå uppströms- och nedströmsberoenden för HBase-instansen, som migreras till Azure Cosmos DB.

Exempel på underordnade beroenden kan vara program som läser data från HBase. Dessa måste omstruktureras för att kunna läsas från Azure Cosmos DB. Följande punkter måste betraktas som en del av migreringen:

  • Frågor om att utvärdera beroenden – är det aktuella HBase-systemet en oberoende komponent? Eller anropar den en process i ett annat system, eller anropas den av en process i ett annat system eller används den med hjälp av en katalogtjänst? Fungerar andra viktiga processer i ditt HBase-kluster? Dessa systemberoenden måste klargöras för att fastställa effekten av migreringen.

  • RPO och RTO för HBase-distribution lokalt.

Offline- och onlinemigrering

För lyckad datamigrering är det viktigt att förstå egenskaperna hos den verksamhet som använder databasen och bestämma hur den ska utföras. Välj offlinemigrering om du helt kan stänga av systemet, utföra datamigrering och starta om systemet på målet. Om databasen alltid är upptagen och du inte har råd med ett långt avbrott bör du överväga att migrera online.

Kommentar

Det här dokumentet beskriver endast offlinemigrering.

När du utför datamigrering offline beror det på vilken version av HBase du kör för närvarande och vilka verktyg som är tillgängliga. Mer information finns i avsnittet Datamigrering .

Prestandaöverväganden

Den här aspekten av planeringen är att förstå prestandamål för HBase och sedan översätta dem till Azure Cosmos DB-semantik. Om du till exempel vill trycka på "X" IOPS på HBase krävs hur många enheter för begäran (RU/s) som krävs i Azure Cosmos DB. Det finns skillnader mellan HBase och Azure Cosmos DB. Den här övningen fokuserar på att skapa en vy över hur prestandamål från HBase översätts till Azure Cosmos DB. Detta kommer att driva skalningsövningen.

Frågor att ställa:

  • Är HBase-distributionen läsintensiv eller skrivintensiv?
  • Vad är uppdelningen mellan läsningar och skrivningar?
  • Vad uttrycks mål-IOPS som percentil?
  • Hur/vilka program används för att läsa in data till HBase?
  • Hur/vilka program används för att läsa data från HBase?

När du kör frågor som begär sorterade data returnerar HBase resultatet snabbt eftersom data sorteras efter RowKey. Azure Cosmos DB har dock inget sådant begrepp. För att optimera prestandan kan du använda sammansatta index efter behov.

Att tänka på vid distribuering

Du kan använda Azure Portal eller Azure CLI för att distribuera Azure Cosmos DB för NoSQL. Eftersom migreringsmålet är Azure Cosmos DB för NoSQL väljer du "NoSQL" för API:et som en parameter när du distribuerar. Ange dessutom Geo-Redundans, Skrivningar i flera regioner och Tillgänglighetszoner enligt dina tillgänglighetskrav.

Nätverksövervägande

Azure Cosmos DB har tre huvudsakliga nätverksalternativ. Den första är en konfiguration som använder en offentlig IP-adress och styr åtkomsten med en IP-brandvägg (standard). Den andra är en konfiguration som använder en offentlig IP-adress och endast tillåter åtkomst från ett specifikt undernät för ett specifikt virtuellt nätverk (tjänstslutpunkt). Den tredje är en konfiguration (privat slutpunkt) som ansluter till ett privat nätverk med hjälp av en privat IP-adress.

Mer information om de tre nätverksalternativen finns i följande dokument:

Utvärdera dina befintliga data

Dataidentifiering

Samla in information i förväg från ditt befintliga HBase-kluster för att identifiera de data som du vill migrera. Dessa kan hjälpa dig att identifiera hur du migrerar, bestämmer vilka tabeller som ska migreras, förstår strukturen i dessa tabeller och bestämmer hur du skapar din datamodell. Samla till exempel in information, till exempel följande:

  • HBase-version
  • Migreringsmåltabeller
  • Information om kolumnfamilj
  • Tabellstatus

Följande kommandon visar hur du samlar in informationen ovan med hjälp av ett hbase-gränssnittsskript och lagrar dem i det lokala filsystemet på operativsystemdatorn.

Hämta HBase-versionen

hbase version -n > hbase-version.txt

Utdata:

cat hbase-version.txt
HBase 2.1.8.4.1.2.5

Hämta listan över tabeller

Du kan hämta en lista över tabeller som lagras i HBase. Om du har skapat ett annat namnområde än standard kommer det att matas ut i formatet "Namnområde: Tabell".

echo "list" | hbase shell -n > table-list.txt
HBase 2.1.8.4.1.2.5

Utdata:

echo "list" | hbase shell -n > table-list.txt
cat table-list.txt
TABLE
COMPANY
Contacts
ns1:t1
3 row(s)
Took 0.4261 seconds
COMPANY
Contacts
ns1:t1

Identifiera de tabeller som ska migreras

Hämta information om kolumnfamiljerna i tabellen genom att ange det tabellnamn som ska migreras.

echo "describe '({Namespace}:){Table name}'" | hbase shell -n > {Table name} -schema.txt

Utdata:

cat {Table name} -schema.txt
Table {Table name} is ENABLED
{Table name}
COLUMN FAMILIES DESCRIPTION
{NAME => 'cf1', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'}
{NAME => 'cf2', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'}
2 row(s)
Took 0.5775 seconds

Hämta kolumnfamiljerna i tabellen och deras inställningar

echo "status 'detailed'" | hbase shell -n > hbase-status.txt

Utdata:

{HBase version}
0 regionsInTransition
active master:  {Server:Port number}
2 backup masters
    {Server:Port number}
    {Server:Port number}
master coprocessors: []
# live servers
    {Server:Port number}
        requestsPerSecond=0.0, numberOfOnlineRegions=44, usedHeapMB=1420, maxHeapMB=15680, numberOfStores=49, numberOfStorefiles=14, storefileUncompressedSizeMB=7, storefileSizeMB=7, compressionRatio=1.0000, memstoreSizeMB=0, storefileIndexSizeKB=15, readRequestsCount=36210, filteredReadRequestsCount=415729, writeRequestsCount=439, rootIndexSizeKB=15, totalStaticIndexSizeKB=5, totalStaticBloomSizeKB=16, totalCompactingKVs=464, currentCompactedKVs=464, compactionProgressPct=1.0, coprocessors=[GroupedAggregateRegionObserver, Indexer, MetaDataEndpointImpl, MetaDataRegionObserver, MultiRowMutationEndpoint, ScanRegionObserver, SecureBulkLoadEndpoint, SequenceRegionObserver, ServerCachingEndpointImpl, UngroupedAggregateRegionObserver]

    [...]

        "Contacts,,1611126188216.14a597a0964383a3d923b2613524e0bd."
            numberOfStores=2, numberOfStorefiles=2, storefileUncompressedSizeMB=7168, lastMajorCompactionTimestamp=0, storefileSizeMB=7, compressionRatio=0.0010, memstoreSizeMB=0, readRequestsCount=4393, writeRequestsCount=0, rootIndexSizeKB=14, totalStaticIndexSizeKB=5, totalStaticBloomSizeKB=16, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, completeSequenceId=-1, dataLocality=0.0

[...]

Du kan få användbar storleksinformation, till exempel storleken på heapminnet, antalet regioner, antalet begäranden som status för klustret och storleken på data i komprimerat/okomprimerat som tabellens status.

Om du använder Apache Phoenix i HBase-kluster måste du också samla in data från Phoenix.

  • Migreringsmåltabell
  • Tabellscheman
  • Index
  • Primärnyckel

Ansluta till Apache Phoenix i klustret

sqlline.py ZOOKEEPER/hbase-unsecure

Hämta tabelllistan

!tables

Hämta tabellinformationen

!describe <Table Name>

Hämta indexinformationen

!indexes <Table Name>

Hämta information om primärnyckeln

!primarykeys <Table Name>

Migrera dina data

Migreringsalternativ

Det finns olika metoder för att migrera data offline, men här introducerar vi hur du använder Azure Data Factory.

Lösning Källversion Att tänka på
Azure Data Factory HBase < 2 Lätt att konfigurera. Lämplig för stora datamängder. Stöder inte HBase 2 eller senare.
Apache Spark Alla versioner Stöd för alla versioner av HBase. Lämplig för stora datamängder. Spark-konfiguration krävs.
Anpassat verktyg med Massexekutorbibliotek för Azure Cosmos DB Alla versioner Mest flexibel för att skapa anpassade datamigreringsverktyg med hjälp av bibliotek. Kräver mer arbete för att konfigurera.

I följande flödesschema används vissa villkor för att nå tillgängliga datamigreringsmetoder. Flödesschema för alternativ för att migrera data till Azure Cosmos DB.

Migrera med Data Factory

Det här alternativet är lämpligt för stora datamängder. Massexekutorbiblioteket för Azure Cosmos DB används. Det finns inga kontrollpunkter, så om du stöter på några problem under migreringen måste du starta om migreringsprocessen från början. Du kan också använda Data Factorys lokala integrationskörning för att ansluta till din lokala HBase eller distribuera Data Factory till ett hanterat VNET och ansluta till ditt lokala nätverk via VPN eller ExpressRoute.

Data Factorys aktiviteten Kopiera stöder HBase som datakälla. Mer information finns i artikeln Kopiera data från HBase med Azure Data Factory .

Du kan ange Azure Cosmos DB (API för NoSQL) som mål för dina data. Mer information finns i artikeln Kopiera och transformera data i Azure Cosmos DB (API för NoSQL) med hjälp av Azure Data Factory.

Arkitektur för att migrera data från en lokal plats till Azure Cosmos DB med hjälp av Data Factory.

Migrera med Apache Spark – Apache HBase Connector och Azure Cosmos DB Spark-anslutningsapp

Här är ett exempel för att migrera dina data till Azure Cosmos DB. Det förutsätter att HBase 2.1.0 och Spark 2.4.0 körs i samma kluster.

Apache Spark – Apache HBase Connector-lagringsplatsen finns på Apache Spark – Apache HBase Connector

För Azure Cosmos DB Spark-anslutningsappen läser du snabbstartsguiden och laddar ned lämpligt bibliotek för din Spark-version.

  1. Kopiera hbase-site.xml till spark-konfigurationskatalogen.

    cp /etc/hbase/conf/hbase-site.xml /etc/spark2/conf/

  2. Kör spark -shell med Spark HBase-anslutningsappen och Azure Cosmos DB Spark-anslutningsappen.

    spark-shell --packages com.hortonworks.shc:shc-core:1.1.0.3.1.2.2-1 --repositories http://repo.hortonworcontent/groups/public/ --jars azure-cosmosdb-spark_2.4.0_2.11-3.6.8-uber.jar

  3. När Spark-gränssnittet har startat kör du Scala-koden på följande sätt. Importera de bibliotek som behövs för att läsa in data från HBase.

    // Import libraries
import org.apache.spark.sql.{SQLContext, _}
import org.apache.spark.sql.execution.datasources.hbase._
import org.apache.spark.{SparkConf, SparkContext}
import spark.sqlContext.implicits._

  4. Definiera Spark-katalogschemat för dina HBase-tabeller. Här är namnområdet "standard" och tabellnamnet är "Kontakter". Radnyckeln anges som nyckel. Kolumner, Kolumnfamilj och Kolumn mappas till Sparks katalog.

    // define a catalog for the Contacts table you created in HBase
def catalog = s"""{
    |"table":{"namespace":"default", "name":"Contacts"},
    |"rowkey":"key",
    |"columns":{
    |"rowkey":{"cf":"rowkey", "col":"key", "type":"string"},
    |"officeAddress":{"cf":"Office", "col":"Address", "type":"string"},
    |"officePhone":{"cf":"Office", "col":"Phone", "type":"string"},
    |"personalName":{"cf":"Personal", "col":"Name", "type":"string"},
    |"personalPhone":{"cf":"Personal", "col":"Phone", "type":"string"}
    |}
|}""".stripMargin

  5. Definiera sedan en metod för att hämta data från tabellen HBase-kontakter som en DataFrame.

    def withCatalog(cat: String): DataFrame = {
    spark.sqlContext
    .read
    .options(Map(HBaseTableCatalog.tableCatalog->cat))
    .format("org.apache.spark.sql.execution.datasources.hbase")
    .load()
 }

  6. Skapa en DataFrame med den definierade metoden.

    val df = withCatalog(catalog)

  7. Importera sedan de bibliotek som behövs för att använda Azure Cosmos DB Spark-anslutningsappen.

    import com.microsoft.azure.cosmosdb.spark.schema._
import com.microsoft.azure.cosmosdb.spark._
import com.microsoft.azure.cosmosdb.spark.config.Config

  8. Gör inställningar för att skriva data till Azure Cosmos DB.

    val writeConfig = Config(Map(   "Endpoint" -> "https://<cosmos-db-account-name>.documents.azure.com:443/",   "Masterkey" -> "<comsmos-db-master-key>",   "Database" -> "<database-name>",   "Collection" -> "<collection-name>",   "Upsert" -> "true" ))

  9. Skriva DataFrame-data till Azure Cosmos DB.

    import org.apache.spark.sql.SaveMode df.write.mode(SaveMode.Overwrite).cosmosDB(writeConfig)

Det skriver parallellt med hög hastighet, dess prestanda är hög. Observera å andra sidan att den kan förbruka RU/s på Azure Cosmos DB-sidan.

Phoenix

Phoenix stöds som datakälla för Data Factory. Mer information finns i följande dokument.

Migrera din kod

I det här avsnittet beskrivs skillnaderna mellan att skapa program i Azure Cosmos DB för NoSQLs och HBase. Exemplen här använder Apache HBase 2.x API:er och Azure Cosmos DB Java SDK v4.

Dessa HBase-exempelkoder baseras på de som beskrivs i HBases officiella dokumentation.

Koden för Azure Cosmos DB som visas här baseras på dokumentationen om Azure Cosmos DB for NoSQL: Java SDK v4-exempel . Du kan komma åt det fullständiga kodexemplet i dokumentationen.

Mappningarna för kodmigrering visas här, men de HBase RowKeys- och Azure Cosmos DB-partitionsnycklar som används i dessa exempel är inte alltid väl utformade. Utforma enligt den faktiska datamodellen för migreringskällan.

Upprätta anslutning

HBase

Configuration config = HBaseConfiguration.create();
config.set("hbase.zookeeper.quorum","zookeepernode0,zookeepernode1,zookeepernode2");
config.set("hbase.zookeeper.property.clientPort", "2181");
config.set("hbase.cluster.distributed", "true");
Connection connection = ConnectionFactory.createConnection(config)

Phoenix

//Use JDBC to get a connection to an HBase cluster
Connection conn = DriverManager.getConnection("jdbc:phoenix:server1,server2:3333",props);

Azure Cosmos DB

// Create sync client
client = new CosmosClientBuilder()
    .endpoint(AccountSettings.HOST)
    .key(AccountSettings.MASTER_KEY)
    .consistencyLevel(ConsistencyLevel.{ConsistencyLevel})
    .contentResponseOnWriteEnabled(true)
    .buildClient();

Skapa databas/tabell/samling

HBase

// create an admin object using the config
HBaseAdmin admin = new HBaseAdmin(config);
// create the table...
HTableDescriptor tableDescriptor = new HTableDescriptor(TableName.valueOf("FamilyTable"));
// ... with single column families
tableDescriptor.addFamily(new HColumnDescriptor("ColFam"));
admin.createTable(tableDescriptor);

Phoenix

CREATE IF NOT EXISTS FamilyTable ("id" BIGINT not null primary key, "ColFam"."lastName" VARCHAR(50));

Azure Cosmos DB

//  Create database if not exists
CosmosDatabaseResponse databaseResponse = client.createDatabaseIfNotExists(databaseName);
database = client.getDatabase(databaseResponse.getProperties().getId());

//  Create container if not exists
CosmosContainerProperties containerProperties = new CosmosContainerProperties("FamilyContainer", "/lastName");

// Provision throughput
ThroughputProperties throughputProperties = ThroughputProperties.createManualThroughput(400);

//  Create container with 400 RU/s
CosmosContainerResponse databaseResponse = database.createContainerIfNotExists(containerProperties, throughputProperties);
container = database.getContainer(databaseResponse.getProperties().getId());

Skapa rad/dokument

HBase

HTable table = new HTable(config, "FamilyTable");
Put put = new Put(Bytes.toBytes(RowKey));

put.add(Bytes.toBytes("ColFam"), Bytes.toBytes("id"), Bytes.toBytes("1"));
put.add(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"), Bytes.toBytes("Witherspoon"));
table.put(put)

Phoenix

UPSERT INTO FamilyTable (id, lastName) VALUES (1, ‘Witherspoon’);

Azure Cosmos DB

Azure Cosmos DB ger typsäkerhet via datamodell. Vi använder datamodellen "Familj".

public class Family {
    public Family() {
    }

    public void setId(String id) {
        this.id = id;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    private String id="";
    private String lastName="";
}

Ovanstående är en del av koden. Se det fullständiga kodexemplet.

Använd klassen Familj för att definiera dokument och infoga objekt.

Family family = new Family();
family.setLastName("Witherspoon");
family.setId("1");

// Insert this item as a document
// Explicitly specifying the /pk value improves performance.
container.createItem(family,new PartitionKey(family.getLastName()),new CosmosItemRequestOptions());

Läs rad/dokument

HBase

HTable table = new HTable(config, "FamilyTable");

Get get = new Get(Bytes.toBytes(RowKey));
get.addColumn(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"));

Result result = table.get(get);

byte[]  col = result.getValue(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"));

Phoenix

SELECT lastName FROM FamilyTable;

Azure Cosmos DB

//  Read document by ID
Family family = container.readItem(documentId,new PartitionKey(documentLastName),Family.class).getItem();

String sql = "SELECT lastName FROM c";

CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(), Family.class);

Uppdatera data

HBase

För HBase använder du append-metoden och metoden checkAndPut för att uppdatera värdet. Tillägg är processen att lägga till ett värde atomiskt i slutet av det aktuella värdet och checkAndPut jämför det aktuella värdet atomiskt med det förväntade värdet och uppdateringarna endast om de matchar.

// append
HTable table = new HTable(config, "FamilyTable");
Append append = new Append(Bytes.toBytes(RowKey));
Append.add(Bytes.toBytes("ColFam"), Bytes.toBytes("id"), Bytes.toBytes(2));
Append.add(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"), Bytes.toBytes("Harris"));
Result result = table.append(append)

// checkAndPut
byte[] row = Bytes.toBytes(RowKey);
byte[] colfam = Bytes.toBytes("ColFam");
byte[] col = Bytes.toBytes("lastName");
Put put = new Put(row);
put.add(colfam, col, Bytes.toBytes("Patrick"));
boolearn result = table.checkAndPut(row, colfam, col, Bytes.toBytes("Witherspoon"), put);

Phoenix

UPSERT INTO FamilyTable (id, lastName) VALUES (1, ‘Brown’)
ON DUPLICATE KEY UPDATE id = "1", lastName = "Whiterspoon";

Azure Cosmos DB

I Azure Cosmos DB behandlas uppdateringar som Upsert-åtgärder. Det innebär att om dokumentet inte finns infogas det.

// Replace existing document with new modified document (contingent on modification).

Family family = new Family();
family.setLastName("Brown");
family.setId("1");

CosmosItemResponse<Family> famResp = container.upsertItem(family, new CosmosItemRequestOptions());

Ta bort rad/dokument

HBase

I Hbase finns det inget direkt borttagningssätt för att välja raden efter värde. Du kan ha implementerat borttagningsprocessen i kombination med ValueFilter osv. I det här exemplet anges raden som ska tas bort av RowKey.

HTable table = new HTable(config, "FamilyTable");

Delete delete = new Delete(Bytes.toBytes(RowKey));
delete.deleteColumn(Bytes.toBytes("ColFam"), Bytes.toBytes("id"));
delete.deleteColumn(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"));

table.dalate(delete)

Phoenix

DELETE FROM TableName WHERE id = "xxx";

Azure Cosmos DB

Borttagningsmetoden efter dokument-ID visas nedan.

container.deleteItem(documentId, new PartitionKey(documentLastName), new CosmosItemRequestOptions());

Fråga efter rader/dokument

Med HBase HBase kan du hämta flera rader med hjälp av genomsökning. Du kan använda Filter för att ange detaljerade genomsökningsvillkor. Se Filter för klientbegäran för inbyggda HBase-filtertyper.

HTable table = new HTable(config, "FamilyTable");

Scan scan = new Scan();
SingleColumnValueFilter filter = new SingleColumnValueFilter(Bytes.toBytes("ColFam"),
Bytes.toBytes("lastName"), CompareOp.EQUAL, New BinaryComparator(Bytes.toBytes("Witherspoon")));
filter.setFilterIfMissing(true);
filter.setLatestVersionOnly(true);
scan.setFilter(filter);

ResultScanner scanner = table.getScanner(scan);

Phoenix

SELECT * FROM FamilyTable WHERE lastName = "Witherspoon"

Azure Cosmos DB

Filteråtgärd

String sql = "SELECT * FROM c WHERE c.lastName = 'Witherspoon'";
CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(), Family.class);

Ta bort tabell/samling

HBase

HBaseAdmin admin = new HBaseAdmin(config);
admin.deleteTable("FamilyTable")

Phoenix

DROP TABLE IF EXISTS FamilyTable;

Azure Cosmos DB

CosmosContainerResponse containerResp = database.getContainer("FamilyContainer").delete(new CosmosContainerRequestOptions());

Övriga beaktanden

HBase-kluster kan användas med HBase-arbetsbelastningar och MapReduce, Hive, Spark med mera. Om du har andra arbetsbelastningar med din aktuella HBase måste de också migreras. Mer information finns i varje migreringsguide.

  • MapReduce
  • HBase
  • Spark

Programmering på serversidan

HBase erbjuder flera programmeringsfunktioner på serversidan. Om du använder de här funktionerna måste du också migrera bearbetningen.

HBase

  • Anpassade filter

    Olika filter är tillgängliga som standard i HBase, men du kan också implementera dina egna anpassade filter. Anpassade filter kan implementeras om filtren som är tillgängliga som standard på HBase inte uppfyller dina krav.

  • Coprocessor

    Coprocessorn är ett ramverk som gör att du kan köra din egen kod på regionservern. Med hjälp av coprocessorn är det möjligt att utföra bearbetningen som kördes på klientsidan på serversidan, och beroende på bearbetningen kan den göras mer effektiv. Det finns två typer av coprocessorer, Observer och Endpoint.

    • Observatör

      • Observatören kopplar specifika åtgärder och händelser. Det här är en funktion för att lägga till godtycklig bearbetning. Det här är en funktion som liknar RDBMS-utlösare.

    • Slutpunkt

      • Slutpunkten är en funktion för att utöka HBase RPC. Det är en funktion som liknar en RDBMS-lagrad procedur.

Azure Cosmos DB

  • Lagrad procedur

    • Lagrade Procedurer i Azure Cosmos DB skrivs i JavaScript och kan utföra åtgärder som att skapa, uppdatera, läsa, fråga och ta bort objekt i Azure Cosmos DB-containrar.

  • Utlösare

    • Utlösare kan anges för åtgärder i databasen. Det finns två metoder: en förutlösare som körs innan databasobjektet ändras och en efterutlösare som körs efter att databasobjektet har ändrats.

  • UDF

    • Med Azure Cosmos DB kan du definiera användardefinierade funktioner (UDF:er). UDF:er kan också skrivas i JavaScript.

Lagrade procedurer och utlösare förbrukar RU:er baserat på komplexiteten i de åtgärder som utförs. När du utvecklar bearbetning på serversidan kontrollerar du vilken användning som krävs för att få en bättre förståelse för mängden RU som förbrukas av varje åtgärd. Mer information finns i Enheter för begäranden i Azure Cosmos DB och Optimera kostnaden för begäran i Azure Cosmos DB .

Programmeringsmappningar på serversidan

HBase Azure Cosmos DB beskrivning
Anpassade filter WHERE-sats Om bearbetningen som implementeras av det anpassade filtret inte kan uppnås med WHERE-satsen i Azure Cosmos DB använder du UDF i kombination.
Coprocessor (Observatör) Utlösare Observer är en utlösare som körs före och efter en viss händelse. Precis som Observer stöder för- och efteranrop stöder Azure Cosmos DB:s utlösare även pre- och post-triggers.
Coprocessor (slutpunkt) Lagrad procedur Slutpunkten är en databehandlingsmekanism på serversidan som körs för varje region. Detta liknar en lagrad RDBMS-procedur. Lagrade Procedurer i Azure Cosmos DB skrivs med JavaScript. Den ger åtkomst till alla åtgärder som du kan utföra i Azure Cosmos DB via lagrade procedurer.

Kommentar

Olika mappningar och implementeringar kan krävas i Azure Cosmos DB beroende på vilken bearbetning som implementeras på HBase.

Säkerhet

Datasäkerhet är ett delat ansvar för kunden och databasleverantören. För lokala lösningar måste kunderna tillhandahålla allt från slutpunktsskydd till fysisk maskinvarusäkerhet, vilket inte är en lätt uppgift. Om du väljer en PaaS-molndatabasprovider, till exempel Azure Cosmos DB, minskar kundernas engagemang. Azure Cosmos DB körs på Azure-plattformen så att den kan förbättras på ett annat sätt än HBase. Azure Cosmos DB kräver inte att några extra komponenter installeras för säkerhet. Vi rekommenderar att du överväg att migrera din databassystemsäkerhetsimplementering med hjälp av följande checklista:

Säkerhetskontroll HBase Azure Cosmos DB
Nätverkssäkerhet och brandväggsinställning Kontrollera trafik med hjälp av säkerhetsfunktioner som nätverksenheter. Stöder principbaserad IP-baserad åtkomstkontroll i den inkommande brandväggen.
Användarautentisering och detaljerade användarkontroller Detaljerad åtkomstkontroll genom att kombinera LDAP med säkerhetskomponenter som Apache Ranger. Du kan använda kontots primära nyckel för att skapa användar- och behörighetsresurser för varje databas. Du kan också använda ditt Microsoft Entra-ID för att autentisera dina databegäranden. På så sätt kan du auktorisera databegäranden med hjälp av en detaljerad RBAC-modell.
Möjlighet att replikera data globalt för regionala fel Skapa en databasreplik i ett fjärrdatacenter med HBase-replikering. Azure Cosmos DB utför konfigurationsfri global distribution och gör att du kan replikera data till datacenter runt om i världen i Azure med ett knappval. När det gäller säkerhet säkerställer global replikering att dina data skyddas från lokala fel.
Möjlighet att redundansväsna från ett datacenter till ett annat Du måste implementera redundans själv. Om du replikerar data till flera datacenter och regionens datacenter går offline, rullar Azure Cosmos DB automatiskt över åtgärden.
Lokal datareplikering i ett datacenter Med HDFS-mekanismen kan du ha flera repliker över noder i ett enda filsystem. Azure Cosmos DB replikerar automatiskt data för att upprätthålla hög tillgänglighet, även i ett enda datacenter. Du kan välja konsekvensnivå själv.
Automatiska säkerhetskopieringar av data Det finns ingen automatisk säkerhetskopieringsfunktion. Du måste implementera säkerhetskopiering av data själv. Azure Cosmos DB säkerhetskopieras regelbundet och lagras i den geo-redundanta lagringen.
Skydda och isolera känsliga data Om du till exempel använder Apache Ranger kan du använda Ranger-principen för att tillämpa principen på tabellen. Du kan separera personliga och andra känsliga data i specifika containrar och läsa/skriva, eller begränsa skrivskyddad åtkomst till specifika användare.
Övervakning av attacker Den måste implementeras med hjälp av produkter från tredje part. Genom att använda granskningsloggning och aktivitetsloggar kan du övervaka ditt konto för normal och onormal aktivitet.
Svara på attacker Den måste implementeras med hjälp av produkter från tredje part. När du kontaktar Azure Support och rapporterar en potentiell attack börjar en femstegsprocess för incidenthantering.
Möjlighet att geo-stängseldata att följa datastyrningsbegränsningar Du måste kontrollera begränsningarna för varje land/region och implementera dem själv. Garanterar datastyrning för nationella regioner (Tyskland, Kina, US Gov osv.).
Fysiskt skydd av servrar i skyddade datacenter Det beror på det datacenter där systemet finns. En lista över de senaste certifieringarna finns på den globala azure-efterlevnadswebbplatsen.
Certifieringar Beror på Hadoop-fördelningen. Se Dokumentation om Azure-efterlevnad

Övervakning

HBase övervakar vanligtvis klustret med hjälp av webbgränssnittet för klustermått eller med Ambari, Cloudera Manager eller andra övervakningsverktyg. Med Azure Cosmos DB kan du använda övervakningsmekanismen som är inbyggd i Azure-plattformen. Mer information om Azure Cosmos DB-övervakning finns i Övervaka Azure Cosmos DB.

Om din miljö implementerar HBase-systemövervakning för att skicka aviseringar, till exempel via e-post, kanske du kan ersätta den med Azure Monitor-aviseringar. Du kan ta emot aviseringar baserat på mått eller aktivitetslogghändelser för ditt Azure Cosmos DB-konto.

Mer information om aviseringar i Azure Monitor finns i Skapa aviseringar för Azure Cosmos DB med Azure Monitor

Mer information finns i Azure Cosmos DB-mått och loggtyper som kan samlas in av Azure Monitor.

Säkerhetskopiering och haveriberedskap

Backup

Det finns flera sätt att få en säkerhetskopia av HBase. Till exempel Ögonblicksbild, Export, CopyTable, Offlinesäkerhetskopiering av HDFS-data och andra anpassade säkerhetskopior.

Azure Cosmos DB säkerhetskopierar automatiskt data med jämna mellanrum, vilket inte påverkar prestanda eller tillgänglighet för databasåtgärder. Säkerhetskopior lagras i Azure Storage och kan användas för att återställa data om det behövs. Det finns två typer av Azure Cosmos DB-säkerhetskopior:

Haveriberedskap

HBase är ett feltolerant distribuerat system, men du måste implementera haveriberedskap med hjälp av ögonblicksbilder, replikering osv. när redundans krävs på säkerhetskopieringsplatsen vid fel på datacenternivå. HBase-replikering kan konfigureras med tre replikeringsmodeller: Leader-Follower, Leader-Leader och Cyclic. Om källan HBase implementerar haveriberedskap måste du förstå hur du kan konfigurera haveriberedskap i Azure Cosmos DB och uppfylla systemkraven.

Azure Cosmos DB är en globalt distribuerad databas med inbyggda funktioner för haveriberedskap. Du kan replikera dina DB-data till valfri Azure-region. Azure Cosmos DB håller databasen mycket tillgänglig i den osannolika händelsen av ett fel i vissa regioner.

Azure Cosmos DB-konto som endast använder en enda region kan förlora tillgängligheten om en region misslyckas. Vi rekommenderar att du konfigurerar minst två regioner för att alltid säkerställa hög tillgänglighet. Du kan också säkerställa hög tillgänglighet för både skrivningar och läsningar genom att konfigurera ditt Azure Cosmos DB-konto så att det omfattar minst två regioner med flera skrivregioner för att säkerställa hög tillgänglighet för skrivningar och läsningar. För konton i flera regioner som består av flera skrivregioner identifieras och hanteras redundans mellan regioner av Azure Cosmos DB-klienten. Dessa är ögonblickliga och kräver inga ändringar från programmet. På så sätt kan du uppnå en tillgänglighetskonfiguration som innehåller Haveriberedskap för Azure Cosmos DB. Som tidigare nämnts kan HBase-replikering konfigureras med tre modeller, men Azure Cosmos DB kan konfigureras med SLA-baserad tillgänglighet genom att konfigurera regioner med enkel skrivning och flera skrivningar.

Mer information om hög tillgänglighet finns i Hur ger Azure Cosmos DB hög tillgänglighet

Vanliga frågor och svar

Varför migrera till API för NoSQL i stället för andra API:er i Azure Cosmos DB?

API för NoSQL ger den bästa upplevelsen från slutpunkt till slutpunkt när det gäller gränssnitt, tjänst-SDK-klientbibliotek. De nya funktionerna som distribueras till Azure Cosmos DB blir först tillgängliga i ditt API för NoSQL-konto. Dessutom har API:et för NoSQL stöd för analys och ger prestandaavgränsning mellan arbetsbelastningar för produktion och analys. Om du vill använda de moderniserade teknikerna för att skapa dina appar är API för NoSQL det rekommenderade alternativet.

Kan jag tilldela HBase RowKey till Azure Cosmos DB-partitionsnyckeln?

Den kanske inte är optimerad som den är. I HBase sorteras data efter angiven RowKey, lagras i regionen och delas upp i fasta storlekar. Detta fungerar annorlunda än partitionering i Azure Cosmos DB. Därför måste nycklarna göras om för att bättre distribuera data enligt arbetsbelastningens egenskaper. Mer information finns i avsnittet Distribution .

Data sorteras efter RowKey i HBase, men partitioneras efter nyckel i Azure Cosmos DB. Hur kan Azure Cosmos DB uppnå sortering och sortering?

I Azure Cosmos DB kan du lägga till ett sammansatt index för att sortera dina data i stigande eller fallande ordning för att förbättra prestanda för likhets- och intervallfrågor. Se avsnittet Distribution och sammansatt index i produktdokumentationen.

Analytisk bearbetning körs på HBase-data med Hive eller Spark. Hur kan jag modernisera dem i Azure Cosmos DB?

Du kan använda Azure Cosmos DB-analysarkivet för att automatiskt synkronisera driftdata till ett annat kolumnlager. Formatet för kolumnarkivet är lämpligt för stora analysfrågor som körs på ett optimerat sätt, vilket förbättrar svarstiden för sådana frågor. Med Azure Synapse Link kan du skapa en ETL-fri HTAP-lösning genom att länka direkt från Azure Synapse Analytics till Azure Cosmos DB-analysarkivet. På så sätt kan du utföra storskaliga analyser nästan i realtid av driftdata. Synapse Analytics stöder Apache Spark- och serverlösa SQL-pooler i Azure Cosmos DB-analysarkivet. Du kan använda den här funktionen för att migrera din analysbearbetning. Mer information finns i Analysarkiv .

Hur kan användare använda tidsstämpelfråga i HBase till Azure Cosmos DB?

Azure Cosmos DB har inte exakt samma tidsstämpelversionsfunktion som HBase. Men Azure Cosmos DB ger möjlighet att komma åt ändringsflödet och du kan använda det för versionshantering.

  • Lagra varje version/ändring som ett separat objekt.

  • Läs ändringsflödet för att sammanfoga/konsolidera ändringar och utlösa lämpliga åtgärder nedströms genom att filtrera med fältet "_ts". För gamla dataversioner kan du dessutom förfalla gamla versioner med hjälp av TTL.

Nästa steg