Sincronizar ApsaraDB RDS for MySQL para um cluster ApsaraDB for ClickHouse - ApsaraDB for ClickHouse: Central de Documentação do Alibaba Cloud

Visão geral

Empresas frequentemente gerenciam dados operacionais distribuídos em diversos sistemas.

O processo de ETL (Extract, Transform, Load) consolida dados de sistemas de negócios upstream em um data warehouse para análise.

Os fluxos de trabalho tradicionais de ETL apresentam os seguintes desafios:

Altos custos de recursos: Fontes de dados diferentes geralmente exigem ferramentas de ETL distintas, e a construção desses pipelines gera custos adicionais.
Elevada complexidade do sistema: Manter ferramentas de ETL aumenta a complexidade operacional e desvia o foco do desenvolvimento de aplicações.
Latência de dados: Atualizações em lote periódicas, comuns em ETL, podem atrasar análises em cenários de quase tempo real.

Para resolver esses problemas, a Alibaba Cloud fornece um recurso zero-ETL que constrói automaticamente pipelines de dados entre sistemas de processamento transacional online (OLTP) e data warehouses de processamento analítico online (OLAP). Ele extrai, transforma e carrega dados automaticamente, oferecendo uma solução completa que integra processamento transacional e análise de dados para que você possa focar na análise.

Benefícios

Facilidade de uso: Selecione os dados de source e a instância de destino, e o sistema cria automaticamente um pipeline de dados em tempo real. Não há necessidade de construir ou manter pipelines complexos de ETL, permitindo que você foque no desenvolvimento de aplicações.
Custo zero: O pipeline zero-ETL é gratuito. Analise dados upstream no data warehouse sem custos adicionais.
Agregação de múltiplas fontes: Sincronize dados de várias instâncias com uma única instância do ApsaraDB for ClickHouse em tempo real para criar uma visão analítica abrangente.

Nota
Se você sincronizar dados de várias instâncias com uma única instância do ApsaraDB for ClickHouse, os objetos de sincronização em tarefas diferentes não podem se sobrepor.

Pipeline compatível

Do ApsaraDB RDS for MySQL para o ApsaraDB for ClickHouse

Faturamento

O pipeline de sincronização zero-ETL é gratuito.

Pré-requisitos

O cluster ApsaraDB for ClickHouse e a instância RDS for MySQL devem estar localizados na mesma região.
Crie contas de banco de dados para a instância de source ApsaraDB RDS for MySQL e para o banco de dados de destino. Para mais informações, consulte Create an account for an ApsaraDB RDS for MySQL instance e Create an account for an ApsaraDB for ClickHouse cluster.

Limitações

Tipo	Descrição
Limitações do ApsaraDB RDS for MySQL	Não é possível sincronizar tabelas sem chave primária. A operação RENAME TABLE não é compatível. Se você sincronizar dados no nível de tabela e precisar editar objetos, como mapear nomes de tabelas ou colunas, uma única tarefa de sincronização de dados aceita no máximo 1.000 tabelas. Se esse limite for excedido, um erro será reportado após o envio da tarefa. Nesse caso, divida as tabelas em várias tarefas ou configure uma tarefa para sincronizar todo o banco de dados. Logs binários: O ApsaraDB RDS for MySQL habilita logs binários por padrão. Certifique-se de que o parâmetro binlog_row_image esteja definido como full. Caso contrário, a pré-verificação falhará e não será possível iniciar a tarefa de sincronização. Para instruções, consulte Configure instance parameters. Importante Se sua instância de source for um banco de dados MySQL autogerenciado, habilite logs binários e defina binlog_format como row e binlog_row_image como full. Se seu banco de dados MySQL autogerenciado for um cluster com dois primários (onde ambos os nós atuam como primário e secundário), habilite o parâmetro log_slave_updates para que o DTS possa capturar todos os eventos de log binário. Para instruções, consulte Create an account and configure binary logging for a self-managed MySQL database. Os logs binários locais de uma instância ApsaraDB RDS for MySQL devem ser retidos por pelo menos três dias (sete dias é o recomendado). Para um banco de dados MySQL autogerenciado, retenha os logs binários locais por pelo menos sete dias. Caso contrário, o DTS pode falhar ao recuperar logs binários, causando a falha da tarefa. Em casos extremos, isso pode causar inconsistência ou perda de dados. Problemas causados por períodos de retenção de logs binários inferiores aos exigidos pelo DTS não são cobertos pelo SLA do DTS. Nota Para configurar o retention period dos logs binários locais em uma instância ApsaraDB RDS for MySQL, consulte Automatically delete local logs. Não execute operações DDL que alterem esquemas de banco de dados ou tabelas durante a sincronização de esquema ou a sincronização completa. Caso contrário, a tarefa de sincronização falhará. Nota Durante a sincronização completa, o DTS consulta o banco de dados de source. Isso cria bloqueios de metadados que podem impedir operações DDL no banco de dados de source. Dados gerados por alterações que não gravam em logs binários — como dados restaurados de backups físicos ou criados por operações em cascata — não são sincronizados com o banco de dados de destino. Nota Se isso ocorrer, remova o banco de dados ou tabela afetado dos objetos de sincronização e adicione-o novamente. Faça isso apenas se o seu negócio permitir. Para mais informações, consulte Modify synchronization objects. Se o banco de dados de source for MySQL 8.0.23 ou posterior e contiver colunas ocultas invisíveis, o DTS pode não ler essas colunas, o que pode causar perda de dados. Nota Execute o comando `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` para tornar a coluna oculta visível. Para mais informações, consulte Invisible Columns. Se a instância ApsaraDB RDS for MySQL tiver Always-Encrypted habilitado, a sincronização completa de dados não é compatível. Nota Instâncias do ApsaraDB RDS for MySQL com Transparent Data Encryption (TDE) habilitado aceitam sincronização de esquema, sincronização completa de dados e sincronização incremental de dados. Instâncias somente leitura do ApsaraDB RDS for MySQL que não registram logs de transações, como instâncias somente leitura do ApsaraDB RDS for MySQL 5.6, não são aceitas como bancos de dados de source. O recurso zero-ETL executa periodicamente o comando `CREATE DATABASE IF NOT EXISTS test` no banco de dados de source para avançar o deslocamento do log binário.
Outras limitações	Dados do tipo time no ApsaraDB for ClickHouse possuem limitações de intervalo. Se os dados de tempo no RDS MySQL estiverem fora desse intervalo, o tempo sincronizado com o ApsaraDB for ClickHouse estará incorreto. Para informações sobre as limitações de intervalo, consulte Time information.

Notas de uso

Observações sobre a criação de pipelines zero-ETL

Se o número de links zero-ETL de um cluster ApsaraDB for ClickHouse atingir o limite, não será possível criar novos links. Utilize o DTS para criar um link de sincronização ou exclua links zero-ETL não utilizados. Os limites são os seguintes:
- O número máximo de links em um cluster Enterprise Edition é calculado pela fórmula [Limite inferior de CCU do cluster / 8], arredondando o resultado para cima. Por exemplo, se um cluster tem limite inferior de CCU de 22 e limite superior de 36, o cálculo usa o limite inferior de 22. O resultado é 22 / 8 = 2,75, arredondado para 3. Isso significa que você pode criar no máximo 3 links zero-ETL.
- Máximo de links para um cluster Community Edition: [Número total de núcleos do cluster / 8]. O resultado é arredondado para cima. Por exemplo, para um cluster com dois nós de 8 núcleos e 32 GB, o número total de núcleos de CPU é 8*2=16. O número máximo de links é calculado como 16/8=2. Isso significa que você pode criar no máximo 2 links zero-ETL.
Observações sobre tarefas de sincronização
- Se as instruções DDL da instância de source RDS MySQL não seguirem a sintaxe padrão do MySQL, a tarefa de sincronização poderá falhar ou haver perda de dados.
- A quantidade de bancos de dados a serem sincronizados não deve exceder o limite do ApsaraDB for ClickHouse, que é de 256.
- Os nomes dos bancos de dados, tabelas e colunas a serem sincronizados devem obedecer às convenções de nomenclatura do ApsaraDB for ClickHouse. Para mais informações sobre as convenções, consulte Object naming conventions.
- Ao sincronizar uma ou mais tabelas em vez de todo o banco de dados, não utilize ferramentas como pt-online-schema-change para executar operações DDL online nos objetos de sincronização do banco de dados de source. Caso contrário, a sincronização falhará.
- Antes de sincronizar dados, avalie o desempenho dos bancos de dados de source e de destino. Recomendamos realizar a sincronização de dados fora dos horários de pico. A sincronização inicial completa consome recursos de leitura e gravação das bases de source e destino, o que pode aumentar a carga dos bancos de dados.
- Durante a fase de sincronização de esquema, o recurso zero-ETL adiciona os campos _sign, _is_deleted e _version às tabelas de destino.
- Se o destino for um cluster ApsaraDB for ClickHouse Community-Compatible Edition, a integração perfeita cria uma tabela local e uma tabela distribuída para o destino.
  - O nome da tabela distribuída é igual ao nome da tabela de source.
  - O nome de uma tabela local é <distributed_table_name> + _local.

Mapeamentos de tipos de dados

Como clusters MySQL e ApsaraDB for ClickHouse aceitam tipos de dados diferentes, um mapeamento um para um não é possível. Quando o DTS realiza a sincronização inicial de esquema, ele mapeia os tipos de dados com base nos tipos aceitos pelo banco de dados de destino. Para mais informações, consulte Data type mappings for initial schema synchronization.

Preparações

Crie uma função vinculada ao service e conceda as permissões necessárias a um usuário RAM.

Crie a função vinculada ao service AliyunServiceRoleForClickHouseZeroETL.

Nota
O sistema cria automaticamente a função vinculada ao service AliyunServiceRoleForClickHouseZeroETL. Se uma caixa de diálogo solicitar que você crie essa função manualmente durante a configuração, ignore-a.
Conceda permissões a um usuário RAM.

Um usuário RAM requer as três permissões a seguir para criar um pipeline zero-ETL. Para obter informações sobre como conceder permissões a um usuário RAM, consulte Manage RAM user permissions.
- Permissão para a instância de source ApsaraDB RDS for MySQL: AliyunRDSFullAccess
- Permissão para o cluster de destino ApsaraDB for ClickHouse: AliyunClickHouseFullAccess
- Permissão para o DTS: O código abaixo fornece o script de política personalizada para o DTS. Para obter informações sobre como criar uma política personalizada, consulte Create a custom permission policy.
```
{
    "Version": "1",
    "Statement": [
        {
            "Action": "dts:*",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "ram:PassRole",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:Service": "dts.aliyuncs.com"
                }
            }
        }
    ]
}
```

Sincronizar dados

Etapa 1: Acessar a página Zero-ETL

Faça login no console do ApsaraDB for ClickHouse. No canto superior esquerdo, selecione a região onde seu cluster de destino está localizado.
Na página Clusters, selecione Clusters of Community-compatible Edition e clique em no ID do cluster alvo.
No painel de navegação à esquerda, clique em Zero-ETL.

Etapa 2: Criar e iniciar a tarefa zero-ETL****

Clique em Create Zero-ETL Task para abrir a página Create Zero-ETL Task.

Insira o Task Name e conclua as configurações a seguir.

Configure os bancos de dados de source e de destino.

Defina os bancos de dados de source e de destino com os parâmetros abaixo e clique em Test Connectivity and Proceed.

Banco de dados de source

Parâmetro

Descrição

Database Type

Apenas ApsaraDB RDS for MySQL é compatível.

Access Method

Apenas Alibaba Cloud instance é compatível.

Instance Region

Selecione a região da instância de source.

RDS Instance ID

O ID da instância ApsaraDB RDS for MySQL.

Database Account

A conta do banco de dados da instância ApsaraDB RDS for MySQL.

Database Account

A senha da conta do banco de dados da instância ApsaraDB RDS for MySQL.

Encryption

Selecione Non-encrypted ou SSL-encrypted conforme suas necessidades. Se selecionar SSL-encrypted, ative primeiro a criptografia SSL para a instância RDS MySQL. Para mais informações, consulte Use a cloud certificate to quickly enable SSL encryption.

Banco de dados de destino

Parâmetro

Descrição

Database Type

ClickHouse

Access Method

Apenas Alibaba Cloud instance é compatível.

Instance Region

A região do cluster de destino.

Cluster ID

O ID do cluster de destino.

Cluster Type

O tipo do cluster. Valores válidos: Community-Compatible Edition e Enterprise Edition.

Database Account

A conta do banco de dados do cluster de destino.

Database Password

A senha da conta do banco de dados do cluster de destino.

Configure o zero-ETL.

Na caixa Source Objects, selecione os objetos a serem sincronizados e clique em para movê-los para a caixa Selected Objects. Clique em Next: Configure Database and Table Fields.
Configure os campos de banco de dados e tabela.

Na página Configure Zero-ETL, defina o Type, Primary Key Column, Sort Key, Distribution Key e Partition Key da tabela a ser sincronizada no banco de dados de destino.
Nota
- Por padrão, a página exibe informações sobre tabelas indefinidas. Faça modificações após definir o Definition Status como All.
- A Primary Key Column e a Sort Key podem ser chaves compostas. Isso significa que você pode selecionar vários campos nas listas suspensas correspondentes para Primary Key Column ou Sort Key. Selecione uma ou mais colunas da Primary Key Column para usar como Partition Key. Apenas um campo pode ser selecionado para a Distribution Key. Para mais informações sobre chave primária, chave de ordenação e chave de partição, consulte CREATE TABLE.
- A Partition Key é opcional, mas não pode ser um campo anulável. Caso contrário, a tarefa de sincronização falhará.
Salve a tarefa.

Após configurar os campos da tabela do banco de dados, clique em Next: Save Task Settings and Precheck.

Nota
Após esta operação, a tarefa é salva, independentemente de a pré-verificação ser aprovada ou não.
Faça a pré-verificação e inicie a tarefa.

Quando a Success Rate for 100%, clique em Start para iniciar a tarefa Zero-ETL.

Na página Zero-ETL, visualize o ID/Name, Source/Destination e Status da tarefa Zero-ETL alvo.

Se a pré-verificação falhar, ajuste os bancos de dados de source e de destino com base nas informações de falha. Em seguida, localize a tarefa na página Zero-ETL, modifique-a e execute a pré-verificação novamente. Após a aprovação da pré-verificação, inicie a tarefa.

Monitorar tarefas zero-ETL

Monitore tarefas zero-ETL usando os métodos a seguir. Configure alertas ou assinaturas de eventos para receber atualizações oportunas sobre o status da tarefa. Se uma tarefa apresentar anomalias, use o monitoramento ativo para solucionar o problema.

Método de monitoramento	Benefício	Limitação	Ações
Monitoramento ativo	Oferece uma visão abrangente do status da tarefa, incluindo desempenho de sincronização, detalhes e logs.	Não notifica ativamente quando uma tarefa zero-ETL apresenta anomalias.	Monitor a task in the ApsaraDB for ClickHouse console
Monitoramento de alertas	O CloudMonitor envia automaticamente notificações de alerta com base em regras, ajudando a identificar e tratar rapidamente dados anômalos.	Monitora apenas a latência de sincronização (em milissegundos) das tarefas zero-ETL.	Monitor synchronization latency by using CloudMonitor alerts
Assinatura de eventos	Quando um evento do sistema de uma tarefa zero-ETL atende às condições de alerta, o CloudMonitor envia automaticamente uma notificação, mantendo você informado sobre falhas e recuperações de tarefas.	Monitora apenas falhas e recuperações de tarefas zero-ETL.	Subscribe to zero-ETL task events in CloudMonitor

Monitorar no console

Faça login no console do ApsaraDB for ClickHouse. No canto superior esquerdo, selecione a região onde seu cluster de destino está localizado.
Na página Clusters, selecione Clusters of Community-compatible Edition e clique em no ID do cluster alvo.
No painel de navegação à esquerda, clique em Zero-ETL.
Clique em Task Details na coluna Actions da tarefa alvo.

Na página de detalhes da tarefa, visualize informações completas e monitore a tarefa.

Alertas de latência do CloudMonitor

Crie regras de alerta no CloudMonitor para monitorar a latência zero-ETL. Quando uma métrica atender às condições de alerta, o CloudMonitor enviará automaticamente uma notificação.

Etapa 1: Criar um alerta de latência zero-ETL

Para obter informações sobre como criar um alerta de latência zero-ETL, consulte Use the CloudMonitor console. Ao criar o alerta, certifique-se de definir os seguintes parâmetros.

Parâmetro	Descrição
Product	Selecione Clickhouse - ZeroETL Latency.
Metric	Selecione Synchronization Latency.

Etapa 2: Visualizar a latência do cluster

Faça login no CloudMonitor.
Na lista Clickhouse - ZeroETL Latency, clique em Monitoring Charts na coluna Actions do cluster alvo para visualizar a latência de sincronização do cluster.

Assinatura de eventos do CloudMonitor

Para monitorar a recuperação e falha de tarefas zero-ETL e receber notificações oportunas, assine os eventos relevantes.

Para obter informações sobre como assinar eventos Zero-ETL, consulte Manage event subscriptions. Ao criar uma política de assinatura, certifique-se de definir os seguintes parâmetros.

Evento	Parâmetro	Descrição
Falha na tarefa Zero-ETL	Subscription type	Selecione System Event.
	Product	Selecione ApsaraDB for ClickHouse.
	Event type	Selecione Abnormal.
	Event name	Selecione ZeroETL task abnormal.
Recuperação da tarefa Zero-ETL	Subscription type	Selecione System Event.
	Product	Selecione ApsaraDB for ClickHouse.
	Event type	Selecione Restore.
	Event name	Selecione ZeroETLTaskRestore.

Perguntas frequentes

P: Após usar o Zero-ETL para sincronizar dados com o ApsaraDB for ClickHouse, por que o volume de dados no banco de dados de destino é maior do que no banco de dados de source?

Causa: Ao executar uma operação UPDATE ou DELETE na source, o ApsaraDB for ClickHouse grava uma nova linha e usa os campos _sign, _is_deleted e _version para marcar essas operações. Como resultado, o banco de dados de destino tem mais linhas do que o banco de dados de source.

Solução: Ao consultar, use condições _sign ou _is_deleted para filtrar dados excluídos com base na versão. Além disso, adicione FINAL após o nome da tabela para deduplicar registros. Para mais informações sobre identificadores de campo, consulte Field information.

P: Após usar o Zero-ETL para sincronizar dados com o ApsaraDB for ClickHouse, por que uma tabela local aparece no banco de dados de destino?

Se o destino for um cluster ApsaraDB for ClickHouse Community-Compatible Edition, a integração perfeita cria uma tabela local e uma tabela distribuída para o destino.

O nome da tabela distribuída é igual ao nome da tabela de source.
O nome de uma tabela local é <distributed_table_name> + _local.