Delen via

Gegevens migreren van Apache HBase naar een Azure Cosmos DB for NoSQL-account

  • Artikel

VAN TOEPASSING OP: NoSQL

Azure Cosmos DB is een schaalbare, wereldwijd gedistribueerde, volledig beheerde database. Het biedt gegarandeerde toegang tot lage latentie tot uw gegevens. Zie het overzichtsartikel voor meer informatie over Azure Cosmos DB. In dit artikel wordt uitgelegd hoe u uw gegevens migreert van HBase naar een Azure Cosmos DB for NoSQL-account.

Verschillen tussen Azure Cosmos DB en HBase

Voordat u migreert, moet u de verschillen tussen Azure Cosmos DB en HBase begrijpen.

Resourcemodel

Azure Cosmos DB heeft het volgende resourcemodel: Azure Cosmos DB-resourcemodel met account, databases, containers en items.

HBase heeft het volgende resourcemodel: HBase-resourcemodel met naamruimte, tabellen, rijen en kolommen.

Resourcetoewijzing

In de volgende tabel ziet u een conceptuele toewijzing tussen Apache HBase, Apache Phoenix en Azure Cosmos DB.

HBase Phoenix Azure Cosmos DB
Cluster Cluster Rekening
Naamruimte Schema (indien ingeschakeld) Database
Tabel Tabel Container/verzameling
Kolomfamilie Kolomfamilie N.v.t.
Rij Rij Item/document
Versie (tijdstempel) Versie (tijdstempel) N.v.t.
N.v.t. Primaire sleutel Partitiesleutel
N.v.t. Index Index
N.v.t. Secundaire index Secundaire index
N.v.t. Weergave N.v.t.
N.v.t. Sequence N.v.t.

Vergelijking van gegevensstructuur en verschillen

De belangrijkste verschillen tussen de gegevensstructuur van Azure Cosmos DB en HBase zijn als volgt:

RowKey

  • In HBase worden gegevens opgeslagen door RowKey en horizontaal gepartitioneerd in regio's door het bereik van RowKey dat is opgegeven tijdens het maken van de tabel.

  • Azure Cosmos DB aan de andere kant distribueert gegevens naar partities op basis van de hash-waarde van een opgegeven partitiesleutel.

Kolomfamilie

  • In HBase worden kolommen gegroepeerd binnen een kolomfamilie (CF).

  • Azure Cosmos DB (API for NoSQL) slaat gegevens op als JSON-document . Daarom zijn alle eigenschappen die zijn gekoppeld aan een JSON-gegevensstructuur van toepassing.

Tijdstempel

  • HBase gebruikt tijdstempel om meerdere exemplaren van een bepaalde cel te versien. U kunt verschillende versies van een cel opvragen met behulp van een tijdstempel.

  • Azure Cosmos DB wordt geleverd met de functie Wijzigingenfeed waarmee permanente records van wijzigingen in een container worden bijgehouden in de volgorde waarin ze plaatsvinden. Als output verschijnt er vervolgens een gesorteerde lijst met gewijzigde documenten op volgorde van wijziging.

Gegevensindeling

  • HBase-gegevensindeling bestaat uit RowKey, Kolomfamilie: Kolomnaam, Tijdstempel, Waarde. Hier volgt een voorbeeld van een HBase-tabelrij:

    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

  • In Azure Cosmos DB for NoSQL vertegenwoordigt het JSON-object de gegevensindeling. De partitiesleutel bevindt zich in een veld in het document en stelt in welk veld de partitiesleutel voor de verzameling is. Azure Cosmos DB beschikt niet over het concept van tijdstempel dat wordt gebruikt voor de kolomfamilie of -versie. Zoals eerder is gemarkeerd, heeft het ondersteuning voor wijzigingenfeeds waarmee wijzigingen in een container kunnen worden bijgehouden/vastgelegd. Hier volgt een voorbeeld van een document.

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

Tip

HBase slaat gegevens op in bytematrix, dus als u gegevens wilt migreren die dubbele bytetekens bevatten naar Azure Cosmos DB, moeten de gegevens UTF-8 zijn gecodeerd.

Consistentiemodel

HBase biedt strikt consistente lees- en schrijfbewerkingen.

Azure Cosmos DB biedt vijf goed gedefinieerde consistentieniveaus. Elk niveau biedt een afweging tussen beschikbaarheid en prestaties. Van sterkste tot zwakste, de ondersteunde consistentieniveaus zijn:

  • Sterk
  • Gebonden veroudering
  • Sessie
  • Consistent voorvoegsel
  • Eventual

Grootte

HBase

Voor een implementatie op ondernemingsniveau van HBase, Master; Regioservers; en ZooKeeper rijden bulk van de grootte. Net als elke gedistribueerde toepassing is HBase ontworpen om uit te schalen. HBase-prestaties worden voornamelijk aangestuurd door de grootte van de HBase RegionServers. De grootte wordt voornamelijk bepaald door twee belangrijke vereisten: doorvoer en grootte van de gegevensset die moet worden opgeslagen op HBase.

Azure Cosmos DB

Azure Cosmos DB is een PaaS-aanbieding van Microsoft en details van de onderliggende infrastructuurimplementatie worden geabstraheerd van de eindgebruikers. Wanneer een Azure Cosmos DB-container is ingericht, richt het Azure-platform automatisch de onderliggende infrastructuur (compute, opslag, geheugen, netwerkstack) in ter ondersteuning van de prestatievereisten van een bepaalde workload. De kosten van alle databasebewerkingen worden genormaliseerd door Azure Cosmos DB en worden uitgedrukt in aanvraageenheden (of RU's, kortom).

Als u ru's wilt schatten die door uw workload worden verbruikt, moet u rekening houden met de volgende factoren:

Er is een capaciteitscalculator beschikbaar om te helpen bij het aanpassen van de grootte van RU's.

U kunt ook automatische inrichtingsdoorvoer in Azure Cosmos DB gebruiken om uw database- of containerdoorvoer (RU/sec) automatisch en onmiddellijk te schalen. Doorvoer wordt geschaald op basis van gebruik zonder dat dit van invloed is op de beschikbaarheid, latentie, doorvoer of prestaties van workloads.

Gegevensdistributie

HBase HBase sorteert gegevens op basis van RowKey. De gegevens worden vervolgens gepartitioneerd in regio's en opgeslagen in RegionServers. De automatische partitionering verdeelt regio's horizontaal volgens het partitioneringsbeleid. Dit wordt bepaald door de waarde die is toegewezen aan de HBase-parameter hbase.hregion.max.filesize (de standaardwaarde is 10 GB). Een rij in HBase met een bepaalde RowKey behoort altijd tot één regio. Daarnaast worden de gegevens gescheiden op schijf voor elke kolomfamilie. Hiermee kunt u filteren op het moment van lezen en isoleren van I/O op HFile.

Azure Cosmos DB Azure Cosmos DB maakt gebruik van partitionering om afzonderlijke containers in de database te schalen. Partitionering verdeelt de items in een container in specifieke subsets met de naam logische partities. Logische partities worden gevormd op basis van de waarde van de partitiesleutel die is gekoppeld aan elk item in de container. Alle items in een logische partitie hebben dezelfde partitiesleutelwaarde. Elke logische partitie kan maximaal 20 GB aan gegevens bevatten.

Fysieke partities bevatten elk een replica van uw gegevens en een exemplaar van de Azure Cosmos DB-database-engine. Deze structuur maakt uw gegevens duurzaam en maximaal beschikbaar en de doorvoer wordt gelijk verdeeld over de lokale fysieke partities. Fysieke partities worden automatisch gemaakt en geconfigureerd en het is niet mogelijk om de grootte, locatie of de logische partities die ze bevatten te beheren. Logische partities worden niet gesplitst tussen fysieke partities.

Net als bij HBase RowKey is het ontwerpen van partitiesleutels belangrijk voor Azure Cosmos DB. De rijsleutel van HBase werkt door gegevens te sorteren en doorlopende gegevens op te slaan, en de partitiesleutel van Azure Cosmos DB is een ander mechanisme omdat deze hash gegevens distribueert. Ervan uitgaande dat uw toepassing die HBase gebruikt, is geoptimaliseerd voor gegevenstoegangspatronen voor HBase, levert het gebruik van dezelfde RowKey voor de partitiesleutel geen goede prestatieresultaten op. Gezien het feit dat deze gegevens zijn gesorteerd op HBase, kan de samengestelde Azure Cosmos DB-index nuttig zijn. Dit is vereist als u de ORDER BY-component in meer dan één veld wilt gebruiken. U kunt ook de prestaties van veel gelijke query's en bereikquery's verbeteren door een samengestelde index te definiëren.

Beschikbaarheid

HBase HBase bestaat uit Master; Regioserver; en ZooKeeper. Hoge beschikbaarheid in één cluster kan worden bereikt door elk onderdeel redundant te maken. Wanneer u georedundantie configureert, kunt u HBase-clusters implementeren in verschillende fysieke datacenters en replicatie gebruiken om meerdere clusters synchroon te houden.

Azure Cosmos DB Azure Cosmos DB vereist geen configuratie, zoals redundantie van clusteronderdelen. Het biedt een uitgebreide SLA voor hoge beschikbaarheid, consistentie en latentie. Zie sla voor Azure Cosmos DB voor meer informatie.

Betrouwbaarheid van gegevens

HBase HBase is gebouwd op Hadoop Distributed File System (HDFS) en gegevens die zijn opgeslagen in HDFS, worden drie keer gerepliceerd.

Azure Cosmos DB Azure Cosmos DB biedt voornamelijk hoge beschikbaarheid op twee manieren. Ten eerste worden in Azure Cosmos DB gegevens gerepliceerd tussen regio's die zijn geconfigureerd binnen uw Azure Cosmos DB-account. Ten tweede bewaart Azure Cosmos DB vier replica's van de gegevens in de regio.

Overwegingen voordat u migreert

Systeemafhankelijkheden

Dit aspect van de planning is gericht op het begrijpen van upstream- en downstreamafhankelijkheden voor het HBase-exemplaar, dat wordt gemigreerd naar Azure Cosmos DB.

Voorbeeld van downstreamafhankelijkheden kan toepassingen zijn die gegevens uit HBase lezen. Deze moeten worden geherstructureerd om te lezen uit Azure Cosmos DB. Deze volgende punten moeten worden beschouwd als onderdeel van de migratie:

  • Vragen over het beoordelen van afhankelijkheden: is het huidige HBase-systeem een onafhankelijk onderdeel? Of roept het een proces aan op een ander systeem, of wordt het aangeroepen door een proces op een ander systeem of wordt het geopend met behulp van een adreslijstservice? Werken andere belangrijke processen in uw HBase-cluster? Deze systeemafhankelijkheden moeten worden verduidelijkt om de impact van de migratie te bepalen.

  • De RPO en RTO voor HBase-implementatie on-premises.

Offline- en onlinemigratie

Voor een succesvolle gegevensmigratie is het belangrijk om inzicht te hebben in de kenmerken van het bedrijf dat gebruikmaakt van de database en te bepalen hoe u dit moet doen. Selecteer offlinemigratie als u het systeem volledig kunt afsluiten, gegevensmigratie kunt uitvoeren en het systeem opnieuw kunt opstarten op de bestemming. Als uw database altijd bezet is en u zich geen lange storing kunt veroorloven, kunt u ook online migreren.

Notitie

In dit document wordt alleen de offlinemigratie behandeld.

Wanneer u offlinegegevensmigratie uitvoert, is dit afhankelijk van de versie van HBase die u momenteel gebruikt en de beschikbare hulpprogramma's. Zie de sectie Gegevensmigratie voor meer informatie.

Prestatieoverwegingen

Dit aspect van de planning is het begrijpen van prestatiedoelen voor HBase en deze vervolgens omzetten in semantiek van Azure Cosmos DB. Als u bijvoorbeeld X IOPS op HBase wilt bereiken, is het aantal aanvraageenheden (RU/s) vereist in Azure Cosmos DB. Er zijn verschillen tussen HBase en Azure Cosmos DB. Deze oefening is gericht op het bouwen van een weergave van hoe prestatiedoelen van HBase worden omgezet in Azure Cosmos DB. Hierdoor wordt de schaaloefening aangedreven.

Vragen om te stellen:

  • Is de HBase-implementatie leesintensief of schrijfintensief?
  • Wat is de splitsing tussen lees- en schrijfbewerkingen?
  • Wat is de doel-IOPS die als percentiel worden weergegeven?
  • Hoe/welke toepassingen worden gebruikt om gegevens in HBase te laden?
  • Hoe/welke toepassingen worden gebruikt om gegevens uit HBase te lezen?

Bij het uitvoeren van query's die gesorteerde gegevens aanvragen, retourneert HBase het resultaat snel omdat de gegevens worden gesorteerd op RowKey. Azure Cosmos DB heeft echter geen dergelijk concept. Als u de prestaties wilt optimaliseren, kunt u indien nodig samengestelde indexen gebruiken.

Implementatieoverwegingen

U kunt Azure Portal of Azure CLI gebruiken om Azure Cosmos DB for NoSQL te implementeren. Omdat de migratiebestemming Azure Cosmos DB for NoSQL is, selecteert u NoSQL voor de API als parameter bij het implementeren. Stel bovendien georedundantie, schrijfbewerkingen voor meerdere regio's en Beschikbaarheidszones in op basis van uw beschikbaarheidsvereisten.

Netwerkoverweging

Azure Cosmos DB heeft drie hoofdnetwerkopties. De eerste is een configuratie die gebruikmaakt van een openbaar IP-adres en de toegang beheert met een IP-firewall (standaard). De tweede is een configuratie die gebruikmaakt van een openbaar IP-adres en alleen toegang toestaat vanuit een specifiek subnet van een specifiek virtueel netwerk (service-eindpunt). De derde is een configuratie (privé-eindpunt) die lid wordt van een privénetwerk met behulp van een privé-IP-adres.

Zie de volgende documenten voor meer informatie over de drie netwerkopties:

Uw bestaande gegevens beoordelen

Gegevensdetectie

Verzamel vooraf informatie van uw bestaande HBase-cluster om de gegevens te identificeren die u wilt migreren. Deze kunnen u helpen bij het migreren, bepalen welke tabellen moeten worden gemigreerd, inzicht in de structuur in deze tabellen en bepalen hoe u uw gegevensmodel bouwt. Verzamel bijvoorbeeld details zoals de volgende:

  • HBase-versie
  • Doeltabellen voor migratie
  • Kolomfamiliegegevens
  • Tabelstatus

De volgende opdrachten laten zien hoe u de bovenstaande details verzamelt met behulp van een hbase-shellscript en deze opslaat in het lokale bestandssysteem van de besturingssysteemcomputer.

De HBase-versie ophalen

hbase version -n > hbase-version.txt

Uitvoer:

cat hbase-version.txt
HBase 2.1.8.4.1.2.5

De lijst met tabellen ophalen

U kunt een lijst met tabellen ophalen die zijn opgeslagen in HBase. Als u een andere naamruimte dan standaard hebt gemaakt, wordt deze uitgevoerd in de indeling Naamruimte: Tabel.

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

Uitvoer:

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

De tabellen identificeren die moeten worden gemigreerd

Haal de details van de kolomfamilies in de tabel op door de tabelnaam op te geven die moet worden gemigreerd.

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

Uitvoer:

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

De kolomfamilies in de tabel en de bijbehorende instellingen ophalen

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

Uitvoer:

{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

[...]

U kunt nuttige gegevens over de grootte van het formaat krijgen, zoals de grootte van heap-geheugen, het aantal regio's, het aantal aanvragen als de status van het cluster en de grootte van de gegevens in gecomprimeerde/niet-gecomprimeerde gegevens als de status van de tabel.

Als u Apache Phoenix op HBase-cluster gebruikt, moet u ook gegevens van Phoenix verzamelen.

  • Migratiedoeltabel
  • Tabelschema's
  • Indexen
  • Primaire sleutel

Verbinding maken met Apache Phoenix in uw cluster

sqlline.py ZOOKEEPER/hbase-unsecure

De lijst met tabellen ophalen

!tables

De tabeldetails ophalen

!describe <Table Name>

De indexdetails ophalen

!indexes <Table Name>

De details van de primaire sleutel ophalen

!primarykeys <Table Name>

Uw gegevens migreren

Migratieopties

Er zijn verschillende methoden om gegevens offline te migreren, maar hier wordt uitgelegd hoe u Azure Data Factory gebruikt.

Oplossing Bronversie Overwegingen
Azure Data Factory HBase < 2 Eenvoudig in te stellen. Geschikt voor grote gegevenssets. Biedt geen ondersteuning voor HBase 2 of hoger.
Apache Spark Alle versies Alle versies van HBase ondersteunen. Geschikt voor grote gegevenssets. Spark-installatie is vereist.
Aangepast hulpprogramma met azure Cosmos DB-bibliotheek voor bulkexecutor Alle versies Het meest flexibel om aangepaste hulpprogramma's voor gegevensmigratie te maken met behulp van bibliotheken. Vereist meer inspanning om in te stellen.

In het volgende stroomdiagram worden enkele voorwaarden gebruikt om de beschikbare gegevensmigratiemethoden te bereiken. Stroomdiagram voor opties voor het migreren van gegevens naar Azure Cosmos DB.

Migreren met Data Factory

Deze optie is geschikt voor grote gegevenssets. De Azure Cosmos DB Bulk Executor-bibliotheek wordt gebruikt. Er zijn geen controlepunten, dus als u problemen ondervindt tijdens de migratie, moet u het migratieproces vanaf het begin opnieuw starten. U kunt ook de zelf-hostende Integration Runtime van Data Factory gebruiken om verbinding te maken met uw on-premises HBase, of Data Factory implementeren in een beheerd VNET en verbinding maken met uw on-premises netwerk via VPN of ExpressRoute.

De Copy-activiteit van Data Factory ondersteunt HBase als gegevensbron. Zie het artikel Over het kopiëren van gegevens uit HBase met behulp van Azure Data Factory voor meer informatie.

U kunt Azure Cosmos DB (API voor NoSQL) opgeven als de bestemming voor uw gegevens. Zie het artikel Over het kopiëren en transformeren van gegevens in Azure Cosmos DB (API voor NoSQL) met behulp van azure Data Factory voor meer informatie.

Architectuur voor het migreren van gegevens van on-premises naar Azure Cosmos DB met behulp van Data Factory.

Migreren met Apache Spark - Apache HBase Connector en Azure Cosmos DB Spark-connector

Hier volgt een voorbeeld van het migreren van uw gegevens naar Azure Cosmos DB. Hierbij wordt ervan uitgegaan dat HBase 2.1.0 en Spark 2.4.0 worden uitgevoerd in hetzelfde cluster.

Apache Spark - Apache HBase Connector-opslagplaats vindt u in Apache Spark - Apache HBase Connector

Raadpleeg de snelstartgids voor Azure Cosmos DB Spark-connector en download de juiste bibliotheek voor uw Spark-versie.

  1. Kopieer hbase-site.xml naar uw Spark-configuratiemap.

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

  2. Spark-shell uitvoeren met Spark HBase-connector en Azure Cosmos DB Spark-connector.

    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. Nadat de Spark-shell is gestart, voert u de Scala-code als volgt uit. Importeer de bibliotheken die nodig zijn om gegevens uit HBase te laden.

    // 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. Definieer het Spark-catalogusschema voor uw HBase-tabellen. Hier is de naamruimte 'standaard' en de tabelnaam 'Contactpersonen'. De rijsleutel wordt opgegeven als de sleutel. Kolommen, kolomfamilie en kolom worden toegewezen aan de catalogus van Spark.

    // 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. Definieer vervolgens een methode om de gegevens op te halen uit de tabel HBase-contactpersonen als een DataFrame.

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

  6. Maak een DataFrame met behulp van de gedefinieerde methode.

    val df = withCatalog(catalog)

  7. Importeer vervolgens de bibliotheken die nodig zijn om de Azure Cosmos DB Spark-connector te gebruiken.

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

  8. Instellingen maken voor het schrijven van gegevens naar 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. DataFrame-gegevens schrijven naar Azure Cosmos DB.

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

Het schrijft parallel met hoge snelheid, de prestaties zijn hoog. Houd er echter rekening mee dat ru/s aan de kant van Azure Cosmos DB kunnen worden verbruikt.

Phoenix

Phoenix wordt ondersteund als een Data Factory-gegevensbron. Raadpleeg de volgende documenten voor gedetailleerde stappen.

Uw code migreren

In deze sectie worden de verschillen beschreven tussen het maken van toepassingen in Azure Cosmos DB for NoSQLs en HBase. In de voorbeelden hier worden Apache HBase 2.x API's en Azure Cosmos DB Java SDK v4 gebruikt.

De voorbeeldcodes van deze HBase zijn gebaseerd op de codes die worden beschreven in de officiële documentatie van HBase.

De code voor Azure Cosmos DB die hier wordt gepresenteerd, is gebaseerd op de documentatie over Azure Cosmos DB for NoSQL: Java SDK v4-voorbeelden . U hebt toegang tot het volledige codevoorbeeld in de documentatie.

De toewijzingen voor codemigratie worden hier weergegeven, maar de HBase RowKeys en Azure Cosmos DB-partitiesleutels die in deze voorbeelden worden gebruikt, zijn niet altijd goed ontworpen. Ontwerp volgens het werkelijke gegevensmodel van de migratiebron.

Verbinding maken

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();

Database/tabel/verzameling maken

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());

Rij/document maken

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 biedt typeveiligheid via het gegevensmodel. We gebruiken een gegevensmodel met de naam 'Family'.

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="";
}

Het bovenstaande maakt deel uit van de code. Zie het volledige codevoorbeeld.

Gebruik de klasse Gezin om een document te definiëren en item in te voegen.

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());

Rij/document lezen

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);

Gegevens bijwerken

HBase

Gebruik voor HBase de toevoegmethode en checkAndPut-methode om de waarde bij te werken. Toevoegen is het proces van het toevoegen van een waarde atomisch aan het einde van de huidige waarde en checkAndPut vergelijkt atomisch de huidige waarde met de verwachte waarde en wordt alleen bijgewerkt als ze overeenkomen.

// 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

In Azure Cosmos DB worden updates behandeld als Upsert-bewerkingen. Als het document niet bestaat, wordt het ingevoegd.

// 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());

Rij/document verwijderen

HBase

In Hbase is er geen directe manier om de rij op waarde te selecteren. Mogelijk hebt u het verwijderingsproces in combinatie met ValueFilter enzovoort geïmplementeerd. In dit voorbeeld wordt de te verwijderen rij opgegeven door 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

De verwijderingsmethode op document-id wordt hieronder weergegeven.

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

Query's uitvoeren op rijen/documenten

Met HBase HBase kunt u meerdere rijen ophalen met scan. U kunt Filter gebruiken om gedetailleerde scanvoorwaarden op te geven. Zie Filters voor clientaanvragen voor ingebouwde HBase-filtertypen.

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

Filterbewerking

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

Tabel/verzameling verwijderen

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());

Andere overwegingen

HBase-clusters kunnen worden gebruikt met HBase-workloads en MapReduce, Hive, Spark en meer. Als u andere workloads met uw huidige HBase hebt, moeten ze ook worden gemigreerd. Raadpleeg elke migratiehandleiding voor meer informatie.

  • MapReduce
  • HBase
  • Spark

Programmeren op de server

HBase biedt verschillende programmeerfuncties aan de serverzijde. Als u deze functies gebruikt, moet u ook de verwerking ervan migreren.

HBase

  • Aangepaste filters

    Verschillende filters zijn standaard beschikbaar in HBase, maar u kunt ook uw eigen aangepaste filters implementeren. Aangepaste filters kunnen worden geïmplementeerd als de filters die standaard beschikbaar zijn op HBase, niet voldoen aan uw vereisten.

  • Coprocessor

    De Coprocessor is een framework waarmee u uw eigen code kunt uitvoeren op de regioserver. Door de Coprocessor te gebruiken, is het mogelijk om de verwerking uit te voeren die aan de clientzijde aan de serverzijde is uitgevoerd, en afhankelijk van de verwerking kan het efficiënter worden gemaakt. Er zijn twee typen coprocessors, waarnemer en eindpunt.

    • Waarnemer

      • Waarnemer koppelt specifieke bewerkingen en gebeurtenissen. Dit is een functie voor het toevoegen van willekeurige verwerking. Dit is een functie die vergelijkbaar is met RDBMS-triggers.

    • Eindpunt

      • Eindpunt is een functie voor het uitbreiden van HBase RPC. Het is een functie die vergelijkbaar is met een opgeslagen RDBMS-procedure.

Azure Cosmos DB

  • Opgeslagen procedure

    • Opgeslagen Azure Cosmos DB-procedures worden geschreven in JavaScript en kunnen bewerkingen uitvoeren, zoals het maken, bijwerken, lezen, opvragen en verwijderen van items in Azure Cosmos DB-containers.

  • Trigger

    • Triggers kunnen worden opgegeven voor bewerkingen in de database. Er zijn twee methoden beschikbaar: een pretrigger die wordt uitgevoerd voordat het database-item wordt gewijzigd en een post-trigger die wordt uitgevoerd nadat het database-item is gewijzigd.

  • UDF

    • Met Azure Cosmos DB kunt u door de gebruiker gedefinieerde functies (UDF's) definiëren. UDF's kunnen ook worden geschreven in JavaScript.

Opgeslagen procedures en triggers verbruiken RU's op basis van de complexiteit van de uitgevoerde bewerkingen. Bij het ontwikkelen van verwerking aan de serverzijde controleert u het vereiste gebruik om een beter inzicht te krijgen in de hoeveelheid RU die door elke bewerking wordt verbruikt. Zie aanvraageenheden in Azure Cosmos DB en kosten optimaliseren voor aanvragen in Azure Cosmos DB voor meer informatie.

Programmeertoewijzingen aan de serverzijde

HBase Azure Cosmos DB Beschrijving
Aangepaste filters WHERE-component Als de verwerking die door het aangepaste filter is geïmplementeerd, niet kan worden bereikt door de WHERE-component in Azure Cosmos DB, gebruikt u UDF in combinatie.
Coprocessor (waarnemer) Activator Waarnemer is een trigger die vóór en na een bepaalde gebeurtenis wordt uitgevoerd. Net zoals Observer pre- en post-aanroepen ondersteunt, ondersteunt de trigger van Azure Cosmos DB ook pre- en post-triggers.
Coprocessor (eindpunt) Opgeslagen procedure Eindpunt is een mechanisme voor gegevensverwerking aan de serverzijde dat wordt uitgevoerd voor elke regio. Dit is vergelijkbaar met een opgeslagen RDBMS-procedure. Opgeslagen Azure Cosmos DB-procedures worden geschreven met behulp van JavaScript. Het biedt toegang tot alle bewerkingen die u op Azure Cosmos DB kunt uitvoeren via opgeslagen procedures.

Notitie

Er kunnen verschillende toewijzingen en implementaties vereist zijn in Azure Cosmos DB, afhankelijk van de verwerking die is geïmplementeerd op HBase.

Beveiliging

Gegevensbeveiliging is een gedeelde verantwoordelijkheid van de klant en de databaseprovider. Voor on-premises oplossingen moeten klanten alles bieden, van eindpuntbeveiliging tot fysieke hardwarebeveiliging, wat geen eenvoudige taak is. Als u een PaaS-clouddatabaseprovider zoals Azure Cosmos DB kiest, wordt de betrokkenheid van klanten verminderd. Azure Cosmos DB wordt uitgevoerd op het Azure-platform, zodat het op een andere manier kan worden uitgebreid dan HBase. Azure Cosmos DB vereist geen extra onderdelen om te worden geïnstalleerd voor beveiliging. U wordt aangeraden de implementatie van uw databasesysteembeveiliging te migreren met behulp van de volgende controlelijst:

Beveiligingsbeheer HBase Azure Cosmos DB
Netwerkbeveiliging en firewallinstelling Beheer verkeer met behulp van beveiligingsfuncties zoals netwerkapparaten. Ondersteunt op beleid gebaseerd IP-toegangsbeheer op de binnenkomende firewall.
Gebruikersverificatie en fijnmazige gebruikersbesturingselementen Fijnmazig toegangsbeheer door LDAP te combineren met beveiligingsonderdelen zoals Apache Ranger. U kunt de primaire sleutel van het account gebruiken om resources voor gebruikers en machtigingen te maken voor elke database. U kunt ook uw Microsoft Entra-id gebruiken om uw gegevensaanvragen te verifiëren. Hiermee kunt u gegevensaanvragen autoriseren met behulp van een gedetailleerd RBAC-model.
Mogelijkheid om gegevens globaal te repliceren voor regionale fouten Maak een databasereplica in een extern datacenter met behulp van de replicatie van HBase. Azure Cosmos DB voert wereldwijde distributie zonder configuratie uit en stelt u in staat om gegevens te repliceren naar datacenters over de hele wereld in Azure met de selectie van een knop. Met betrekking tot beveiliging zorgt globale replicatie ervoor dat uw gegevens worden beschermd tegen lokale fouten.
Mogelijkheid om een failover uit te wisselen van het ene datacenter naar het andere U moet zelf failover implementeren. Als u gegevens naar meerdere datacenters repliceert en het datacenter van de regio offline gaat, wordt de bewerking automatisch overgeslagen in Azure Cosmos DB.
Replicatie van lokale gegevens binnen een datacenter Met het HDFS-mechanisme kunt u meerdere replica's tussen knooppunten in één bestandssysteem hebben. Azure Cosmos DB repliceert automatisch gegevens om hoge beschikbaarheid te behouden, zelfs binnen één datacenter. U kunt zelf het consistentieniveau kiezen.
Automatische back-ups van gegevens Er is geen automatische back-upfunctie. U moet zelf gegevensback-ups implementeren. Er wordt regelmatig een back-up van Azure Cosmos DB gemaakt en opgeslagen in de geografisch redundante opslag.
Gevoelige gegevens beveiligen en isoleren Als u bijvoorbeeld Apache Ranger gebruikt, kunt u Ranger-beleid gebruiken om het beleid toe te passen op de tabel. U kunt persoonlijke en andere gevoelige gegevens scheiden in specifieke containers en lezen/schrijven, of de toegang tot alleen-lezentoegang beperken tot specifieke gebruikers.
Controle op aanvallen Het moet worden geïmplementeerd met behulp van producten van derden. Door auditlogboeken en activiteitenlogboeken te gebruiken, kunt u uw account controleren op normale en abnormale activiteiten.
Reageren op aanvallen Het moet worden geïmplementeerd met behulp van producten van derden. Wanneer u contact op neemt met ondersteuning voor Azure en een mogelijke aanval rapporteert, begint een proces voor het reageren op incidenten in vijf stappen.
Mogelijkheid om gegevens geografisch te omheinen om te voldoen aan beperkingen voor gegevensbeheer U moet de beperkingen van elk land/elke regio controleren en deze zelf implementeren. Garandeert gegevensgovernance voor onafhankelijke regio's (Duitsland, China, US Gov, enzovoort).
Fysieke beveiliging van servers in beveiligde datacenters Dit is afhankelijk van het datacenter waar het systeem zich bevindt. Zie de globale Azure-nalevingssite voor een lijst met de meest recente certificeringen.
Certificeringen Is afhankelijk van de Hadoop-distributie. Raadpleeg de documentatie voor Azure-naleving

Controleren

HBase bewaakt het cluster doorgaans met behulp van de metrische webinterface van het cluster of met Ambari, Cloudera Manager of andere bewakingsprogramma's. Met Azure Cosmos DB kunt u het bewakingsmechanisme gebruiken dat is ingebouwd in het Azure-platform. Zie Azure Cosmos DB bewaken voor meer informatie over Azure Cosmos DB-bewaking.

Als uw omgeving HBase-systeembewaking implementeert om waarschuwingen te verzenden, zoals per e-mail, kunt u deze mogelijk vervangen door Azure Monitor-waarschuwingen. U kunt waarschuwingen ontvangen op basis van metrische gegevens of gebeurtenissen in activiteitenlogboeken voor uw Azure Cosmos DB-account.

Raadpleeg Waarschuwingen maken voor Azure Cosmos DB met behulp van Azure Monitor voor meer informatie over waarschuwingen in Azure Monitor

Zie ook metrische gegevens en logboektypen van Azure Cosmos DB die kunnen worden verzameld door Azure Monitor.

Back-up en herstel na noodgevallen

Backup

Er zijn verschillende manieren om een back-up van HBase op te halen. Bijvoorbeeld Momentopname, Exporteren, CopyTable, Offline back-up van HDFS-gegevens en andere aangepaste back-ups.

Azure Cosmos DB maakt automatisch een back-up van gegevens met periodieke intervallen, wat geen invloed heeft op de prestaties of beschikbaarheid van databasebewerkingen. Back-ups worden opgeslagen in Azure Storage en kunnen zo nodig worden gebruikt om gegevens te herstellen. Er zijn twee typen Back-ups van Azure Cosmos DB:

Herstel na noodgeval

HBase is een fouttolerant gedistribueerd systeem, maar u moet herstel na noodgevallen implementeren met momentopname, replicatie, enzovoort wanneer failover is vereist op de back-uplocatie in het geval van een storing op datacenterniveau. HBase-replicatie kan worden ingesteld met drie replicatiemodellen: Leader-Follower, Leader-Leader en Cyclic. Als de bron-HBase herstel na noodgevallen implementeert, moet u weten hoe u herstel na noodgevallen in Azure Cosmos DB kunt configureren en aan uw systeemvereisten kunt voldoen.

Azure Cosmos DB is een wereldwijd gedistribueerde database met ingebouwde mogelijkheden voor herstel na noodgevallen. U kunt uw DB-gegevens repliceren naar elke Azure-regio. Azure Cosmos DB houdt uw database maximaal beschikbaar in het onwaarschijnlijke geval van een storing in sommige regio's.

Azure Cosmos DB-account dat slechts één regio gebruikt, kan de beschikbaarheid verliezen in het geval van een regiofout. U wordt aangeraden ten minste twee regio's te configureren om altijd hoge beschikbaarheid te garanderen. U kunt ook zorgen voor hoge beschikbaarheid voor zowel schrijf- als leesbewerkingen door uw Azure Cosmos DB-account te configureren voor ten minste twee regio's met meerdere schrijfregio's om hoge beschikbaarheid voor schrijf- en leesbewerkingen te garanderen. Voor accounts met meerdere regio's die bestaan uit meerdere schrijfregio's, wordt failover tussen regio's gedetecteerd en verwerkt door de Azure Cosmos DB-client. Deze zijn tijdelijk en vereisen geen wijzigingen van de toepassing. Op deze manier kunt u een beschikbaarheidsconfiguratie bereiken met herstel na noodgevallen voor Azure Cosmos DB. Zoals eerder vermeld, kan HBase-replicatie worden ingesteld met drie modellen, maar Azure Cosmos DB kan worden ingesteld met beschikbaarheid op basis van een SLA door regio's met één schrijfbewerking en meerdere schrijfbewerkingen te configureren.

Raadpleeg hoe Azure Cosmos DB hoge beschikbaarheid biedt voor meer informatie over hoge beschikbaarheid

Veelgestelde vragen

Waarom migreren naar API voor NoSQL in plaats van andere API's in Azure Cosmos DB?

API voor NoSQL biedt de beste end-to-end-ervaring op het gebied van interface, service SDK-clientbibliotheek. De nieuwe functies die zijn geïmplementeerd in Azure Cosmos DB, zijn voor het eerst beschikbaar in uw API voor NoSQL-account. Bovendien biedt de API voor NoSQL ondersteuning voor analyses en prestatiescheiding tussen productie- en analyseworkloads. Als u de gemoderniseerde technologieën wilt gebruiken om uw apps te bouwen, is API voor NoSQL de aanbevolen optie.

Kan ik de HBase RowKey toewijzen aan de Azure Cosmos DB-partitiesleutel?

Het is mogelijk niet geoptimaliseerd zoals het is. In HBase worden de gegevens gesorteerd op de opgegeven RowKey, opgeslagen in de regio en onderverdeeld in vaste grootten. Dit gedraagt zich anders dan partitioneren in Azure Cosmos DB. Daarom moeten de sleutels opnieuw worden ontworpen om de gegevens beter te distribueren op basis van de kenmerken van de workload. Zie de sectie Distributie voor meer informatie.

Gegevens worden gesorteerd op RowKey in HBase, maar partitioneren op sleutel in Azure Cosmos DB. Hoe kan Azure Cosmos DB sorteren en collocatie bereiken?

In Azure Cosmos DB kunt u een samengestelde index toevoegen om uw gegevens in oplopende of aflopende volgorde te sorteren om de prestaties van gelijkheids- en bereikquery's te verbeteren. Zie de sectie Distributie en de samengestelde index in productdocumentatie.

Analytische verwerking wordt uitgevoerd op HBase-gegevens met Hive of Spark. Hoe kan ik deze moderniseren in Azure Cosmos DB?

U kunt de analytische opslag van Azure Cosmos DB gebruiken om operationele gegevens automatisch te synchroniseren met een ander kolomarchief. De kolomopslagindeling is geschikt voor grote analysequery's die op een geoptimaliseerde manier worden uitgevoerd, waardoor de latentie voor dergelijke query's wordt verbeterd. Met Azure Synapse Link kunt u een HTAP-oplossing zonder ETL bouwen door rechtstreeks vanuit Azure Synapse Analytics te koppelen aan de analytische opslag van Azure Cosmos DB. Hiermee kunt u grootschalige, bijna realtime analyse van operationele gegevens uitvoeren. Synapse Analytics ondersteunt Apache Spark- en serverloze SQL-pools in het Azure Cosmos DB-analysearchief. U kunt profiteren van deze functie om uw analytische verwerking te migreren. Zie Analytische opslag voor meer informatie.

Hoe kunnen gebruikers een tijdstempelquery in HBase gebruiken in Azure Cosmos DB?

Azure Cosmos DB heeft niet precies dezelfde functie voor tijdstempelversiebeheer als HBase. Maar Azure Cosmos DB biedt de mogelijkheid om toegang te krijgen tot de wijzigingenfeed en u kunt deze gebruiken voor versiebeheer.

  • Sla elke versie/wijziging op als afzonderlijk item.

  • Lees de wijzigingenfeed om wijzigingen samen te voegen/samen te voegen en de juiste acties downstream te activeren door te filteren met het veld '_ts'. Daarnaast kunt u voor een oude versie van gegevens oude versies verlopen met behulp van TTL.

Volgende stappen