Como usar a replicação do Apache Hive em clusters do Azure HDInsight
No contexto de bancos de dados e armazéns, a replicação é o processo de duplicação de entidades de um depósito para outro. A duplicação pode ser aplicada a um banco de dados inteiro ou a um nível menor, como uma tabela ou partição. O objetivo é ter uma réplica que muda sempre que a entidade base muda. A replicação no Apache Hive concentra-se na recuperação de desastres e oferece replicação unidirecional de cópia primária. Nos clusters HDInsight, a Replicação do Hive pode ser usada para replicar unidirecionalmente o metastore do Hive e o data lake subjacente associado no Azure Data Lake Storage Gen2.
A replicação do Hive evoluiu ao longo dos anos com versões mais recentes que oferecem melhor funcionalidade e são mais rápidas e consomem menos recursos. Neste artigo, discutimos a replicação do Hive (Replv2), que é suportada nos tipos de cluster HDInsight 3.6 e HDInsight 4.0.
Vantagens do replv2
O Hive ReplicationV2 (também chamado de Replv2) tem as seguintes vantagens em relação à primeira versão da replicação do Hive que usava o Hive IMPORT-EXPORT:
- Replicação incremental baseada em eventos
- Replicação point-in-time
- Requisitos de largura de banda reduzidos
- Redução do número de exemplares intermédios
- O estado de replicação é mantido
- Replicação restrita
- Suporte para um modelo Hub e Spoke
- Suporte para tabelas ACID (no HDInsight 4.0)
Fases de replicação
A replicação baseada em eventos do Hive é configurada entre os clusters primário e secundário. Essa replicação consiste em duas fases distintas: inicialização e execuções incrementais.
Bootstrapping
O bootstrapping destina-se a ser executado uma vez para replicar o estado base dos bancos de dados do primário para o secundário. Você pode configurar a inicialização, se necessário, para incluir um subconjunto das tabelas no banco de dados de destino onde a replicação precisa ser habilitada.
Execuções incrementais
Após a inicialização, as execuções incrementais são automatizadas no cluster primário e os eventos gerados durante essas execuções incrementais são reproduzidos no cluster secundário. Quando o cluster secundário alcança o cluster primário, o secundário torna-se consistente com os eventos do primário.
Comandos de replicação
O Hive oferece um conjunto de comandos REPL – DUMP, LOAD, e STATUS – para orquestrar o fluxo de eventos. O DUMP comando gera um log local de todos os eventos DDL/DML no cluster primário. O LOAD comando é uma abordagem para copiar com preguiça metadados e dados registrados na saída de despejo de replicação extraída e é executado no cluster de destino. O STATUS comando é executado a partir do cluster de destino para fornecer a ID de evento mais recente de que a carga de replicação mais recente foi replicada com êxito.
Definir origem de replicação
Antes de começar com a replicação, verifique se o banco de dados a ser replicado está definido como a fonte de replicação. Você pode usar o DESC DATABASE EXTENDED <db_name> comando para determinar se o parâmetro repl.source.for está definido com o nome da política.
Se a política estiver agendada e o repl.source.for parâmetro não estiver definido, você precisará primeiro definir esse parâmetro usando ALTER DATABASE <db_name> SET DBPROPERTIES ('repl.source.for'='<policy_name>').
ALTER DATABASE tpcds_orc SET DBPROPERTIES ('repl.source.for'='replpolicy1')
Despejar metadados no data lake
O REPL DUMP [database name]. => location / event_id comando é usado na fase de inicialização para despejar metadados relevantes no Azure Data Lake Storage Gen2. O event_id especifica o evento mínimo para o qual os metadados relevantes foram colocados no Azure Data Lake Storage Gen2.
repl dump tpcds_orc;
Saída de exemplo:
| dump_dir | last_repl_id |
|---|---|
| /tmp/colmeia/repl/38896729-67d5-41b2-90dc-46eeed4c5dd0 | 2925 |
Carregar dados no cluster de destino
O REPL LOAD [database name] FROM [ location ] { WITH ( ‘key1’=‘value1’{, ‘key2’=‘value2’} ) } comando é usado para carregar dados no cluster de destino para as fases de bootstrap e incremental da replicação. O [database name] pode ser o mesmo que a origem ou um nome diferente no cluster de destino. O [location] representa o local da saída do comando anterior REPL DUMP . Isso significa que o cluster de destino deve ser capaz de falar com o cluster de origem. A WITH cláusula foi adicionada principalmente para impedir uma reinicialização do cluster de destino, permitindo a replicação.
repl load tpcds_orc from '/tmp/hive/repl/38896729-67d5-41b2-90dc-46eeed4c5dd0';
Saída do último ID de evento replicado
O REPL STATUS [database name] comando é executado em clusters de destino e produz o último replicado event_id. O comando também permite que os usuários saibam para qual estado seu cluster de destino foi replicado. Você pode usar a saída deste comando para construir o próximo REPL DUMP comando para replicação incremental.
repl status tpcds_orc;
Saída de exemplo:
| last_repl_id |
|---|
| 2925 |
Despejar dados e metadados relevantes para o data lake
O REPL DUMP [database name] FROM [event-id] { TO [event-id] } { LIMIT [number of events] } comando é usado para despejar metadados e dados relevantes no Armazenamento do Azure Data Lake. Este comando é usado na fase incremental e é executado no armazém de origem. O FROM [event-id] é necessário para a fase incremental, e o valor de pode ser derivado executando o REPL STATUS [database name] comando no armazém de event-id destino.
repl dump tpcds_orc from 2925;
Saída de exemplo:
| dump_dir | last_repl_id |
|---|---|
| /tmp/colmeia/repl/38896729-67d5-41b2-90dc-466466agadd0 | 2960 |
Processo de replicação do Hive
As etapas a seguir são os eventos sequenciais que ocorrem durante o processo de replicação do Hive.
Certifique-se de que as tabelas a serem replicadas sejam definidas como a fonte de replicação para uma determinada política.
O
REPL_DUMPcomando é emitido para o cluster primário com restrições associadas, como nome do banco de dados, intervalo de ID de evento e URL de armazenamento do Azure Data Lake Storage Gen2.O sistema serializa um despejo de todos os eventos rastreados do metastore para o mais recente. Esse despejo é armazenado na conta de armazenamento do Azure Data Lake Storage Gen2 no cluster primário na URL especificada pelo
REPL_DUMP.O cluster primário persiste os metadados de replicação para o armazenamento do Azure Data Lake Storage Gen2 do cluster primário. O caminho é configurável na interface do usuário do Hive Config no Ambari. O processo fornece o caminho onde os metadados são armazenados e a ID do último evento DML/DDL rastreado.
O
REPL_LOADcomando é emitido a partir do cluster secundário. O comando aponta para o caminho configurado na Etapa 3.O cluster secundário lê o arquivo de metadados com eventos rastreados que foi criado na Etapa 3. Verifique se o cluster secundário tem conectividade de rede com o armazenamento do Azure Data Lake Storage Gen2 do cluster primário de onde os eventos
REPL_DUMPrastreados estão armazenados.O cluster secundário gera cópia distribuída (
DistCP) computar.O cluster secundário copia dados do armazenamento do cluster primário.
O metastore no cluster secundário é atualizado.
A última ID de evento rastreada é armazenada no metastore primário.
A replicação incremental segue o mesmo processo e requer a última ID de evento replicada como entrada. Isso leva a uma cópia incremental desde o último evento de replicação. As replicações incrementais são normalmente automatizadas com uma frequência pré-determinada para atingir os RPO (Recovery Point Objetives, objetivos de ponto de recuperação) necessários.
Padrões de replicação
A replicação é normalmente configurada de forma unidirecional entre o primário e o secundário, onde o primário atende às solicitações de leitura e gravação. O cluster secundário atende somente a solicitações de leitura. As gravações são permitidas no secundário se houver um desastre, mas a replicação reversa precisa ser configurada de volta para o principal.
Há muitos padrões adequados para a replicação do Hive, incluindo Primário – Secundário, Hub e Spoke e Relé.
No HDInsight Ative Primary – Standby Secondary é um padrão comum de continuidade de negócios e recuperação de desastres (BCDR) e o HiveReplicationV2 pode usar esse padrão com clusters Hadoop HDInsight separados regionalmente com emparelhamento VNet. Uma máquina virtual comum emparelhada para ambos os clusters pode ser usada para hospedar os scripts de automação de replicação. Para obter mais informações sobre possíveis padrões BCDR do HDInsight, consulte a documentação de continuidade de negócios do HDInsight.
Replicação do Hive com o pacote de segurança empresarial
Nos casos em que a replicação do Hive é planejada em clusters Hadoop do HDInsight com o Enterprise Security Package, é necessário considerar os mecanismos de replicação para o metastore Ranger e os Serviços de Domínio Microsoft Entra.
Use o recurso de conjuntos de réplicas dos Serviços de Domínio Microsoft Entra para criar mais de um conjunto de réplicas dos Serviços de Domínio Microsoft Entra por locatário do Microsoft Entra em várias regiões. Cada conjunto de réplicas individuais precisa ser emparelhado com VNets HDInsight em suas respetivas regiões. Nessa configuração, as alterações nos Serviços de Domínio do Microsoft Entra, incluindo configuração, identidade e credenciais do usuário, grupos, objetos de diretiva de grupo, objetos de computador e outras alterações, são aplicadas a todos os conjuntos de réplicas no domínio gerenciado usando a replicação dos Serviços de Domínio do Microsoft Entra.
As políticas da Ranger podem ser periodicamente copiadas e replicadas do primário para o secundário usando a funcionalidade Ranger Import-Export. Você pode optar por replicar todas ou um subconjunto de políticas da Ranger dependendo do nível de autorizações que você está procurando implementar no cluster secundário.
Código de exemplo
A sequência de código a seguir fornece um exemplo de como a inicialização e a replicação incremental podem ser implementadas em uma tabela de exemplo chamada tpcds_orc.
Defina a tabela como a origem de uma política de replicação.
ALTER DATABASE tpcds_orc SET DBPROPERTIES ('repl.source. for'='replpolicy1');Despejo de bootstrap no cluster primário.
repl dump tpcds_orc with ('hive.repl.rootdir'='/tmpag/hiveag/replag');Saída de exemplo:
dump_dir last_repl_id /tmpag/hiveag/replag/675d1bea-2361-4cad-bcbf-8680d305a27a 2925 Carga de bootstrap no cluster secundário.
repl load tpcds_orc from '/tmpag/hiveag/replag 675d1bea-2361-4cad-bcbf-8680d305a27a';Verifique o
REPLstatus no cluster secundário.repl status tpcds_orc;last_repl_id 2925 Despejo incremental no cluster primário.
repl dump tpcds_orc from 2925 with ('hive.repl.rootdir'='/tmpag/hiveag/ replag');Saída de exemplo:
dump_dir last_repl_id /tmpag/hiveag/replag/31177ff7-a40f-4f67-a613-3b64ebe3bb31 2960 Carga incremental no cluster secundário.
repl load tpcds_orc from '/tmpag/hiveag/replag/31177ff7-a40f-4f67-a613-3b64ebe3bb31';Verifique
REPLo status no cluster secundário.repl status tpcds_orc;last_repl_id 2960
Próximos passos
Para saber mais sobre os itens discutidos neste artigo, consulte: