As tabelas geridas são tabelas próprias da colmeia, onde todo o ciclo de vida dos dados das tabelas é gerido e controlado pela colmeia. Os quadros externos são quadros em que a colmeia tem um acoplamento solto com os dados. O Replication Manager replica com sucesso tabelas externas a um cluster alvo. As tabelas geridas são convertidas em tabelas externas após a replicação.
Hive suporta a replicação de tabelas externas com dados para o cluster de destino e retém todas as propriedades das tabelas externas. A permissão e propriedade dos ficheiros de dados são preservadas para que os processos externos relevantes possam continuar a escrever nele mesmo após o failover.
As escritas nas tabelas externas são efectuadas utilizando os comandos SQL da Colmeia e os ficheiros de dados também podem ser acedidos e geridos por processos fora da Colmeia. Se uma tabela ou partição externa for abandonada, apenas os metadados associados à tabela ou partição são apagados, mas os ficheiros de dados subjacentes permanecem intactos. Um exemplo típico de uma tabela externa é a execução de consultas analíticas sobre dados de propriedade do HBase ou do Druid usando o Hive, onde os arquivos de dados são escritos pelo HBase ou pelo Druid e o Hive os lê para fins analíticos.
Quando se cria um calendário para uma política de replicação da Colmeia, defina a frequência para que as alterações sejam replicadas com a frequência suficiente para evitar cópias demasiado grandes.
Pode deparar-se com os seguintes casos de utilização durante a replicação da Colmeia:
Caso de utilização do Replication Manager Num cenário normal, se tiver tabelas externas que foram replicadas como tabelas geridas, após o processo de actualização, deve largar essas tabelas do destino e definir o directório base. Na próxima instância, elas serão replicadas como tabelas externas. Conflitos no local de dados das tabelas externas para replicação de vários clusters de origem para o mesmo cluster de destino Para tratar os conflitos no local de dados das tabelas externas para replicação de vários clusters de origem para o mesmo cluster de destino, o Gerenciador de replicação atribui um diretório base único para cada cluster de origem sob o qual os dados das tabelas externas do cluster de origem correspondente são copiados. Por exemplo, se o local da tabela externa em um cluster de origem for /ext/hbase_data, o local no cluster de destino após a replicação será <base_dir>/ext/hbase_data. É possível usar o comando DESCRIBE TABLE para rastrear a nova localização de tabelas externas. Conflitos de replicação entre HDFS e a localização da tabela externa da colmeia Quando se executa a política de replicação da colmeia numa tabela externa, os dados são armazenados no directório de destino, num local específico. Em seguida, quando se executa a política de replicação HDFS que tenta copiar os dados no mesmo local de tabela externa, o Replication Manager assegura-se de que os dados da Colmeia não são substituídos pelo HDFS. Por exemplo, quando se executa uma política de replicação Hive em uma tabela externa, a política cria um diretório de destino /tmp/db1/ext1. Quando se executa uma política de replicação HDFS, a política não deve substituir os dados, replicando no diretório /tmp/db1/ext1. Conflitos durante o processo de replicação de tabelas externas Os conflitos aparecem quando duas políticas de replicação Hive no DB1 e DB2 (do mesmo cluster de origem ou de clusters de origem diferentes) têm tabelas externas que apontam para o mesmo local de dados (por exemplo, /abc) e são replicadas para o mesmo cluster de destino. Para evitar tais conflitos, é necessário definir caminhos diferentes para a configuração do diretório base da tabela externa para ambas as políticas. Por exemplo, definir /db1 para DB1 e /db2 para DB2. Isso garante que a localização dos dados da tabela externa de destino seja diferente para ambos os bancos de dados. Por exemplo, /db1/abcd e /db2/abcd.