Esta página foi traduzida pela API Cloud Translation.

Vista geral das alterações de streams

O Bigtable oferece a captura de dados de alterações (CDC) com a respetiva funcionalidade de streams de alterações. Uma stream de alterações capta as alterações de dados a uma tabela do Bigtable à medida que ocorrem, o que lhe permite transmiti-las para processamento ou análise.

Este documento oferece uma vista geral das streams de alterações do Bigtable. Antes de ler este documento, deve estar familiarizado com a vista geral do Bigtable.

As streams de alterações são valiosas para exemplos de utilização de CDC, incluindo o seguinte:

Acionar a lógica da aplicação a jusante quando ocorrem alterações especificadas
Integração com um pipeline de análise de dados
Apoio técnico para requisitos de auditoria e arquivo

O que é uma stream de alterações

Uma stream de alterações acompanha as alterações ao nível da tabela feitas por um utilizador ou uma aplicação, normalmente através de uma das bibliotecas de cliente do Cloud Bigtable. As alterações à recolha de lixo também são capturadas.

Todas as alterações aplicadas a uma tabela com streams de alterações ativadas são armazenadas como registos de alterações de dados. Os registos de alterações de dados incluem alterações de dados aplicadas pelo seguinte:

Escritas, eliminações e atualizações enviadas através dos métodos da API Cloud Bigtable MutateRow, MutateRows, CheckAndMutateRow e ReadModifyWriteRow
Eliminações que ocorrem devido à recolha de lixo
Linhas eliminadas através do método DropRowRange da API Admin

Para ver detalhes sobre os tipos de alterações que pode enviar para uma tabela do Bigtable, consulte Leituras, Escritas, Eliminações e Vista geral da recolha de lixo.

As alterações de streams não acompanham as alterações de esquemas, como adicionar ou modificar uma família de colunas, ou a topologia de replicação, como adicionar ou remover um cluster.

Os registos de alterações de dados para cada chave de linha e cada cluster estão por ordem da data/hora de confirmação. No entanto, não existe garantia de ordenação nos registos de alterações de dados para uma chave de linha ou um cluster diferente.

Ativa as streams de alterações numa tabela e especifica um período de retenção de 1 a 7 dias.

O que inclui um registo de alteração de dados

Cada registo 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.

Se um valor for substituído, o valor recém-escrito é registado no registo de alterações de dados. O registo de alteração de dados não contém o valor antigo.

Um registo de alteração de dados recebe a respetiva data/hora, denominada data/hora de confirmação, ao mesmo tempo que a alteração é aplicada ao primeiro cluster que a recebe. Por exemplo, considere uma instância com dois clusters. Se enviar um pedido de gravação para a tabela 1 no cluster A, a data/hora de confirmação do registo de alteração de dados é atribuída quando a gravação é recebida pelo cluster A, e o registo de alteração de dados no cluster B para esta gravação tem a mesma data/hora de confirmação.

Cada registo de alteração de dados contém o seguinte:

Entradas: alterações feitas à linha, incluindo uma ou mais das seguintes:
- Escrever
  - Família de colunas
  - Qualificador da coluna
  - Indicação de tempo
  - Valor
- Eliminação de células
  - Família de colunas
  - Qualificador da coluna
  - Intervalo de data/hora
- Eliminação de uma família de colunas
  - Família de colunas
  - Eliminação de uma linha: a eliminação de uma linha é convertida numa lista de eliminações de famílias de colunas para cada família de colunas em que a linha tem dados.
Chave da linha: o identificador da linha alterada
Tipo de alteração: iniciada pelo utilizador ou recolha de lixo
ID do cluster que recebeu a alteração
Data/hora de confirmação: hora do lado do servidor em que a alteração foi confirmada na tabela
Desempate: um valor que permite à aplicação que está a ler o fluxo usar a política de resolução de conflitos incorporada do Bigtable
Token: usado pela aplicação de consumo para retomar a stream se for interrompida
Limite inferior estimado: a hora estimada desde que a partição do registo alcançou a replicação em todos os clusters. Para obter detalhes, consulte as secções Partições e Marcas de água.

Para mais informações acerca dos campos num registo de alteração de dados, consulte a referência da API para DataChange.

Altere o armazenamento de streams

Uma tabela e o respetivo fluxo de alterações partilham os mesmos recursos ao nível do cluster, incluindo nós e armazenamento. Como resultado, o armazenamento de dados de fluxo de alterações faz parte do armazenamento de uma tabela. Numa instância que usa a replicação, é armazenada uma cópia dos dados de uma stream de alterações em todos os clusters da instância que contém a tabela com a stream de alterações ativada.

O armazenamento usado para os dados do fluxo de alterações não é contabilizado para a utilização total de armazenamento (% máximo). Como resultado, não precisa de adicionar nós para processar o aumento do armazenamento consumido pelos dados do fluxo de alterações (embora possa ter de adicionar nós para aumentar a capacidade de computação). No entanto, é-lhe cobrado o armazenamento que os dados da stream de alterações consomem. Para obter detalhes, consulte a secção Considerações sobre o custo.

Ler uma stream de alterações

Para ler (transmitir) uma stream de alterações, tem de usar um perfil de aplicação configurado para encaminhamento de cluster único e, se transmitir através do Dataflow, tem de ativar as transações de linha única.

Para mais informações acerca das políticas de encaminhamento, consulte as Opções de encaminhamento.

Para mais informações sobre transações de uma única linha, consulte o artigo Transações de uma única linha.

Os métodos de fluxo de alterações são fornecidos pela API Cloud Bigtable (API Data). Em alternativa, recomendamos que use uma das seguintes opções em vez de chamar a API sem usar uma biblioteca de cliente ou um conector:

Modelos do Dataflow
Conetor do Bigtable Beam
Biblioteca cliente Java

Todas as opções permitem evitar a necessidade de monitorizar e processar alterações de partições devido a divisões e uniões.

Para mais informações, consulte ReadChangeStream.

Modelos do Dataflow

Pode usar um dos seguintes modelos do Dataflow fornecidos pela Google:

Conetor do Bigtable Beam

Pode usar o conetor Bigtable Beam para criar um pipeline:

Conetor Bigtable Beam

Se não quiser criar o seu próprio pipeline, pode usar os exemplos de código do tutorial ou do início rápido do Bigtable como ponto de partida para o seu código:

Biblioteca cliente Java

Cliente do Cloud Bigtable para Java

Partições

Para manter um débito de leitura elevado que corresponda a uma taxa de gravação ou alteração elevada, o Bigtable divide um fluxo de alterações em várias partições que podem ser usadas para ler o fluxo de alterações em paralelo. Cada partição da stream de alterações está associada a um tablet. As partições são subsecções de uma tabela que são redistribuídas conforme necessário para ajudar a equilibrar a carga de trabalho de pedidos da tabela. Para saber mais, consulte Equilíbrio de carga.

A biblioteca de cliente Java permite-lhe consultar cada partição para ver as alterações e fornece as informações necessárias para gerir as alterações nas partições devido a divisões e uniões.

Marcas de água

Uma marca de água é uma data/hora que estima a antiguidade com que uma partição alcançou a replicação em todos os clusters. A marca cronológica da partição é atualizada continuamente à medida que a replicação ocorre, avançando no tempo.

Cada ChangeStreamMutation (registo de alteração de dados) inclui um campo estimatedLowWatermark, que é a marca de água da partição associada ao registo de alteração de dados. Esta estimatedLowWatermark é uma estimativa e não garante que não existam dados que ainda não chegaram à stream.

Marcas de água para tabelas replicadas

O estimatedLowWatermark (limite inferior) de uma partição não avança se a replicação não estiver totalmente atualizada para a partição. A marca de água baixa ao nível da stream, ou seja, a mais baixa de todas as marcas de água baixas estimadas ao nível da partição, deixa de avançar se a marca de água de qualquer partição não estiver a avançar. Uma marca de água que parou de avançar é considerada parada. Quando isto acontece, se estiver a fazer streaming da stream de alterações num pipeline, o pipeline fica parado.

Existem vários fatores que podem fazer com que uma ou mais marcas cronológicas ao nível da partição fiquem paradas durante algum tempo, incluindo o seguinte:

Sobrecarga de um cluster com tráfego que faz com que a replicação fique atrasada para uma ou mais partições
Atrasos na rede
Indisponibilidade do cluster

O conetor Bigtable Beam processa esta situação definindo a data/hora de saída como zero para todos os dados. Para mais informações, consulte o artigo Agrupar dados sem horas de eventos.

Monitorização

Para ajudar a compreender como a ativação de um fluxo de alterações afeta a utilização da CPU e do armazenamento de uma instância que contém tabelas com o fluxo de alterações ativado, fornecemos duas métricas específicas do fluxo de alterações. Pode ver as métricas na página de estatísticas do sistema do Bigtable ou através do conjunto de ferramentas do Cloud Monitoring.

Bytes usados pelos registos da stream de alterações (change_stream_log_used_bytes)
Utilização da CPU por streams de alterações ( usa cpu_load_by_app_profile_by_method_by_table)

Para ver detalhes sobre estas métricas, consulte o artigo Monitorização.

Considerações sobre o custo

A ativação de um fluxo de alterações numa tabela resulta num aumento dos custos para os nós e o armazenamento. Em particular, pode esperar incorrer em custos de armazenamento mais elevados.

Nós

Normalmente, tem de adicionar nós a um cluster (ou aumentar o número máximo de nós se usar o dimensionamento automático) para processar o tráfego adicional da ativação e do processamento dos registos de alterações de dados.

A ativação de um fluxo de alterações pode aumentar a utilização da CPU em cerca de 10%, mesmo antes de começar a processá-lo. O processamento de uma stream de alterações, como a leitura da mesma através de um pipeline do Dataflow, pode aumentar a utilização da CPU em cerca de 20 a 30%, consoante o nível de atividade de alterações e a forma como os dados da stream são lidos.

Armazenamento

São-lhe cobradas as tarifas de armazenamento do Bigtable padrão para armazenar os registos de alterações de dados da sua tabela. Também lhe é cobrado o armazenamento da tabela criada para acompanhar os metadados da stream de alterações. O período de retenção que especificar afeta diretamente os custos de armazenamento.

Como regra geral, os registos de alterações de dados de um dia, que refletem apenas as mutações ocorridas nesse dia, ocupam cerca de 1,5 vezes mais armazenamento do que os dados que foram escritos nesse dia consomem no disco.

Transferência de dados por rede

Se ler um fluxo de alterações em várias regiões, pode incorrer em custos por esse tráfego. Consulte a secção Rede em Preços do Bigtable para ver uma lista completa das taxas de transferência de dados de rede.

Custos de processamento

Consoante a forma como lê os registos de alterações de dados, aplicam-se custos adicionais aos serviços que não sejam o Bigtable. Por exemplo, se usar o Dataflow, paga pelos bytes processados e pelas máquinas de trabalho que processam a tarefa. Para ver detalhes, consulte o artigo Preços do Dataflow.

Soltar intervalos de linhas

Se possível, evite eliminar um intervalo de linhas de uma tabela que tenha um fluxo de alterações ativado. Se tiver de eliminar um intervalo de linhas, tenha em atenção que o Bigtable pode demorar muito tempo a concluir a operação e que a utilização da CPU aumenta durante a operação.