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

Descripción general de las transmisiones de cambios

Bigtable proporciona la captura de datos modificados (CDC) con su función de flujos de cambios. Un flujo de cambios captura los cambios de datos en una tabla de Bigtable a medida que ocurren, lo que te permite transmitirlos para su procesamiento 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 la descripción general de Bigtable.

Los flujos de cambios son valiosos para los casos de uso de CDC, entre los que se incluyen los siguientes:

Activa la lógica de aplicación descendente cuando se producen cambios especificados
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 realiza un seguimiento de los cambios a nivel de tabla que realizan un usuario o una aplicación, por lo general, mediante una de las bibliotecas cliente de Cloud Bigtable. También se capturan los cambios en la recolección de elementos no utilizados.

Todos los cambios aplicados a una tabla habilitada para el flujo de cambios se almacenan como registros de cambios de datos. Los registros de cambios en los datos incluyen las modificaciones en los datos que aplica lo siguiente:

Escrituras, eliminaciones y actualizaciones que se envían mediante los métodos de la API de Cloud Bigtable MutateRow, MutateRows, CheckAndMutateRow y ReadModifyWriteRow
Eliminaciones 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 puedes enviar a una tabla de Bigtable, consulta Lecturas, Escrituras, Borraciones 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 una familia de columnas, o la topología de replicación, como agregar o quitar un clúster.

Los registros de cambios en los datos de cada clave de fila y cada clúster están en orden de marca de tiempo de confirmación. Sin embargo, no hay garantía de orden en los registros de cambios de datos para una clave de fila o un clúster diferentes.

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

Qué hay en un registro de cambios de datos

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

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

Un registro de cambio de datos recibe su marca de tiempo, denominada marca de tiempo de confirmación, al mismo tiempo que el cambio se aplica al primer clúster que lo recibe. Por ejemplo, considera una instancia con dos clústeres. Si envías una solicitud de escritura a la Tabla 1 del Clúster A, la marca de tiempo de confirmación del registro de cambio de datos se asigna cuando el Clúster A recibe la escritura, y el registro de cambios de datos del Clúster B para 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 elementos:
- 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
- La 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 en la que la 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 cuando se confirmó el cambio en la tabla
Desempate: un valor que permite que la aplicación que lee la transmisión use la política integrada de resolución de conflictos de Bigtable.
Token: La aplicación consumidora lo usa para reanudar la transmisión en caso de que se interrumpa.
Marca de agua estimada baja: tiempo estimado desde que la partición del registro alcanzó 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 de datos, consulta la referencia de la API para DataChange.

Almacenamiento de flujos de cambios

Una tabla y su flujo de cambios comparten los mismos recursos a nivel de clúster, incluidos los nodos y el almacenamiento. Como resultado, el almacenamiento de datos de flujos de cambios forma parte del almacenamiento de una tabla. En una instancia que usa la replicación, se almacena una copia de los datos de una transmisión de cambios en cada clúster de la instancia que contiene la tabla habilitada para el flujo de cambios.

El almacenamiento que se usa para los datos de flujos de cambios no se considera en la utilización total del almacenamiento (% del máximo). Como resultado, no necesitas agregar nodos para manejar el mayor almacenamiento que consumen los datos de flujos de cambios (aunque es posible que debas agregar nodos para obtener potencia de procesamiento adicional). Sin embargo, se te cobra por el almacenamiento que consuman los datos de tu flujo de cambios. Para obtener más información, consulta Consideraciones sobre el costo.

Cómo leer un flujo de cambios

A fin de leer (transmitir) una transmisión de cambios, debes usar un perfil de aplicación configurado para el 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 una sola fila.

La API de Cloud Bigtable (API de datos) proporciona métodos de flujo de cambios. Te recomendamos usar 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 Beam de Bigtable
biblioteca cliente de Java

Todas las opciones te permiten evitar la necesidad de hacer 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 proporcionadas por Google:

Conector de Beam de Bigtable

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

Conector de Bigtable Beam

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

biblioteca cliente de Java

Cliente de Cloud Bigtable para Java

Particiones

Para mantener una capacidad de procesamiento de lectura alta que coincide con una tasa alta de escritura o cambio, Bigtable divide un flujo de cambios en varias particiones que se pueden usar para leer el flujo de cambios en paralelo. Cada partición de flujo de cambios está asociada con una tablet. Las tablets son subsecciones de una tabla que se redistribuyen según sea necesario para ayudar a equilibrar la carga de trabajo de solicitudes de la tabla. Para obtener más información, 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 los cambios en las particiones debido a divisiones y combinaciones.

Marcas de agua

Una marca de agua es una marca de tiempo que estima qué tan recientemente una partición alcanzó la replicación en todos los clústeres. La marca de agua de la partición se actualiza de forma continua a medida que se produce la replicación, avanzando en el tiempo.

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

Marcas de agua para tablas replicadas

El estimatedLowWatermark (marca de agua baja) de una partición no avanza si la replicación no está completamente alcanzada para la partición. La marca de agua baja en todo el flujo (la más baja de todas las marcas de agua estimadas bajas en todo el nivel de partición) deja de avanzar si la marca de agua de alguna partición no avanza. Una marca de agua que dejó de avanzar se considera detenida. Cuando esto ocurre, si estás transmitiendo tu flujo de cambios en una canalización, la canalización se detiene.

Muchos factores pueden hacer que una o más marcas de agua a nivel de partición se detengan durante un período, incluidos los siguientes:

Sobrecargar un clúster con tráfico que provoca que la replicación se ubique en una o más particiones
Demoras en la red
No hay disponibilidad del clúster

El conector de Bigtable Beam se encarga de esto mediante la configuración de la marca de tiempo de salida en cero para todos los datos. Para obtener más información, consulta Cómo agrupar datos sin tiempos de eventos.

Supervisión

Para ayudarte a comprender cómo habilitar un flujo de cambios afecta la utilización de la CPU y el almacenamiento en una instancia que contiene tablas con flujos de cambios habilitados, proporcionamos dos métricas específicas del flujo de cambios. Puedes ver las métricas en la página de Bigtable Monitoring o con el paquete de herramientas de Cloud Monitoring.

Bytes que usan los registros del flujo de cambios (change_stream_log_used_bytes)
Uso de CPU por flujos de cambios ( usa cpu_load_by_app_profile_by_method_by_table)

Para obtener detalles sobre estas métricas, consulta Monitoring.

Consideraciones de costo

Habilitar un flujo de cambios en una tabla aumenta los costos de los nodos y el almacenamiento. En particular, es posible que incurras en más costos de almacenamiento.

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 que conlleva habilitar y procesar los registros de cambios en los datos.

Habilitar una transmisión de cambios puede aumentar el uso de CPU en aproximadamente un 10%, incluso antes de comenzar a procesarlo. Procesar una transmisión de cambios, como leerla con una canalización de Dataflow, puede aumentar el uso de CPU en alrededor de un 20% a un 30%, según el nivel de actividad de cambios y cómo se leen los datos de transmisión.

Almacenamiento

Se te cobran las tarifas de almacenamiento de Bigtable estándar para almacenar los registros de cambio de datos de tu tabla. También se te cobra por almacenar la tabla que se crea para hacer un seguimiento de los metadatos del flujo de cambios. El período de retención que especificas afecta de forma directa los costos de almacenamiento.

Como regla general, los registros de cambios de datos de un día, que reflejan solo las mutaciones que ocurrieron ese día, ocupan alrededor de 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 generar costos por ese tráfico. Consulta la sección Red en los 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, se aplican costos adicionales por servicios que no sean Bigtable. Por ejemplo, si usas Dataflow, pagas por los bytes que se procesan y las máquinas de trabajador que procesan el trabajo. Para obtener más detalles, consulta Precios de Dataflow.

Quitar rangos de filas

Si es posible, evita descartar un rango de filas en una tabla que tiene habilitado un flujo de cambios. Si debes descartar un rango de filas, ten en cuenta que Bigtable puede tardar mucho tiempo en completar la operación y que el uso de CPU aumenta durante la operación.