Freigeben über

Migrieren von Daten von Apache HBase zu einem Azure Cosmos DB for NoSQL-Konto

GILT FÜR: NoSQL

Azure Cosmos DB ist eine skalierbare, global verteilte, vollständig verwaltete Datenbank. Sie bietet garantierten Zugriff mit geringer Wartezeit auf Ihre Daten. Weitere Informationen zu Azure Cosmos DB finden Sie im Artikel Übersicht. In diesem Artikel erfahren Sie, wie Sie Ihre Daten von HBase zu einem Azure Cosmos DB for NoSQL-Konto migrieren.

Unterschiede zwischen Azure Cosmos DB und HBase

Bevor Sie migrieren, müssen Sie die Unterschiede zwischen Azure Cosmos DB und HBase verstehen.

Ressourcenmodell

Azure Cosmos DB verwendet das folgende Ressourcenmodell: Azure Cosmos DB-Ressourcenmodell mit Konto, Datenbanken, Containern und Elementen.

HBase nutzt das folgende Ressourcenmodell: HBase-Ressourcenmodell mit Namespace, Tabellen, Zeilen und Spalten.

Ressourcenkartierung

Die folgende Tabelle zeigt ein konzeptionelles Mapping zwischen Apache HBase, Apache Phoenix und Azure Cosmos DB.

HBase Phoenix Azure Cosmos DB
Cluster Cluster Konto
Namespace Schema (falls aktiviert) Datenbank
Tabelle Tabelle Container/Sammlung
Säule Familie Säule Familie –
Zeile Zeile Gegenstand/Dokument
Version (Zeitstempel) Version (Zeitstempel) –
n/v Primary Key (Primärschlüssel) Partitionsschlüssel
– Index Index
– Sekundärer Index Sekundärer Index
– Sicht –
– Sequenz –

Datenstrukturvergleich und Unterschiede

Die wichtigsten Unterschiede zwischen der Datenstruktur von Azure Cosmos DB und HBase sind die folgenden:

RowKey

  • In HBase werden die Daten nach RowKey gespeichert und horizontal in Regionen nach dem bei der Tabellenerstellung angegebenen RowKey-Bereich partitioniert.

  • Azure Cosmos DB auf der anderen Seite verteilt die Daten in Partitionen basierend auf dem Hash-Wert eines angegebenen Partitionsschlüssels.

Spaltenfamilie

  • In HBase werden Spalten in einer Column Family (CF) gruppiert.

  • Azure Cosmos DB (API für NoSQL) speichert Daten als JSON-Dokument. Es gelten also alle Eigenschaften, die mit einer JSON-Datenstruktur verbunden sind.

Timestamp

  • HBase verwendet Zeitstempel zur Versionierung mehrerer Instanzen einer bestimmten Zelle. Sie können verschiedene Versionen einer Zelle mit Hilfe des Zeitstempels abfragen.

  • Azure Cosmos DB wird mit der Funktion Änderungsfeed ausgeliefert, die eine dauerhafte Aufzeichnung von Änderungen an einem Container in der Reihenfolge ihres Auftretens verfolgt. Anschließend wird die sortierte Liste von geänderten Dokumenten in der Reihenfolge ausgegeben, in der sie geändert wurden.

Datenformat

  • Das HBase-Datenformat besteht aus RowKey, Column Family: Spaltenname, Zeitstempel, Wert. Es folgt ein Beispiel für eine HBase-Tabellenzeile:

    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 repräsentiert das JSON-Objekt das Datenformat. Der Partitionsschlüssel befindet sich in einem Feld des Dokuments und legt fest, welches Feld der Partitionsschlüssel für die Sammlung ist. Azure Cosmos DB verfügt nicht über das Konzept des Zeitstempels, der für die Spaltenfamilie oder Version verwendet wird. Wie bereits hervorgehoben, unterstützt es Change Feeds, mit denen man Änderungen an einem Container verfolgen und aufzeichnen kann. Im Folgenden finden Sie ein Beispiel für ein Dokument.

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

Tipp

HBase speichert Daten in Byte-Arrays. Wenn Sie also Daten, die Doppelbyte-Zeichen enthalten, zu Azure Cosmos DB migrieren möchten, müssen die Daten UTF-8-kodiert sein.

Konsistenzmodell

HBase bietet streng konsistente Lese- und Schreibvorgänge.

Azure Cosmos DB bietet fünf klar definierte Konsistenzstufen. Jede Stufe bietet Kompromisse bei der Verfügbarkeit und Leistung. Die unterstützten Konsistenzstufen sind von der stärksten zur schwächsten:

  • Stark
  • Begrenzte Veraltung
  • Sitzung
  • Konsistentes Präfix
  • Letztlich

Festlegen der Größe

HBase

Bei einer unternehmensweiten Bereitstellung von HBase sind Master, Regionalserver und ZooKeeper für den Großteil der Dimensionierung verantwortlich. Wie jede verteilte Anwendung ist auch HBase auf Skalierung ausgelegt. Die Leistung von HBase hängt in erster Linie von der Größe der HBase RegionServer ab. Die Dimensionierung wird in erster Linie von zwei Hauptanforderungen bestimmt: Durchsatz und Größe des Datasets, das in HBase gespeichert werden muss.

Azure Cosmos DB

Azure Cosmos DB ist ein PaaS-Angebot von Microsoft und die zugrundeliegenden Details der Infrastrukturbereitstellung werden von den Endnutzern abstrahiert. Wenn ein Azure Cosmos DB-Container bereitgestellt wird, stellt die Azure-Plattform automatisch die zugrunde liegende Infrastruktur (Rechenleistung, Speicher, Speicher, Netzwerkstapel) bereit, um die Leistungsanforderungen einer bestimmten Workload zu unterstützen. Die Kosten aller Datenbankoperationen werden von Azure Cosmos DB normalisiert und durch Request Units (oder kurz RUs) ausgedrückt.

Um den RU-Verbrauch Ihres Workloads zu schätzen, berücksichtigen Sie die folgenden Faktoren:

Es gibt einen Kapazitätsrechner, der bei der Größendimensionierung von RUs hilft.

Sie können auch den autoskalierenden Bereitstellungsdurchsatz in Azure Cosmos DB verwenden, um Ihren Datenbank- oder Containerdurchsatz (RU/sec) automatisch und sofort zu skalieren. Der Durchsatz wird je nach Nutzung skaliert, ohne die Verfügbarkeit, die Latenz, den Durchsatz oder die Leistung zu beeinträchtigen.

Verteilung der Daten

HBase HBase sortiert Daten nach RowKey. Die Daten werden dann in Regionen aufgeteilt und in RegionServern gespeichert. Bei der automatischen Partitionierung werden die Regionen entsprechend der Partitionierungsrichtlinie horizontal aufgeteilt. Dies wird durch den dem HBase-Parameter hbase.hregion.max.filesize zugewiesenen Wert gesteuert (Standardwert ist 10 GB). Eine Zeile in HBase mit einem bestimmten RowKey gehört immer zu einer Region. Darüber hinaus werden die Daten auf der Festplatte für jede Spaltenfamilie getrennt. Dies ermöglicht die Filterung beim Lesen und die E/A-Isolierung auf HFile.

Azure Cosmos DB Azure Cosmos DB verwendet Partitionierung zur Skalierung einzelner Container in der Datenbank. Bei der Partitionierung werden die Elemente in einem Container in bestimmte Teilmengen unterteilt, die als "logische Partitionen" bezeichnet werden. Logische Partitionen werden auf der Grundlage des Wertes des "Partitionsschlüssels" gebildet, der mit jedem Element im Container verbunden ist. Alle Elemente in einer logischen Partition haben denselben Partitionsschlüsselwert. Jede logische Partition kann bis zu 20 GB an Daten speichern.

Physische Partitionen enthalten jeweils ein Replikat Ihrer Daten und eine Instanz der Azure Cosmos DB-Datenbank-Engine. Diese Struktur sorgt für permanente und hochverfügbare Daten und der Durchsatz wird gleichmäßig auf die lokalen physischen Partitionen verteilt. Physische Partitionen werden automatisch erstellt und konfiguriert, und es ist nicht möglich, ihre Größe, ihren Speicherort oder die darin enthaltenen logischen Partitionen zu steuern. Logische Partitionen werden nicht zwischen physischen Partitionen aufgeteilt.

Wie bei HBase RowKey ist das Design von Partitionsschlüsseln auch für Azure Cosmos DB wichtig. Der Row Key von HBase arbeitet mit der Sortierung von Daten und der Speicherung von kontinuierlichen Daten, während der Partition Key von Azure Cosmos DB ein anderer Mechanismus ist, da er die Daten per Hash verteilt. Unter der Annahme, dass Ihre Anwendung, die HBase verwendet, für Datenzugriffsmuster auf HBase optimiert ist, wird die Verwendung desselben RowKey für den Partitionsschlüssel keine guten Leistungsergebnisse liefern. Da es sich um sortierte Daten in HBase handelt, kann der Azure Cosmos DB Composite Index nützlich sein. Sie ist erforderlich, wenn Sie die ORDER BY-Klausel in mehr als einem Feld verwenden möchten. Sie können auch die Leistung vieler Gleichheits- und Bereichsabfragen verbessern, indem Sie einen zusammengesetzten Index definieren.

Verfügbarkeit

HBase HBase besteht aus Master, Region Server und ZooKeeper. Hohe Verfügbarkeit in einem einzigen Cluster kann erreicht werden, indem jede Komponente redundant ausgelegt wird. Bei der Konfiguration der geografischen Redundanz können HBase-Cluster in verschiedenen physischen Rechenzentren eingesetzt werden, wobei die Replikation dazu dient, mehrere Cluster synchron zu halten.

Azure Cosmos DB Azure Cosmos DB erfordert keine Konfiguration wie z.B. die Redundanz von Clusterkomponenten. Es bietet ein umfassendes SLA für hohe Verfügbarkeit, Konsistenz und Latenz. Weitere Einzelheiten finden Sie unter SLA für Azure Cosmos DB.

Datenzuverlässigkeit

HBase HBase basiert auf dem Hadoop Distributed File System (HDFS) und die im HDFS gespeicherten Daten werden dreimal repliziert.

Azure Cosmos DB Azure Cosmos DB bietet in erster Linie auf zwei Arten Hochverfügbarkeit. Zunächst repliziert Azure Cosmos DB Daten zwischen Regionen, die in Ihrem Azure Cosmos DB-Konto konfiguriert sind. Zweitens behält Azure Cosmos DB vier Replikate der Daten in der Region.

Überlegungen vor der Migration

Systembedingte Abhängigkeiten

Dieser Aspekt der Planung konzentriert sich auf das Verständnis der vor- und nachgelagerten Abhängigkeiten für die HBase-Instanz, die zu Azure Cosmos DB migriert wird.

Ein Beispiel für nachgelagerte Abhängigkeiten könnten Anwendungen sein, die Daten aus HBase lesen. Diese müssen optimiert werden, um Daten aus Azure Cosmos DB zu lesen. Die folgenden Punkte müssen im Rahmen der Migration berücksichtigt werden:

  • Fragen zur Beurteilung von Abhängigkeiten - Ist das aktuelle HBase-System eine unabhängige Komponente? Oder ruft er einen Prozess auf einem anderen System auf, oder wird er von einem Prozess auf einem anderen System aufgerufen, oder wird er über einen Verzeichnisdienst angesprochen? Arbeiten andere wichtige Prozesse in Ihrem HBase-Cluster? Diese Systemabhängigkeiten müssen geklärt werden, um die Auswirkungen der Migration zu bestimmen.

  • Das RPO und RTO für die HBase-Bereitstellung vor Ort.

Offline- und Online-Migration

Für eine erfolgreiche Datenmigration ist es wichtig, die Merkmale des Unternehmens, das die Datenbank nutzt, zu verstehen und zu entscheiden, wie sie durchgeführt werden soll. Wählen Sie Offline-Migration, wenn Sie das System vollständig herunterfahren, die Datenmigration durchführen und das System am Zielort neu starten können. Auch wenn Ihre Datenbank ständig ausgelastet ist und Sie sich keinen längeren Ausfall leisten können, sollten Sie eine Online-Migration in Betracht ziehen.

Hinweis

Dieses Dokument behandelt nur die Offline-Migration.

Die Durchführung einer Offline-Datenmigration hängt von der Version von HBase ab, die Sie derzeit verwenden, und von den verfügbaren Tools. Weitere Einzelheiten finden Sie im Abschnitt Datenmigration.

Leistungserwägungen

Bei diesem Aspekt der Planung geht es darum, die Leistungsziele für HBase zu verstehen und sie dann in die Semantik von Azure Cosmos DB zu übersetzen. Beispiel: Wie viele Anforderungseinheiten (Request Units, RU/s) werden in Azure Cosmos DB benötigt, um einen IOPS von X IOPS in HBase zu erreichen? Es gibt Unterschiede zwischen HBase und Azure Cosmos DB. Diese Übung konzentriert sich darauf, eine Übersicht darüber zu erstellen, wie die Leistungsziele von HBase auf Azure Cosmos DB übertragen werden. Dies wird die Grundlage für die Skalierung sein.

Fragen, die man stellen sollte:

  • Ist der HBase-Einsatz lese- oder schreiblastig?
  • Wie ist die Aufteilung zwischen Lesen und Schreiben?
  • Wie hoch ist die IOPS-Zielvorgabe, ausgedrückt in Prozent?
  • Wie/welche Anwendungen werden verwendet, um Daten in HBase zu laden?
  • Wie/welche Anwendungen werden zum Lesen von Daten aus HBase verwendet?

Bei der Ausführung von Abfragen, die sortierte Daten anfordern, gibt HBase das Ergebnis schnell zurück, da die Daten nach RowKey sortiert sind. Azure Cosmos DB verfügt jedoch nicht über ein solches Konzept. Um die Leistung zu optimieren, können Sie bei Bedarf zusammengesetzte Indizes verwenden.

Überlegungen zur Bereitstellung

Sie können Azure Cosmos DB for NoSQL mit dem Azure-Portal oder der Azure CLI bereitstellen. Da als Migrationsziel Azure Cosmos DB for NoSQL verwendet wird, wählen Sie bei der Bereitstellung als Parameter für die API „NoSQL“ aus. Legen Sie außerdem Geo-Redundanz, regionsübergreifende Schreibvorgänge und Verfügbarkeitszonen entsprechend Ihren Verfügbarkeitsanforderungen fest.

Berücksichtigung des Netzes

Azure Cosmos DB umfasst drei wichtige Netzwerkoptionen. Die erste ist eine Konfiguration, die eine öffentliche IP-Adresse verwendet und den Zugriff mit einer IP-Firewall kontrolliert (Standard). Die zweite ist eine Konfiguration, die eine öffentliche IP-Adresse verwendet und den Zugriff nur von einem bestimmten Subnetz eines bestimmten virtuellen Netzwerks (Service-Endpunkt) erlaubt. Die dritte ist eine Konfiguration (privater Endpunkt), die mit einer privaten IP-Adresse in ein privates Netz eintritt.

In den folgenden Dokumenten finden Sie weitere Informationen zu den drei Netzoptionen:

Bewerten Sie Ihre vorhandenen Daten

Datenermittlung

Sammeln Sie vorab Informationen aus Ihrem bestehenden HBase-Cluster, um die Daten zu identifizieren, die Sie migrieren möchten. Diese können Ihnen dabei helfen, die Art der Migration zu bestimmen, zu entscheiden, welche Tabellen migriert werden sollen, die Struktur innerhalb dieser Tabellen zu verstehen und zu entscheiden, wie Sie Ihr Datenmodell aufbauen wollen. Sammeln Sie zum Beispiel Details wie die folgenden:

  • HBase-Version
  • Zieltabellen für die Migration
  • Informationen zur Spaltenfamilie
  • Status der Tabelle

Die folgenden Befehle zeigen, wie die oben genannten Details mit einem hbase-Shell-Skript gesammelt und im lokalen Dateisystem des Betriebssystems gespeichert werden.

HBase-Version abrufen

hbase version -n > hbase-version.txt

Ausgabe:

cat hbase-version.txt
HBase 2.1.8.4.1.2.5

Abrufen der Liste der Tabellen

Sie können eine Liste der in HBase gespeicherten Tabellen abrufen. Wenn Sie einen anderen als den Standard-Namensraum erstellt haben, wird dieser im Format "Namespace: Tabelle"-Format ausgegeben.

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

Ausgabe:

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

Identifizieren Sie die zu migrierenden Tabellen

Rufen Sie die Details der Spaltenfamilien in der Tabelle ab, indem Sie den Tabellennamen angeben, der migriert werden soll.

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

Ausgabe:

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

Abrufen der Spaltenfamilien in der Tabelle und ihrer Einstellungen

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

Ausgabe:

{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

[...]

Sie können nützliche Größeninformationen wie die Größe des Heap-Speichers, die Anzahl der Regionen, die Anzahl der Anfragen als Status des Clusters und die Größe der Daten in komprimierter/unkomprimierter Form als Status der Tabelle erhalten.

Wenn Sie Apache Phoenix auf einem HBase-Cluster verwenden, müssen Sie auch Daten von Phoenix sammeln.

  • Zieltabelle für die Migration
  • Tabellenschemata
  • Indizes
  • Primärschlüssel

Verbinden Sie sich mit Apache Phoenix auf Ihrem Cluster

sqlline.py ZOOKEEPER/hbase-unsecure

Tabellenliste abrufen

!tables

Tabellendetails abrufen

!describe <Table Name>

Indexdetails anzeigen

!indexes <Table Name>

Abrufen der Primärschlüsseldetails

!primarykeys <Table Name>

Migrieren Ihrer Daten

Migrationsoptionen

Es gibt verschiedene Methoden, um Daten offline zu migrieren, aber hier stellen wir Ihnen vor, wie Sie Azure Data Factory verwenden.

Lösung Quellversion Überlegungen
Azure Data Factory HBase < 2 Einfache Einrichtung Geeignet für große Datasets Unterstützt HBase 2 oder höher nicht.
Apache Spark Alle Versionen Unterstützung aller Versionen von HBase. Geeignet für große Datasets Spark-Setup erforderlich.
Benutzerdefiniertes Tool mit Azure Cosmos DB-Bulk Executor-Bibliothek Alle Versionen Höchste Flexibilität bei der Erstellung benutzerdefinierter Datenmigrations-Tools unter Verwendung von Bibliotheken. Erfordert mehr Aufwand bei der Einrichtung.

Das folgende Flussdiagramm verwendet einige Bedingungen, um die verfügbaren Datenmigrationsmethoden zu erreichen. Flussdiagramm der Optionen zum Migrieren von Daten zu Azure Cosmos DB

Migrieren mit Data Factory

Diese Option ist für große Datensätze geeignet. Die Azure Cosmos DB Bulk Executor-Bibliothek wird verwendet. Es gibt keine Kontrollpunkte, d. h., wenn Sie während der Migration auf Probleme stoßen, müssen Sie den Migrationsprozess von Anfang an neu starten. Sie können auch die selbst gehostete Integrationslaufzeit von Data Factory verwenden, um eine Verbindung zu Ihrer lokalen HBase herzustellen, oder Data Factory in einem Managed VNET bereitstellen und über VPN oder ExpressRoute eine Verbindung zu Ihrem lokalen Netzwerk herstellen.

Die Kopieraktivität von Data Factory unterstützt HBase als Datenquelle. Siehe den Artikel Kopieren von Daten aus HBase mit Azure Data Factory für weitere Details.

Sie können Azure Cosmos DB (API für NoSQL) als Ziel für Ihre Daten angeben. Weitere Informationen finden Sie im Artikel Kopieren und Transformieren von Daten in Azure Cosmos DB (API für NoSQL) mit Azure Data Factory.

Architektur zum Migrieren von Daten vom lokalen System zu Azure Cosmos DB mithilfe von Data Factory

Migrieren mit Apache Spark – Apache HBase-Connector und Azure Cosmos DB Spark-Connector

Hier ist ein Beispiel für die Migration Ihrer Daten zu Azure Cosmos DB. Es wird davon ausgegangen, dass HBase 2.1.0 und Spark 2.4.0 im selben Cluster ausgeführt werden.

Apache Spark: Das Repository für den Apache HBase-Connector finden Sie unter Apache Spark: Apache HBase-Connector.

Für den Azure Cosmos DB Spark-Konnektor lesen Sie bitte den Quick Start Guide und laden Sie die entsprechende Bibliothek für Ihre Spark-Version herunter.

  1. Kopieren Sie hbase-site.xml in Ihr Spark-Konfigurationsverzeichnis.

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

  2. Führen Sie spark -shell mit Spark HBase Connector und Azure Cosmos DB Spark Connector aus.

    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. Nachdem die Spark-Shell gestartet wurde, führen Sie den Scala-Code wie folgt aus. Importieren Sie die Bibliotheken, die zum Laden von Daten aus HBase benötigt werden.

    // 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. Definieren Sie das Spark-Katalogschema für Ihre HBase-Tabellen. Hier ist der Namensraum „default” und der Tabellenname ist „Contacts”. Der Zeilenschlüssel wird als Schlüssel angegeben. Spalten, Spaltenfamilie und Spalte werden dem Katalog von Spark zugeordnet.

    // 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. Definieren Sie als nächstes eine Methode, um die Daten aus der HBase-Kontakttabelle als DataFrame zu erhalten.

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

  6. Erstellen Sie einen DataFrame mit der definierten Methode.

    val df = withCatalog(catalog)

  7. Importieren Sie dann die Bibliotheken, die für die Verwendung des Azure Cosmos DB Spark-Connectors benötigt werden.

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

  8. Nehmen Sie Einstellungen für das Schreiben von Daten in Azure Cosmos DB vor.

    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. Schreiben Sie DataFrame-Daten in Azure Cosmos DB.

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

Es schreibt parallel mit hoher Geschwindigkeit, seine Leistung ist hoch. Andererseits ist zu beachten, dass dies auf der Azure Cosmos DB-Seite bis zu RU/s verbrauchen kann.

Phoenix

Phoenix wird als Data Factory-Datenquelle unterstützt. Detaillierte Schritte finden Sie in den folgenden Dokumenten.

Migrieren Ihres Codes

Dieser Abschnitt beschreibt die Unterschiede zwischen der Erstellung von Anwendungen in Azure Cosmos DB for NoSQL und HBase. Die Beispiele hier verwenden Apache HBase 2.x APIs und Azure Cosmos DB Java SDK v4.

Diese HBase-Beispielcodes basieren auf denen, die in der offiziellen HBase-Dokumentation beschrieben sind.

Die Mappings für die Code-Migration werden hier gezeigt, aber die in diesen Beispielen verwendeten HBase RowKeys und Azure Cosmos DB Partition Keys sind nicht immer gut gestaltet. Entwurf entsprechend dem tatsächlichen Datenmodell der Migrationsquelle.

Herstellen der Verbindung

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

Datenbank/Tabelle/Auflistung erstellen

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

Zeile oder Dokument erstellen

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 bietet Typsicherheit aufgrund des Datenmodells. Hier wird ein Datenmodell namens „Familie“ verwendet.

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

Der obige Text ist Teil des Codes. Siehe vollständiges Codebeispiel.

Verwenden Sie die Klasse "Familie", um ein Dokument zu definieren und ein Element einzufügen.

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

Zeile/Dokument lesen

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

Aktualisieren von Daten

HBase

Für HBase verwenden Sie die append-Methode und checkAndPut-Methode, um den Wert zu aktualisieren. „Append“ ist der Prozess des atomaren Anhängens eines Wertes an das Ende des aktuellen Wertes, und „checkAndPut“ vergleicht atomar den aktuellen Wert mit dem erwarteten Wert und aktualisiert nur, wenn sie übereinstimmen.

// 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 werden Aktualisierungen als Upsert-Operationen behandelt. Das heißt, wenn das Dokument nicht vorhanden ist, wird es eingefügt.

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

Zeile/Dokument löschen

HBase

In Hbase gibt es keine Möglichkeit, eine Zeile direkt nach Wert zu löschen. Möglicherweise haben Sie den Löschvorgang in Kombination mit ValueFilter usw. implementiert. In diesem Beispiel wird die zu löschende Zeile durch RowKey angegeben.

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

Die Löschmethode nach Dokument-ID ist unten dargestellt.

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

Abfrage von Zeilen/Dokumenten

HBase HBase ermöglicht es, mehrere Zeilen durch Scannen abzurufen. Sie können Filter verwenden, um detaillierte Scanbedingungen festzulegen. Siehe Client Request Filters für die in HBase eingebauten 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

Filterbetrieb

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

Tabelle/Auflistung löschen

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

Weitere Überlegungen

HBase-Cluster können mit HBase-Workloads und MapReduce, Hive, Spark und anderen verwendet werden. Wenn Sie andere Workloads mit Ihrer aktuellen HBase haben, müssen diese ebenfalls migriert werden. Einzelheiten finden Sie im jeweiligen Migrationsleitfaden.

  • MapReduce
  • hbase
  • Spark

Serverseitige Programmierung

HBase bietet mehrere Funktionen für die serverseitige Programmierung. Wenn Sie diese Funktionen verwenden, müssen Sie auch deren Verarbeitung migrieren.

HBase

  • Benutzerdefinierte Filter

    In HBase sind verschiedene Filter standardmäßig verfügbar, aber Sie können auch Ihre eigenen benutzerdefinierten Filter implementieren. Benutzerdefinierte Filter können implementiert werden, wenn die in HBase standardmäßig verfügbaren Filter Ihren Anforderungen nicht genügen.

  • Prozessor

    Der Coprozessor ist ein Framework, mit dem Sie Ihren eigenen Code auf dem Regionalserver ausführen können. Durch die Verwendung des Coprozessors ist es möglich, die Verarbeitung, die auf der Client-Seite ausgeführt wurde, auf der Server-Seite durchzuführen, und je nach Verarbeitung kann sie effizienter gestaltet werden. Es gibt zwei Arten von Coprozessoren: Beobachter und Endpunkt.

    • Beobachter

      • Beobachter haken bestimmte Vorgänge und Ereignisse ab. Dies ist eine Funktion zum Hinzufügen einer beliebigen Verarbeitung. Dies ist eine Funktion, die den RDBMS-Triggern ähnelt.

    • Endpunkt

      • Endpoint ist eine Funktion zur Erweiterung von HBase RPC. Es handelt sich um eine Funktion, die einer RDBMS Stored Procedure ähnelt.

Azure Cosmos DB

  • Gespeicherte Prozedur

    • Gespeicherte Azure Cosmos DB-Prozeduren sind in JavaScript geschrieben und können Vorgänge wie das Erstellen, Aktualisieren, Lesen, Abfragen und Löschen von Elementen in Azure Cosmos DB-Containern ausführen.

  • Trigger

    • Für Operationen in der Datenbank können Auslöser angegeben werden. Es sind zwei Methoden vorgesehen: ein Pre-Trigger, der vor der Änderung des Datenbankelements ausgeführt wird, und ein Post-Trigger, der nach der Änderung des Datenbankelements ausgeführt wird.

  • UDF

    • Azure Cosmos DB ermöglicht es Ihnen, benutzerdefinierte Funktionen (UDFs) zu definieren. UDFs können auch in JavaScript geschrieben werden.

Gespeicherte Prozeduren und Auslöser verbrauchen RUs je nach Komplexität der durchgeführten Operationen. Prüfen Sie bei der Entwicklung der serverseitigen Verarbeitung die erforderliche Nutzung, um ein besseres Verständnis für die Menge an EVU zu erhalten, die von jedem Vorgang verbraucht wird. Siehe Abfrageeinheiten in Azure Cosmos DB und Abfragekosten in Azure Cosmos DB optimieren für Details.

Server-seitige Programmierung von Zuordnungen

hbase Azure Cosmos DB Beschreibung
Benutzerdefinierte Filter WHERE-Klausel Wenn die durch den benutzerdefinierten Filter implementierte Verarbeitung nicht durch die WHERE-Klausel in Azure Cosmos DB erreicht werden kann, verwenden Sie UDF in Kombination.
Coprozessor (Beobachter) Auslöser Observer ist ein Trigger, der vor und nach einem bestimmten Ereignis ausgeführt wird. Ebenso wie Observer Aufrufe vor und nach einem Ereignis unterstützt, unterstützt Azure Cosmos DB Trigger vor und nach einem Ereignis.
Coprozessor (Endpunkt) Gespeicherte Prozedur Endpoint ist ein serverseitiger Datenverarbeitungsmechanismus, der für jede Region ausgeführt wird. Dies ist vergleichbar mit einer im RDBMS gespeicherten Prozedur. Gespeicherte Azure Cosmos DB-Prozeduren werden mit JavaScript geschrieben. So wird der Zugriff auf alle Vorgänge ermöglicht, die Sie über gespeicherte Prozeduren in Azure Cosmos DB durchführen können.

Hinweis

Abhängig von der in HBase implementierten Verarbeitung können unterschiedliche Zuordnungen und Implementierungen in Azure Cosmos DB erforderlich sein.

Sicherheit

Für die Datensicherheit sind der Kunde und der Datenbankanbieter gemeinsam verantwortlich. Bei Vor-Ort-Lösungen müssen die Kunden alles vom Endpunktschutz bis zur physischen Hardwaresicherheit bereitstellen, was keine leichte Aufgabe ist. Wenn Sie sich für einen PaaS-Cloud-Datenbankanbieter wie Azure Cosmos DB entscheiden, wird die Beteiligung des Kunden reduziert. Azure Cosmos DB wird auf der Azure-Plattform ausgeführt und kann daher auf eine andere Weise als HBase erweitert werden. Azure Cosmos DB erfordert keine zusätzlichen Komponenten, die aus Sicherheitsgründen installiert werden müssen. Wir empfehlen Ihnen, die Migration der Sicherheitsimplementierung Ihres Datenbanksystems anhand der folgenden Checkliste zu prüfen:

Sicherheitskontrolle HBase Azure Cosmos DB
Netzwerksicherheit und Firewall-Einstellungen Kontrolle des Datenverkehrs mit Hilfe von Sicherheitsfunktionen wie Netzwerkgeräten. Unterstützt die richtlinienbasierte IP-basierte Zugriffskontrolle auf der eingehenden Firewall.
Benutzerauthentifizierung und feinkörnige Benutzerkontrollen Fein abgestufte Zugriffskontrolle durch Kombination von LDAP mit Sicherheitskomponenten wie Apache Ranger. Sie können den Primärschlüssel des Kontos verwenden, um Benutzer- und Berechtigungsressourcen für jede Datenbank zu erstellen. Sie können auch Ihre Microsoft Entra ID verwenden, um Ihre Datenanforderungen zu authentifizieren. So können Sie Datenanforderungen mit einem fein abgestuften RBAC-Modell autorisieren.
Möglichkeit zum globalen Replizieren von Daten bei regionalen Ausfällen Erstellen Sie eine Datenbankreplik in einem entfernten Rechenzentrum mithilfe der HBase-Replikation. Azure Cosmos DB führt eine konfigurationsfreie globale Verteilung durch und ermöglicht es Ihnen, Daten per Knopfdruck in Azure-Rechenzentren auf der ganzen Welt zu replizieren. Im Hinblick auf die Sicherheit gewährleistet die globale Replikation, dass Ihre Daten vor lokalen Ausfällen geschützt sind.
Möglichkeit zum Durchführen eines Failovers zwischen Rechenzentren Sie müssen die Ausfallsicherung selbst implementieren. Wenn Sie Daten in mehrere Rechenzentren replizieren und das Rechenzentrum der Region offline geht, übernimmt Azure Cosmos DB automatisch die Operation.
Lokale Datenreplikation innerhalb eines Rechenzentrums Der HDFS-Mechanismus ermöglicht es, mehrere Replikate auf verschiedenen Knoten innerhalb eines einzigen Dateisystems zu erstellen. Azure Cosmos DB repliziert automatisch Daten, um eine hohe Verfügbarkeit zu gewährleisten, selbst innerhalb eines einzelnen Rechenzentrums. Sie können die Konsistenzstufe selbst wählen.
Automatische Datensicherungen Es gibt keine automatische Sicherungsfunktion. Sie müssen selbst für die Datensicherung sorgen. Azure Cosmos DB wird regelmäßig gesichert und im georedundanten Speicher abgelegt.
Schützen und Isolieren von vertraulichen Daten Wenn Sie z. B. Apache Ranger verwenden, können Sie die Ranger-Richtlinie verwenden, um die Richtlinie auf die Tabelle anzuwenden. Sie können personenbezogene und andere sensible Daten in spezifischen Containern speichern und den Lese-/Schreibzugriff oder den Nur-Lese-Zugriff auf bestimmte Benutzer beschränken.
Überwachen auf Angriffe Sie muss mit Produkten von Drittanbietern implementiert werden. Mithilfe von Überwachungsprotokollierung und Aktivitätsprotokollen können Sie Ihr Konto auf normale und ungewöhnliche Aktivitäten überwachen.
Reagieren auf Angriffe Sie muss mit Produkten von Drittanbietern implementiert werden. Wenn Sie den Azure-Support kontaktieren und einen potenziellen Angriff melden, beginnt ein fünfstufiger Prozess zur Reaktion auf einen Vorfall.
Möglichkeit, Daten per Geofencing auf einen geografischen Raum einzugrenzen, um Anforderungen an die Datengovernance zu erfüllen Sie müssen die Beschränkungen der jeweiligen Länder oder Regionen selbst prüfen und implementieren. Garantiert die Datenverwaltung für souveräne Regionen (Deutschland, China, US Gov, etc.).
Physischer Schutz von Servern in geschützten Rechenzentren Dies hängt vom Rechenzentrum ab, in dem sich das System befindet. Eine Liste der neuesten Zertifizierungen finden Sie auf der globalen Azure Compliance-Website.
Zertifizierungen Hängt von der Hadoop-Distribution ab. Siehe Azure-Konformitätsdokumentation

Überwachung

HBase überwacht den Cluster in der Regel mit der Web-UI für die Clustermetrik oder mit Ambari, Cloudera Manager oder anderen Überwachungstools. Azure Cosmos DB ermöglicht es Ihnen, den in die Azure-Plattform integrierten Überwachungsmechanismus zu nutzen. Weitere Informationen zur Überwachung von Azure Cosmos DB finden Sie unter Überwachung von Azure Cosmos DB.

Wenn Ihre Umgebung eine HBase-Systemüberwachung implementiert, um Warnungen zu senden, z. B. per E-Mail, können Sie diese möglicherweise durch Azure Monitor-Warnungen ersetzen. Sie können Warnungen basierend auf Metriken oder Aktivitätsprotokoll-Ereignissen für Ihr Azure Cosmos DB-Konto erhalten.

Weitere Informationen zu Alerts in Azure Monitor finden Sie unter Erstellen von Alerts für Azure Cosmos DB mit Azure Monitor

Sehen Sie sich auch die Informationen zu Azure Cosmos DB-Metriken und -Protokolltypen an, die von Azure Monitor gesammelt werden können.

Sicherung und Notfallwiederherstellung

Datensicherung

Es gibt mehrere Möglichkeiten, ein Backup von HBase zu erstellen. Zum Beispiel Snapshot, Export, CopyTable, Offline-Sicherung von HDFS-Daten und andere benutzerdefinierte Sicherungen.

Azure Cosmos DB sichert die Daten automatisch in regelmäßigen Abständen, was die Leistung oder Verfügbarkeit der Datenbankoperationen nicht beeinträchtigt. Backups werden im Azure-Speicher gespeichert und können bei Bedarf zur Wiederherstellung von Daten verwendet werden. Es gibt zwei Arten von Azure Cosmos DB-Sicherungen:

Notfallwiederherstellung

HBase ist ein fehlertolerantes verteiltes System, aber Sie müssen eine Notfallwiederherstellung mit Snapshot, Replikation usw. implementieren, wenn im Falle eines Ausfalls auf der Ebene des Rechenzentrums ein Failover am Backup-Standort erforderlich ist. Die HBase-Replikation kann mit drei Replikationsmodellen eingerichtet werden: Leader-Follower, Leader-Leader und Cyclic. Wenn die HBase-Quellinstanz eine Notfallwiederherstellung implementiert, müssen Sie wissen, wie Sie die Notfallwiederherstellung in Azure Cosmos DB konfigurieren und Ihre Systemanforderungen erfüllen können.

Azure Cosmos DB ist eine global verteilte Datenbank mit integrierten Disaster-Recovery-Funktionen. Sie können Ihre DB-Daten in jede beliebige Azure-Region replizieren. Azure Cosmos DB hält Ihre Datenbank im unwahrscheinlichen Fall eines Ausfalls in einigen Regionen hochverfügbar.

Azure Cosmos DB-Konto, das nur eine einzige Region verwendet, kann im Falle eines Regionsausfalls die Verfügbarkeit verlieren. Wir empfehlen Ihnen, mindestens zwei Regionen zu konfigurieren, um stets eine hohe Verfügbarkeit zu gewährleisten. Sie können auch eine hohe Verfügbarkeit für Schreib- und Lesevorgänge sicherstellen, indem Sie Ihr Azure Cosmos DB-Konto so konfigurieren, dass es mindestens zwei Regionen mit mehreren Schreibregionen umfasst, um eine hohe Verfügbarkeit für Schreib- und Lesevorgänge sicherzustellen. Bei Multi-Region-Konten, die aus mehreren Schreibregionen bestehen, wird der Failover-Vorgang zwischen Regionen vom Azure Cosmos DB-Client erkannt und verwaltet. Diese sind vorübergehend und erfordern keine Änderungen in der Anwendung. Auf diese Weise können Sie eine Verfügbarkeitskonfiguration erreichen, die Disaster Recovery für Azure Cosmos DB beinhaltet. Wie bereits erwähnt, kann die HBase-Replikation mit drei Modellen eingerichtet werden, aber Azure Cosmos DB kann mit SLA-basierter Verfügbarkeit eingerichtet werden, indem einzelne und mehrere Schreibregionen konfiguriert werden.

Weitere Informationen zur Hochverfügbarkeit finden Sie unter Wie bietet Azure Cosmos DB Hochverfügbarkeit

Häufig gestellte Fragen

Warum sollten Sie zur API für NoSQL statt zu anderen APIs in Azure Cosmos DB migrieren?

Die API für NoSQL bietet das beste End-to-End-Erlebnis in Bezug auf die Schnittstelle, die Clientbibliothek des Dienst-SDK. Neue Features, die in Azure Cosmos DB eingeführt werden, sind zuerst in Ihrem API für NoSQL-Konto verfügbar. Darüber hinaus unterstützt die API für NoSQL Analysen und bietet eine Leistungstrennung zwischen Produktions- und Analyseworkloads. Wenn Sie die modernisierten Technologien zum Entwickeln Ihrer Anwendungen nutzen möchten, ist die API für NoSQL die empfohlene Option.

Kann ich den HBase RowKey dem Azure Cosmos DB-Partitionsschlüssel zuweisen?

Es kann sein, dass sie noch nicht optimiert ist. In HBase werden die Daten nach dem angegebenen RowKey sortiert, in der Region gespeichert und in feste Größen unterteilt. Dieses Verhalten unterscheidet sich von der Partitionierung in Azure Cosmos DB. Daher müssen die Schlüssel umgestaltet werden, um die Daten entsprechend den Merkmalen der Arbeitslast besser zu verteilen. Siehe Abschnitt Verteilung für weitere Einzelheiten.

Die Daten werden in HBase nach RowKey sortiert, in Azure Cosmos DB jedoch nach Schlüssel partitioniert. Wie kann Azure Cosmos DB Sortierung und Kollokation erreichen?

In Azure Cosmos DB können Sie einen zusammengesetzten Index hinzufügen, um Ihre Daten in aufsteigender oder absteigender Reihenfolge zu sortieren und so die Leistung von Gleichheits- und Bereichsabfragen zu verbessern. Siehe den Abschnitt Verteilung und den Zusammengesetzten Index in der Produktdokumentation.

Die analytische Verarbeitung wird auf HBase-Daten mit Hive oder Spark ausgeführt. Wie lässt sich diese in Azure Cosmos DB modernisieren?

Sie können den analytischen Speicher von Azure Cosmos DB verwenden, um Betriebsdaten automatisch mit einem anderen Spaltenspeicher zu synchronisieren. Das Spaltenspeicherformat eignet sich für große analytische Abfragen, die auf optimierte Weise ausgeführt werden, wodurch sich die Latenz für solche Abfragen verbessert. Mit Azure Synapse Link können Sie eine ETL-freie HTAP-Lösung aufbauen, indem Sie Azure Synapse Analytics direkt mit dem analytischen Speicher Azure Cosmos DB verknüpfen. Dies ermöglicht Ihnen die Durchführung umfangreicher Analysen von Betriebsdaten nahezu in Echtzeit. Synapse Analytics unterstützt Apache Spark und serverlose SQL-Pools im Azure Cosmos DB-Analysespeicher. Sie können diese Funktion nutzen, um Ihre analytische Verarbeitung zu migrieren. Siehe Analytischer Speicher für weitere Informationen.

Wie können Benutzer die Zeitstempelabfrage in HBase für Azure Cosmos DB nutzen?

Die Versionierung von Zeitstempeln in Azure Cosmos DB entspricht nicht genau derjenigen in HBase. Azure Cosmos DB bietet jedoch die Möglichkeit, auf den Änderungsfeed zuzugreifen und ihn für die Versionierung zu nutzen.

  • Speichern Sie jede Version/Änderung als separates Element.

  • Lesen Sie den Änderungsfeed, um Änderungen zusammenzuführen/zu konsolidieren und entsprechende Aktionen auszulösen, indem Sie nach dem Feld "_ts" filtern. Außerdem können Sie bei alten Datenversionen mit TTL alte Versionen auslaufen lassen.

Nächste Schritte

  • Last updated on