Le tabelle gestite sono tabelle di proprietà di Hive dove l’intero ciclo di vita dei dati delle tabelle è gestito e controllato da Hive. Le tabelle esterne sono tabelle in cui Hive ha un accoppiamento libero con i dati. Replication Manager replica con successo le tabelle esterne su un cluster di destinazione. Le tabelle gestite vengono convertite in tabelle esterne dopo la replica.
Hive supporta la replica di tabelle esterne con dati al cluster di destinazione e mantiene tutte le proprietà delle tabelle esterne. Il permesso e la proprietà dei file di dati vengono conservati in modo che i processi esterni pertinenti possano continuare a scriverci anche dopo il failover.
Le scritture sulle tabelle esterne vengono eseguite utilizzando i comandi SQL di Hive e i file di dati possono essere accessibili e gestiti anche da processi esterni a Hive. Se una tabella o una partizione esterna viene eliminata, solo i metadati associati alla tabella o alla partizione vengono cancellati, ma i file di dati sottostanti rimangono intatti. Un tipico esempio per una tabella esterna è l’esecuzione di query analitiche sui dati di proprietà di HBase o Druid utilizzando Hive, dove i file di dati sono scritti da HBase o Druid e Hive li legge per le analisi.
Quando si crea una pianificazione per una politica di replica di Hive, impostare la frequenza in modo che le modifiche siano replicate abbastanza spesso per evitare copie troppo grandi.
Potresti imbatterti nei seguenti casi d’uso durante la replica di Hive:
Caso d’uso del Replication Manager In uno scenario normale, se avevi tabelle esterne che erano replicate come tabelle gestite, dopo il processo di aggiornamento, devi eliminare quelle tabelle dalla destinazione e impostare la directory di base. Nell’istanza successiva vengono replicate come tabelle esterne. Conflitti nella posizione dei dati delle tabelle esterne per la replica di più cluster di origine nello stesso cluster di destinazione Per gestire i conflitti nella posizione dei dati delle tabelle esterne per la replica di più cluster di origine nello stesso cluster di destinazione, Replication Manager assegna una directory di base unica per ogni cluster di origine in cui vengono copiati i dati delle tabelle esterne dal cluster di origine corrispondente. Per esempio, se la posizione della tabella esterna in un cluster sorgente è /ext/hbase_data, allora la posizione nel cluster di destinazione dopo la replica è <base_dir>/ext/hbase_data. Puoi usare il comando DESCRIBE TABLE per tracciare la nuova posizione delle tabelle esterne. Conflitti di replica tra HDFS e la posizione della tabella esterna di Hive Quando si esegue la politica di replica Hive su una tabella esterna, i dati vengono memorizzati nella directory di destinazione in una posizione specifica. Successivamente, quando si esegue la policy di replica HDFS che cerca di copiare i dati nella stessa posizione della tabella esterna, Replication Manager assicura che i dati Hive non vengano sovrascritti da HDFS. Per esempio, quando si esegue una policy di replica Hive su una tabella esterna, la policy crea una directory di destinazione /tmp/db1/ext1. Quando si esegue una policy di replica HDFS, la policy non dovrebbe sovrascrivere i dati replicando sulla directory /tmp/db1/ext1. Conflitti durante il processo di replica delle tabelle esterne I conflitti appaiono quando due politiche di replica Hive su DB1 e DB2 (sia dallo stesso cluster di origine che da cluster di origine diversi) hanno tabelle esterne che puntano alla stessa posizione dei dati (per esempio, /abc) e sono replicate allo stesso cluster di destinazione. Per evitare tali conflitti, è necessario impostare percorsi diversi per la configurazione della directory di base delle tabelle esterne per entrambe le politiche. Per esempio, impostare /db1 per DB1 e /db2 per DB2. Questo assicura che la posizione dei dati della tabella esterna di destinazione sia diversa per entrambi i database. Per esempio, /db1/abcd e /db2/abcd.