Usa el ETL inverso para cargar datos de BigQuery en Spanner Graph

En este documento, se describe cómo usar canalizaciones inversas de extracción, transformación y carga (ETL) para transferir y sincronizar de forma continua datos de grafos de BigQuery a Spanner Graph. Abarca los siguientes aspectos clave:

Para usar el ETL inverso y exportar datos de BigQuery a Spanner, consulta Exporta datos a Spanner.

BigQuery realiza una manipulación de datos compleja a gran escala como plataforma de procesamiento analítico, mientras que Spanner está optimizado para casos de uso que requieren un QPS alto y una latencia de servicio baja. Spanner Graph y BigQuery se integran de manera eficaz para preparar datos de grafos en las canalizaciones de análisis de BigQuery, lo que permite que Spanner realice recorridos de grafos con baja latencia.

Antes de comenzar

  1. Crea una instancia de Spanner con una base de datos que contenga datos de gráficos. Para obtener más información, consulta Cómo configurar y consultar Spanner Graph.

  2. En BigQuery, crea una reserva de ranuras de nivel Enterprise o Enterprise Plus. Puedes reducir los costos de procesamiento de BigQuery cuando ejecutas exportaciones a Spanner Graph. Para ello, establece una capacidad de ranuras de referencia de cero y habilita el ajuste de escala automático.

  3. Otorga roles de Identity and Access Management (IAM) que les brindan a los usuarios los permisos necesarios para realizar cada tarea de este documento.

Roles obligatorios

Para obtener los permisos que necesitas para exportar los datos del gráfico de BigQuery a Spanner Graph, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto:

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

Casos de uso de ETL inverso

A continuación, se incluyen ejemplos de casos de uso. Después de analizar y procesar los datos en BigQuery, puedes transferirlos a Spanner Graph con ETL inversa.

Agregación y resumen de datos: Usa BigQuery para calcular agregaciones sobre datos detallados y hacerlos más adecuados para casos de uso operativos.

Transformación y enriquecimiento de datos: Usa BigQuery para limpiar y estandarizar los datos recibidos de diferentes fuentes de datos.

Filtrado y selección de datos: Usa BigQuery para filtrar un conjunto de datos grande con fines analíticos. Por ejemplo, puedes filtrar los datos que no se requieren para las aplicaciones en tiempo real.

Ingeniería y procesamiento previo de atributos: En BigQuery, usa la función ML.TRANSFORM para transformar datos o la función ML.FEATURE_CROSS para crear combinaciones de atributos de atributos de entrada. Luego, usa el ETL inverso para transferir los datos resultantes a Spanner Graph.

Información sobre la canalización de ETL inversa

Los datos se transfieren de BigQuery a Spanner Graph en una canalización de ETL inversa en dos pasos:

  1. BigQuery usa ranuras asignadas al trabajo de canalización para extraer y transformar los datos de origen.

  2. La canalización de ETL inversa de BigQuery usa las APIs de Spanner para cargar datos en una instancia de Spanner aprovisionada.

En el siguiente diagrama, se muestran los pasos de una canalización de ETL inversa:

Diagrama que muestra los tres pasos principales cuando los datos se transfieren de BigQuery a Spanner Graph en una canalización de ETL inversa.

Figura 1. Proceso de canalización de ETL inverso de BigQuery

Administra los cambios en los datos del gráfico

Puedes usar la ETL inversa para hacer lo siguiente:

  • Carga un conjunto de datos de grafos de BigQuery en Spanner Graph.

  • Sincroniza los datos de Spanner Graph con las actualizaciones en curso de un conjunto de datos en BigQuery.

Configuras una canalización de ETL inversa con una consulta en SQL para especificar los datos de origen y la transformación que se aplicará. La canalización carga todos los datos que satisfacen la cláusula WHERE de la instrucción SELECT en Spanner con una operación de upsert. Una operación de upsert es equivalente a las instrucciones INSERT OR UPDATE. Inserta filas nuevas y actualiza las existentes en las tablas que almacenan datos de gráficos. La canalización basa las filas nuevas y actualizadas en una clave primaria de la tabla de Spanner.

Inserta y actualiza datos para tablas con dependencias de orden de carga

Las prácticas recomendadas para el diseño de esquemas de Spanner Graph sugieren usar tablas intercaladas y claves externas. Si usas tablas intercaladas o claves externas aplicadas, debes cargar los datos de nodos y bordes en un orden específico. Esto garantiza que las filas a las que se hace referencia existan antes de que crees la fila que hace referencia. Para obtener más información, consulta Crea tablas intercaladas.

El siguiente ejemplo de esquema de tabla de entrada de grafo usa una tabla intercalada y una restricción de clave externa para modelar la relación entre una persona y sus cuentas:

CREATE TABLE Person (
  id    INT64 NOT NULL,
  name  STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE Account (
  id           INT64 NOT NULL,
  create_time  TIMESTAMP,
  is_blocked   BOOL,
  type        STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE PersonOwnAccount (
  id           INT64 NOT NULL,
  account_id   INT64 NOT NULL,
  create_time  TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Person,
    Account
  )
  EDGE TABLES (
    PersonOwnAccount
      SOURCE KEY (id) REFERENCES Person
      DESTINATION KEY (account_id) REFERENCES Account
      LABEL Owns
  );

En este esquema de ejemplo, PersonOwnAccount es una tabla intercalada en Person. Carga los elementos de la tabla Person antes que los de la tabla PersonOwnAccount. Además, la restricción de clave externa en PersonOwnAccount garantiza que exista una fila coincidente en Account, el destino de la relación de borde. Por lo tanto, carga la tabla Account antes de la tabla PersonOwnAccount. En la siguiente lista, se resumen las dependencias del orden de carga de este esquema:

Sigue estos pasos para cargar los datos:

  1. Carga Person antes de PersonOwnAccount.
  2. Carga Account antes de PersonOwnAccount.

Spanner aplica las restricciones de integridad referencial en el esquema de ejemplo. Si la canalización intenta crear una fila en la tabla PersonOwnAccount sin una fila coincidente en la tabla Person o en la tabla Account, Spanner devuelve un error. Luego, la canalización falla.

Esta canalización de ETL inversa de ejemplo usa sentencias EXPORTDATA en BigQuery para exportar datos de las tablas Person, Account y PersonOwnAccount de un conjunto de datos para cumplir con las dependencias del orden de carga:

BEGIN
EXPORT DATA OPTIONS (
    uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "Person",
      "priority": "HIGH",
      "tag" : "graph_data_load_person"
    }"""
  ) AS
  SELECT
    id,
    name
  FROM
    DATASET_NAME.Person;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "Account",
    "priority": "HIGH",
    "tag" : "graph_data_load_account"
  }"""
) AS
SELECT
  id,
  create_time,
  is_blocked,
  type
FROM
  DATASET_NAME.Account;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "PersonOwnAccount",
    "priority": "HIGH",
    "tag" : "graph_data_load_person_own_account"
  }"""
) AS
SELECT
  id,
  account_id,
  create_time
FROM
  DATASET_NAME.PersonOwnAccount;
END;

Sincroniza datos

Para sincronizar BigQuery con Spanner Graph, usa canalizaciones de ETL inversa. Puedes configurar una canalización para que realice una de las siguientes acciones:

  • Aplica las inserciones y actualizaciones de la fuente de BigQuery a la tabla de destino del gráfico de Spanner. Puedes agregar elementos de esquema a las tablas de destino para comunicar de forma lógica las eliminaciones y quitar las filas de las tablas de destino según un programa.

  • Usa una función de serie temporal que aplique operaciones de inserción y actualización, y que identifique las operaciones de eliminación.

Restricciones de integridad referencial

A diferencia de Spanner, BigQuery no aplica restricciones de clave externa y primarias. Si tus datos de BigQuery no cumplen con las restricciones que creas en tus tablas de Spanner, es posible que la canalización de ETL inversa falle cuando cargue esos datos.

El ETL inverso agrupa automáticamente los datos en lotes que no superan el límite máximo de mutaciones por confirmación y aplica los lotes de forma atómica a una tabla de Spanner en un orden arbitrario. Si un lote contiene datos que no superan una verificación de integridad referencial, Spanner no lo carga. Entre los ejemplos de estos errores, se incluyen una fila secundaria intercalada que carece de una fila principal o una columna de clave externa obligatoria sin un valor coincidente en la columna a la que se hace referencia. Si un lote no pasa una verificación, la canalización falla con un error y deja de cargar lotes.

Comprende los errores de restricción de integridad referencial

En los siguientes ejemplos, se muestran errores de restricción de integridad referencial que podrías encontrar:

Cómo resolver errores de restricción de clave externa

  • Error: "Se incumplió la restricción de clave externa FK_Account en la tabla PersonOwnAccount. No se pueden encontrar los valores a los que se hace referencia en Account(id)".

  • Causa: Falló la inserción de una fila en la tabla PersonOwnAccount porque falta una fila coincidente en la tabla Account, que requiere la clave externa FK_Account.

Cómo resolver errores de falta de filas principales

  • Error: "Falta la fila principal de la fila [15,1] en la tabla PersonOwnAccount"

  • Causa: Falló la inserción de una fila en PersonOwnAccount (id: 15 y account_id: 1) porque falta una fila principal en la tabla Person (id: 15).

Para reducir el riesgo de errores de integridad referencial, considera las siguientes opciones. Cada opción tiene sus ventajas y desventajas.

  • Relaja las restricciones para permitir que Spanner Graph cargue datos.
  • Agrega lógica a tu canalización para omitir las filas que incumplen las restricciones de integridad referencial.

Relaja la integridad referencial

Una opción para evitar errores de integridad referencial al cargar datos es relajar las restricciones para que Spanner no aplique la integridad referencial.

  • Puedes crear tablas intercaladas con la cláusula INTERLEAVE IN para usar las mismas características de intercalación de filas físicas. Si usas INTERLEAVE IN en lugar de INTERLEAVE IN PARENT, Spanner no aplica la integridad referencial, aunque las consultas se benefician de la ubicación conjunta de las tablas relacionadas.

  • Puedes crear claves externas informativas con la opción NOT ENFORCED. La opción NOT ENFORCED proporciona beneficios de optimización de consultas. Sin embargo, Spanner no aplica la integridad referencial.

Por ejemplo, para crear la tabla de entrada de aristas sin verificaciones de integridad referencial, puedes usar este DDL:

CREATE TABLE PersonOwnAccount (
  id          INT64 NOT NULL,
  account_id  INT64 NOT NULL,
  create_time TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) NOT ENFORCED
) PRIMARY KEY (id, account_id),
INTERLEAVE IN Person;

Respeta la integridad referencial en las canalizaciones de ETL inversa

Para garantizar que la canalización solo cargue las filas que satisfacen las verificaciones de integridad referencial, incluye solo las filas de PersonOwnAccount que tengan filas coincidentes en las tablas Person y Account. Luego, conserva el orden de carga para que Spanner cargue las filas de Person y Account antes de las filas de PersonOwnAccount que hacen referencia a ellas.

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_load_person_own_account"
    }"""
  ) AS
  SELECT
    poa.id,
    poa.account_id,
    poa.create_time
  FROM `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
    JOIN `PROJECT_ID.DATASET_NAME.Person` p ON (poa.id = p.id)
    JOIN `PROJECT_ID.DATASET_NAME.Account` a ON (poa.account_id = a.id)
  WHERE poa.id = p.id
    AND poa.account_id = a.id;

Borra elementos del gráfico

Las canalizaciones de ETL inversa usan operaciones de upsert. Dado que las operaciones de upsert son equivalentes a las instrucciones INSERT OR UPDATE, una canalización solo puede sincronizar las filas que existen en los datos de origen en el tiempo de ejecución. Esto significa que la canalización excluye las filas borradas. Si borras datos de BigQuery, una canalización de ETL inversa no puede quitar directamente los mismos datos del gráfico de Spanner.

Puedes usar una de las siguientes opciones para controlar las eliminaciones de las tablas de origen de BigQuery:

Realiza una eliminación lógica o no definitiva en la fuente.

Para marcar lógicamente las filas para su eliminación, usa una marca de eliminación en BigQuery. Luego, crea una columna en la tabla de Spanner de destino en la que puedas propagar la marca. Cuando el ETL inverso aplica las actualizaciones de la canalización, borra las filas que tienen esta marca en Spanner. Puedes encontrar y borrar esas filas de forma explícita con el DML particionado. Como alternativa, puedes borrar filas de forma implícita configurando una columna de TTL (tiempo de actividad) con una fecha que dependa de la columna de marcas de borrado. Escribe consultas de Spanner para excluir estas filas borradas de forma lógica. Esto garantiza que Spanner excluya estas filas de los resultados antes de la eliminación programada. Una vez que se completa la canalización de ETL inversa, Spanner refleja los borrados lógicos en sus filas. Luego, puedes borrar filas de BigQuery.

En este ejemplo, se agrega una columna is_deleted a la tabla PersonOwnAccount en Spanner. Luego, agrega una columna expired_ts_generated que depende del valor de is_deleted. La política de TTL programa la eliminación de las filas afectadas porque la fecha de la columna generada es anterior al umbral de DELETION POLICY.

ALTER TABLE PersonOwnAccount
  ADD COLUMN is_deleted BOOL DEFAULT (FALSE);

ALTER TABLE PersonOwnAccount ADD COLUMN
  expired_ts_generated TIMESTAMP AS (IF(is_deleted,
    TIMESTAMP("1970-01-01 00:00:00+00"),
    TIMESTAMP("9999-01-01 00:00:00+00"))) STORED HIDDEN;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts_generated, INTERVAL 0 DAY));

Usa el historial de cambios de BigQuery para las operaciones INSERT, UPDATE y de borrado lógico

Puedes hacer un seguimiento de los cambios en una tabla de BigQuery con su historial de cambios. Usa la función CHANGES de GoogleSQL para encontrar filas que cambiaron dentro de un intervalo de tiempo específico. Luego, usa la información de la fila borrada con una canalización de ETL inversa. Puedes configurar la canalización para establecer un indicador, como una marca de borrado o una fecha de vencimiento, en la tabla de Spanner. Este indicador marca las filas para su eliminación en las tablas de Spanner.

Usa los resultados de la función de series temporales CHANGES para decidir qué filas de la tabla de origen incluir en la carga de tu canalización de ETL inversa.

La canalización incluye filas con _CHANGE_TYPE como INSERT o UPDATE como inserciones si la fila existe en la tabla de origen. La fila actual de la tabla de origen proporciona los datos más recientes.

Usa filas con _CHANGE_TYPE como DELETE que no tengan filas existentes en la tabla de origen para establecer un indicador en la tabla de Spanner, como una marca de borrado o una fecha de vencimiento de la fila.

Tu consulta de exportación debe tener en cuenta el orden de las inserciones y eliminaciones en BigQuery. Por ejemplo, considera una fila borrada en el momento T1 y una fila nueva insertada en un momento posterior T2. Si ambos se asignan a la misma fila de la tabla de Spanner, la exportación debe conservar los efectos de estos eventos en su orden original.

Si se configura, el indicador delete marca las filas para su eliminación en las tablas de Spanner.

Por ejemplo, puedes agregar una columna a una tabla de entrada de Spanner para almacenar la fecha de vencimiento de cada fila. Luego, crea una política de eliminación que use estas fechas de vencimiento.

En el siguiente ejemplo, se muestra cómo agregar una columna para almacenar las fechas de vencimiento de las filas de la tabla.

ALTER TABLE PersonOwnAccount ADD COLUMN expired_ts TIMESTAMP;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts, INTERVAL 1 DAY));

Para usar la función CHANGES en una tabla de BigQuery, configura la opción enable_change_history de la tabla como TRUE:

ALTER TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`
  SET OPTIONS (enable_change_history=TRUE);

En el siguiente ejemplo, se muestra cómo puedes usar la ETL inversa para actualizar filas nuevas o modificadas, y establecer la fecha de vencimiento de las filas marcadas para su eliminación. Una unión izquierda con la tabla PersonOwnAccount proporciona a la consulta información sobre el estado actual de cada fila.

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_delete_via_reverse_etl"
    }"""
  ) AS
SELECT
  DISTINCT
   IF (changes._CHANGE_TYPE = 'DELETE', changes.id, poa.id) AS id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.account_id, poa.account_id) AS account_id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.create_time, poa.create_time) AS create_time,
   IF (changes._CHANGE_TYPE = 'DELETE', changes._CHANGE_TIMESTAMP, NULL) AS expired_ts
FROM
  CHANGES(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
    TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY), DAY),
    TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), DAY)) changes
LEFT JOIN `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
  ON (poa.id = changes.id
  AND poa.account_id = changes.account_id)
WHERE (changes._CHANGE_TYPE = 'DELETE'
   AND poa.id IS NULL)
   OR (changes._CHANGE_TYPE IN ( 'UPDATE', 'INSERT')
   AND poa.id IS NOT NULL );

La consulta de ejemplo usa un LEFT JOIN con la tabla de origen para conservar el orden. Esta unión garantiza que se ignoren los registros de cambios de DELETE para las filas borradas y, luego, recreadas dentro del intervalo del historial de cambios de la consulta. La canalización conserva la fila nueva y válida.

Cuando borras filas, la canalización completa la columna expired_ts en la fila correspondiente del gráfico de Spanner con la marca de tiempo DELETE de la columna _CHANGE_TIMESTAMP. Una política de eliminación de filas (política de TTL) en Spanner borra cualquier fila en la que el valor de expired_ts sea más de un día anterior.

Para garantizar la confiabilidad del sistema, coordina la programación de la canalización, el período de observación del cambio y la política de TTL de Spanner. Programa la canalización para que se ejecute a diario. La política de TTL de Spanner debe tener una duración mayor que este intervalo de ejecución. Esto evita que la canalización vuelva a procesar un evento DELETE anterior para una fila que ya quitó la política de TTL de Spanner.

En este ejemplo, se muestran los intervalos start_timestamp y end_timestamp para las consultas diarias que capturan todos los cambios en la tabla de BigQuery del día anterior en UTC. Dado que se trata de una consulta por lotes y la función CHANGES tiene limitaciones, el valor de end_timestamp debe ser al menos 10 minutos anterior a la hora actual. Por lo tanto, programa esta consulta para que se ejecute al menos 10 minutos después de la medianoche (UTC). Para obtener más detalles, consulta la documentación de CHANGES.

Usa columnas de TTL con la marca de tiempo de la última vez que se vio

Un canal de ETL inverso establece una columna last_seen_ts en la marca de tiempo actual para cada fila de la tabla de Spanner. Cuando borras filas de BigQuery, Spanner no actualiza las filas correspondientes y la columna last_seen_ts no cambia. Luego, Spanner quita las filas con un last_seen_ts desactualizado con una política de TTL o una DML particionada, según un umbral definido. Antes de la eliminación programada, las consultas de Spanner pueden filtrar las filas con un last_seen_ts anterior a este umbral. Este enfoque funciona de manera eficaz cuando los datos del gráfico se actualizan de forma rutinaria y las actualizaciones faltantes indican que los datos están desactualizados y deben borrarse.

Cómo realizar una actualización completa

Antes de cargar datos desde BigQuery, puedes borrar tablas de Spanner para reflejar los borrados en las tablas de origen. Esto evita que la canalización cargue en Spanner las filas borradas de las tablas de BigQuery de origen durante la próxima ejecución de la canalización. Esta podría ser la opción más fácil de implementar. Sin embargo, ten en cuenta el tiempo necesario para volver a cargar por completo tus datos de gráficos.

Mantener una canalización de ETL inversa por lotes programada

Después de la ejecución inicial de tu canalización de ETL inversa, que carga datos de forma masiva desde BigQuery en Spanner Graph, los datos del mundo real siguen cambiando. Los conjuntos de datos cambian, y la canalización agrega o quita elementos del grafo con el tiempo. La canalización descubre nodos nuevos y agrega nuevas relaciones de borde, o bien la inferencia de IA los genera.

Para garantizar que la base de datos de Spanner Graph se mantenga actualizada, programa y secuencia la orquestación de la canalización de BigQuery con una de las siguientes opciones:

BigQuery Pipelines te permite desarrollar, probar, controlar versiones y también implementar flujos de trabajo complejos de transformación de datos en SQL en BigQuery. Maneja de forma nativa las dependencias de orden, ya que te permite definir relaciones entre las consultas de tu canalización. Dataform crea un árbol de dependencias y ejecuta tus consultas en el orden correcto. Esto garantiza que las dependencias upstream se completen antes de que comiencen las tareas downstream.

Los flujos de trabajo invocados por Cloud Scheduler proporcionan una solución útil y flexible para organizar secuencias de servicios deGoogle Cloud , incluidas las consultas de BigQuery. Definir un flujo de trabajo como una serie de pasos en los que cada uno ejecuta un trabajo de BigQuery Puedes usar Cloud Scheduler para invocar estos flujos de trabajo según un programa definido. Administra las dependencias con la definición del flujo de trabajo para especificar el orden de ejecución, implementar lógica condicional, controlar errores y pasar resultados de una consulta a otra.

Las consultas programadas, también conocidas como trabajos de transferencia de BigQuery, te permiten ejecutar declaraciones de SQL de forma recurrente. Las consultas programadas no ofrecen un manejo de errores sólido ni una administración de dependencias dinámica.

ETL inverso con consultas continuas de BigQuery

La función de consultas continuas de BigQuery te permite ejecutar operaciones de BigQuery casi en tiempo real. La combinación de EXPORT DATA con consultas continuas proporciona un método alternativo para ejecutar canalizaciones de ETL inversas que evitan los trabajos por lotes programados.

Una consulta continua es una consulta de larga duración que supervisa una tabla de BigQuery de origen en busca de filas nuevas. Cuando BigQuery detecta que se agregaron filas nuevas a la tabla, transmite los resultados de la consulta a la operación EXPORT DATA.

Este enfoque ofrece las siguientes ventajas:

  • Sincronización de datos casi en tiempo real: Las filas nuevas en BigQuery se reflejan en Spanner con una demora mínima.

  • Reducción de la sobrecarga del procesamiento por lotes: Una consulta continua elimina la necesidad de trabajos por lotes periódicos, lo que reduce la sobrecarga computacional.

  • Actualizaciones basadas en eventos: Actualizaciones de datos de Spanner en respuesta a cambios reales en BigQuery.

Una canalización de consulta continua requiere una asignación de reserva de ranuras con el job_type de CONTINUOUS. Asigna este rol a nivel del proyecto o la carpeta, o bien a nivel de la organización.

Crea una consulta continua con ETL inverso de BigQuery a Spanner

Configura el parámetro start_timestamp de la función APPENDS para comenzar a procesar los datos en el punto en el que se detuvo la carga por lotes. Esta función captura todas las filas creadas en el período específico. En el siguiente ejemplo, la canalización establece arbitrariamente el punto de partida 10 minutos antes del CURRENT_TIME. Esta marca de tiempo debe estar dentro del período de viaje en el tiempo de BigQuery.

Existen varios métodos para iniciar una canalización de consultas continuas, incluidos los siguientes:

  1. En BigQuery Studio, selecciona Más y elige Consulta continua en Elige el modo de consulta.

  2. Usa la CLI de bq y proporciona la opción --continuous=true.

EXPORT DATA OPTIONS ( uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format="CLOUD_SPANNER",
  spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag": "reverse-etl-continuous",
      "change_timestamp_column": "create_time"
   }"""
)
AS SELECT id, account_id, _CHANGE_TIMESTAMP as create_time
  FROM
APPENDS(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
  CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE )

No se garantiza el orden de carga

Los datos de Spanner Graph constan de varias tablas de entrada. Debes cumplir con un orden de carga estricto cuando las tablas tienen restricciones de integridad referencial. Sin embargo, las consultas continuas simultáneas no pueden controlar el orden en el que Spanner agrega filas. Como resultado, la carga de datos de Spanner Graph con consultas continuas solo se aplica a esquemas de gráficos con restricciones de integridad referencial flexibles.

Integración con canalizaciones existentes

La consulta continua complementa los trabajos por lotes programados existentes. Por ejemplo, usa consultas continuas para obtener actualizaciones casi en tiempo real y trabajos programados para la sincronización o conciliación completa de los datos.

Usa la consulta continua de BigQuery para compilar canalizaciones de ETL inversas responsivas y actualizadas para sincronizar datos entre BigQuery y Spanner Graph.

Consideraciones sobre las consultas continuas

  • Costo: Las consultas continuas generan costos por la ejecución continua de la consulta y la transmisión de datos.

  • Administración de errores: Se cancela una canalización de consultas continuas si se detectan errores de base de datos, como una clave primaria duplicada o un incumplimiento de la integridad referencial. Si falla una canalización, debes corregir manualmente los datos en la tabla de BigQuery de origen antes de reiniciar la consulta.

  • No se controlan las actualizaciones ni los borrados: La función APPENDS solo captura las inserciones. No captura las actualizaciones ni las eliminaciones.

Sigue las prácticas recomendadas de la ETL inversa

Para obtener los mejores resultados, haz lo siguiente.

  • Elige una estrategia para evitar errores de integridad referencial cuando cargues datos de borde.

  • Diseña tu canalización de datos general para evitar bordes colgantes. Los bordes colgantes pueden comprometer la eficiencia de las consultas de Spanner Graph y la integridad de la estructura del gráfico. Para obtener más información, consulta cómo evitar los bordes colgantes.

  • Sigue las recomendaciones de optimización de exportaciones de Spanner.

  • Si cargas una gran cantidad de datos, considera dividir la canalización en varias canalizaciones más pequeñas para evitar alcanzar la cuota predeterminada de seis horas de tiempo de ejecución de consultas de BigQuery. Para obtener más información, consulta Límites de trabajos de consulta de BigQuery.

  • Para las cargas de datos grandes, agrega índices y restricciones de clave externa después de que se complete la carga inicial masiva de datos. Esta práctica mejora el rendimiento de la carga de datos, ya que las restricciones de clave externa requieren lecturas adicionales para la validación y los índices requieren escrituras adicionales. Estas operaciones aumentan la cantidad de participantes en la transacción, lo que puede ralentizar el proceso de carga de datos.

  • Habilita el ajuste de escala automático en Spanner para acelerar los tiempos de carga de datos en una instancia. Luego, configura el parámetro priority de Spanner en la sección spanner_options del comando EXPORT DATA de BigQuery como HIGH. Para obtener más información, consulta Descripción general del ajuste de escala automático de Spanner, Configura exportaciones con la opción spanner_options y RequestOptions.priority.

  • Para cargas de datos grandes, crea puntos de división para dividir previamente tu base de datos. Esto prepara Spanner para un mayor procesamiento.

  • Configura la prioridad de solicitud de Spanner para la carga de datos en la definición de la canalización.

¿Qué sigue?