ETL inverso de Snowflake a Spanner con BigQuery

1. Crea una canalización de ETL inversa de Snowflake a Spanner con Google Cloud Storage y BigQuery

Introducción

En este codelab, se compila una canalización de ETL inversa de Snowflake a Spanner. Tradicionalmente, las canalizaciones de ETL (extracción, transformación y carga) mueven los datos de las bases de datos operativas a un almacén de datos como Snowflake para su análisis. Una canalización de ETL inversa hace lo contrario: mueve datos seleccionados y procesados desde el almacén de datos de vuelta a los sistemas operativos, donde pueden potenciar aplicaciones, ofrecer funciones orientadas al usuario o usarse para la toma de decisiones en tiempo real.

El objetivo es transferir un conjunto de datos agregados de una tabla de Iceberg de Snowflake a Spanner, una base de datos relacional distribuida a nivel global ideal para aplicaciones de alta disponibilidad.

Para lograrlo, se usan Google Cloud Storage (GCS) y BigQuery como pasos intermedios. A continuación, se muestra un desglose del flujo de datos y la lógica detrás de esta arquitectura:

1. Snowflake a Google Cloud Storage (GCS) en formato Iceberg:

• El primer paso es extraer los datos de Snowflake en un formato abierto y bien definido. La tabla se exporta en formato Apache Iceberg. En este proceso, se escriben los datos subyacentes como un conjunto de archivos Parquet y los metadatos de la tabla (esquema, particiones, ubicaciones de archivos) como archivos JSON y Avro. Al organizar esta estructura de tabla completa en GCS, los datos se vuelven portátiles y accesibles para cualquier sistema que comprenda el formato de Iceberg.

2. Convierte tablas de Iceberg en GCS a tablas externas de BigLake de BigQuery:

• En lugar de cargar los datos directamente desde GCS a Spanner, se usa BigQuery como un potente intermediario. Crearás una tabla externa de BigLake en BigQuery que apunte directamente al archivo de metadatos de Iceberg en GCS. Este enfoque tiene varias ventajas:
• Sin duplicación de datos: BigQuery lee la estructura de la tabla desde los metadatos y consulta los archivos de datos de Parquet in situ sin transferirlos, lo que ahorra una cantidad significativa de tiempo y costos de almacenamiento.
• Consultas federadas: Permiten ejecutar consultas en SQL complejas sobre los datos de GCS como si fueran una tabla nativa de BigQuery.

3. BigQuery a Spanner:

• El último paso es transferir los datos de BigQuery a Spanner. Para ello, usarás una función potente de BigQuery llamada consulta EXPORT DATA, que es el paso de "ETL inversa".
• Preparación operativa: Spanner está diseñado para cargas de trabajo transaccionales, lo que proporciona coherencia sólida y alta disponibilidad para las aplicaciones. Al trasladar los datos a Spanner, se los hace accesibles para las aplicaciones orientadas al usuario, las APIs y otros sistemas operativos que requieren búsquedas puntuales de baja latencia.
• Escalabilidad: Este patrón permite aprovechar la potencia analítica de BigQuery para procesar grandes conjuntos de datos y, luego, entregar los resultados de manera eficiente a través de la infraestructura escalable a nivel global de Spanner.

Servicios y terminología

• Snowflake: Es una plataforma de datos en la nube que proporciona un almacén de datos como servicio.
• Spanner: Es una base de datos relacional completamente administrada y distribuida a nivel global.
• Google Cloud Storage: Es la oferta de almacenamiento de BLOB de Google Cloud.
• BigQuery: Es un almacén de datos sin servidores completamente administrado para el análisis de datos.
• Iceberg: Es un formato de tabla abierta definido por Apache que proporciona abstracción sobre los formatos de archivo de datos de código abierto comunes.
• Parquet: Es un formato de archivo de datos binarios columnar de código abierto de Apache.

Qué aprenderás

• Cómo cargar datos en Snowflake
• Cómo crear un bucket de GCS
• Cómo exportar una tabla de Snowflake a GCS en formato Iceberg
• Cómo configurar una instancia de Spanner
• Cómo cargar tablas externas de BigLake en BigQuery a Spanner

2. Configuración, requisitos y limitaciones

Requisitos previos

• Una cuenta de Snowflake
• Se requiere una cuenta de Google Cloud con una reserva de nivel Enterprise o superior de BigQuery para exportar datos de BigQuery a Spanner.
• Acceso a la consola de Google Cloud a través de un navegador web
• Una terminal para ejecutar comandos de Google Cloud CLI
• Si tu organización de Google Cloud tiene habilitada la política iam.allowedPolicyMemberDomains, es posible que un administrador deba otorgar una excepción para permitir cuentas de servicio de dominios externos. Esto se abordará en un paso posterior, cuando corresponda.

Limitaciones

Es importante tener en cuenta ciertas limitaciones e incompatibilidades de tipos de datos que pueden surgir en esta canalización.

De Snowflake a Iceberg

Los tipos de datos de las columnas difieren entre Snowflake y Iceberg. En la documentación de Snowflake, se incluye información sobre la traducción entre ellos.

Iceberg a BigQuery

Cuando usas BigQuery para consultar tablas de Iceberg, existen algunas limitaciones. Para obtener una lista completa, consulta la documentación de BigQuery. Ten en cuenta que, actualmente, no se admiten tipos como BIGNUMERIC, INTERVAL, JSON, RANGE o GEOGRAPHY.

BigQuery a Spanner

El comando EXPORT DATA de BigQuery a Spanner no admite todos los tipos de datos de BigQuery. Si exportas una tabla con los siguientes tipos, se producirá un error:

• STRUCT
• GEOGRAPHY
• DATETIME
• RANGE
• TIME

Además, si el proyecto de BigQuery usa el dialecto GoogleSQL, los siguientes tipos numéricos tampoco se admiten para la exportación a Spanner:

• BIGNUMERIC

Para obtener una lista completa y actualizada de las limitaciones, consulta la documentación oficial: Limitaciones de la exportación a Spanner.

Snowflake

Para este codelab, puedes usar una cuenta de Snowflake existente o configurar una cuenta de prueba gratuita.

Permisos de IAM de Google Cloud Platform

La Cuenta de Google necesitará los siguientes permisos para ejecutar todos los pasos de este codelab.

Cuentas de servicio
iam.serviceAccountKeys.create	Permite la creación de cuentas de servicio.
Spanner
spanner.instances.create	Permite crear una instancia de Spanner nueva.
spanner.databases.create	Permite ejecutar instrucciones DDL para crear
spanner.databases.updateDdl	Permite ejecutar sentencias DDL para crear tablas en la base de datos.
Google Cloud Storage
storage.buckets.create	Permite crear un bucket de GCS nuevo para almacenar los archivos Parquet exportados.
storage.objects.create	Permite escribir los archivos Parquet exportados en el bucket de GCS.
storage.objects.get	Permite que BigQuery lea los archivos Parquet del bucket de GCS.
storage.objects.list	Permite que BigQuery cree una lista de los archivos Parquet en el bucket de GCS.
Dataflow
Dataflow.workitems.lease	Permite reclamar elementos de trabajo de Dataflow.
Dataflow.workitems.sendMessage	Permite que el trabajador de Dataflow envíe mensajes al servicio de Dataflow.
Logging.logEntries.create	Permite que los trabajadores de Dataflow escriban entradas de registro en Cloud Logging de Google Cloud.

Para mayor comodidad, se pueden usar roles predefinidos que contengan estos permisos.

roles/resourcemanager.projectIamAdmin

roles/iam.serviceAccountKeyAdmin

roles/spanner.instanceAdmin

roles/spanner.databaseAdmin

roles/storage.admin

roles/dataflow.serviceAgent

roles/dataflow.worker

roles/dataflow.serviceAgent

Configura propiedades reutilizables

A lo largo de este lab, necesitarás algunos valores de forma reiterada. Para que sea más fácil, estableceremos estos valores en variables de shell para usarlos más adelante.

• GCP_REGION: Es la región específica en la que se ubicarán los recursos de GCP. Puedes encontrar la lista de regiones aquí.
• GCP_PROJECT: Es el ID del proyecto de GCP que se usará.
• GCP_BUCKET_NAME: Es el nombre del bucket de GCS que se creará y en el que se almacenarán los archivos de datos.

Los nombres de los depósitos deben ser únicos a nivel global. Un patrón común es [organization_name]-[project_id]-[environment]-[purpose].

export GCP_REGION = <GCP REGION HERE> 
export GCP_PROJECT= <GCP PROJECT HERE>
export GCS_BUCKET_NAME = <GCS BUCKET NAME HERE>
export SPANNER_INSTANCE = <SPANNER INSTANCE ID HERE>
export SPANNER_DB = <SPANNER DATABASE ID HERE>

Ten en cuenta que estas variables de entorno solo se establecerán en la instancia de shell en la que se ejecutan y deberán establecerse de nuevo si ejecutas los comandos de este lab en una instancia de shell diferente más adelante.

Proyecto de Google Cloud

Un proyecto es una unidad básica de organización en Google Cloud. Si un administrador proporcionó una para usar, se puede omitir este paso.

Puedes crear un proyecto con la CLI de la siguiente manera:

gcloud projects create $GCP_PROJECT
gcloud config set project $GCP_PROJECT

Obtén más información para crear y administrar proyectos aquí.

Configura Spanner

Para comenzar a usar Spanner, debes aprovisionar una instancia y una base de datos. Puedes encontrar detalles sobre cómo configurar y crear una instancia de Spanner aquí.

Crea la instancia

gcloud spanner instances create $SPANNER_INSTANCE \
--config=regional-$GCP_REGION \
--description="Codelabs Snowflake RETL" \
--processing-units=100 \
--edition=ENTERPRISE

Crea la base de datos

gcloud spanner databases create $SPANNER_DB \
--instance=$SPANNER_INSTANCE

3. Crear un bucket de Google Cloud Storage

Google Cloud Storage (GCS) se usará para almacenar los archivos de datos de Parquet y los metadatos de Iceberg generados por Snowflake. Para ello, primero se deberá crear un bucket nuevo que se usará como destino del archivo. Desde una ventana de la terminal en una máquina local, sigue estos pasos.

Crea un bucket

Usa el siguiente comando para crear un bucket de almacenamiento en una región específica (p.ej., us-central1).

gcloud storage buckets create gs://$GCS_BUCKET_NAME --location=$GCP_REGION

Verifica la creación del bucket

Una vez que el comando se ejecute correctamente, verifica el resultado enumerando todos los buckets. El bucket nuevo debería aparecer en la lista resultante. Las referencias a los buckets suelen mostrarse con el prefijo gs:// delante del nombre del bucket.

gcloud storage ls | grep gs://$GCS_BUCKET_NAME

Cómo probar los permisos de escritura

Este paso garantiza que el entorno local se autentique correctamente y tenga los permisos necesarios para escribir archivos en el bucket recién creado.

echo "Hello, GCS" | gcloud storage cp - gs://$GCS_BUCKET_NAME/hello.txt

Verifica el archivo subido

Enumera los objetos del bucket. Aparecerá la ruta de acceso completa del archivo que acabas de subir.

gcloud storage ls gs://$GCS_BUCKET_NAME

Deberías ver el siguiente resultado:

gs://$GCS_BUCKET_NAME/hello.txt

Para ver el contenido de un objeto en un bucket, se puede usar gcloud storage cat.

gcloud storage cat gs://$GCS_BUCKET_NAME/hello.txt

Debería verse el contenido del archivo:

Hello, GCS

Limpia el archivo de prueba

El bucket de Cloud Storage ya está configurado. Ahora se puede borrar el archivo de prueba temporal.

gcloud storage rm gs://$GCS_BUCKET_NAME/hello.txt

El resultado debería confirmar la eliminación:

Removing gs://$GCS_BUCKET_NAME/hello.txt...
/ [1 objects]
Operation completed over 1 objects.

4. Exporta datos de Snowflake a GCS

En este lab, usarás el conjunto de datos TPC-H, que es una comparativa estándar de la industria para los sistemas de asistencia para decisiones. Su esquema modela un entorno empresarial realista con clientes, pedidos, proveedores y piezas, lo que lo hace perfecto para demostrar una situación real de análisis y movimiento de datos. Este conjunto de datos está disponible de forma predeterminada en todas las cuentas de Snowflake.

En lugar de usar las tablas sin procesar y normalizadas de TPC-H, crearás una tabla nueva y agregada. Esta nueva tabla combinará los datos de las tablas orders, customer y nation para generar una vista desnormalizada y resumida de los totales de ventas nacionales. Este paso de preagregación es una práctica común en el análisis, ya que prepara los datos para un caso de uso específico, en este caso, para el consumo por parte de una aplicación operativa.

Permite que Snowflake acceda a Google Cloud Storage

Para permitir que Snowflake escriba datos en el bucket de GCS, se deben crear dos elementos: un volumen externo y los permisos necesarios.

• Un volumen externo es un objeto de Snowflake que proporciona un vínculo seguro a una ubicación específica en un bucket de GCS. No almacena datos en sí, sino que contiene la configuración necesaria para que Snowflake acceda al almacenamiento en la nube.
• Por motivos de seguridad, los buckets de almacenamiento en la nube son privados de forma predeterminada. Cuando se crea un volumen externo, Snowflake genera una cuenta de servicio dedicada. Se le deben otorgar permisos a esta cuenta de servicio para leer y escribir en el bucket.

Crea una base de datos

1. En el menú de la izquierda, en Horizon Catalog, coloca el cursor sobre Catalog y, luego, haz clic en Database Explorer.
2. Una vez que estés en la página Bases de datos, haz clic en el botón + Base de datos en la parte superior derecha.
3. Asigna el nombre codelabs_retl_db a la nueva base de datos.

Crea una hoja de cálculo

Para ejecutar comandos SQL en la base de datos, se necesitarán hojas de trabajo.

Para crear una hoja de cálculo, sigue estos pasos:

1. En el menú lateral izquierdo, en Trabaja con datos, coloca el cursor sobre Proyectos y, luego, haz clic en Espacios de trabajo.
2. En la barra lateral Mis espacios de trabajo, haz clic en el botón + Agregar nuevo y selecciona Archivo SQL.

Todos los demás comandos de SQL para Snowflake se pueden ejecutar reemplazando el contenido de este archivo. Para ejecutar porciones de párrafos del archivo, coloca el cursor en el párrafo y presiona Ctrl + Intro en el teclado.

Crea un volumen externo

Ejecuta el siguiente comando en una hoja de cálculo de Snowflake para crear el volumen.

Ten en cuenta que Snowflake usa el prefijo gcs:// para las rutas de Google Cloud Storage, no gs://.

Dado que el siguiente código SQL no se ejecutará como parte de la instancia de shell con las variables de entorno establecidas, asegúrate de reemplazar los valores de tu nombre del bucket de GCS donde aparezca.

CREATE EXTERNAL VOLUME codelabs_retl_ext_vol
STORAGE_LOCATIONS = 
(
  (
    NAME = 'codelabs_retl_ext_vol'
    STORAGE_PROVIDER = 'GCS'
    STORAGE_BASE_URL = 'gcs://<Your bucket name>/snowflake_extvol'
  )
); 

Obtén la cuenta de servicio de Snowflake

DESC (describe) el volumen externo recién creado para obtener la cuenta de servicio única que Snowflake generó para él.

DESC EXTERNAL VOLUME codelabs_retl_ext_vol;

1. En el panel de resultados, busca las propiedades json y encuentra la entrada property_value que contiene una cadena JSON que comienza con "NAME":"codelabs_retl_ext_vol".
2. Busca la propiedad STORAGE_GCP_SERVICE_ACCOUNT dentro del objeto JSON y copia su valor (se verá como una dirección de correo electrónico). Es el identificador de la cuenta de servicio que necesita acceso al bucket de GCS.
3. Almacena esta cuenta de servicio en una variable de entorno en tu instancia de shell para reutilizarla más adelante.

export GCP_SERVICE_ACCOUNT=<Your service account>

Nota: Si tu organización de Google Cloud aplica la restricción iam.allowedPolicyMemberDomains, un administrador de seguridad deberá agregar el dominio de esta cuenta de servicio (la parte que aparece después del símbolo @) a la lista de entidades permitidas.

Otorga permisos de GCS a Snowflake

Ahora, se debe otorgar permiso a la cuenta de servicio de Snowflake para escribir en el bucket de GCS.

gcloud storage buckets add-iam-policy-binding gs://$GCS_BUCKET_NAME \
    --member="serviceAccount:$GCP_SERVICE_ACCOUNT" \
    --role="roles/storage.objectAdmin"

gcloud storage buckets add-iam-policy-binding gs://$GCS_BUCKET_NAME \
    --member="serviceAccount:$GCP_SERVICE_ACCOUNT" \
    --role="roles/storage.legacyBucketReader"

Verifica el acceso en Snowflake

De vuelta en la hoja de cálculo de Snowflake, ejecuta este comando para verificar que Snowflake ahora se pueda conectar correctamente al bucket de GCS.

SELECT SYSTEM$VERIFY_EXTERNAL_VOLUME('codelabs_retl_ext_vol');

El resultado debe ser un objeto JSON que contenga "success":true.

Para obtener más información sobre los volúmenes externos en Snowflake, consulta la documentación oficial.

Exporta datos de pedidos de muestra

Ahora puedes crear una tabla de Iceberg en Snowflake. El siguiente comando le indica a Snowflake que ejecute una consulta y almacene los resultados en GCS con el formato de Iceberg. Los archivos de datos serán de Parquet y los metadatos serán de Avro y JSON. Todos se almacenarán en la ubicación definida por el volumen externo de codelabs_retl_ext_vol.

Crea una base de datos

1. En el menú de la izquierda, en Horizon Catalog, coloca el cursor sobre Catalog y, luego, haz clic en Database Explorer.
2. Una vez que estés en la página Bases de datos, haz clic en el botón + Base de datos en la parte superior derecha.
3. Asigna el nombre codelabs_retl_db a la nueva base de datos.

USE DATABASE codelabs_retl_db; 

CREATE ICEBERG TABLE REGIONAL_SALES_ICEBERG (
    NATION_NAME STRING,
    MARKET_SEGMENT STRING,
    ORDER_YEAR INTEGER,
    ORDER_PRIORITY STRING,
    TOTAL_ORDER_COUNT INTEGER,
    TOTAL_REVENUE NUMBER(24,2),
    UNIQUE_CUSTOMER_COUNT INTEGER
) 
EXTERNAL_VOLUME = 'codelabs_retl_ext_vol'
CATALOG = 'SNOWFLAKE'
BASE_LOCATION = 'regional_sales_iceberg'
AS (
    SELECT 
        n.n_name AS nation_name,
        c.c_mktsegment AS market_segment,
        YEAR(o.o_orderdate) AS order_year,
        o.o_orderpriority AS order_priority,
        COUNT(o.o_orderkey) AS total_order_count,
        ROUND(SUM(o.o_totalprice), 2) AS total_revenue,
        COUNT(DISTINCT c.c_custkey) AS unique_customer_count
    FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.orders AS o
    INNER JOIN SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.customer AS c 
        ON o.o_custkey = c.c_custkey
    INNER JOIN SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.nation AS n
        ON c.c_nationkey = n.n_nationkey
    GROUP BY 
        n.n_name, 
        c.c_mktsegment, 
        YEAR(o.o_orderdate), 
        o.o_orderpriority
);

Para obtener más información sobre cómo crear y administrar tablas de Iceberg con Snowflake, consulta la documentación oficial.

Verifica los datos en GCP

Ahora, verifica el bucket de GCS. Deberían verse los archivos que creó Snowflake. Esto confirma que la exportación se realizó correctamente. Los metadatos de Iceberg se encontrarán en la carpeta metadata y los datos reales como archivos Parquet en la carpeta data.

gcloud storage ls "gs://$GCS_BUCKET_NAME/snowflake_extvol/**"

Los nombres de los archivos exactos variarán, pero la estructura debería verse de la siguiente manera:

gs://$GCS_BUCKET_NAME/snowflake_extvol/
gs://$GCS_BUCKET_NAME/snowflake_extvol/regional_sales_iceberg.snvrAWuR/data/snow_cbsKIRmdDmo_wLg128fugxg_0_2_009.parquet
...
gs://$GCS_BUCKET_NAME/snowflake_extvol/regional_sales_iceberg.snvrAWuR/metadata/00001-62f831ff-6708-4494-94c5-c891b7ad447f.metadata.json
...

Los datos ahora se copiaron de Snowflake a Google Cloud Storage en formato Iceberg.

Mientras tenemos esta lista, guardemos el archivo metadata.json en una variable de entorno, ya que lo necesitaremos más adelante.

export GCS_METADATA_JSON=$(gcloud storage ls "gs://$GCS_BUCKET_NAME/snowflake_extvol/**" | grep .metadata.json)

5. Configura una tabla externa de BigQuery

Ahora que la tabla de Iceberg está en Google Cloud Storage, el siguiente paso es hacer que sea accesible para BigQuery. Para ello, crea una tabla externa de BigLake.

BigLake es un motor de almacenamiento que permite crear tablas en BigQuery que leen datos directamente de fuentes externas, como Google Cloud Storage. En este lab, es la tecnología clave que permite que BigQuery comprenda la tabla de Iceberg que se acaba de exportar sin necesidad de transferir los datos.

Para que esto funcione, se necesitan dos componentes:

1. Una conexión de recursos de Cloud: Es un vínculo seguro entre BigQuery y GCS. Utiliza una cuenta de servicio especial para controlar la autenticación, lo que garantiza que BigQuery tenga los permisos necesarios para leer los archivos del bucket de GCS.
2. Una definición de tabla externa: Indica a BigQuery dónde encontrar el archivo de metadatos de la tabla de Iceberg en GCS y cómo se debe interpretar.

Configura una conexión a Google Cloud Storage

Primero, se creará la conexión que le permite a BigQuery acceder a GCS. Este comando crea un recurso de conexión en BigQuery.

bq mk \
  --connection \
  --project_id=$GCP_PROJECT \
  --location=$GCP_REGION \
  --connection_type=CLOUD_RESOURCE \
  codelabs-retl-connection

El éxito se verá de la siguiente manera:

Connection 12345678.region.codelabs-retl-connection successfully created

En la documentación de Google Cloud, encontrarás más información sobre las conexiones de recursos de Cloud en BigQuery.

Autoriza la conexión de BigQuery para leer datos

La nueva conexión de BigQuery tiene su propia cuenta de servicio que necesita permiso para leer datos del bucket de Google Cloud Storage.

1. Obtén la cuenta de servicio de la conexión

Primero, obtén el ID de la cuenta de servicio de la conexión que acabas de crear:

bq show \
  --location $GCP_REGION \
  --connection codelabs-retl-connection

En los resultados, se mostrará una tabla de las conexiones coincidentes.

Establezcamos serviceAccountId en una variable de entorno para usarla más adelante.

export GCP_BQ_SERVICE_ACCOUNT=<Your service account email>

2. Otorgar permisos

Ejecuta el siguiente comando para autorizar a la cuenta de servicio a ver datos en el bucket de GCS.

gcloud storage buckets add-iam-policy-binding \
  gs://$GCS_BUCKET_NAME \
  --member serviceAccount:$GCP_BQ_SERVICE_ACCOUNT \
  --role roles/storage.objectViewer

Crea la tabla externa

Ahora, crea la tabla externa de BigLake en BigQuery. Este comando no mueve ningún dato. Simplemente crea un puntero a los datos existentes en GCS. Se necesitará la ruta de acceso a uno de los archivos .metadata.json que creó Snowflake.

Sustituye el valor external_table_definition por la ruta de acceso adecuada a tu archivo metadata.json en el siguiente comando.

Asegúrate de que esta tabla se cree en la misma región que la conexión del paso anterior.

bq mk --dataset --location=$GCP_REGION codelabs_retl

bq mk \
    --table \
    --location=$GCP_REGION \
--external_table_definition=ICEBERG=$GCS_METADATA_JSON@projects/$GCP_PROJECT/locations/$GCP_REGION/connections/codelabs-retl-connection \
    codelabs_retl.regional_sales

Verifica los datos en BigQuery

Ahora se puede consultar esta tabla con SQL estándar, al igual que con cualquier otra tabla de BigQuery. BigQuery usará la conexión para leer los archivos Parquet de GCS sobre la marcha.

bq query \
  --location=$GCP_REGION \
  --nouse_legacy_sql "SELECT * FROM \`$GCP_PROJECT.codelabs_retl.regional_sales\` LIMIT 10;"

6. Importa datos de BigQuery a Spanner: el paso final

Llegamos a la parte final y más importante de la canalización: mover los datos de la tabla de BigLake a Spanner. Este es el paso de "ETL inversa", en el que los datos, después de procesarse y organizarse en el almacén de datos, se cargan en un sistema operativo para que los usen las aplicaciones.

Spanner es una base de datos relacional completamente administrada y distribuida a nivel global. Ofrece la coherencia transaccional de una base de datos relacional tradicional, pero con la escalabilidad horizontal de una base de datos NoSQL. Esto la convierte en una opción ideal para compilar aplicaciones escalables y con alta disponibilidad.

El proceso será el siguiente:

1. Crea un esquema de tabla en la base de datos de Spanner que coincida con la estructura de los datos.
2. Ejecuta una consulta EXPORT DATA de BigQuery para cargar los datos de la tabla de BigLake directamente en la tabla de Spanner.

Crea la tabla de Spanner

Antes de transferir datos desde BigQuery, se debe crear una tabla de destino en Spanner con un esquema compatible.

gcloud spanner databases ddl update $SPANNER_DB \
  --instance=$SPANNER_INSTANCE \
  --ddl="$(cat <<EOF
CREATE TABLE regional_sales (
    nation_name STRING(MAX),
    market_segment STRING(MAX),
    order_year INT64,
    order_priority STRING(MAX),
    total_order_count INT64,
    total_revenue NUMERIC,
    unique_customer_count INT64
) PRIMARY KEY (nation_name, market_segment, order_year, order_priority);
EOF
)"

Exporta datos desde BigQuery

Este es el paso final. Con los datos de origen listos en una tabla de BigLake de BigQuery y la tabla de destino creada en Spanner, el movimiento de datos real es sorprendentemente simple. Se usará una sola consulta de BigQuery SQL: EXPORT DATA.

Esta consulta está diseñada específicamente para situaciones como esta. Exporta datos de manera eficiente desde una tabla de BigQuery (incluidas las externas, como la tabla de BigLake) a un destino externo. En este caso, el destino es la tabla de Spanner.

bq query --location=$GCP_REGION --use_legacy_sql=false <<EOF
EXPORT DATA OPTIONS (
uri="https://spanner.googleapis.com/projects/${GCP_PROJECT}/instances/${SPANNER_INSTANCE}/databases/${SPANNER_DB}",
  format='CLOUD_SPANNER',
  spanner_options="""{ 
      "table": "regional_sales", 
      "priority": "HIGH" 
      }"""
) AS 
SELECT * FROM \`${PROJECT_ID}.codelabs_retl.regional_sales\`
EOF

Cuando finalice la consulta, en el panel Resultados debería aparecer el mensaje "Se completó la actualización".

7. Verifica los datos en Spanner

¡Felicitaciones! Se compiló y ejecutó correctamente una canalización de Reverse ETL completa. El paso final es verificar que los datos hayan llegado a Spanner según lo previsto.

gcloud spanner databases execute-sql \
  --instance=$SPANNER_INSTANCE \
  $SPANNER_DB \
  --sql='SELECT * FROM regional_sales LIMIT 10'

Los datos de muestra importados aparecen como se solicitó:

nation_name  market_segment  order_year  order_priority   total_order_count  total_revenue  unique_customer_count
ALGERIA      AUTOMOBILE      1992        1-URGENT         375                59232423.66    298
ALGERIA      AUTOMOBILE      1992        2-HIGH           328                47371891.08    269
ALGERIA      AUTOMOBILE      1992        3-MEDIUM         346                52823195.87    262
ALGERIA      AUTOMOBILE      1992        4-NOT SPECIFIED  365                52935998.34    288
ALGERIA      AUTOMOBILE      1992        5-LOW            380                54920263.68    293
ALGERIA      AUTOMOBILE      1993        1-URGENT         394                63145618.78    312
ALGERIA      AUTOMOBILE      1993        2-HIGH           340                50737488.4     277
ALGERIA      AUTOMOBILE      1993        3-MEDIUM         383                55871057.46    298
ALGERIA      AUTOMOBILE      1993        4-NOT SPECIFIED  365                56424662.05    291
ALGERIA      AUTOMOBILE      1993        5-LOW            363                54673249.06    283

Se cerró con éxito la brecha entre los mundos de los datos operativos y analíticos.

8. Corrección

Limpia Spanner

Borra la base de datos y la instancia de Spanner

gcloud spanner instances delete $SPANNER_INSTANCE

Limpia GCS

Borra el bucket de GCS creado para alojar los datos

gcloud storage rm --recursive gs://$GCS_BUCKET_NAME

Limpia BigQuery

bq rm -r codelabs_retl
bq rm --connection --location=$GCP_REGION codelabs-retl-connection

Limpieza de Snowflake

Desconecta la base de datos

1. En el menú de la izquierda, en Horizon Catalog, coloca el cursor sobre Catalog y, luego, haz clic en Database Explorer.
2. Haz clic en … a la derecha de la base de datos CODELABS_RETL_DB para expandir las opciones y seleccionar Soltar.
3. En el diálogo de confirmación que aparece, selecciona Drop Database.

Cómo borrar libros de trabajo

4. En el menú lateral izquierdo, en Trabaja con datos, coloca el cursor sobre Proyectos y, luego, haz clic en Espacios de trabajo.
5. En la barra lateral Mi espacio de trabajo, coloca el cursor sobre los diferentes archivos del espacio de trabajo que usaste para este lab para mostrar las opciones adicionales … y haz clic en ellas.
6. Selecciona Borrar y, luego, vuelve a seleccionar Borrar en el diálogo de confirmación que aparece.
7. Haz esto para todos los archivos del espacio de trabajo de SQL que creaste para este lab.

Borra volúmenes externos

8. En el menú lateral izquierdo, en Horizon Catalog, coloca el cursor sobre Catalog y, luego, haz clic en External Data.
9. Haz clic en a la derecha de CODELABS_RETL_EXT_VOL, selecciona Soltar volumen externo y, luego, vuelve a hacer clic en Soltar volumen externo en el cuadro de diálogo de confirmación.

9. Felicitaciones

Felicitaciones por completar el codelab.

Temas abordados

• Cómo cargar datos en Snowflake
• Cómo crear un bucket de GCS
• Cómo exportar una tabla de Snowflake a GCS en formato CSV
• Cómo configurar una instancia de Spanner
• Cómo cargar tablas CSV en Spanner con Dataflow