Se usó la API de Cloud Translation para traducir esta página.

Descripción general de los flujos de cambios

Bigtable proporciona captura de datos modificados (CDC) con sus flujos de cambio . Los flujos de cambios capturan los cambios en los datos de una tabla de Bigtable a medida que ocurren los cambios, lo que te permite transmitirlos para procesarlos o análisis.

En este documento, se proporciona una descripción general de los flujos de cambios de Bigtable. Antes de leer este documento, debes familiarizarte con los Descripción general de Bigtable.

Los flujos de cambios son valiosos para los casos de uso de los CDC, incluidos los siguientes:

Activa la lógica de la aplicación descendente cuando se producen cambios específicos
Integración en una canalización de análisis de datos
Satisface los requisitos de auditoría y archivo

Qué es un flujo de cambios

Un flujo de cambios hace un seguimiento de los cambios a nivel de la tabla que realiza un usuario de Compute Engine, generalmente con una de las bibliotecas cliente de Cloud Bigtable. También se registran los cambios en la recolección de elementos no utilizados.

Todos los cambios aplicados a una tabla con flujos de cambios habilitados se almacenan como cambio de datos registros. Los registros de cambios en los datos incluyen los cambios de datos aplicados por las siguientes entidades:

Las operaciones de escritura, eliminación y actualización que se envían con los métodos de la API de Cloud Bigtable MutateRow, MutateRows, CheckAndMutateRow y ReadModifyWriteRow
Eliminaciones que ocurran debido a la recolección de elementos no utilizados
Filas borradas con el método DropRowRange de la API de Admin

Para obtener detalles sobre los tipos de cambios que puede enviar a un en la tabla de Bigtable, consulta Lecturas, Escrituras, Eliminaciones, y Descripción general de la recolección de elementos no utilizados.

Los flujos de cambios no realizan un seguimiento de los cambios de esquema, como agregar o modificar un o la topología de replicación, como agregar o quitar un clúster.

Los registros de cambios de datos para cada clave de fila y cada clúster se encuentran en una marca de tiempo de confirmación en el orden personalizado. Sin embargo, no hay garantía de ordenamiento sobre registros de cambios de datos para un clave de fila o clúster diferentes.

Habilitas flujos de cambios en una tabla y especificas un período de retención de 1 a 7 días.

¿Qué es un registro de cambios en los datos?

Cada registro de cambios en los datos contiene todos los cambios de una fila que se aplicaron de forma atómica como parte de una única llamada RPC.

Si se reemplaza un valor, el valor recién escrito se registra en los datos. registro de cambios. El registro de cambios en los datos no contiene el valor anterior.

Un registro de cambios de datos recibe su marca de tiempo, denominada marca de tiempo de confirmación, en la misma vez que se aplica el cambio al primer clúster que lo recibe. Para Por ejemplo, considera una instancia con dos clústeres. Si envías una solicitud de escritura a En la tabla 1 del Clúster A, la marca de tiempo de confirmación del registro de cambios de datos se asigna cuando el Clúster A recibe la escritura y el registro de cambios de datos del clúster B esta escritura tiene la misma marca de tiempo de confirmación.

Cada registro de cambios en los datos contiene lo siguiente:

Entradas: cambios realizados en la fila, incluidos uno o más de los siguientes:
- Escritura
  - Familia de columnas
  - Calificador de columna
  - Marca de tiempo
  - Valor
- Eliminación de celdas
  - Familia de columnas
  - Calificador de columna
  - Rango de marca de tiempo
- Eliminación de una familia de columnas
  - Familia de columnas
  - Eliminación de una fila: La eliminación de una fila se convierte en una lista. de eliminaciones de familias de columnas para cada familia de columnas a la que fila tiene datos.
Clave de fila: el identificador de la fila modificada
Tipo de cambio: Iniciado por el usuario o recolección de elementos no utilizados
ID del clúster que recibió el cambio
Marca de tiempo de confirmación: la hora del servidor en la que se confirmó el cambio tabla
Desempate: un valor que permite a la aplicación que está leyendo la transmisión. usar la resolución de conflictos integrada de Bigtable política
Token: lo usa la aplicación consumidora para reanudar la transmisión si es interrumpido
Marca de agua baja estimada: el tiempo estimado desde la partición del registro están al día con la replicación en todos los clústeres. Para obtener más información, consulta Particiones y Marcas de agua.

Para obtener más información sobre los campos de un registro de cambios en los datos, consulta la API referencia para DataChange.

Almacenamiento de flujos de cambios

Una tabla y su flujo de cambios comparten los mismos recursos a nivel del clúster, que incluyen lo siguiente: los nodos y el almacenamiento. Como resultado, el almacenamiento de datos del flujo de cambios y almacenamiento de los datos. En una instancia que usa la replicación, una copia de los datos de un flujo de cambios se almacena en cada clúster de la instancia que contiene el cambio con transmisión habilitada.

El almacenamiento usado en tus datos de flujos de cambios no se considera en el total el uso del almacenamiento (% del máx.). Como resultado, no es necesario agregar nodos para controlar el aumento de almacenamiento que consumen los datos del flujo de cambios (aunque podría necesitar para agregar nodos y así obtener capacidad de procesamiento adicional). Sin embargo, sí se te cobra por y el almacenamiento que consumen los datos del flujo de cambios. Para obtener más información, consulta Consideraciones de costo.

Cómo leer un flujo de cambios

Para leer (transmitir) un flujo de cambios, debes usar un perfil de aplicación configurado para enrutamiento de un solo clúster y, si transmites con Dataflow, debes habilitar las transacciones de una sola fila.

Para obtener más información sobre las políticas de enrutamiento, consulta Opciones de enrutamiento

Para obtener más información sobre las transacciones de una sola fila, consulta Transacciones de fila única.

La API de Cloud Bigtable (API de Data) proporciona los métodos de flujo de cambios. Te recomendamos que uses una de las siguientes opciones en lugar de llamar a la API sin usar una biblioteca cliente o un conector:

Plantillas de Dataflow
Conector de Bigtable Beam
Biblioteca cliente de Java

Todas las opciones te permiten evitar la necesidad de realizar un seguimiento y controlar los cambios de partición debido a las divisiones y combinaciones.

Para obtener más información, consulta ReadChangeStream

Plantillas de Dataflow

Puedes usar una de las siguientes plantillas de Dataflow que proporciona Google:

Conector de Bigtable Beam

Puedes usar el conector de Bigtable Beam para compilar una canalización:

Conector de Bigtable de Beam

Si no quieres compilar tu propia canalización, puedes usar las muestras de código de el instructivo o la guía de inicio rápido de Bigtable como punto de partida para tus código:

Biblioteca cliente de Java

Cliente de Cloud Bigtable para Java

Particiones

Para mantener una alta capacidad de procesamiento de lectura que coincida con una tasa alta de escritura o cambio, Bigtable divide un flujo de cambios en varias particiones que se puede usar para leer el flujo de cambios en paralelo. Cada partición de flujo de cambios está asociado a una tablet. Las tabletas son subsecciones de una tabla que son según sea necesario para ayudar a equilibrar la carga de trabajo de solicitudes de la tabla. Para aprender más, consulta Balanceo de cargas.

La biblioteca cliente de Java te permite consultar cada partición en busca de cambios y proporciona la información necesaria para administrar cambios en particiones debido en fracciones y combinaciones.

Marcas de agua

Una marca de agua es una marca de tiempo que estima qué tan recientemente capturó una partición. con la replicación en todos los clústeres. La marca de agua de la partición es se actualiza continuamente a medida que se produce la replicación, lo que avanza en el tiempo.

Cada ChangeStreamMutation (registro de cambios de datos) incluye un campo estimatedLowWatermark, que es la marca de agua de la partición que se asociados con el registro de cambios en los datos. Este estimatedLowWatermark es un una estimación y no garantiza que no haya datos que aún no hayan llegado. la transmisión.

Marcas de agua para mesas replicadas

El estimatedLowWatermark (marca de agua baja) de una partición no avanza si la replicación no está completamente disponible para la partición. La baja en toda la transmisión marca de agua: la más baja de todas las marcas de agua estimadas bajas a nivel de partición — deja de avanzar si la marca de agua de alguna partición no se mueve. R Una marca de agua que dejó de avanzar se considera detenida. Cuando esta si transmites tu flujo de cambios en una canalización, esta puestos.

Muchos factores pueden hacer que una o más marcas de agua a nivel de partición se detengan en algunos de tiempo, que incluye lo siguiente:

Sobrecargar un clúster con tráfico que provoca que caiga la replicación detrás de una o más particiones
Demoras en la red
Falta de disponibilidad del clúster

El conector de Bigtable Beam se encarga de esto configurando el marca de tiempo de salida en cero para todos los datos. Para obtener más información, consulta Agrupar datos sin la hora del evento.

Supervisión

Ayudarte a comprender cómo la habilitación de un flujo de cambios afecta la CPU y el almacenamiento para una instancia que contiene tablas con flujos de cambios habilitados, proporcionan dos métricas específicas del flujo de cambios. Puedes ver las métricas Página de supervisión de Bigtable o mediante el paquete de Cloud Monitoring de herramientas.

Bytes utilizados por los registros de flujos de cambios (change_stream_log_used_bytes)
Uso de CPU por flujos de cambios ( usos cpu_load_by_app_profile_by_method_by_table)

Para obtener detalles sobre estas métricas, consulta Supervisión

Consideraciones de costo

Habilitar un flujo de cambios en una tabla aumenta el costo de los nodos y almacenamiento de los datos. En particular, se prevé más almacenamiento los costos.

Nodos

Por lo general, debes agregar nodos a un clúster (o aumentar la cantidad máxima de nodos (si usas el ajuste de escala automático) para controlar el tráfico adicional el procesamiento de los registros de cambios en los datos.

Habilitar un flujo de cambios puede aumentar el uso de la CPU alrededor de un 10%, incluso antes de comenzar a procesarlos. Procesar un flujo de cambios, por ejemplo, leerlo mediante una canalización de Dataflow, puede aumentar el uso de CPU en aproximadamente 20 a 30%, según el nivel de actividad de cambio y la forma en que los datos de transmisión de lectura.

Almacenamiento

Se te cobra el precio estándar Tarifas de almacenamiento de Bigtable para almacenar los registros de cambios de datos de tu tabla. También se te cobra por almacenar que se crea para hacer un seguimiento de los metadatos del flujo de cambios. El período de retención que que especifiques tendrá un impacto directo en los costos de almacenamiento.

Como regla general, el equivalente a un día de registros de cambios en los datos, que refleja solo el de mutaciones que se produjeron ese día: ocupa aproximadamente 1.5 veces más almacenamiento que los datos escritos ese día consumen en el disco.

Transferencia de datos de red

Si lees un flujo de cambios entre regiones, puedes incurrir en costos por ese tráfico. Consulta la sección Red en Precios de Bigtable para obtener una lista completa de las tasas de transferencia de datos de red.

Costos de procesamiento

Según cómo leas los registros de cambios en los datos, los costos adicionales por de Google Cloud que no sean Bigtable. Por ejemplo, si utilizas Dataflow, pagas por los bytes que se procesan y el trabajador máquinas que procesan el trabajo. Para obtener más información, consulta Precios de Dataflow.

Quitar rangos de filas

Si es posible, evita abandonar una fila rango de una tabla que tenga habilitado un flujo de cambios. Si debes descartar un rango de filas, saber que Bigtable podría tardar mucho tiempo en completar y el uso de CPU aumenta durante la operación.