Delen via


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

Azure Cosmos DB is een schaalbare, wereldwijd gedistribueerde, volledig beheerde database. Het biedt gegarandeerde toegang met 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.

Hulpbronnenmodel

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

Deze tabel toont een conceptuele mapping tussen Apache HBase, Apache Phoenix en Azure Cosmos DB.

HBase Phoenix Azure Cosmos DB
Cluster Cluster Account
Namespace Schema (indien ingeschakeld) gegevensbank
Table Table Container/verzameling
Kolomfamilie Kolomfamilie N/A
Row Row Item/document
Versie (tijdstempel) Versie (tijdstempel) N/A
N/A Primaire sleutel Partitiesleutel
N/A Index Index
N/A Secundaire index Secundaire index
N/A Bekijk N/A
N/A Sequentie N/A

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 geeft aan welk veld als partitiesleutel voor de verzameling wordt gebruikt. 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",
    }
    

Aanbeveling

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
  • Begrensde onvolledigheid
  • Session
  • Consistent voorvoegsel
  • Uiteindelijk

Sizing

HBase

Voor een implementatie van HBase op ondernemingsniveau bepalen de Master, Regioservers en ZooKeeper grotendeels de omvang. 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 de functie autoscaling provisioning-ruimtedoorvoer in Azure Cosmos DB gebruiken om de doorvoer (RU/sec) van uw database of container 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 te schalen. Zie het overzicht van partitionering voor uitgebreide informatie over logische partities, fysieke partities en selectie van partitiesleutels.

Belangrijkste verschillen voor migratie:

  • Mechanisme voor gegevensdistributie: De RowKey van HBase sorteert gegevens en slaat doorlopende gegevens op, terwijl de partitiesleutel-hash van Azure Cosmos DB gegevens distribueert. Het gebruik van dezelfde RowKey voor uw partitiesleutel levert doorgaans geen optimale prestatieresultaten op.
  • Samengestelde indexen voor gesorteerde query's: Aangezien gegevens zijn gesorteerd op HBase, kan de samengestelde Azure Cosmos DB-index nuttig zijn. Dit is vereist als u de ORDER BY-component voor meerdere velden wilt gebruiken. U kunt ook de prestaties van veel gelijkheids- en bereikquery's verbeteren door een samengestelde index te definiëren.

Availability

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 op locatie.

Offline- en online migratie

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.

Opmerking

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.

Prestatie-overwegingen

Dit aspect van de planning is het begrijpen van prestatiedoelen voor HBase en deze vervolgens omzetten in semantiek van Azure Cosmos DB. Hoeveel aanvraageenheden (RU/s) zijn er vereist in Azure Cosmos DB om bijvoorbeeld "X" IOPS op HBase te halen? 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. Dit zal het opschalen bevorderen.

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 wordt 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.

Overwegingen bij de implementatie

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 informatie over de grootte verkrijgen, zoals de grootte van het heap-geheugen, het aantal regio's, het aantal verzoeken in verband met de status van het cluster, en de grootte van de gegevens in gecomprimeerde/niet-gecomprimeerde vorm wat betreft de status van de tabel.

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

  • Migratiedoeltableau
  • Tabelschema's
  • Indexes
  • Primaire sleutel

Verbinding maken met Apache Phoenix in uw cluster

sqlline.py ZOOKEEPER/hbase-unsecure

De lijst met tabellen ophalen

!tables

Verkrijg de tabeldetails

!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.

Solution 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. Voor Spark is installatie vereist.
Aangepast hulpprogramma met Azure Cosmos DB-bibliotheek voor bulk executor 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 als sleutel opgegeven. 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. Aan de andere kant, houd er rekening mee dat RU/s aan de zijde van Azure Cosmos DB kunnen worden verbruikt.

Feniks

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

Maak rij/document

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 een rij te verwijderen door middel van selectie op waarde. 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 per 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 Description
Aangepaste filters WHERE-clausule 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) Aanleiding Een observator is een trigger die wordt uitgevoerd vóór en na een bepaalde gebeurtenis. 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.

Opmerking

Er kunnen verschillende toewijzingen en implementaties nodig zijn in Azure Cosmos DB, afhankelijk van de verwerking die op HBase is uitgevoerd.

Security

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. We raden u aan te overwegen de beveiligingsimplementatie van uw databasesysteem 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 over te schakelen van het ene datacenter naar het andere. Je moet de failover zelf 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.
Certifications Is afhankelijk van de Hadoop-distributie. Raadpleeg de documentatie voor Azure-naleving

Controle

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 een ramp

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 interfaces en de 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 onvoldoende geoptimaliseerd zoals het nu 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 gepartitioneerd 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 Azure Cosmos DB-spiegeling naar Microsoft Fabric gebruiken om operationele gegevens automatisch te synchroniseren met een ander kolomarchief. Met spiegeling kunt u een HTAP-oplossing zonder ETL bouwen naar OneLake in Microsoft Fabric. Hiermee kunt u grootschalige, bijna realtime analyse van operationele gegevens uitvoeren. Microsoft Fabric ondersteunt Apache Spark- en serverloze SQL-pools. U kunt profiteren van deze functie om uw analytische verwerking te migreren. Zie Azure Cosmos DB Mirroring voor meer informatie.

Hoe kunnen gebruikers een tijdstempelquery gebruiken in HBase naar 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 te consolideren en de juiste vervolgacties 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