Esta página se ha traducido con Cloud Translation API.

Información general sobre la transferencia de esquemas y datos

En este documento se explican los conceptos y las tareas para transferir el esquema y los datos de tu almacén de datos a BigQuery.

Migrar tu almacén de datos a la nube es un proceso complejo que requiere planificación, recursos y tiempo. Para gestionar esta complejidad, debes abordar la migración del almacén de datos de forma gradual e iterativa. Hacer varias iteraciones de migración de esquemas y datos puede mejorar el resultado.

Proceso de migración de esquemas y datos

Al principio de tu proceso de migración, tienes sistemas ascendentes que alimentan tu almacén de datos y sistemas descendentes que usan esos datos en informes, paneles de control y como feeds para otros procesos.

Este flujo de datos general admite muchos casos prácticos de analíticas, como se muestra en el siguiente diagrama:

Estado inicial antes de la migración.

El objetivo final es que se ejecuten tantos casos prácticos como sea posible en BigQuery. Este estado te permite minimizar el uso de tu almacén de datos y, con el tiempo, dejar de usarlo. Tú decides qué casos prácticos se migran y cuándo, priorizándolos durante la fase de preparación y descubrimiento de la migración.

Transferir esquemas y datos a BigQuery

En la fase de planificación de la migración, identifica los casos prácticos que quieres migrar. A continuación, inicia las iteraciones de la migración en la fase execute. Para gestionar tus iteraciones mientras ejecutas tu entorno de analíticas con las mínimas interrupciones, sigue este proceso general:

Transfiere las tablas, configura los procesos posteriores y pruébalos.
- Transfiere el grupo de tablas de cada caso práctico a BigQuery sin hacer ningún cambio. Para ello, usa BigQuery Data Transfer Service u otra herramienta de ETL. Para obtener información sobre las herramientas, consulta la sección Transferencia de datos inicial.
- Configura versiones de prueba de tus procesos posteriores para que lean de las tablas de BigQuery.
Este paso inicial divide el flujo de datos. En el siguiente diagrama se muestra el flujo resultante. Algunos sistemas posteriores ahora leen datos de BigQuery, como se muestra en los flujos etiquetados con la letra B. Otros siguen leyendo del almacén de datos, como se muestra en los flujos etiquetados como A.
Configura algunos procesos upstream de prueba para escribir datos en tablas de BigQuery en lugar del almacén de datos actual (o además de él).

Después de las pruebas, configura los procesos upstream y downstream de producción para escribir y leer en las tablas de BigQuery. Estos procesos pueden conectarse a BigQuery mediante la API de BigQuery e incorporar nuevos productos en la nube, como Looker Studio y Dataflow.

En este punto, tiene tres flujos de datos:
1. Existente. Los datos y los procesos no han cambiado y siguen centrados en su almacén de datos.
2. Descargado. Los procesos upstream alimentan tu almacén de datos, los datos se descargan en BigQuery y, a continuación, alimentan los procesos downstream.
3. Migración completa. Los procesos upstream y downstream ya no escriben ni leen datos del almacén de datos.
  En el siguiente diagrama se muestra un sistema con los tres flujos:
Selecciona más casos prácticos para la migración y, a continuación, ve al paso 1 para iniciar una iteración de ejecución. Sigue repitiendo estos pasos hasta que todos tus casos prácticos se hayan migrado por completo a BigQuery. Cuando selecciones casos prácticos, puedes volver a los que se hayan quedado en el estado de descarga para migrarlos por completo. En los casos prácticos que se hayan migrado por completo, te recomendamos que sigas el proceso de evolución siguiendo las directrices de Evolucionar el esquema en BigQuery.

Desarrollar el esquema en BigQuery

El esquema del almacén de datos define cómo se estructuran los datos y las relaciones entre las entidades de datos. El esquema es el elemento central del diseño de tus datos e influye en muchos procesos, tanto upstream como downstream.

La migración de un almacén de datos ofrece una oportunidad única para desarrollar tu esquema una vez que se haya trasladado a BigQuery. En esta sección se presentan directrices para desarrollar tu esquema siguiendo una serie de pasos. Estas directrices te ayudan a mantener tu entorno de almacén de datos en funcionamiento durante los cambios de esquema con las mínimas interrupciones posibles en los procesos ascendentes y descendentes.

En esta sección, se explica cómo transformar el esquema para un solo caso práctico.

En función de lo lejos que quieras llegar con la evolución, puedes detenerte en un paso intermedio o continuar hasta que tu sistema haya evolucionado por completo.

Transferir un caso práctico tal cual a BigQuery.

Antes de continuar con los pasos siguientes, asegúrate de que los procesos upstream y downstream de tu caso práctico ya escriben y leen datos de BigQuery. Sin embargo, también es posible empezar desde un estado intermedio en el que solo el proceso posterior lea de BigQuery. En este caso, aplica solo las directrices de la parte posterior. En el siguiente diagrama se muestra un caso práctico en el que los procesos ascendentes y descendentes escriben y leen datos de tablas de BigQuery.
Aplica optimizaciones de luz.
1. Vuelve a crear las tablas aplicando particiones y agrupación en clústeres. Para esta tarea, puedes usar el método de crear una tabla a partir del resultado de una consulta. Para obtener más información, consulta la conversación y el ejemplo de tablas particionadas, así como la conversación y el ejemplo de tablas agrupadas en clústeres.
2. Redirige tus procesos ascendentes y descendentes a las nuevas tablas.
Crea vistas de fachada.

Si quieres desarrollar tu esquema más allá de las optimizaciones básicas, crea vistas de fachada para tus tablas. El patrón de fachada es un método de diseño que oculta el código o las estructuras subyacentes para ocultar la complejidad. En este caso, las vistas de fachada ocultan las tablas subyacentes para ocultar la complejidad causada por los cambios en las tablas de los procesos posteriores.

Las vistas pueden describir un nuevo esquema, sin deuda técnica, y modelarse teniendo en cuenta nuevos escenarios de ingestión y consumo.

Las tablas y la propia definición de la consulta de la vista pueden cambiar. Sin embargo, las vistas abstraen estos cambios como un detalle de implementación interno de tu almacén de datos y siempre devuelven los mismos resultados. Esta capa de abstracción, compuesta por vistas de fachada, aísla los sistemas ascendentes y descendentes de los cambios durante el tiempo que sea necesario y solo muestra los cambios cuando sea oportuno.
Transformar los procesos posteriores.

Puedes transformar algunos de tus procesos posteriores para que lean de las vistas de fachada en lugar de las tablas reales. Estos procesos ya se beneficiarán del esquema actualizado. Estos procesos no saben que, en segundo plano, las vistas de fachada siguen obteniendo sus datos del esquema de BigQuery de origen, tal como se muestra en el siguiente diagrama:

Primero hemos descrito la transformación del proceso posterior. De esta forma, puedes mostrar el valor de negocio más rápidamente, en forma de paneles de control o informes migrados, que si transformaras procesos anteriores que no son visibles para las partes interesadas no técnicas. Sin embargo, puedes empezar la transformación con tus procesos anteriores. La prioridad de estas tareas depende totalmente de tus necesidades.
Transformar los procesos iniciales.

Puedes transformar algunos de tus procesos anteriores para escribir en el nuevo esquema. Como las vistas son de solo lectura, se crean tablas basadas en el nuevo esquema y, a continuación, se modifica la definición de consulta de las vistas de fachada. Algunas vistas seguirán consultando el esquema de origen, mientras que otras consultarán las tablas recién creadas o realizarán una operación UNION de SQL en ambas, como se muestra en el siguiente diagrama:

En este punto, puede aprovechar los campos anidados y repetidos al crear las nuevas tablas. De esta forma, puedes desnormalizar aún más tu modelo y aprovechar directamente la representación columnar subyacente de los datos de BigQuery.

Una de las ventajas de las vistas de fachada es que los procesos posteriores pueden seguir transformándose de forma independiente a estos cambios de esquema subyacentes y a los cambios en los procesos anteriores.
Desarrolla completamente tu caso práctico.

Por último, puedes transformar los procesos restantes de la cadena de suministro. Cuando todos estos elementos se hayan actualizado para escribir en las nuevas tablas y leer de las nuevas vistas de fachada, modifica las definiciones de consulta de las vistas de fachada para que ya no lean del esquema de origen. Después, puedes retirar las tablas del modelo de origen del flujo de datos. En el siguiente diagrama se muestra el estado en el que ya no se usan las tablas de origen.

Si las vistas de fachada no agregan campos ni filtran columnas, puede configurar sus procesos posteriores para que lean de las tablas actualizadas y, a continuación, retirar las vistas de fachada para reducir la complejidad, tal como se muestra en el siguiente diagrama:

Realizar una transferencia inicial de tu esquema y tus datos

En esta sección se tratan aspectos prácticos que debes tener en cuenta al migrar tu esquema y tus datos de un almacén de datos a BigQuery.

Te recomendamos que transfieras el esquema sin hacer ningún cambio durante las iteraciones iniciales de la migración. Esto te ofrece las siguientes ventajas:

No es necesario ajustar las canalizaciones de datos que alimentan tu almacén de datos para un nuevo esquema.
Evitas añadir un nuevo esquema a la lista de material de formación para tu personal.
Puedes usar herramientas automatizadas para llevar a cabo la transferencia de esquemas y datos.

Además, las pruebas de concepto y otras actividades de exploración de datos que aprovechan las funciones de la nube pueden llevarse a cabo sin problemas, incluso mientras se realiza la migración en paralelo.

Elige un método de transferencia

Puedes hacer la transferencia inicial de varias formas.

En el caso de los almacenes de datos de Amazon Redshift y Teradata, puedes usar BigQuery Data Transfer Service para cargar el esquema y los datos directamente desde tu sistema a BigQuery. Cloud Storage se sigue usando para almacenar datos provisionalmente como parte del proceso de migración.
En cualquier almacén de datos, puede extraer los archivos que contengan su esquema y sus datos, subirlos a Cloud Storage y, a continuación, usar una de las siguientes opciones para cargar el esquema y los datos de esos archivos en BigQuery:

Para obtener más información sobre lo que debes tener en cuenta al elegir un método de transferencia de datos, consulta el artículo Elegir un método de ingesta de datos.

Tener en cuenta la transformación de datos

En función del formato de extracción de datos y de si quieres acotar o enriquecer los datos antes de cargarlos en BigQuery, puedes incluir un paso para transformar los datos. Puedes transformar los datos en el entorno actual o en Google Cloud:

Si transforma los datos en el entorno actual, tenga en cuenta cómo pueden limitar el rendimiento la capacidad de computación y las herramientas disponibles. Además, si vas a enriquecer los datos durante el proceso de transformación, ten en cuenta si necesitas más tiempo de transferencia o ancho de banda de la red.
Si transforma los datos en Google Cloud, consulte el artículo Cargar datos con una herramienta de ETL para obtener más información sobre las opciones disponibles.

Extraer el esquema y los datos en archivos

Es probable que tu plataforma actual proporcione una herramienta para exportar datos a un formato independiente del proveedor, como Apache AVRO o CSV. Para reducir la complejidad de la transferencia, le recomendamos que utilice AVRO, ORC o Parquet, donde la información del esquema se inserta en los datos. Si elige el formato CSV o un formato de datos delimitados sencillo similar, debe especificar el esquema por separado. La forma de hacerlo depende del método de transferencia de datos que elijas. Por ejemplo, en la subida por lotes, puedes especificar un esquema en el momento de la carga o permitir la detección automática del esquema en función del contenido del archivo CSV.

A medida que extraigas estos archivos de tu plataforma, cópialos en el almacenamiento provisional de tu entorno.

Subir los archivos a Cloud Storage

A menos que uses BigQuery Data Transfer Service para cargar datos directamente desde un almacén de datos de Amazon Redshift o Teradata, debes subir los archivos extraídos a un segmento de Cloud Storage. En función de la cantidad de datos que transfieras y del ancho de banda de la red disponible, puedes elegir entre las siguientes opciones de transferencia:

Si los datos extraídos están en otro proveedor de la nube, usa el Servicio de transferencia de Storage.
Si los datos se encuentran en un entorno local o en un centro de datos compartido que tiene un buen ancho de banda de red, utiliza Google Cloud CLI. La CLI de gcloud admite cargas paralelas multiproceso, se reanuda después de los errores y cifra el tráfico en tránsito por motivos de seguridad.
- Si no puedes usar la CLI de gcloud, puedes probar una herramienta de terceros de un partner de Google.
- Si el ancho de banda de tu red es limitado, puedes usar técnicas de compresión para limitar el tamaño de los datos o modificar tu conexión actual a Google Cloud para aumentar el ancho de banda.
Si no puedes conseguir suficiente ancho de banda de red, puedes realizar una transferencia sin conexión mediante un Transfer Appliance.

Cuando crees el segmento de Cloud Storage y transfieras datos a través de la red, minimiza la latencia de la red eligiendo la ubicación más cercana a tu centro de datos. Si es posible, elige la misma ubicación para el bucket que para el conjunto de datos de BigQuery.

Para obtener información detallada sobre las prácticas recomendadas al mover datos a Cloud Storage, incluido cómo estimar los costes, consulta Estrategias para transferir conjuntos de datos de gran volumen.

Cargar el esquema y los datos en BigQuery

Carga el esquema y los datos en BigQuery mediante una de las opciones descritas en Elegir un método de transferencia.

Para obtener más información sobre las cargas únicas, consulta el artículo Introducción a la carga de datos desde Cloud Storage en la documentación de BigQuery. Para obtener más información sobre las cargas programadas a intervalos regulares, consulta el artículo Información general sobre las transferencias de Cloud Storage de la documentación de BigQuery Data Transfer Service.

Cargar datos con una herramienta de ETL

Si tus datos necesitan más transformaciones a medida que se cargan en BigQuery, usa una de las siguientes opciones:

Cloud Data Fusion. Esta herramienta crea gráficamente flujos de procesamiento de datos de extracción, transformación y carga (ETL) y de extracción, carga y transformación (ELT) totalmente gestionados mediante una biblioteca de código abierto de conectores y transformaciones preconfigurados.
Dataflow. Esta herramienta define y ejecuta gráficos complejos de transformación y enriquecimiento de datos mediante el modelo Apache Beam. Dataflow no requiere servidor y Google lo gestiona por completo, lo que te da acceso a una capacidad de procesamiento prácticamente ilimitada.
Dataproc. Ejecuta clústeres de Apache Spark y Apache Hadoop en un servicio en la nube totalmente gestionado.
Herramientas de terceros. Ponte en contacto con uno de nuestros partners. Pueden ofrecer opciones eficaces cuando quieras externalizar la creación de un flujo de datos.

En el siguiente diagrama se muestra el patrón descrito en esta sección. La herramienta de transferencia de datos es la CLI de gcloud, y hay un paso de transformación que aprovecha Dataflow y escribe directamente en BigQuery, quizás usando el conector de E/S de Google BigQuery integrado de Apache Beam.

El almacén de datos copia los datos en un almacenamiento temporal local. La CLI de gcloud copia los datos en un segmento de Cloud Storage. Dataflow lee los datos del bucket de almacenamiento provisional y los mueve a BigQuery.

Una vez que hayas cargado un conjunto inicial de tus datos en BigQuery, podrás empezar a aprovechar las potentes funciones de BigQuery.

Sin embargo, al igual que cuando transfieres tu esquema, la subida de datos forma parte de un proceso iterativo. En las iteraciones posteriores, se puede empezar ampliando la cobertura de los datos que se transfieren a BigQuery. Después, puede redirigir sus feeds de datos ascendentes a BigQuery para no tener que mantener en funcionamiento su almacén de datos. Estos temas se tratan en la siguiente sección.

Validar los datos

Ahora que tus datos están en BigQuery, puedes verificar que la transferencia de datos se ha realizado correctamente con la herramienta de validación de datos (DVT). DVT es una herramienta de CLI de Python de código abierto que te permite comparar datos de varias fuentes con tu destino en BigQuery. Puede especificar las agregaciones que quiere ejecutar (por ejemplo, recuento, suma o media) y las columnas a las que se deben aplicar. Para obtener más información, consulta el artículo Automatizar la validación de datos con DVT.

Iterar en la transferencia inicial

En esta sección se explica cómo proceder después de la transferencia de datos inicial para sacar el máximo partido a BigQuery.

Ahora, una parte de tus datos está en BigQuery. Estás preparando un aumento de la superficie de los datos que se usan en BigQuery y, por lo tanto, una reducción de la dependencia de tu almacén de datos.

El método que elijas para las iteraciones posteriores dependerá de la importancia que tenga para tu caso práctico que los datos se actualicen al segundo actual. Si tus analistas de datos pueden trabajar con datos que se incorporan al almacén de datos a intervalos recurrentes, la opción programada es la más adecuada. Puedes crear transferencias programadas de forma similar a la transferencia inicial. Utiliza BigQuery Data Transfer Service, otras herramientas de ETL, como Storage Transfer Service de Google, o implementaciones de terceros.

Si usas BigQuery Data Transfer Service, primero debes decidir qué tablas quieres mover. A continuación, crea un patrón de nombre de tabla para incluir esas tablas. Por último, establece una programación periódica para ejecutar la transferencia.

Por otro lado, si tu caso práctico requiere un acceso casi instantáneo a datos nuevos, necesitas un enfoque de streaming. Dispones de dos opciones:

Configura una canalización de carga con Google Cloud productos. Google ofrece un conjunto de plantillas de Dataflow de streaming para facilitar esta tarea.
Usa una solución de uno de nuestros partners.

A corto plazo, el aumento de la superficie de tus datos de BigQuery y de su uso en procesos posteriores debe centrarse en satisfacer tus casos prácticos de máxima prioridad, con el objetivo a medio plazo de dejar de usar tu almacén de datos actual. Usa las iteraciones iniciales con prudencia y no dediques muchos recursos a perfeccionar los flujos de procesamiento de datos de tu almacén de datos a BigQuery. En última instancia, tendrás que adaptar esas canalizaciones para que no usen el almacén de datos actual.

Optimizar el esquema

Si migras tus tablas tal cual a BigQuery, podrás aprovechar sus funciones únicas. Por ejemplo, no es necesario reconstruir índices, reorganizar bloques de datos (limpieza) ni sufrir tiempos de inactividad o degradación del rendimiento debido a las actualizaciones de versión.

Sin embargo, mantener intacto el modelo del almacén de datos más allá de las iteraciones iniciales de la migración también tiene desventajas:

Los problemas y la deuda técnica asociados al esquema siguen existiendo.
Las optimizaciones de consultas son limitadas y es posible que deban rehacerse si el esquema se actualiza más adelante.
No aprovechas al máximo otras funciones de BigQuery, como los campos anidados y repetidos, el particionado y el agrupamiento en clústeres.

Cuando te acerques a la transferencia final, te recomendamos que mejores el rendimiento del sistema aplicando particiones y clústeres a las tablas que crees en tu esquema.

Particiones

BigQuery te permite dividir tus datos en segmentos, llamados particiones, para que te resulte más fácil y eficiente gestionar y consultar tus datos. Puedes particionar tus tablas en función de una columna de TIMESTAMP o de DATE, o bien BigQuery puede añadir pseudocolumnas para particionar automáticamente tus datos durante la ingestión. Las consultas que implican particiones más pequeñas pueden ser más eficientes porque solo analizan un subconjunto de los datos y pueden reducir los costes minimizando el número de bytes que se leen.

La partición no afecta a la estructura de las tablas. Por lo tanto, te recomendamos que crees tablas con particiones aunque no modifiques el esquema.

Agrupamiento en clústeres

En BigQuery, no se usan índices para consultar los datos. El rendimiento de BigQuery se optimiza gracias a su modelo, sus técnicas de almacenamiento y de consulta, y su arquitectura masivamente paralela. Cuando ejecutas una consulta, cuantos más datos se procesen, más máquinas se añadirán para analizar los datos y agregar los resultados simultáneamente. Esta técnica se adapta bien a conjuntos de datos enormes, mientras que la reconstrucción de índices no.

Sin embargo, se pueden optimizar aún más las consultas con técnicas como el clustering. Con la creación de clústeres, BigQuery ordena automáticamente los datos según los valores de las columnas que especifiques y los coloca en bloques de tamaño óptimo. El agrupamiento en clústeres mejora el rendimiento de las consultas en comparación con la situación en la que no se utiliza. Con la creación de clústeres, BigQuery puede estimar mejor el coste de ejecutar la consulta que sin ella. Con las columnas agrupadas, las consultas también eliminan los análisis de datos innecesarios y pueden calcular agregaciones más rápido porque los bloques colocan los registros con valores similares.

Examina tus consultas para ver qué columnas se usan con frecuencia para filtrar y crea tus tablas con clustering en esas columnas. Para obtener más información sobre la agrupación en clústeres, consulta el artículo Introducción a las tablas agrupadas en clústeres.

Desnormalización

La migración de datos es un proceso iterativo. Por lo tanto, una vez que hayas migrado tu esquema inicial a la nube, hayas realizado optimizaciones sencillas y hayas probado algunos casos prácticos clave, puede que sea el momento de explorar otras funciones que se beneficien del diseño subyacente de BigQuery. Entre ellos, se incluyen los campos anidados y repetidos.

Históricamente, los esquemas de almacén de datos han usado los siguientes modelos:

Esquema de estrella Se trata de un modelo desnormalizado en el que una tabla de hechos recoge métricas como el importe del pedido, el descuento y la cantidad, junto con un grupo de claves. Estas claves pertenecen a tablas de dimensiones, como cliente, proveedor, región, etc. Gráficamente, el modelo se parece a una estrella, con la tabla de hechos en el centro rodeada de tablas de dimensiones.
Esquema en copo de nieve Es similar al esquema de estrella, pero con sus tablas de dimensiones normalizadas, lo que le da al esquema el aspecto de un copo de nieve único.

BigQuery admite esquemas de estrella y de copo de nieve, pero su representación de esquema nativa no es ninguna de esas dos. En su lugar, usa campos anidados y repetidos para representar los datos de forma más natural. Para obtener más información, consulta el esquema de ejemplo en la documentación de BigQuery.

Cambiar el esquema para usar campos anidados y repetidos es una excelente opción evolutiva. Reduce el número de combinaciones necesarias para tus consultas y alinea tu esquema con la representación interna de los datos de BigQuery. Internamente, BigQuery organiza los datos mediante el modelo Dremel y los almacena en un formato de almacenamiento en columnas llamado Capacitor.

Para decidir cuál es el mejor enfoque de desnormalización en tu caso, ten en cuenta cómo usar campos anidados y repetidos en BigQuery, así como las técnicas para gestionar los cambios de esquema.

Siguientes pasos

Consulta más información sobre los siguientes pasos de la migración de almacenes de datos:

También puedes consultar información sobre cómo migrar a BigQuery desde tecnologías de almacén de datos específicas: