Visão geral do fluxo de alterações
O Bigtable oferece a captura de dados alterados (CDC) com os fluxos de alteração . Um fluxo de alterações captura alterações de dados em uma tabela do Bigtable à medida que as alterações ocorrem, permitindo mostrá-las para processamento ou análise.
Este documento fornece uma visão geral do fluxo de alterações do Bigtable. Antes de ler este documento, você precisa ter familiaridade com a visão geral do Bigtable.
O fluxo de alterações é valioso nos seguintes casos de uso de CDC:
- Acionar a lógica de aplicativo downstream quando ocorrerem alterações especificadas
- Fazer a integração com um pipeline de análise de dados
- Ser compatível com requisitos de auditoria e arquivamento
O que é um fluxo de alterações
Um fluxo de alterações rastreia as alterações no nível da tabela, feitas por um usuário ou que geralmente usa uma das bibliotecas de cliente do Cloud Bigtable. As alterações na coleta de lixo também são capturadas.
Todas as alterações aplicadas a uma tabela com fluxo de alterações ativado são armazenadas como registros de alteração de dados. Os registros de alteração de dados incluem alterações de dados aplicadas por:
- Gravações, exclusões e atualizações enviadas usando os métodos da API Cloud Bigtable
MutateRow
,MutateRows
,CheckAndMutateRow
eReadModifyWriteRow
- exclusões que ocorrem devido à coleta de lixo;
- linhas excluídas pelo método
DropRowRange
da API Admin.
Para obter detalhes sobre os tipos de alterações que você pode enviar a um do Bigtable, consulte Leituras, Escreve, Exclusões, e Visão geral da coleta de lixo.
Os fluxos de alterações não rastreiam alterações de esquema, como a adição ou modificação de grupos de colunas ou topologia de replicação, como adicionar ou remover um cluster.
Os registros de alteração de dados para cada chave de linha e cada cluster estão no carimbo de data/hora de confirmação ordem. No entanto, não há garantia de ordem nos registros de alteração de dados para uma chave de linha ou cluster diferente.
Você ativa o fluxo de alterações em uma tabela e especifica um período de armazenamento de 1 a 7 dias.
O que há em um registro de alteração de dados
Cada registro de alteração de dados contém todas as alterações de uma linha que foram aplicadas atomicamente como parte de uma única chamada RPC (remote procedure call).
Se um valor for substituído, o valor recém-gravado será registrado no registro de alteração de dados. O registro de alteração de dados não contém o valor antigo.
Um registro de alteração de dados recebe um carimbo de data/hora, chamado carimbo de data/hora de confirmação, no ao mesmo tempo que a alteração é aplicada ao primeiro cluster que a recebe. Por exemplo, considere uma instância com dois clusters. Se você enviar uma solicitação de gravação para a Tabela 1 no Cluster A, o carimbo de data/hora de confirmação do registro de alteração de dados será atribuído quando a gravação for recebida pelo Cluster A e o registro de alteração de dados no Cluster B dessa gravação terá o mesmo carimbo de data/hora de confirmação.
Cada registro de alteração de dados contém os seguintes itens:
- Entradas: alterações feitas na linha, incluindo uma ou mais das opções a seguir:
- Gravar
- Grupo de colunas
- Qualificador de coluna
- Carimbo de data/hora
- Valor
- Exclusão de células
- Grupo de colunas
- Qualificador de coluna
- Intervalo de carimbo de data/hora
- Exclusão de um grupo de colunas
- Grupo de colunas
- Exclusão de uma linha: a exclusão de uma linha é convertida em uma lista. de exclusões de grupos de colunas para cada grupo de colunas que o linha contém dados.
- Gravar
- Chave de linha: o identificador da linha alterada
- Tipo de alteração: iniciada pelo usuário ou coleta de lixo
- ID do cluster que recebeu a alteração
- Carimbo de data/hora de confirmação: tempo do lado do servidor em que a alteração foi confirmada na tabela.
- Desempate: um valor que permite que o aplicativo que está lendo o stream use a solução de conflitos integrada do Bigtable política
- Token: usado pelo aplicativo consumidor para retomar o fluxo em caso de interrupção
- Marca-d'água baixa estimada: o tempo estimado desde a partição do registro. a replicação entre todos os clusters. Para mais detalhes, consulte Partições e Marcas-d'água.
Para mais informações sobre os campos em um registro de alteração de dados, consulte a API
referência para
DataChange
Armazenamento do fluxo de alterações
Uma tabela e seu fluxo de alterações compartilham os mesmos recursos no nível do cluster, incluindo nós e armazenamento. Por isso, o armazenamento de dados do fluxo de alterações faz parte do armazenamento de uma tabela. Em uma instância que usa replicação, uma cópia dos dados de um fluxo de alterações é armazenada em todos os clusters da instância que contém a tabela com fluxo de alterações ativado.
O armazenamento usado para os seus dados do fluxo de alterações não é contabilizado na utilização total do armazenamento (% máxima). Por isso, você não precisa adicionar nós para lidar com o aumento de armazenamento consumido pelos dados do fluxo de alterações (embora talvez seja necessário adicionar nós para maior potência computacional). No entanto, haverá cobrança pelo armazenamento consumido pelos dados do fluxo de alterações. Para mais detalhes, consulte Considerações sobre custos.
Como ler um fluxo de alterações
Para ler (transmitir) um fluxo de alterações, você precisa usar um perfil de aplicativo configurado para roteamento de cluster único e, se você usa o Dataflow para fazer streaming, precisa ativar as transações de linha única.
Para mais informações sobre políticas de roteamento, consulte Opções de roteamento.
Para mais informações sobre transações de linha única, consulte Transações de linha única.
Os métodos de fluxo de alterações são fornecidos pela API Cloud Bigtable (API Data). Recomendamos que você use uma das opções a seguir em vez de chamar a API sem usar uma biblioteca de cliente ou um conector:
- Modelos do Dataflow
- Conector Bigtable Beam
- Biblioteca de cliente Java
Todas as opções evitam a necessidade de rastrear e processar alterações de partição devido a divisões e mesclagens.
Para ver mais informações, consulte ReadChangeStream
.
Modelos do Dataflow
É possível usar um dos seguintes modelos do Dataflow fornecidos pelo Google:
Conector Bigtable Beam
É possível usar o conector do Bigtable Beam para criar um pipeline:
Se você não quiser criar seu próprio pipeline, use os exemplos de código do tutorial ou do guia de início rápido do Bigtable como ponto de partida para seu código:
Biblioteca de cliente Java
Partições
Para manter uma alta capacidade de leitura que corresponda a uma alta taxa de gravação ou alteração, O Bigtable divide um fluxo de alterações em várias partições que pode ser usada para ler o fluxo de alterações em paralelo. Cada partição do fluxo de alterações é associada a um bloco. Os blocos são subseções de uma tabela redistribuídas conforme necessário para ajudar a equilibrar a carga de trabalho de solicitação da tabela. Para saber mais, consulte Balanceamento de carga.
A biblioteca de cliente Java permite consultar cada partição em busca de alterações e fornece as informações necessárias para gerenciar as alterações nas partições devido a divisões e mesclagens.
Marcas-d'água
Uma marca-d'água é um carimbo de data/hora que estima quando uma partição alcançou uma replicação em todos os clusters pela última vez. A marca-d'água da partição é atualizada continuamente à medida que a replicação ocorre, com avanço no tempo.
Cada registro de alteração de dados (ChangeStreamMutation
) inclui um campo estimatedLowWatermark
, que é a marca-d'água da partição associada ao registro de alteração de dados. Essa estimatedLowWatermark
é uma estimativa e não garante que ainda não haja dados a chegar no fluxo.
Marcas-d'água para tabelas replicadas
A marca-d'água baixa (estimatedLowWatermark
) de uma partição não avançará se a replicação não for totalmente alcançada pela partição. A marca-d'água baixa no fluxo todo, a menor marca-d'água estimada no nível da partição, deixará de avançar se a marca-d'água de qualquer partição não avançar. Uma marca-d'água que deixa de avançar é considerada interrompida. Quando isso ocorre, se você estiver mostrando o fluxo de alterações em um pipeline, o pipeline será interrompido.
Muitos fatores podem interromper uma ou mais marcas-d'água no nível da partição por algum tempo, como estes:
- Sobrecarga de um cluster com tráfego que causa atraso na replicação para uma ou mais partições
- Atrasos na rede
- Indisponibilidade do cluster
O conector do Bigtable Beam lida com isso definindo o o carimbo de data/hora de saída como zero para todos os dados. Para mais informações, consulte Como agrupar dados sem horários de eventos.
Monitoramento
Para ajudar você a entender como a ativação de um fluxo de alterações afeta a utilização da CPU e do armazenamento para uma instância que contém tabelas com fluxo de alterações ativado, fornecemos duas métricas específicas do fluxo de alterações. Para ver as métricas, acesse a página do Monitoring do Bigtable ou use o pacote de ferramentas do Cloud Monitoring.
- Bytes usados pelos registros do fluxo de alterações (
change_stream_log_used_bytes
) - Utilização da CPU por fluxo de alterações (usa
cpu_load_by_app_profile_by_method_by_table
)
Veja detalhes sobre essas métricas no Monitoring.
Considerações sobre o custo
Ativar um fluxo de alterações em uma tabela resulta em maiores custos de nós e armazenamento. Espere sobretudo mais custos de armazenamento.
Nós
Normalmente, você precisa adicionar nós a um cluster (ou aumentar o número máximo de nós, se você usa o escalonamento automático) para lidar com o tráfego extra por ativar e processar os registros de alteração de dados.
A ativação de um fluxo de alterações pode aumentar o uso da CPU em cerca de 10%, mesmo antes de começar a processá-lo. O processamento de um fluxo de alterações, como a leitura dele por um pipeline do Dataflow, pode aumentar a utilização da CPU em cerca de 20 a 30%, dependendo do nível de atividade de alteração e de como os dados do fluxo são lidos.
Armazenamento
Você paga o valor padrão Taxas de armazenamento do Bigtable para armazenar os registros de alteração de dados da tabela. Há cobrança também por armazenar a tabela criada para rastrear metadados do fluxo de alterações. O período de armazenamento especificado afeta diretamente os custos de armazenamento.
Como regra geral, os registros de alteração de dados de um dia, que refletem apenas as mutações que ocorreram nesse dia, ocupam cerca de 1,5 vez mais armazenamento do que os dados gravados nesse dia em termos de consumo no disco.
Transferência de dados de rede
Se você ler um fluxo de alterações entre regiões, poderá haver custos desse tráfego. Consulte a seção "Rede" Preços do Bigtable para uma lista completa das taxas de transferência de dados de rede.
Custos de processamento
Dependendo de como você lê os registros de alteração de dados, são aplicados custos extras de outros serviços além do Bigtable. Por exemplo, se você usar o Dataflow, pagará pelos bytes processados e pelas máquinas do worker que processam o job. Para detalhes, consulte Preços do Dataflow.
Como descartar intervalos de linhas
Se possível, evite descartar um intervalo de linhas de uma tabela com fluxo de alterações ativado. Se você precisar descartar um intervalo de linhas, lembre-se de que pode demorar muito para o Bigtable concluir a operação e que o uso da CPU aumentará durante a operação.
A seguir
- Conclua um guia de início rápido para saber como ativar um fluxo de alterações e ver as mudanças.
- Configure fluxo de alterações.
- Use o conector Bigtable Beam para ler um fluxo de alterações com o Dataflow.
- Usar a biblioteca de cliente do Cloud Bigtable para Java para ler fluxos de alterações
- Siga um tutorial sobre o processamento de um fluxo de alterações.