Descripción general de los flujos de cambios

Bigtable ofrece la captura de datos de cambios (CDC) con su función flujos de cambios. Un flujo de cambios captura los cambios de datos de una tabla de Bigtable a medida que se producen, lo que te permite transmitirlos para procesarlos o analizarlos.

En este documento se ofrece 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 útiles en casos prácticos de CDC, como los siguientes:

  • Activar la lógica de la aplicación de nivel inferior cuando se produzcan los cambios especificados
  • Integración con un flujo de procesamiento de analíticas de datos
  • Cumplir los requisitos de auditoría y archivo

Qué es un flujo de cambios

Un flujo de cambios monitoriza los cambios que se realizan a nivel de tabla por un usuario o una aplicación, normalmente mediante una de las bibliotecas de cliente de Cloud Bigtable. También se registran los cambios en la recogida 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 de datos incluyen los cambios de datos aplicados por lo siguiente:

  • Escrituras, eliminaciones y actualizaciones que se envían mediante los métodos de la API Cloud Bigtable MutateRow, MutateRows, CheckAndMutateRow y ReadModifyWriteRow
  • Eliminaciones que se producen debido a la recolección de elementos no utilizados
  • Filas eliminadas mediante el método DropRowRange de las APIs Admin

Para obtener información sobre los tipos de cambios que puedes enviar a una tabla de Bigtable, consulta Lecturas, Escrituras, Eliminaciones y Descripción general de la recogida de elementos no utilizados.

Los flujos de cambios no monitorizan los cambios de esquema, como añadir o modificar una familia de columnas, ni la topología de replicación, como añadir o quitar un clúster.

Los registros de cambios de datos de cada clave de fila y cada clúster están ordenados por la marca de tiempo de confirmación. Sin embargo, no se garantiza el orden de los registros de cambios de datos de una clave de fila o un clúster diferentes.

Habilita los flujos de cambios en una tabla y especifica un periodo de conservación de entre 1 y 7 días.

Qué se incluye en un registro de cambios de datos

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

Si se sobrescribe 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 antiguo.

Un registro de cambios de datos recibe su marca de tiempo, llamada marca de tiempo de confirmación, al mismo tiempo que el cambio se aplica al primer clúster que lo recibe. Por ejemplo, supongamos que tiene 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 cambios de datos se asigna cuando el clúster A recibe la escritura, y el registro de cambios de datos del clúster B de esta escritura tiene la misma marca de tiempo de confirmación.

Cada registro de cambio de datos contiene lo siguiente:

  • Entradas: cambios realizados en la fila, incluidos uno o varios de los siguientes:
    • Escribe
      • Familia de columnas
      • Calificador de columna
      • Marca de tiempo
      • Valor
    • Eliminación de celdas
      • Familia de columnas
      • Calificador de columna
      • Intervalo de marcas 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 en la que la fila tenga datos.
  • Clave de fila: el identificador de la fila modificada.
  • Tipo de cambio: iniciado por el usuario o por la recogida de elementos no utilizados
  • ID del clúster que ha recibido el cambio
  • Marca de tiempo de confirmación: hora del lado del servidor en la que se confirmó el cambio en la tabla.
  • Desempate: valor que permite que la aplicación que lee el flujo use la política de resolución de conflictos integrada de Bigtable.
  • Token: lo usa la aplicación que consume el contenido para reanudar la emisión si se interrumpe.
  • Marca de agua mínima estimada: tiempo estimado transcurrido desde que la partición del registro se ha puesto al día con la replicación en todos los clústeres. Para obtener más información, consulta las secciones 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 de DataChange.

Cambiar el almacenamiento de la emisión

Una tabla y su flujo de cambios comparten los mismos recursos a nivel de clúster, incluidos los nodos y el almacenamiento. Por lo tanto, el almacenamiento de datos de la secuencia 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 un flujo de cambios en cada clúster de la instancia que contiene la tabla con el flujo de cambios habilitado.

El almacenamiento que se utiliza para los datos de tu flujo de cambios no se tiene en cuenta en el porcentaje máximo de almacenamiento total utilizado. Por lo tanto, no es necesario que añada nodos para gestionar el aumento del almacenamiento que consumen los datos del flujo de cambios (aunque puede que tenga que añadir nodos para obtener más potencia de computación). Sin embargo, se te cobra por el almacenamiento que consumen los datos de tu flujo de cambios. Para obtener más información, consulta la sección Consideraciones sobre los costes.

Leer un flujo de cambios

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

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

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

La API Cloud Bigtable (API de datos) 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 de cliente o un conector:

  • Plantillas de Dataflow
  • Conector de Bigtable para Beam
  • Biblioteca de cliente Java

Todas las opciones te permiten evitar tener que monitorizar y gestionar los cambios de partición debidos a 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 Bigtable para Beam

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

Si no quieres crear tu propia canalización, puedes usar los ejemplos de código del tutorial o la guía de inicio rápido de Bigtable como punto de partida para tu código:

Biblioteca de cliente Java

Particiones

Para mantener un alto rendimiento de lectura que coincida con una alta tasa de escritura o de cambios, 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 a 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 las solicitudes de la tabla. Para obtener más información, consulta Balanceo de carga.

La biblioteca de cliente de Java te permite consultar cada partición para ver los cambios y proporciona la información necesaria para gestionar los cambios en las particiones debido a divisiones y fusiones.

Marcas de agua

Una marca de agua es una marca de tiempo que estima cuánto tiempo hace que una partición se ha puesto al día con la replicación en todos los clústeres. La marca de agua de la partición se actualiza continuamente a medida que se produce la replicación, avanzando en el tiempo.

Cada ChangeStreamMutation (registro de cambio de datos) incluye un campo estimatedLowWatermark, que es la marca de agua de la partición asociada al registro de cambio de datos. Esta estimatedLowWatermark es una estimación y no garantiza que no haya datos que aún no hayan llegado al flujo.

Marcas de agua en tablas replicadas

La estimatedLowWatermark (marca de agua mínima) de una partición no avanza si la replicación no se ha completado en la partición. La marca de agua mínima de todo el flujo, es decir, la más baja de todas las marcas de agua mínimas estimadas a nivel de partición, deja de avanzar si la marca de agua de alguna partición no se mueve. Una marca de agua que ha dejado 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.

Hay muchos factores que pueden provocar que una o varias marcas de agua a nivel de partición se detengan durante un periodo de tiempo, entre los que se incluyen los siguientes:

  • Sobrecargar un clúster con tráfico que provoque que la replicación se retrase en una o varias particiones
  • Retrasos de red
  • No disponibilidad del clúster

El conector de Bigtable Beam lo gestiona asignando la marca de tiempo de salida a cero para todos los datos. Para obtener más información, consulta Agrupar datos sin horas de evento.

Supervisión

Para ayudarte a entender cómo afecta la habilitación de un flujo de cambios al uso de CPU y almacenamiento de una instancia que contiene tablas con flujos de cambios habilitados, te proporcionamos dos métricas específicas de flujos de cambios. Puedes ver las métricas en la página Estadísticas del sistema de Bigtable o mediante el conjunto de herramientas de Cloud Monitoring.

Para obtener más información sobre estas métricas, consulta la sección Monitorización.

Consideraciones sobre el coste

Si habilitas un flujo de cambios en una tabla, aumentarán los costes de los nodos y del almacenamiento. En concreto, es probable que tengas que pagar más por el almacenamiento.

Nodos

Normalmente, tienes que añadir nodos a un clúster (o aumentar el número máximo de nodos si usas el autoescalado) para gestionar el tráfico adicional que supone habilitar y procesar los registros de cambios de datos.

Si habilitas un flujo de cambios, el uso de la CPU puede aumentar en torno a un 10%, incluso antes de que empieces a procesarlo. Procesar un flujo de cambios, como leerlo mediante una canalización de Dataflow, puede aumentar la utilización de la CPU entre un 20 y un 30%, en función del nivel de actividad de los cambios y de cómo se lean los datos del flujo.

Almacenamiento

Se te cobrarán las tarifas de almacenamiento de Bigtable estándar por almacenar los registros de cambios de datos de tu tabla. También se te cobrará por almacenar la tabla que se crea para hacer un seguimiento de los metadatos del flujo de cambios. El periodo de conservación que especifiques afecta directamente a los costes de almacenamiento.

Por lo general, los registros de cambios de datos de un día (que solo reflejan las mutaciones que se han producido ese día) ocupan aproximadamente 1,5 veces más espacio de almacenamiento que los datos que se han escrito ese día en el disco.

Transferencia de datos de red

Si lees un flujo de cambios en varias regiones, puedes incurrir en costes por ese tráfico. Consulta la sección Red de la página Precios de Bigtable para ver una lista completa de las tarifas de transferencia de datos por red.

Costes de procesamiento

En función de cómo leas los registros de cambios de datos, se aplicarán costes adicionales por servicios distintos de Bigtable. Por ejemplo, si usas Dataflow, pagas por los bytes que se procesan y por las máquinas de trabajo que procesan la tarea. Para obtener más información, consulta los precios de Dataflow.

Eliminar intervalos de filas

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

Siguientes pasos