Migrace dat z Apache HBase do účtu Azure Cosmos DB for NoSQL
PLATÍ PRO: NoSQL
Azure Cosmos DB je škálovatelná globálně distribuovaná plně spravovaná databáze. Poskytuje zaručený přístup k datům s nízkou latencí. Další informace o službě Azure Cosmos DB najdete v článku s přehledem. Tento článek vás provede migrací dat z HBase do účtu Azure Cosmos DB for NoSQL.
Rozdíly mezi Azure Cosmos DB a HBase
Před migrací musíte porozumět rozdílům mezi Azure Cosmos DB a HBase.
Model prostředků
Azure Cosmos DB má následující model prostředků:
HBase má následující model prostředků:
Mapování prostředků
Následující tabulka ukazuje koncepční mapování mezi Apache HBase, Apache Phoenix a Azure Cosmos DB.
HBase | Phoenix | Azure Cosmos DB |
---|---|---|
Cluster | Cluster | Obchodní vztah |
Obor názvů | Schéma (pokud je povoleno) | Databáze |
Table | Table | Kontejner nebo kolekce |
Řada sloupců | Řada sloupců | – |
Řádek | Řádek | Položka nebo dokument |
Verze (časové razítko) | Verze (časové razítko) | – |
N/A | Primární klíč | Klíč oddílu |
– | Index | Index |
– | Sekundární index | Sekundární index |
– | Zobrazení | – |
N/A | Sequence | – |
Porovnání a rozdíly ve struktuře dat
Hlavní rozdíly mezi datovou strukturou služby Azure Cosmos DB a HBase jsou následující:
RowKey
V HBase se data ukládají pomocí RowKey a horizontálně rozdělují do oblastí podle rozsahu RowKey zadaného během vytváření tabulky.
Azure Cosmos DB na druhé straně distribuuje data do oddílů na základě hodnoty hash zadaného klíče oddílu.
Řada sloupců
V HBase jsou sloupce seskupené v rámci rodiny sloupců (CF).
Azure Cosmos DB (API for NoSQL) ukládá data jako dokument JSON . Proto platí všechny vlastnosti přidružené ke struktuře dat JSON.
Timestamp
HBase používá časové razítko k verzi více instancí dané buňky. Pomocí časového razítka můžete dotazovat různé verze buňky.
Azure Cosmos DB se dodává s funkcí kanálu změn, která sleduje trvalý záznam změn v kontejneru v pořadí, v jakém k nim dochází. Výstupem je pak seznam změněných dokumentů v pořadí podle času úprav.
Formát dat
Datový formát HBase se skládá z RowKey, Column Family: Column Name, Timestamp, Value. Následuje příklad řádku tabulky HBase:
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
Ve službě Azure Cosmos DB for NoSQL představuje objekt JSON formát dat. Klíč oddílu se nachází v poli v dokumentu a nastaví, které pole je klíčem oddílu pro kolekci. Azure Cosmos DB nemá koncept časového razítka používaného pro řadu sloupců nebo verzi. Jak už bylo zvýrazněno dříve, má podporu kanálu změn, prostřednictvím které může sledovat nebo zaznamenávat změny provedené v kontejneru. Následuje příklad dokumentu.
{ "RowId": "1000", "OfficeAddress": "1111 San Gabriel Dr.", "OfficePhone": "1-425-000-0002", "PersonalName": "John Dole", "PersonalPhone": "1-425-000-0001", }
Tip
HBase ukládá data do bajtového pole, takže pokud chcete migrovat data, která obsahují dvojité bajtové znaky do služby Azure Cosmos DB, musí být data zakódovaná pomocí kódování UTF-8.
Model konzistence
HBase nabízí přísně konzistentní čtení a zápisy.
Azure Cosmos DB nabízí pět jasně definovaných úrovní konzistence. Každá úroveň poskytuje kompromisy mezi dostupností a výkonem. Úrovně konzistence jsou podporované od nejsilnějších po nejslabší:
- Silné
- Omezená neaktuálnost
- Relace
- Konzistentní předpona
- Případné
Nastavení velikosti
HBase
Pro nasazení HBase na podnikové úrovni, master; Servery oblastí; a ZooKeeper řídí většinu velikosti. Stejně jako každá distribuovaná aplikace je HBase navržená tak, aby škáloval na více instancí. Výkon HBase je primárně řízen velikostí HBase RegionServers. Určení velikosti je primárně řízeno dvěma klíčovými požadavky – propustností a velikostí datové sady, která musí být uložena v HBase.
Azure Cosmos DB
Azure Cosmos DB je nabídka PaaS od Microsoftu a podrobností o nasazení základní infrastruktury se od koncových uživatelů abstrahují. Když se zřídí kontejner Azure Cosmos DB, platforma Azure automaticky zřídí základní infrastrukturu (výpočetní prostředky, úložiště, paměť, zásobník sítí), aby podporovala požadavky na výkon dané úlohy. Azure Cosmos DB normalizuje náklady na všechny databázové operace a jsou vyjádřeny jednotkami žádostí (nebo RU).
Pokud chcete odhadnout jednotky RU spotřebované vaší úlohou, zvažte následující faktory:
K dispozici je kalkulačka kapacity, která vám pomůže s určením velikosti ru.
Propustnost zřizování automatického škálování ve službě Azure Cosmos DB můžete také použít k automatickému a okamžitému škálování databáze nebo propustnosti kontejneru (RU/s). Propustnost se škáluje na základě využití, aniž by to mělo vliv na dostupnost úloh, latenci, propustnost nebo výkon.
Distribuce dat
HBase HBase seřadí data podle RowKey. Data se pak rozdělí do oblastí a uloží se do oblastí. Automatické dělení rozděluje oblasti horizontálně podle zásad dělení. To je řízeno hodnotou přiřazenou parametru hbase.hregion.max.filesize
HBase (výchozí hodnota je 10 GB). Řádek v HBase s daným klíčem RowKey vždy patří do jedné oblasti. Kromě toho jsou data oddělená na disku pro každou řadu sloupců. To umožňuje filtrování v době čtení a izolace vstupně-výstupních operací v HFile.
Azure Cosmos DB Azure Cosmos DB používá dělení k škálování jednotlivých kontejnerů v databázi. Dělení rozdělí položky v kontejneru na konkrétní podmnožinu s názvem "logické oddíly". Logické oddíly se vytvářejí na základě hodnoty klíče oddílu přidruženého ke každé položce v kontejneru. Všechny položky v logickém oddílu mají stejnou hodnotu klíče oddílu. Každý logický oddíl může obsahovat až 20 GB dat.
Fyzické oddíly obsahují repliku vašich dat a instanci databázového stroje Azure Cosmos DB. Díky této struktuře jsou vaše data odolná a vysoce dostupná a propustnost se rovnoměrně rozdělí mezi místní fyzické oddíly. Fyzické oddíly se vytvářejí a konfigurují automaticky a není možné řídit jejich velikost, umístění nebo logické oddíly, které obsahují. Logické oddíly nejsou rozdělené mezi fyzické oddíly.
Stejně jako u HBase RowKey je návrh klíče oddílu důležitý pro službu Azure Cosmos DB. Klíč řádku HBase funguje tak, že seřadí data a uloží průběžná data a klíč oddílu služby Azure Cosmos DB je jiný mechanismus, protože distribuuje data pomocí hodnot hash. Za předpokladu, že je vaše aplikace využívající HBase optimalizovaná pro vzory přístupu k datům do HBase, použití stejného RowKey pro klíč oddílu nebude poskytovat dobré výsledky výkonu. Vzhledem k tomu, že jsou seřazená data v HBase, může být užitečný složený index Azure Cosmos DB. Vyžaduje se, pokud chcete použít klauzuli ORDER BY ve více než jednom poli. Výkon mnoha dotazů se stejným rozsahem můžete také zlepšit definováním složeného indexu.
Dostupnost
HBase HBase se skládá z hlavního serveru; Server oblasti; a ZooKeeper. Vysokou dostupnost v jednom clusteru je možné dosáhnout tak, že každou komponentu redundantní. Při konfiguraci geografické redundance můžete clustery HBase nasadit napříč různými fyzickými datovými centry a pomocí replikace udržovat více clusterů v synchronizaci.
Azure Cosmos DB Azure Cosmos DB nevyžaduje žádnou konfiguraci, jako je redundance součástí clusteru. Poskytuje komplexní smlouvu SLA pro zajištění vysoké dostupnosti, konzistence a latence. Další podrobnosti najdete ve sla pro Službu Azure Cosmos DB .
Spolehlivost dat
HBase HBase je založená na systému souborů HDFS (Hadoop Distributed File System) a data uložená v HDFS se replikují třikrát.
Azure Cosmos DB Azure Cosmos DB primárně poskytuje vysokou dostupnost dvěma způsoby. Nejprve Azure Cosmos DB replikuje data mezi oblastmi nakonfigurovanými v rámci vašeho účtu služby Azure Cosmos DB. Za druhé, Azure Cosmos DB uchovává čtyři repliky dat v oblasti.
Důležité informace před migrací
Systémové závislosti
Tento aspekt plánování se zaměřuje na pochopení nadřazených a podřízených závislostí pro instanci HBase, která se migruje do služby Azure Cosmos DB.
Příkladem podřízených závislostí můžou být aplikace, které čtou data z HBase. Musí se refaktorovat pro čtení ze služby Azure Cosmos DB. V rámci migrace je nutné zvážit tyto následující body:
Dotazy týkající se posouzení závislostí – je aktuální systém HBase nezávislou komponentou? Nebo volá proces v jiném systému, nebo je volána procesem v jiném systému, nebo se k němu přistupuje pomocí adresářové služby? Fungují v clusteru HBase další důležité procesy? Tyto systémové závislosti je potřeba upřesnit, aby bylo možné určit dopad migrace.
RPO a RTO pro místní nasazení HBase.
Offline a online migrace
Pro úspěšnou migraci dat je důležité porozumět charakteristikám firmy, která databázi používá, a rozhodnout se, jak to udělat. Vyberte offline migraci, pokud můžete systém úplně vypnout, provést migraci dat a restartovat systém v cíli. Pokud je databáze vždy zaneprázdněná a nemůžete si dovolit dlouhý výpadek, zvažte migraci online.
Poznámka:
Tento dokument popisuje pouze offline migraci.
Při offline migraci dat to závisí na verzi HBase, kterou právě používáte, a dostupných nástrojích. Další podrobnosti najdete v části Migrace dat.
Důležité informace o výkonu
Tento aspekt plánování spočívá v porozumění cílům výkonu pro HBase a jejich následnému překladu do sémantiky služby Azure Cosmos DB. Pokud například chcete v HBase stisknout IOPS X , kolik jednotek žádostí (RU/s) se bude v Azure Cosmos DB vyžadovat. Mezi HBase a Azure Cosmos DB existují rozdíly. Toto cvičení se zaměřuje na vytvoření zobrazení toho, jak se budou cíle výkonu z HBase překládat do azure Cosmos DB. To bude řídit cvičení škálování.
Dotazy k kladení:
- Je nasazení HBase náročné na čtení nebo zápis?
- Jaké je rozdělení mezi čtení a zápisy?
- Jaký je cílový počet vstupně-výstupních operací za sekundu jako percentil?
- Jak/jaké aplikace se používají k načtení dat do HBase?
- Jak/jaké aplikace se používají ke čtení dat z HBase?
Při provádění dotazů, které požadují seřazená data, vrátí HBase výsledek rychle, protože data jsou seřazena podle RowKey. Azure Cosmos DB ale takový koncept nemá. K optimalizaci výkonu můžete podle potřeby použít složené indexy .
Aspekty nasazení
K nasazení služby Azure Cosmos DB for NoSQL můžete použít Azure Portal nebo Azure CLI. Vzhledem k tomu, že cílem migrace je Azure Cosmos DB for NoSQL, jako parametr při nasazování rozhraní API vyberte NoSQL. Kromě toho nastavte geografickou redundanci, zápisy do více oblastí a Zóny dostupnosti podle vašich požadavků na dostupnost.
Důležité informace o síti
Azure Cosmos DB má tři hlavní možnosti sítě. První je konfigurace, která používá veřejnou IP adresu a řídí přístup pomocí brány firewall protokolu IP (výchozí). Druhá je konfigurace, která používá veřejnou IP adresu a umožňuje přístup pouze z konkrétní podsítě konkrétní virtuální sítě (koncového bodu služby). Třetí je konfigurace (privátní koncový bod), která připojí privátní síť pomocí privátní IP adresy.
Další informace o třech možnostech sítě najdete v následujících dokumentech:
Posouzení existujících dat
Zjišťování dat
Shromážděte informace předem z existujícího clusteru HBase a identifikujte data, která chcete migrovat. To vám může pomoct určit, jak migrovat, rozhodnout se, které tabulky se mají migrovat, porozumět struktuře v těchto tabulkách a rozhodnout se, jak vytvořit datový model. Shromážděte například následující podrobnosti:
- Verze HBase
- Cílové tabulky migrace
- Informace o rodině sloupců
- Stav tabulky
Následující příkazy ukazují, jak shromáždit výše uvedené podrobnosti pomocí skriptu prostředí hbase a uložit je do místního systému souborů operačního počítače.
Získání verze HBase
hbase version -n > hbase-version.txt
Výstup:
cat hbase-version.txt
HBase 2.1.8.4.1.2.5
Získání seznamu tabulek
Můžete získat seznam tabulek uložených v HBase. Pokud jste vytvořili jiný obor názvů než výchozí, bude výstupem ve formátu Obor názvů: Tabulka.
echo "list" | hbase shell -n > table-list.txt
HBase 2.1.8.4.1.2.5
Výstup:
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
Identifikace tabulek, které se mají migrovat
Podrobnosti o rodinách sloupců v tabulce získáte zadáním názvu tabulky, který se má migrovat.
echo "describe '({Namespace}:){Table name}'" | hbase shell -n > {Table name} -schema.txt
Výstup:
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
Získání rodin sloupců v tabulce a jejich nastavení
echo "status 'detailed'" | hbase shell -n > hbase-status.txt
Výstup:
{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
[...]
Můžete získat užitečné informace o velikosti, jako je velikost paměti haldy, počet oblastí, počet požadavků jako stav clusteru a velikost dat v komprimovaném nebo nekomprimovaném stavu tabulky.
Pokud používáte Apache Phoenix v clusteru HBase, musíte shromažďovat i data z Phoenixu.
- Cílová tabulka migrace
- Schémata tabulek
- Indexy
- Primární klíč
Připojení k Apache Phoenixu v clusteru
sqlline.py ZOOKEEPER/hbase-unsecure
Získání seznamu tabulek
!tables
Získání podrobností o tabulce
!describe <Table Name>
Získání podrobností o indexu
!indexes <Table Name>
Získání podrobností o primárním klíči
!primarykeys <Table Name>
Migrace dat
Možnosti migrace
Existují různé metody migrace dat do offline režimu, ale tady si představíme, jak používat Azure Data Factory.
Řešení | Zdrojová verze | Důležité informace |
---|---|---|
Azure Data Factory | HBase < 2 | Snadné nastavení. Vhodné pro velké datové sady. Nepodporuje HBase 2 nebo novější. |
Apache Spark | Všechny verze | Podporuje všechny verze HBase. Vhodné pro velké datové sady. Vyžaduje se nastavení Sparku. |
Vlastní nástroj s knihovnou Bulk Executor služby Azure Cosmos DB | Všechny verze | Nejflexibilnější pro vytváření vlastních nástrojů pro migraci dat pomocí knihoven. Vyžaduje větší úsilí k nastavení. |
Následující vývojový diagram používá k dosažení dostupných metod migrace dat určité podmínky.
Migrace pomocí služby Data Factory
Tato možnost je vhodná pro velké datové sady. Používá se knihovna Bulk Executor služby Azure Cosmos DB. Neexistují žádné kontrolní body, takže pokud během migrace narazíte na nějaké problémy, budete muset proces migrace restartovat od začátku. Můžete také použít místní prostředí Integration Runtime služby Data Factory k připojení k místní databázi HBase nebo nasazení služby Data Factory do spravované virtuální sítě a připojení k místní síti přes VPN nebo ExpressRoute.
Aktivita Copy data Factory podporuje HBase jako zdroj dat. Další podrobnosti najdete v článku Kopírování dat z HBase pomocí služby Azure Data Factory .
Jako cíl vašich dat můžete zadat azure Cosmos DB (API for NoSQL). Další podrobnosti najdete v článku o kopírování a transformaci dat ve službě Azure Cosmos DB (API for NoSQL) pomocí služby Azure Data Factory .
Migrace s využitím Apache Sparku – Konektor Apache HBase a konektor Spark služby Azure Cosmos DB
Tady je příklad migrace dat do služby Azure Cosmos DB. Předpokládá se, že HBase 2.1.0 a Spark 2.4.0 běží ve stejném clusteru.
Apache Spark – Úložiště konektoru Apache HBase najdete v Apache Sparku – Konektor Apache HBase
Informace o konektoru Spark služby Azure Cosmos DB najdete v úvodní příručce a stáhněte si příslušnou knihovnu pro vaši verzi Sparku.
Zkopírujte hbase-site.xml do konfiguračního adresáře Sparku.
cp /etc/hbase/conf/hbase-site.xml /etc/spark2/conf/
Spusťte spark -shell s konektorem Spark HBase a konektorem Spark služby Azure Cosmos DB.
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
Po spuštění prostředí Spark spusťte následující kód Scala. Importujte knihovny potřebné k načtení dat z HBase.
// Import libraries import org.apache.spark.sql.{SQLContext, _} import org.apache.spark.sql.execution.datasources.hbase._ import org.apache.spark.{SparkConf, SparkContext} import spark.sqlContext.implicits._
Definujte schéma katalogu Spark pro tabulky HBase. Obor názvů je "výchozí" a název tabulky je "Kontakty". Klíč řádku je určen jako klíč. Sloupce, rodina sloupců a sloupec se mapují na katalog Sparku.
// 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
Dále definujte metodu pro získání dat z tabulky Kontakty HBase jako datový rámec.
def withCatalog(cat: String): DataFrame = { spark.sqlContext .read .options(Map(HBaseTableCatalog.tableCatalog->cat)) .format("org.apache.spark.sql.execution.datasources.hbase") .load() }
Vytvořte datový rámec pomocí definované metody.
val df = withCatalog(catalog)
Potom naimportujte knihovny potřebné k použití konektoru Spark služby Azure Cosmos DB.
import com.microsoft.azure.cosmosdb.spark.schema._ import com.microsoft.azure.cosmosdb.spark._ import com.microsoft.azure.cosmosdb.spark.config.Config
Nastavení zápisu dat do služby 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" ))
Zapisujte data datového rámce do služby Azure Cosmos DB.
import org.apache.spark.sql.SaveMode df.write.mode(SaveMode.Overwrite).cosmosDB(writeConfig)
Zapisuje paralelně při vysoké rychlosti, jeho výkon je vysoký. Na druhou stranu mějte na paměti, že může spotřebovávat RU/s na straně služby Azure Cosmos DB.
Phoenix
Phoenix je podporovaný jako zdroj dat služby Data Factory. Podrobné kroky najdete v následujících dokumentech.
- Kopírování dat z Phoenixu pomocí služby Azure Data Factory
- Kopírování dat z HBase pomocí Azure Data Factory
Migrace kódu
Tato část popisuje rozdíly mezi vytvářením aplikací ve službě Azure Cosmos DB pro seznamy NoSQLs a HBase. Zde uvedené příklady používají rozhraní API Apache HBase 2.x a sadu Java SDK služby Azure Cosmos DB v4.
Vzorové kódy HBase jsou založené na kódech popsaných v oficiální dokumentaci HBase.
Zde uvedený kód je založený na dokumentaci k sadě Azure Cosmos DB for NoSQL: Java SDK v4. K úplnému příkladu kódu se dostanete z dokumentace.
Tady se zobrazují mapování migrace kódu, ale klíče oddílů HBase a Azure Cosmos DB použité v těchto příkladech nejsou vždy dobře navržené. Návrh podle skutečného datového modelu zdroje migrace.
Navázání připojení
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();
Vytvoření databáze, tabulky nebo kolekce
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());
Vytvoření řádku nebo dokumentu
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 poskytuje zabezpečení typů prostřednictvím datového modelu. Používáme datový model s názvem Rodina.
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="";
}
Výše uvedený kód je součástí kódu. Podívejte se na úplný příklad kódu.
Pomocí třídy Family můžete definovat dokument a vložit položku.
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());
Čtení řádku nebo dokumentu
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);
Aktualizace dat
HBase
Pro HBase použijte metodu append a checkAndPut metoda aktualizovat hodnotu. Připojení je proces připojení hodnoty atomicky na konec aktuální hodnoty a checkAndPut atomicky porovná aktuální hodnotu s očekávanou hodnotou a aktualizuje pouze v případě, že odpovídají.
// 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
Ve službě Azure Cosmos DB se aktualizace považují za operace upsertu. To znamená, že pokud dokument neexistuje, vloží se.
// 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());
Odstranění řádku nebo dokumentu
HBase
V Hbase neexistuje žádný přímý způsob odstranění výběru řádku podle hodnoty. Možná jste implementovali proces odstranění v kombinaci s ValueFilter atd. V tomto příkladu je řádek, který má být odstraněn, určen 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
Metoda odstranění podle ID dokumentu je zobrazena níže.
container.deleteItem(documentId, new PartitionKey(documentLastName), new CosmosItemRequestOptions());
Dotazování řádků nebo dokumentů
HBase HBase umožňuje načíst více řádků pomocí skenování. Pomocí filtru můžete zadat podrobné podmínky kontroly. Viz Filtry požadavků klienta pro předdefinované typy filtrů HBase.
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
Operace filtru
String sql = "SELECT * FROM c WHERE c.lastName = 'Witherspoon'";
CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(), Family.class);
Odstranění tabulky nebo kolekce
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());
Ostatní úvahy
Clustery HBase se dají používat s úlohami HBase a MapReduce, Hivem, Sparkem a dalšími funkcemi. Pokud máte s aktuální HBase další úlohy, je potřeba je také migrovat. Podrobnosti najdete v jednotlivých průvodcích migrací.
- MapReduce
- HBase
- Spark
Programování na straně serveru
HBase nabízí několik programovacích funkcí na straně serveru. Pokud tyto funkce používáte, budete také muset migrovat jejich zpracování.
HBase
-
Různé filtry jsou v HBase dostupné jako výchozí, ale můžete také implementovat vlastní filtry. Vlastní filtry se můžou implementovat, pokud filtry dostupné jako výchozí v HBase nesplňují vaše požadavky.
-
Coprocessor je architektura, která umožňuje spustit vlastní kód na serveru oblasti. Pomocí coprocesoru je možné provést zpracování, které bylo spuštěno na straně klienta na straně serveru, a v závislosti na zpracování může být efektivnější. Existují dva typy koprocesorů, pozorovatele a koncového bodu.
Pozorovatel
- Pozorovatel zahodí konkrétní operace a události. Toto je funkce pro přidání libovolného zpracování. Jedná se o funkci podobnou triggerům RDBMS.
Koncový bod
- Koncový bod je funkce pro rozšíření protokolu RPC HBase. Je to funkce podobná uložené procedurě RDBMS.
Azure Cosmos DB
-
- Uložené procedury Azure Cosmos DB jsou napsané v JavaScriptu a můžou provádět operace, jako je vytváření, aktualizace, čtení, dotazování a odstraňování položek v kontejnerech Azure Cosmos DB.
-
- Aktivační události je možné zadat pro operace v databázi. K dispozici jsou dvě metody: před spuštěním triggeru před změnou položky databáze a následným spuštěním po změně položky databáze.
Definovaná funkce definovaná uživatelem
- Azure Cosmos DB umožňuje definovat uživatelem definované funkce (UDF). Uživatelem definované funkce lze také psát v JavaScriptu.
Uložené procedury a triggery spotřebovávají ru na základě složitosti provedených operací. Při vývoji zpracování na straně serveru zkontrolujte požadované využití, abyste lépe porozuměli množství RU spotřebovaných jednotlivými operacemi. Podrobnosti najdete v tématu Jednotky žádostí ve službě Azure Cosmos DB a Optimalizace nákladů na žádosti ve službě Azure Cosmos DB .
Mapování programování na straně serveru
HBase | Azure Cosmos DB | Popis |
---|---|---|
Vlastní filtry | Klauzule WHERE | Pokud zpracování implementované vlastním filtrem nelze dosáhnout klauzulí WHERE ve službě Azure Cosmos DB, použijte funkci definovanou uživatelem v kombinaci. |
Koprocesor (pozorovatel) | Trigger | Pozorovatel je trigger, který se spustí před a po konkrétní události. Stejně jako Pozorovatel podporuje předběžné a následné volání, trigger služby Azure Cosmos DB podporuje také před a po spuštění triggerů. |
Spoluprocesor (koncový bod) | Uložená procedura | Koncový bod je mechanismus zpracování dat na straně serveru, který se spouští pro každou oblast. Podobá se uložené proceduře RDBMS. Uložené procedury Azure Cosmos DB se zapisují pomocí JavaScriptu. Poskytuje přístup ke všem operacím, které můžete ve službě Azure Cosmos DB provádět prostřednictvím uložených procedur. |
Poznámka:
V Azure Cosmos DB můžou být vyžadována různá mapování a implementace v závislosti na zpracování implementovaném v HBase.
Zabezpečení
Zabezpečení dat je sdílenou odpovědností zákazníka a poskytovatele databáze. V případě místních řešení musí zákazníci poskytovat všechno od ochrany koncových bodů až po fyzické hardwarové zabezpečení, což není snadný úkol. Pokud zvolíte poskytovatele cloudové databáze PaaS, jako je Azure Cosmos DB, sníží se zapojení zákazníků. Azure Cosmos DB běží na platformě Azure, takže ji můžete vylepšit jiným způsobem než HBase. Azure Cosmos DB nevyžaduje, aby se pro zabezpečení nainstalovaly žádné další komponenty. Doporučujeme zvážit migraci implementace zabezpečení databázového systému pomocí následujícího kontrolního seznamu:
Řízení zabezpečení | HBase | Azure Cosmos DB |
---|---|---|
Nastavení zabezpečení sítě a brány firewall | Řízení provozu pomocí funkcí zabezpečení, jako jsou síťová zařízení. | Podporuje řízení přístupu na základě IP adres na základě zásad na příchozí bráně firewall. |
Ověřování uživatelů a jemně odstupňované uživatelské ovládací prvky | Jemně odstupňované řízení přístupu zkombinováním protokolu LDAP s komponentami zabezpečení, jako je Apache Ranger. | Primární klíč účtu můžete použít k vytvoření prostředků uživatele a oprávnění pro každou databázi. K ověření žádostí o data můžete použít také své ID Microsoft Entra. To umožňuje autorizovat žádosti o data pomocí jemně odstupňovaného modelu RBAC. |
Schopnost globálně replikovat data pro regionální selhání | Vytvořte repliku databáze ve vzdáleném datovém centru pomocí replikace HBase. | Azure Cosmos DB provádí globální distribuci bez konfigurace a umožňuje replikovat data do datových center po celém světě v Azure výběrem tlačítka. Z hlediska zabezpečení zajišťuje globální replikace ochranu vašich dat před místními selháními. |
Schopnost převzít služby při selhání z jednoho datového centra do jiného | Musíte implementovat převzetí služeb při selhání sami. | Pokud replikujete data do několika datových center a datové centrum oblasti přejde do offline režimu, Azure Cosmos DB tuto operaci automaticky převrací. |
Místní replikace dat v rámci datového centra | Mechanismus HDFS umožňuje mít více replik napříč uzly v rámci jednoho systému souborů. | Azure Cosmos DB automaticky replikuje data, aby se zachovala vysoká dostupnost, a to i v rámci jednoho datového centra. Úroveň konzistence můžete zvolit sami. |
Automatické zálohování dat | Neexistuje žádná funkce automatického zálohování. Musíte implementovat zálohování dat sami. | Azure Cosmos DB se pravidelně zálohuje a ukládá do geograficky redundantního úložiště. |
Ochrana a izolace citlivých dat | Pokud například používáte Apache Ranger, můžete použít zásadu Ranger k použití zásad v tabulce. | Osobní a další citlivá data můžete oddělit do konkrétních kontejnerů a čtení a zápisu nebo omezit přístup jen pro čtení konkrétním uživatelům. |
Monitorování útoků | Musí se implementovat pomocí produktů třetích stran. | Pomocí protokolování auditu a protokolů aktivit můžete monitorovat svůj účet za normální a neobvyklou aktivitu. |
Reakce na útoky | Musí se implementovat pomocí produktů třetích stran. | Když kontaktujete podpora Azure a nahlásíte potenciální útok, zahájí se proces reakce na incidenty s pěti kroky. |
Schopnost geograficky ohraničení dat dodržovat omezení zásad správného řízení dat | Musíte zkontrolovat omezení jednotlivých zemí nebo oblastí a implementovat je sami. | Zaručuje zásady správného řízení dat pro suverénní oblasti (Německo, Čína, US Gov atd.). |
Fyzická ochrana serverů v chráněných datových centrech | Závisí na datovém centru, kde se systém nachází. | Seznam nejnovějších certifikací najdete na globálním webu dodržování předpisů Azure. |
Certifikace | Závisí na distribuci Hadoop. | Prohlédnou si dokumentaci k dodržování předpisů Azure. |
Sledování
HBase obvykle monitoruje cluster pomocí webového uživatelského rozhraní metrik clusteru nebo pomocí Ambari, Cloudera Manageru nebo jiných monitorovacích nástrojů. Azure Cosmos DB umožňuje používat monitorovací mechanismus integrovaný do platformy Azure. Další informace o monitorování služby Azure Cosmos DB najdete v tématu Monitorování služby Azure Cosmos DB.
Pokud vaše prostředí implementuje monitorování systému HBase za účelem odesílání výstrah, jako je e-mail, možná ho budete moct nahradit upozorněními služby Azure Monitor. Můžete přijímat upozornění na základě metrik nebo událostí protokolu aktivit pro váš účet služby Azure Cosmos DB.
Další informace o upozorněních ve službě Azure Monitor najdete v tématu Vytváření upozornění pro službu Azure Cosmos DB pomocí služby Azure Monitor.
Podívejte se také na metriky a typy protokolů služby Azure Cosmos DB, které může Azure Monitor shromažďovat.
Zálohování a zotavení po havárii
Backup
Existuje několik způsobů, jak získat zálohu HBase. Například Snímek, Export, CopyTable, Offline zálohování dat HDFS a další vlastní zálohy.
Azure Cosmos DB automaticky zálohuje data v pravidelných intervalech, což nemá vliv na výkon ani dostupnost databázových operací. Zálohy se ukládají v úložišti Azure a v případě potřeby je možné je použít k obnovení dat. Existují dva typy záloh služby Azure Cosmos DB:
Zotavení po havárii
HBase je distribuovaný systém odolný proti chybám, ale v případě selhání na úrovni datového centra je nutné implementovat zotavení po havárii pomocí snímku, replikace atd. pokud je vyžadováno převzetí služeb při selhání v umístění zálohování. Replikaci HBase je možné nastavit pomocí tří modelů replikace: Leader-Follower, Leader-Leader a Cyklické. Pokud zdroj HBase implementuje zotavení po havárii, musíte pochopit, jak nakonfigurovat zotavení po havárii ve službě Azure Cosmos DB a splnit požadavky na systém.
Azure Cosmos DB je globálně distribuovaná databáze s integrovanými možnostmi zotavení po havárii. Data databáze můžete replikovat do libovolné oblasti Azure. Azure Cosmos DB udržuje vaši databázi vysoce dostupnou v nepravděpodobném případě selhání v některých oblastech.
Účet služby Azure Cosmos DB, který používá pouze jednu oblast, může v případě selhání oblasti ztratit dostupnost. Doporučujeme nakonfigurovat aspoň dvě oblasti, abyste zajistili vysokou dostupnost vždy. Vysokou dostupnost pro zápisy i čtení můžete také zajistit tak, že nakonfigurujete účet služby Azure Cosmos DB tak, aby přesahovat nejméně dvě oblasti s více oblastmi zápisu, aby se zajistila vysoká dostupnost pro zápisy a čtení. U účtů s více oblastmi, které se skládají z několika oblastí zápisu, se zjistí převzetí služeb při selhání mezi oblastmi a zpracuje ho klient služby Azure Cosmos DB. Jedná se o momentální a nevyžadují žádné změny z aplikace. Tímto způsobem můžete dosáhnout konfigurace dostupnosti, která zahrnuje zotavení po havárii pro službu Azure Cosmos DB. Jak už bylo zmíněno dříve, replikaci HBase je možné nastavit se třemi modely, ale službu Azure Cosmos DB je možné nastavit s dostupností založenou na sla konfigurací oblastí s jedním zápisem a více zápisy.
Další informace o vysoké dostupnosti najdete v tématu o tom, jak Azure Cosmos DB poskytuje vysokou dostupnost.
Nejčastější dotazy
Proč migrovat na rozhraní API for NoSQL místo jiných rozhraní API ve službě Azure Cosmos DB?
Rozhraní API pro NoSQL poskytuje nejlepší ucelené prostředí z hlediska rozhraní, klientské knihovny sady SDK služby. Nové funkce, které se nasadí do služby Azure Cosmos DB, budou nejprve k dispozici ve vašem účtu rozhraní API pro NoSQL. Kromě toho rozhraní API pro NoSQL podporuje analýzy a poskytuje oddělení výkonu mezi produkčními a analytickými úlohami. Pokud chcete k vytváření aplikací používat modernizované technologie, doporučujeme použít rozhraní API pro NoSQL.
Můžu klíč oddílu Azure Cosmos DB přiřadit HBase RowKey?
Nemusí být optimalizovaná tak, jak je. V HBase jsou data seřazena podle zadaného RowKey, uloženého v oblasti a rozdělené do pevných velikostí. Chová se jinak než dělení ve službě Azure Cosmos DB. Proto je potřeba přepracovat klíče, aby lépe distribuovaly data podle charakteristik úlohy. Další podrobnosti najdete v části Distribuce .
Data jsou seřazená podle RowKey v HBase, ale dělení podle klíče ve službě Azure Cosmos DB. Jak může Azure Cosmos DB dosáhnout řazení a kolokace?
Ve službě Azure Cosmos DB můžete přidat složený index pro seřazení dat vzestupně nebo sestupně, abyste zlepšili výkon dotazů na rovnost a rozsah. Viz část Distribuce a složený index v dokumentaci k produktu.
Analytické zpracování se provádí na datech HBase pomocí Hive nebo Sparku. Jak je můžu modernizovat ve službě Azure Cosmos DB?
Analytické úložiště Azure Cosmos DB můžete použít k automatické synchronizaci provozních dat do jiného úložiště sloupců. Formát úložiště sloupců je vhodný pro rozsáhlé analytické dotazy spouštěné optimalizovaným způsobem, což zvyšuje latenci těchto dotazů. Azure Synapse Link umožňuje vytvořit řešení HTAP bez ETL propojením přímo z Azure Synapse Analytics do analytického úložiště Azure Cosmos DB. To vám umožní provádět rozsáhlé analýzy provozních dat téměř v reálném čase. Synapse Analytics podporuje Apache Spark a bezserverové fondy SQL v úložišti analýz Azure Cosmos DB. Tuto funkci můžete využít k migraci analytického zpracování. Další informace najdete v tématu Analytické úložiště .
Jak můžou uživatelé používat dotaz časového razítka v HBase do služby Azure Cosmos DB?
Azure Cosmos DB nemá přesně stejnou funkci správy verzí časového razítka jako HBase. Azure Cosmos DB ale poskytuje přístup k kanálu změn a můžete ho využít pro správu verzí.
Uložte každou verzi nebo změnu jako samostatnou položku.
Přečtěte si informační kanál změn, aby se sloučily nebo konsolidovaly změny a aktivovaly příslušné akce, a to filtrováním pomocí pole _ts. Kromě toho můžete pro starou verzi dat vypršet platnost starých verzí pomocí hodnoty TTL.
Další kroky
Pokud chcete provést testování výkonu, přečtěte si článek o testování výkonu a škálování ve službě Azure Cosmos DB .
Pokud chcete kód optimalizovat, podívejte se na tipy k výkonu pro azure Cosmos DB .
Prozkoumejte sadu Java Async V3 SDK, referenční informace o úložišti GitHub sdk.