Transmitir actualizaciones de tablas con la captura de datos de cambios

La captura de datos de cambios (CDC) de BigQuery actualiza tus tablas de BigQuery procesando y aplicando los cambios transmitidos a los datos. Esta sincronización se lleva a cabo mediante operaciones de inserción y eliminación de filas que se transmiten en tiempo real a través de la API Storage Write de BigQuery, que debes conocer antes de continuar.

Antes de empezar

Concede roles de Gestión de Identidades y Accesos (IAM) que proporcionen a los usuarios los permisos necesarios para realizar cada tarea de este documento y asegúrate de que tu flujo de trabajo cumpla todos los requisitos previos.

Permisos obligatorios

Para obtener el permiso que necesitas para usar la API Storage Write, pide a tu administrador que te asigne el rol de gestión de identidades y accesos Editor de datos de BigQuery (roles/bigquery.dataEditor). Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Este rol predefinido contiene el permiso bigquery.tables.updateData, que es necesario para usar la API Storage Write.

También puedes obtener este permiso con roles personalizados u otros roles predefinidos.

Para obtener más información sobre los roles y permisos de gestión de identidades y accesos en BigQuery, consulta la introducción a la gestión de identidades y accesos.

Requisitos previos

Para usar la CDC de BigQuery, tu flujo de trabajo debe cumplir las siguientes condiciones:

  • Debes usar la API Storage Write en el flujo predeterminado.
  • Debe usar el formato protobuf como formato de ingestión. No se admite el formato Apache Arrow.
  • Debe declarar las claves principales de la tabla de destino en BigQuery. Se admiten claves primarias compuestas que contengan hasta 16 columnas.
  • Deben estar disponibles suficientes recursos de computación de BigQuery para realizar las operaciones de filas de CDC. Ten en cuenta que, si fallan las operaciones de modificación de filas de CDC, es posible que conserves datos que querías eliminar. Para obtener más información, consulta Consideraciones sobre los datos eliminados.

Especificar cambios en registros

En la CDC de BigQuery, la pseudocolumna _CHANGE_TYPE indica el tipo de cambio que se va a procesar en cada fila. Para usar CDC, defina _CHANGE_TYPE cuando transmita las modificaciones de las filas mediante la API Storage Write. La pseudocolumna _CHANGE_TYPE solo acepta los valores UPSERT y DELETE. Una tabla se considera habilitada para CDC mientras la API Storage Write transmite las modificaciones de las filas a la tabla de esta forma.

Ejemplo con valores UPSERT y DELETE

Supongamos que tiene la siguiente tabla en BigQuery:

ID Nombre Salario
100 Charlie 2000
101 Tal 3000
102 Lee 5000

La API Storage Write transmite las siguientes modificaciones de filas:

ID Nombre Salario _CHANGE_TYPE
100 ELIMINAR
101 Tal 8000 UPSERT
105 Izumi 6000 UPSERT

La tabla actualizada es la siguiente:

ID Nombre Salario
101 Tal 8000
102 Lee 5000
105 Izumi 6000

Gestionar la antigüedad de las tablas

De forma predeterminada, cada vez que ejecutas una consulta, BigQuery devuelve los resultados más recientes. Para proporcionar los resultados más recientes al consultar una tabla habilitada para CDC, BigQuery debe aplicar cada modificación de fila transmitida hasta la hora de inicio de la consulta, de modo que se consulte la versión más actualizada de la tabla. Aplicar estas modificaciones de filas en el tiempo de ejecución de la consulta aumenta la latencia y el coste de la consulta. Sin embargo, si no necesitas que los resultados de las consultas estén totalmente actualizados, puedes reducir el coste y la latencia de las consultas configurando la opción max_staleness en tu tabla. Cuando se define esta opción, BigQuery aplica las modificaciones de las filas al menos una vez en el intervalo definido por el valor de max_staleness, lo que te permite ejecutar consultas sin esperar a que se apliquen las actualizaciones, pero a costa de que los datos estén algo obsoletos.

Este comportamiento es especialmente útil en los paneles de control y los informes en los que no es esencial que los datos estén actualizados. También es útil para gestionar los costes, ya que te permite controlar con más frecuencia la forma en que BigQuery aplica las modificaciones de las filas.

Consultar tablas con la opción max_staleness definida

Cuando consultas una tabla con la opción max_staleness definida, BigQuery devuelve el resultado en función del valor de max_staleness y de la hora en la que se produjo la última tarea de aplicación, que se representa mediante la marca de tiempo upsert_stream_apply_watermark de la tabla.

Veamos el siguiente ejemplo, en el que una tabla tiene la opción max_staleness configurada en 10 minutos y el último trabajo de aplicación se produjo a las 20:

El tiempo de ejecución de la consulta se produce dentro del intervalo de tiempo máximo de obsolescencia de los datos.

Si consultas la tabla en T25, la versión actual de la tabla tendrá una antigüedad de 5 minutos, que es inferior al intervalo max_staleness de 10 minutos. En este caso, BigQuery devuelve la versión de la tabla en T20, lo que significa que los datos devueltos también tienen 5 minutos de antigüedad.

Cuando activas la opción max_staleness en una tabla, BigQuery aplica las modificaciones de filas pendientes al menos una vez en el intervalo max_staleness. Sin embargo, en algunos casos, es posible que BigQuery no complete el proceso de aplicación de estas modificaciones de filas pendientes en el intervalo.

Por ejemplo, si consultas la tabla en T35 y el proceso de aplicación de las modificaciones de filas pendientes no se ha completado, la versión actual de la tabla tendrá una antigüedad de 15 minutos, que es superior al intervalo max_staleness de 10 minutos. En este caso, en el tiempo de ejecución de la consulta, BigQuery aplica todas las modificaciones de las filas entre T20 y T35 a la consulta actual, lo que significa que los datos consultados están completamente actualizados, pero a costa de una latencia de consulta adicional. Se considera un trabajo de combinación en tiempo de ejecución.

El tiempo de ejecución de la consulta se produce fuera del intervalo de tiempo máximo de obsolescencia de los datos.

El valor max_staleness de una tabla suele ser el mayor de los dos valores siguientes:

  • El tiempo máximo que pueden llevar sin actualizarse los datos de tu flujo de trabajo.
  • El doble del tiempo máximo que se tarda en aplicar los cambios insertados o actualizados en tu tabla, más un margen adicional.

Para calcular el tiempo que se tarda en aplicar los cambios insertados o actualizados en una tabla, usa la siguiente consulta de SQL para determinar el percentil 95 de la duración de las tareas de aplicación en segundo plano, más un margen de siete minutos para permitir la conversión del almacenamiento optimizado para escritura de BigQuery (búfer de streaming).

SELECT
  project_id,
  destination_table.dataset_id,
  destination_table.table_id,
  APPROX_QUANTILES((TIMESTAMP_DIFF(end_time, creation_time,MILLISECOND)/1000), 100)[OFFSET(95)] AS p95_background_apply_duration_in_seconds,
  CEILING(APPROX_QUANTILES((TIMESTAMP_DIFF(end_time, creation_time,MILLISECOND)/1000), 100)[OFFSET(95)]*2/60)+7 AS recommended_max_staleness_with_buffer_in_minutes
FROM `region-REGION`.INFORMATION_SCHEMA.JOBS AS job
WHERE
  project_id = 'PROJECT_ID'
  AND DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
  AND job_id LIKE "%cdc_background%"
GROUP BY 1,2,3;

Haz los cambios siguientes:

  • REGION: el nombre de la región en la que se encuentra tu proyecto. Por ejemplo, us.
  • PROJECT_ID: el ID del proyecto que contiene las tablas de BigQuery que está modificando la función CDC de BigQuery.

La duración de los trabajos de aplicación en segundo plano se ve afectada por varios factores, como el número y la complejidad de las operaciones de CDC emitidas en el intervalo de obsolescencia, el tamaño de la tabla y la disponibilidad de recursos de BigQuery. Para obtener más información sobre la disponibilidad de recursos, consulta Tamaño y monitorización de las reservas de BACKGROUND.

Crear una tabla con la opción max_staleness

Para crear una tabla con la opción max_staleness, usa la declaración CREATE TABLE. En el siguiente ejemplo se crea la tabla employees con un límite de max_staleness de 10 minutos:

CREATE TABLE employees (
  id INT64 PRIMARY KEY NOT ENFORCED,
  name STRING)
  CLUSTER BY
    id
  OPTIONS (
    max_staleness = INTERVAL 10 MINUTE);

Modificar la opción max_staleness de una tabla

Para añadir o modificar un límite max_staleness en una tabla, usa la declaración ALTER TABLE. En el siguiente ejemplo se cambia el límite de max_staleness de la tabla employees a 15 minutos:

ALTER TABLE employees
SET OPTIONS (
  max_staleness = INTERVAL 15 MINUTE);

Determinar el valor max_staleness actual de una tabla

Para determinar el valor max_staleness actual de una tabla, consulta la vista INFORMATION_SCHEMA.TABLE_OPTIONS. En el siguiente ejemplo se comprueba el valor max_staleness actual de la tabla mytable:

SELECT
  option_name,
  option_value
FROM
  DATASET_NAME.INFORMATION_SCHEMA.TABLE_OPTIONS
WHERE
  option_name = 'max_staleness'
  AND table_name = 'TABLE_NAME';

Haz los cambios siguientes:

  • DATASET_NAME: el nombre del conjunto de datos en el que se encuentra la tabla habilitada para CDC.
  • TABLE_NAME: el nombre de la tabla habilitada para CDC.

Los resultados muestran que el valor de max_staleness es de 10 minutos:

+---------------------+--------------+
| Row |  option_name  | option_value |
+---------------------+--------------+
|  1  | max_staleness | 0-0 0 0:10:0 |
+---------------------+--------------+

Monitorizar el progreso de la operación de inserción o actualización de una tabla

Para monitorizar el estado de una tabla y comprobar cuándo se aplicaron por última vez las modificaciones de las filas, consulta la vista INFORMATION_SCHEMA.TABLES para obtener la marca de tiempo upsert_stream_apply_watermark.

En el siguiente ejemplo se comprueba el valor upsert_stream_apply_watermark de la tabla mytable:

SELECT upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES
WHERE table_name = 'TABLE_NAME';

Haz los cambios siguientes:

  • DATASET_NAME: el nombre del conjunto de datos en el que se encuentra la tabla habilitada para CDC.
  • TABLE_NAME: el nombre de la tabla habilitada para CDC.

El resultado es similar al siguiente:

[{
 "upsert_stream_apply_watermark": "2022-09-15T04:17:19.909Z"
}]

Las operaciones de inserción y actualización se realizan mediante la cuenta de servicio bigquery-adminbot@system.gserviceaccount.com y aparecen en el historial de trabajos del proyecto que contiene la tabla con CDC habilitado.

Gestionar el orden personalizado

Cuando se insertan o actualizan datos en BigQuery mediante streaming, el comportamiento predeterminado de ordenación de los registros con claves primarias idénticas se determina en función de la hora del sistema de BigQuery en la que se ingirió el registro en BigQuery. Es decir, el registro insertado más recientemente con la marca de tiempo más reciente tiene prioridad sobre el registro insertado anteriormente con una marca de tiempo anterior. En algunos casos prácticos, como aquellos en los que se pueden producir inserciones y actualizaciones muy frecuentes en la misma clave principal en un periodo muy breve o en los que no se garantiza el orden de las inserciones y actualizaciones, puede que no sea suficiente. En estos casos, puede que sea necesaria una clave de ordenación proporcionada por el usuario.

Para configurar las claves de ordenación proporcionadas por el usuario, se usa la pseudocolumna _CHANGE_SEQUENCE_NUMBER para indicar el orden en el que BigQuery debe aplicar los registros, en función del valor _CHANGE_SEQUENCE_NUMBER más grande entre dos registros coincidentes con la misma clave principal. La pseudocolumna _CHANGE_SEQUENCE_NUMBER es opcional y solo acepta valores en un formato fijo STRING.

Formato _CHANGE_SEQUENCE_NUMBER

La pseudocolumna _CHANGE_SEQUENCE_NUMBER solo acepta valores STRING escritos en un formato fijo. Este formato fijo usa valores STRING escritos en hexadecimal, separados en secciones por una barra diagonal /. Cada sección puede expresarse con un máximo de 16 caracteres hexadecimales y se permiten hasta cuatro secciones por _CHANGE_SEQUENCE_NUMBER. El intervalo permitido de _CHANGE_SEQUENCE_NUMBER admite valores entre 0/0/0/0 y FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF/FFFFFFFFFFFFFFFF. Los valores de _CHANGE_SEQUENCE_NUMBER admiten caracteres en mayúsculas y minúsculas.

Para expresar las claves de ordenación básicas, se puede usar una sola sección. Por ejemplo, para ordenar las claves únicamente en función de la marca de tiempo de procesamiento de un registro de un servidor de aplicaciones, puedes usar una sección: '2024-04-30 11:19:44 UTC', expresada en hexadecimal convirtiendo la marca de tiempo a milisegundos desde Epoch, '18F2EBB6480' en este caso. La lógica para convertir datos en hexadecimal es responsabilidad del cliente que envía la escritura a BigQuery mediante la API Storage Write.

Al admitir varias secciones, puedes combinar varios valores de lógica de procesamiento en una clave para casos prácticos más complejos. Por ejemplo, para ordenar las claves en función de la marca de tiempo de procesamiento de un registro de un servidor de aplicaciones, un número de secuencia de registro y el estado del registro, puedes usar tres secciones: '2024-04-30 11:19:44 UTC' / '123' / 'complete', cada una expresada en hexadecimal. El orden de las secciones es un factor importante para clasificar la lógica de procesamiento. BigQuery compara los valores _CHANGE_SEQUENCE_NUMBER comparando la primera sección y, a continuación, comparando la siguiente sección solo si las secciones anteriores eran iguales.

BigQuery usa _CHANGE_SEQUENCE_NUMBER para ordenar los resultados comparando dos o más campos _CHANGE_SEQUENCE_NUMBER como valores numéricos sin signo.

Consulta los siguientes ejemplos de comparación _CHANGE_SEQUENCE_NUMBER y sus resultados de precedencia:

  • Ejemplo 1:

    • Registro 1: _CHANGE_SEQUENCE_NUMBER = '77'
    • Registro 2: _CHANGE_SEQUENCE_NUMBER = '7B'

    Resultado: El registro n.º 2 se considera el más reciente porque "7B" > "77" (es decir, "123" > "119").

  • Ejemplo 2:

    • Registro 1: _CHANGE_SEQUENCE_NUMBER = 'FFF/B'
    • Registro 2: _CHANGE_SEQUENCE_NUMBER = 'FFF/ABC'

    Resultado: El registro n.º 2 se considera el más reciente porque "FFF/ABC" > "FFF/B" (es decir, "4095/2748" > "4095/11").

  • Ejemplo 3:

    • Registro 1: _CHANGE_SEQUENCE_NUMBER = 'BA/FFFFFFFF'
    • Registro 2: _CHANGE_SEQUENCE_NUMBER = 'ABC'

    Resultado: el registro n.º 2 se considera el más reciente porque "ABC" > "BA/FFFFFFFF" (es decir, "2748" > "186/4294967295")

  • Ejemplo 4:

    • Registro 1: _CHANGE_SEQUENCE_NUMBER = 'FFF/ABC'
    • Registro 2: _CHANGE_SEQUENCE_NUMBER = 'ABC'

    Resultado: El registro n.º 1 se considera el más reciente porque "FFF/ABC" > "ABC" (es decir, "4095/2748" > "2748").

Si dos valores de _CHANGE_SEQUENCE_NUMBER son idénticos, el registro con la hora de ingestión del sistema de BigQuery más reciente tiene prioridad sobre los registros ingeridos anteriormente.

Cuando se usa el orden personalizado en una tabla, siempre se debe proporcionar el valor _CHANGE_SEQUENCE_NUMBER. Las solicitudes de escritura que no especifiquen el valor de _CHANGE_SEQUENCE_NUMBER, lo que provoca una mezcla de filas con y sin valores de _CHANGE_SEQUENCE_NUMBER, dan como resultado un orden impredecible.

Configurar una reserva de BigQuery para usarla con CDC

Puedes usar las reservas de BigQuery para asignar recursos de computación de BigQuery específicos a las operaciones de modificación de filas de CDC. Las reservas te permiten fijar un límite en el coste de realizar estas operaciones. Este enfoque es especialmente útil en flujos de trabajo con operaciones de CDC frecuentes en tablas grandes, que de lo contrario tendrían costes bajo demanda elevados debido al gran número de bytes procesados al realizar cada operación.

Las tareas de CDC de BigQuery que aplican modificaciones de filas pendientes en el intervalo max_staleness se consideran tareas en segundo plano y usan el tipo de asignación BACKGROUND, en lugar del tipo de asignación QUERY. Por el contrario, las consultas que se realizan fuera del intervalo max_staleness y que requieren que se apliquen modificaciones de filas en el tiempo de ejecución de la consulta usan el tipo de asignación QUERY. Las tablas sin el ajuste max_staleness o con el ajuste max_staleness definido como 0 también usan el tipo de asignación QUERY. Las tareas en segundo plano de CDC de BigQuery que se realizan sin una asignación de BACKGROUND usan los precios bajo demanda. Es importante tener en cuenta este aspecto al diseñar tu estrategia de gestión de cargas de trabajo para la CDC de BigQuery.

Para configurar una reserva de BigQuery que se pueda usar con CDC, empieza por configurar una reserva en la región en la que se encuentren tus tablas de BigQuery. Para obtener información sobre el tamaño de tu reserva, consulta Tamaño y monitorización de reservas de BACKGROUND. Una vez que haya creado una reserva, asigne el proyecto de BigQuery a la reserva y defina la opción job_type en BACKGROUND ejecutando la siguiente sentencia CREATE ASSIGNMENT:

CREATE ASSIGNMENT
  `ADMIN_PROJECT_ID.region-REGION.RESERVATION_NAME.ASSIGNMENT_ID`
OPTIONS (
  assignee = 'projects/PROJECT_ID',
  job_type = 'BACKGROUND');

Haz los cambios siguientes:

  • ADMIN_PROJECT_ID: el ID del proyecto de administración que tiene la reserva.
  • REGION: el nombre de la región en la que se encuentra tu proyecto. Por ejemplo, us.
  • RESERVATION_NAME: el nombre de la reserva.
  • ASSIGNMENT_ID: el ID de la tarea. El ID debe ser único para el proyecto y la ubicación, empezar y terminar con una letra minúscula o un número, y solo puede contener letras minúsculas, números y guiones.
  • PROJECT_ID: el ID del proyecto que contiene las tablas de BigQuery que se están modificando con la CDC de BigQuery. Este proyecto está asignado a la reserva.

Consultar y monitorizar las reservas de BACKGROUND

Las reservas determinan la cantidad de recursos de computación disponibles para realizar operaciones de computación de BigQuery. Si una reserva es demasiado pequeña, puede aumentar el tiempo de procesamiento de las operaciones de modificación de filas de CDC. Para dimensionar una reserva con precisión, monitoriza el consumo histórico de ranuras del proyecto que realiza las operaciones de CDC consultando la vista INFORMATION_SCHEMA.JOBS_TIMELINE:

SELECT
  period_start,
  SUM(period_slot_ms) / (1000 * 60) AS slots_used
FROM
  region-REGION.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE
  DATE(job_creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
  AND CURRENT_DATE()
  AND job_id LIKE '%cdc_background%'
GROUP BY
  period_start
ORDER BY
  period_start DESC;

Sustituye REGION por el nombre de la región en la que se encuentra tu proyecto. Por ejemplo, us.

Consideraciones sobre los datos eliminados

  • Las operaciones de CDC de BigQuery usan recursos de computación de BigQuery. Si las operaciones de CDC se configuran para usar la facturación bajo demanda, se realizan periódicamente con recursos internos de BigQuery. Si las operaciones de CDC se configuran con una BACKGROUND reserva, se sujetarán a la disponibilidad de recursos de la reserva configurada. Si no hay suficientes recursos disponibles en la reserva configurada, el procesamiento de las operaciones de CDC, incluida la eliminación, puede tardar más de lo previsto.
  • Una operación de CDC DELETE se considera aplicada solo cuando la marca de tiempo upsert_stream_apply_watermark ha superado la marca de tiempo en la que la API Storage Write ha transmitido la operación. Para obtener más información sobre la marca de tiempo upsert_stream_apply_watermark, consulta Monitorizar el progreso de las operaciones de inserción y actualización de tablas.
  • Para aplicar operaciones de CDC DELETE que llegan desordenadas, BigQuery mantiene una ventana de retención de eliminaciones de dos días. Las operaciones de la tabla DELETE se almacenan durante este periodo antes de que empiece el Google Cloud proceso de eliminación de datos estándar. Las operaciones DELETE que se realicen durante el periodo de conservación de las eliminaciones se facturarán según los precios de almacenamiento de BigQuery estándar.

Limitaciones

  • BigQuery CDC no aplica claves, por lo que es fundamental que tus claves principales sean únicas.
  • Las claves principales no pueden superar las 16 columnas.
  • Las tablas habilitadas para CDC no pueden tener más de 2000 columnas de nivel superior definidas por el esquema de la tabla.
  • Las tablas habilitadas para CDC no admiten lo siguiente:
  • Las tablas habilitadas para CDC que realizan trabajos de combinación en tiempo de ejecución porque el valor de max_staleness de la tabla es demasiado bajo no pueden admitir lo siguiente:
  • Las operaciones de exportación de BigQuery en tablas habilitadas para CDC no exportan las modificaciones de filas transmitidas recientemente que aún no se han aplicado mediante una tarea en segundo plano. Para exportar la tabla completa, usa una declaración EXPORT DATA.
  • Si tu consulta activa una combinación en tiempo de ejecución en una tabla particionada, se analizará toda la tabla, independientemente de si la consulta se limita a un subconjunto de las particiones.
  • Si usas la edición Estándar, las reservas BACKGROUNDno están disponibles, por lo que, para aplicar las modificaciones pendientes de las filas, se usa el modelo de precios bajo demanda. Sin embargo, puedes consultar tablas habilitadas para CDC independientemente de tu edición.
  • Las pseudocolumnas _CHANGE_TYPE y _CHANGE_SEQUENCE_NUMBER no se pueden consultar cuando se lee una tabla.
  • No se admite la combinación de filas que tengan los valores UPSERT o DELETE en el campo _CHANGE_TYPE con filas que tengan los valores INSERT o sin especificar en el campo _CHANGE_TYPE en la misma conexión, lo que provoca el siguiente error de validación: The given value is not a valid CHANGE_TYPE.

Precios de CDC de BigQuery

La función CDC de BigQuery usa la API Storage Write para la ingestión de datos, el almacenamiento de BigQuery para el almacenamiento de datos y los recursos de computación de BigQuery para las operaciones de modificación de filas, todo lo cual genera costes. Para obtener información sobre los precios, consulta los precios de BigQuery.

Estimar los costes de CDC de BigQuery

Además de las prácticas recomendadas generales para estimar los costes de BigQuery, puede ser importante estimar los costes de la CDC de BigQuery en flujos de trabajo que tengan grandes cantidades de datos, una configuración max_staleness baja o datos que cambien con frecuencia.

Los precios de ingestión de datos de BigQuery y los precios de almacenamiento de BigQuery se calculan directamente en función de la cantidad de datos que ingieres y almacenas, incluidas las pseudocolumnas. Sin embargo, los precios de computación de BigQuery pueden ser más difíciles de estimar, ya que están relacionados con el consumo de recursos de computación que se usan para ejecutar tareas de CDC de BigQuery.

Los trabajos de CDC de BigQuery se dividen en tres categorías:

  • Tareas de aplicación en segundo plano: tareas que se ejecutan en segundo plano a intervalos regulares definidos por el valor max_staleness de la tabla. Estos trabajos aplican las modificaciones de las filas transmitidas recientemente a la tabla habilitada para CDC.
  • Consultar trabajos: consultas de GoogleSQL que se ejecutan en la ventana max_staleness y solo leen de la tabla de referencia de CDC.
  • Tareas de combinación de tiempo de ejecución: tareas que se activan mediante consultas de GoogleSQL ad hoc que se ejecutan fuera de la ventana max_staleness. Estos trabajos deben combinar sobre la marcha la tabla de referencia de CDC y las modificaciones de las filas transmitidas recientemente en el tiempo de ejecución de la consulta.

Solo las tareas de consulta aprovechan las particiones de BigQuery. Los trabajos de aplicación en segundo plano y los trabajos de combinación en tiempo de ejecución no pueden usar particiones porque, al aplicar las modificaciones de las filas transmitidas recientemente, no se puede garantizar a qué partición de la tabla se aplican las inserciones y actualizaciones transmitidas recientemente. Es decir, la tabla de referencia completa se lee durante los trabajos de aplicación en segundo plano y los trabajos de combinación en tiempo de ejecución. Por el mismo motivo, solo las tareas de consulta pueden beneficiarse de los filtros de las columnas de agrupación en clústeres de BigQuery. Conocer la cantidad de datos que se leen para realizar operaciones de CDC ayuda a estimar el coste total.

Si la cantidad de datos que se leen de la línea de base de la tabla es alta, considera la posibilidad de usar el modelo de precios por capacidad de BigQuery, que no se basa en la cantidad de datos procesados.

Prácticas recomendadas para optimizar los costes de CDC de BigQuery

Además de las prácticas recomendadas generales para optimizar los costes de BigQuery, usa las siguientes técnicas para optimizar los costes de las operaciones de CDC de BigQuery:

  • A menos que sea necesario, no configure la opción max_staleness de una tabla con un valor muy bajo. El valor max_staleness puede aumentar la frecuencia de las tareas de aplicación en segundo plano y de las tareas de combinación en tiempo de ejecución, que son más caras y lentas que las tareas de consulta. Para obtener instrucciones detalladas, consulta Valor recomendado de max_staleness.
  • Plantéate configurar una reserva de BigQuery para usarla con tablas de CDC. De lo contrario, las tareas de aplicación en segundo plano y las tareas de combinación en el tiempo de ejecución usarán los precios bajo demanda, lo que puede resultar más caro debido al mayor procesamiento de datos. Para obtener más información, consulta Reservas de BigQuery y sigue las instrucciones sobre cómo dimensionar y monitorizar una reserva de BACKGROUND para usarla con la función de CDC de BigQuery.

Siguientes pasos