Esta página foi traduzida pela API Cloud Translation.

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 mudanças feitas por um usuário ou aplicativo no nível da tabela, geralmente usando 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 pelos métodos MutateRow, MutateRows, CheckAndMutateRow e ReadModifyWriteRow da API Cloud Bigtable;
exclusões que ocorrem devido à coleta de lixo;
linhas excluídas pelo método DropRowRange da API Admin.

Para detalhes sobre os tipos de mudanças que podem ser enviadas para uma tabela do Bigtable, consulte Leituras, Gravações, Exclusões e Visão geral da coleta de lixo.

O fluxo de alterações não rastreia alterações de esquema, como adicionar ou modificar um grupo 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 na ordem de carimbo de data/hora de confirmação. No entanto, não há garantia de ordenação 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 em que há dados na linha.
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 ao aplicativo leitor do fluxo usar a política de resolução de conflito integrada do Bigtable
Token: usado pelo aplicativo consumidor para retomar o fluxo em caso de interrupção
Marca-d'água baixa estimada: o tempo estimado desde que a partição do registro alcançou a replicação em 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 do 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 mudanças 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:

Conector Bigtable Beam

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

Cliente do Cloud Bigtable para 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 configurando 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

As taxas de armazenamento do Bigtable padrão são cobradas 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.