Descripción general de transferencia de datos y esquemas

En este documento, se analizan los conceptos y las tareas para transferir el esquema y los datos desde tu almacén de datos existente hasta BigQuery.

La migración de tu almacén de datos a la nube es un proceso complejo que requiere planificación, recursos y tiempo. Para dominar esta complejidad, debes abordar la migración del almacén de datos por etapas y de manera iterativa. Realizar varias iteraciones de la migración del esquema y los datos puede mejorar el resultado.

Proceso de migración del esquema y los datos

Al comienzo de tu migración, tienes sistemas ascendentes que realizan el feed de tu almacén de datos existente y sistemas descendentes que utilizan esos datos en informes, paneles y como feeds de otros procesos.

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

Estado inicial antes de la migración

El estado final de tu recorrido es tener tantos casos prácticos como sea posible en ejecución sobre BigQuery. Este estado te permite minimizar el uso de tu almacén de datos existente y, finalmente, eliminarlo. Para controlar qué casos prácticos se migran y cuándo, priorízalos durante la fase de preparación y descubrimiento de la migración.

Transfiere el esquema y los datos a BigQuery

En la fase de planificación de la migración, identificas los casos de uso que deseas migrar. Luego comienzas las iteraciones de migración en la fase de ejecución. Para administrar tus iteraciones mientras ejecutas tu entorno de estadísticas con una interrupción mínima, completa el proceso de alto nivel siguiente:

Transfiere tablas y configura y prueba procesos descendentes.
- Transfiere el grupo de tablas para cada caso práctico a BigQuery sin ningún cambio mediante el Servicio de transferencia de datos de BigQuery o de 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 descendentes para leer desde las tablas de BigQuery.
Este paso inicial divide el flujo de datos. En el diagrama siguiente, se muestra la infraestructura resultante. Algunos sistemas descendentes ahora realizan lecturas en BigQuery, como se muestra en los flujos que tienen la etiqueta B. Otros aún realizan lecturas en el almacén de datos existente, como se muestra en los flujos que tienen la etiqueta A.
Configura algunos procesos ascendentes de prueba para escribir datos en tablas de BigQuery en lugar (o además) del almacén de datos existente.

Después de las pruebas, configura tus procesos ascendentes y descendentes de producción para que escriban y lean en las tablas de BigQuery. Estos procesos pueden conectarse a BigQuery mediante la API de BigQuery y también incorporar nuevos productos de Cloud como Looker Studio y Dataflow.

En este punto, tienes los tres flujos de datos siguientes:
1. Existente. Los datos y procesos no se modifican y aún se centran en tu almacén de datos existente.
2. Descargado. Los procesos ascendentes realizan el feed de tu almacén de datos existente, los datos se descargan en BigQuery y, luego, realizan el feed de los procesos descendentes.
3. Totalmente migrado. Los procesos ascendentes y descendentes ya no escriben ni leen desde el almacén de datos existente.
  El diagrama siguiente muestra un sistema con los tres flujos siguientes:
Selecciona casos prácticos adicionales para la migración y, luego, ve al paso 1 a fin de comenzar una nueva iteración de ejecución. Continúa la iteración a través de estos pasos hasta que todos tus casos prácticos se migren completamente a BigQuery. Cuando seleccionas casos prácticos, puedes revisar los que permanecieron en el estado descargado para moverlos a los migrados por completo. Para los casos de uso que se migran por completo, considera continuar el proceso de evolución según los lineamientos de Evoluciona tu esquema en BigQuery.

Evoluciona tu esquema en BigQuery

El esquema del almacén de datos define cómo están estructurados tus datos y define las relaciones entre tus entidades de datos. Este esquema está en el núcleo de tu diseño de datos y además influye en muchos procesos, tanto ascendentes como descendentes.

Una migración del almacén de datos es una oportunidad única para desarrollar tu esquema después de que se haya movido a BigQuery. En esta sección, se presentan pautas para desarrollar tu esquema mediante una serie de pasos. Estas te ayudan a mantener tu entorno de almacén de datos en ejecución durante los cambios de esquema con una interrupción mínima de los procesos ascendentes y descendentes.

Los pasos de esta sección se enfocan en la transformación del 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 esté completamente evolucionado.

Transfiere un caso práctico como está a BigQuery.

Antes de continuar con los pasos siguientes, asegúrate de que los procesos ascendentes y descendentes de tu caso práctico ya escriban y lean desde BigQuery. Sin embargo, también es posible comenzar desde un estado intermedio donde solo se lee el proceso descendente desde BigQuery. En este caso, aplica solo las pautas para la parte descendente. En el diagrama siguiente, se ilustra un caso práctico en el que los procesos ascendentes y descendentes escriben y leen desde tablas en BigQuery.
Aplica optimizaciones de luz.
1. Vuelve a crear tus tablas mediante la aplicación de particiones y agrupaciones en clústeres. Para esta tarea, puedes usar el método que permite crear una tabla a partir de un resultado de la consulta. Si deseas obtener detalles, consulta la discusión y el ejemplo para las tablas particionadas, y la discusión y el ejemplo para las tablas agrupadas en clústeres.
2. Redirecciona tus procesos ascendentes y descendentes a las tablas nuevas.
Crea vistas de fachada

Si deseas evolucionar tu esquema más allá de las optimizaciones de luz, crea vistas de fachada para tus tablas. El patrón de fachada es un método de diseño que enmascara el código o las estructuras subyacentes para ocultar la complejidad. En este caso, las vistas de fachada enmascaran las tablas subyacentes para ocultar la complejidad causada por los cambios en la tabla de los procesos descendentes.

Las vistas pueden describir un esquema nuevo, libre de deudas técnicas, y modelado con la contemplación de situaciones nuevas de transferencia y consumo.

Debajo de la cubierta, las tablas y la definición de la consulta de vista pueden cambiar. Sin embargo, las vistas abstraen estos cambios como un detalle de implementación interna de tu almacén de datos y siempre muestran 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 corresponde.
Transforma los procesos descendentes.

Puedes transformar algunos de tus procesos descendentes para leer desde las vistas de fachada en lugar de hacerlo desde las tablas reales. Estos procesos ya se beneficiarán del esquema evolucionado. Esto es transparente para los procesos bajo la cubierta; las vistas de fachada todavía obtienen sus datos del esquema existente de BigQuery, como se muestra en el diagrama siguiente:

Primero describimos la transformación del proceso descendente. Esto te permite mostrar el valor comercial a modo de paneles o informes migrados de forma más rápida que si transformaras procesos ascendentes no para las partes interesadas no técnicas. Sin embargo, es posible iniciar la transformación con los procesos ascendentes. La prioridad de estas tareas depende completamente de tus necesidades.
Transforma los procesos ascendentes.

Puedes transformar algunos de tus procesos ascendentes para escribir en el nuevo esquema. Debido a que las vistas son de solo lectura, las tablas que creas están basadas en el esquema nuevo y, luego, modificas 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 diagrama siguiente:

En este punto, puedes aprovechar los campos anidados y repetidos cuando creas las tablas nuevas. Esto te permite desnormalizar aún más tu modelo y aprovechar directamente la representación en columnas subyacente para los datos de BigQuery.

Un beneficio de las vistas de fachada es que los procesos descendentes pueden continuar su transformación independientemente de estos cambios de esquema subyacentes y de los cambios en los procesos ascendentes.
Evoluciona completamente tu caso práctico.

Por último, puedes transformar los procesos ascendentes y descendentes restantes. Cuando todos estos elementos evolucionan para escribir en las tablas nuevas y leer desde las vistas de fachada nuevas, modificas las definiciones de consulta de las vistas de fachada para que ya no se lean desde el esquema de origen. A continuación, puedes retirar las tablas del modelo de origen del flujo de datos. El diagrama siguiente 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, puedes configurar tus procesos descendentes para leer desde las tablas evolucionadas y, luego, retirar las vistas de fachada a fin de reducir la complejidad, como se muestra en el diagrama siguiente:

Realiza una transferencia inicial de tu esquema y tus datos

En esta sección, se analizan consideraciones prácticas para migrar tu esquema y tus datos de un almacén de datos existente a BigQuery.

Recomendamos que transfieras el esquema sin ningún cambio durante las iteraciones iniciales de la migración. Esto te brinda las siguientes ventajas:

Las canalizaciones de datos que alimentan tu almacén de datos no necesitan ajustarse para un nuevo esquema.
Evitas agregar un nuevo esquema a la lista de material de entrenamiento para tu personal.
Puedes aprovechar las herramientas automatizadas para realizar la transferencia del esquema y los datos.

Además, las pruebas de concepto (PoC) y otras actividades de exploración de datos que aprovechan las capacidades de nube pueden continuar sin obstáculos, incluso cuando la migración se realiza en paralelo.

Elige un método de transferencia

Puedes realizar la transferencia inicial mediante uno de varios enfoques.

Para almacenes de datos de Amazon Redshift y Teradata, puedes usar el Servicio de transferencia de datos de BigQuery a fin de cargar el esquema y los datos directamente desde tu sistema existente a BigQuery. Cloud Storage aún se usa para almacenar los datos en etapa intermedia como parte del proceso de migración.
Para cualquier almacén de datos, puedes extraer archivos que contengan tu esquema y tus datos, subir esos archivos a Cloud Storage y, luego, usar una de las siguientes opciones a fin de cargar el esquema y los datos de esos archivos en BigQuery:

Para obtener más consideraciones sobre la elección de un método de transferencia de datos, consulta Elige un método de transferencia de datos.

Considera la transformación de datos

Según tu formato de extracción de datos y si deseas recortar o enriquecer tus datos antes de cargarlos en BigQuery, puedes incluir un paso para transformar tus datos. Puedes transformar los datos en el entorno existente o en Google Cloud:

Si transformas los datos en el entorno actual, considera cómo la capacidad de procesamiento y las herramientas disponibles pueden limitar la capacidad de procesamiento. Además, si enriqueces los datos durante el proceso de transformación, considera si necesitas tiempo de transferencia adicional o ancho de banda de red.
Si transformas los datos en Google Cloud, consulta Cargar datos con una herramienta de ETL para obtener más información sobre las opciones.

Extrae el esquema y los datos existentes en archivos

Es probable que tu plataforma existente proporcione una herramienta para exportar datos a un formato independiente del proveedor, como Apache AVRO o CSV. Para reducir la complejidad de la transferencia, recomendamos usar AVRO, ORC o Parquet, donde la información del esquema se incorpora en los datos. Si eliges CSV o un formato de datos simple y delimitado similar, debes especificar el esquema por separado. La forma de hacerlo depende del método de transferencia de datos que selecciones. Por ejemplo, para la carga 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 existente, cópialos en el almacenamiento en etapa intermedia de tu entorno existente.

Sube los archivos a Cloud Storage

A menos que uses el Servicio de transferencia de datos de BigQuery para cargar datos directamente desde un almacén de datos existente de Amazon Redshift o Teradata, debes subir los archivos extraídos a un bucket en Cloud Storage. Según la cantidad de datos que transfieras y el ancho de banda de red disponible, puedes elegir entre las siguientes opciones de transferencia:

Si los datos extraídos se encuentran en otro proveedor de servicios en la nube, usa el Servicio de transferencia de almacenamiento.
Si los datos se encuentran en un entorno local o en una instalación de colocación que tiene un buen ancho de banda de red, usa la herramienta de gsutil. La herramienta de gsutil admite cargas paralelas de varios subprocesos, se reanuda después de errores y encripta el tráfico en tránsito por seguridad.
- Si no puedes usar gsutil, puedes probar una herramienta de terceros de un socio 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 bien modificar tu conexión actual a Google Cloud para aumentar el ancho de banda.
Si no puedes lograr suficiente ancho de banda de red, puedes realizar una transferencia sin conexión mediante un dispositivo de transferencia.

Cuando creas el bucket de Cloud Storage y transfieres datos a través de la red, minimizas la latencia de la red mediante la elección de la ubicación más cercana a tu centro de datos. Si es posible, elige la ubicación del depósito para que sea la misma que la ubicación del conjunto de datos de BigQuery.

Si deseas obtener información detallada sobre las prácticas recomendadas con el fin de mover datos a Cloud Storage, incluida la estimación de costos, consulta Estrategias para transferir conjuntos de macrodatos.

Carga el esquema y los datos en BigQuery

Carga el esquema y los datos en BigQuery mediante una de las opciones que se analizan en Elige un método de transferencia.

Para obtener más información sobre cargas únicas, consulta 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 Descripción general de las transferencias de Cloud Storage en la documentación del Servicio de transferencia de datos de BigQuery.

Carga datos con una herramienta de ETL

Si tus datos necesitan una transformación mayor mientras se cargan en BigQuery, usa una de las siguientes opciones:

Cloud Data Fusion. Esta herramienta construye de manera gráfica canalizaciones de datos de ETL/ELT completamente administradas mediante una biblioteca de código abierto de conectores y transformaciones preconfigurados.
Dataflow. Esta herramienta define y ejecuta transformaciones de datos complejas y grafos de enriquecimiento mediante el modelo Apache Beam. Dataflow es una herramienta sin servidores y está completamente administrada por Google, lo que te brinda acceso a una capacidad de procesamiento prácticamente ilimitada.
Dataproc. Esta herramienta ejecuta el clúster de Apache Spark y Apache Hadoop en un servicio en la nube completamente administrado.
Herramientas de terceros. Contacta a uno de nuestros socios. Te pueden proporcionar opciones eficaces para cuando desees externalizar la compilación de una canalización de datos.

El diagrama siguiente muestra el patrón que se describe en esta sección. La herramienta de transferencia de datos es gsutil, hay un paso de transformación que aprovecha Dataflow y los escribe directamente en BigQuery, tal vez con usar Apache Beam integrado al conector de E/S de Google BigQuery.

El almacén de datos existente copia los datos en el almacenamiento temporal local. La herramienta de gsutil copia los datos en un bucket de Cloud Storage. Dataflow lee datos desde el bucket de etapa de pruebas y los traslada a BigQuery.

Después de cargar un conjunto inicial de datos en BigQuery, puedes comenzar a aprovechar las potentes características de BigQuery.

Sin embargo, como cuando transferiste tu esquema, subir los datos es parte de un proceso iterativo. Las iteraciones posteriores pueden comenzar por expandir la huella de los datos que se transfieren a BigQuery. Luego, puedes redirigir tus feeds de datos ascendentes a BigQuery para eliminar la necesidad de mantener tu almacén de datos existente en ejecución. Estos temas se exploran en la sección siguiente.

Valida los datos

Ahora que tus datos están en BigQuery, puedes usar la Herramienta de validación de datos (DVT) para verificar que tu transferencia de datos se ejecutó correctamente. DVT es una herramienta de código abierto de la CLI de Python que te permite comparar datos de varias fuentes con tu destino en BigQuery. Puedes especificar qué agregaciones te gustaría ejecutar (p. ej., recuento, suma, promedio) y las columnas a las que se deben aplicar. Para obtener más información, consulta Automatiza la validación de datos con DVT.

Itera en la transferencia inicial

Esta sección analiza cómo proceder después de la transferencia de datos inicial para aprovechar BigQuery al máximo.

Un subconjunto de tus datos ahora está en BigQuery. Te preparas para aumentar la huella de los datos que se utilizan en BigQuery y, en consecuencia, reducir la dependencia de tu almacén de datos existente.

El método que elijas en iteraciones posteriores dependerá de la importancia que tenga para tu caso de uso la actualización de los datos al segundo actual. Si tus analistas de datos pueden trabajar con datos que se incorporan al almacén de datos en intervalos recurrentes, necesitas una opción programada. Puedes crear transferencias programadas de manera similar a la transferencia inicial. Utilizas el Servicio de transferencia de datos de BigQuery, otras herramientas de ETL, como el Servicio de transferencia de almacenamiento de Google, o implementaciones de terceros.

Si usas el Servicio de transferencia de datos de BigQuery, primero debes decidir qué tablas mover. A continuación, creas un patrón de nombre de tabla para incluir esas tablas. Por último, estableces un cronograma recurrente para el momento de ejecutar la transferencia.

Por otro lado, si tu caso práctico requiere acceso casi instantáneo a datos nuevos, necesitas un enfoque de transmisión. Tienes estas dos opciones:

Configura una canalización de carga con los productos de Google Cloud. Google proporciona un conjunto de plantillas de Dataflow de transmisión para facilitar esta tarea.
Usa una solución de uno de nuestros socios.

A corto plazo, el aumento de la huella de tus datos de BigQuery y de su uso para el proceso descendente debe enfocarse en satisfacer tus casos prácticos de máxima prioridad, con el objetivo a medio plazo de alejarse de tu almacén de datos existente. Usa las iteraciones iniciales de forma sabia y no gastes una gran cantidad de recursos para perfeccionar las canalizaciones de transferencia de tu almacén de datos existente en BigQuery. En última instancia, deberás adaptar las canalizaciones para no usar el almacén de datos existente.

Optimiza el esquema

Tan solo migrar tus tablas como están a BigQuery te permite aprovechar sus funciones únicas. Por ejemplo, no es necesario volver a compilar índices, redistribuir bloques de datos (limpiarlos), o experimentar algún tiempo de inactividad o degradación del rendimiento debido a las actualizaciones de la versión.

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

Los problemas existentes y la deuda técnica asociada con el esquema no se resuelven.
Las optimizaciones de consultas son limitadas y es posible que deban rehacerse si el esquema se actualiza en una etapa posterior.
No aprovechas al máximo otras características de BigQuery, como campos anidados y repetidos, partición y agrupamiento en clústeres.

A medida que avanzas hacia una transferencia final, te recomendamos que mejores el rendimiento del sistema mediante la aplicación de la partición y el agrupamiento en clústeres de las tablas que creas en tu esquema.

Partición

BigQuery te permite dividir tus datos en segmentos, llamados particiones, que facilitan y hacen más eficiente la administración y consulta de tus datos. Puedes particionar tus tablas en función de una columna TIMESTAMP o DATE, o BigQuery puede agregar seudocolumnas para particionar automáticamente tus datos durante la transferencia. Las consultas que involucran particiones más pequeñas pueden ser más eficaces porque escanean solo un subconjunto de los datos y pueden reducir los costos, dado que minimizan el número de bytes que se leen.

La partición no afecta la estructura existente de tus tablas. Por lo tanto, debes considerar crear tablas particionadas incluso si tu esquema no se modifica.

Agrupamiento en clústeres

En BigQuery, no se utilizan índices para consultar tus datos. El rendimiento de BigQuery está optimizado por su modelo subyacente, sus técnicas de almacenamiento y consulta, y su arquitectura masivamente paralela. Cuando ejecutas una consulta, mientras más datos se procesan, más máquinas se adicionan para escanear datos y agregar resultados simultáneamente. Esta técnica se adapta bien a grandes conjuntos de datos, mientras que la nueva compilación de índices no lo hace.

Sin embargo, hay más posibilidades de optimizar las consultas con técnicas como la agrupación en clústeres. Con la agrupación en clústeres, BigQuery clasifica automáticamente tus datos en función de los valores de algunas columnas que especificas y los coloca en bloques de tamaño óptimo. La agrupación en clústeres mejora el rendimiento de la consulta en comparación con su omisión. Con la agrupación en clústeres, BigQuery puede estimar mejor el costo de ejecutar la consulta que con otro tipo de optimización. Con las columnas agrupadas en clústeres, las consultas también eliminan los análisis de datos innecesarios y pueden calcular los agregados más rápido porque los bloques colocan registros con valores similares.

Examina tus consultas de columnas que se usan con frecuencia para filtrar y crear tus tablas con la agrupación en clústeres en esas columnas. La agrupación en clústeres requiere tablas particionadas y también se define en el momento de la creación de la tabla.

Desnormalización

La migración de datos es un proceso iterativo. Por lo tanto, una vez que moviste tu esquema inicial a la nube, realizaste optimizaciones ligeras y probaste algunos casos prácticos, podría ser hora de explorar funciones adicionales que se beneficien del diseño subyacente de BigQuery. Estas incluyen campos anidados y repetidos.

Los esquemas de almacenamiento de datos históricamente han utilizado los modelos siguientes:

Esquema en estrella. Este es un modelo desnormalizado, en el que una tabla de hechos recopila 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étera. Gráficamente, el modelo se asemeja a una estrella, con la tabla de hechos en el centro rodeada de tablas de dimensiones.
Esquema en copo de nieve. Este es similar al esquema en estrella, pero con sus tablas de dimensiones normalizadas, lo que le da al esquema la apariencia de un copo de nieve único.

BigQuery admite esquemas en estrella y copo de nieve, pero su representación de esquema nativo no es ninguno de esos dos. En su lugar, utiliza campos anidados y repetidos para una representación más natural de los datos. 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 la cantidad de uniones requeridas para tus consultas y alinea tu esquema con la representación de datos internos de BigQuery. Internamente, BigQuery organiza los datos mediante el modelo de Dremel y los almacena en un formato de almacenamiento de columnas llamado Capacitor.

Para decidir el mejor enfoque de desnormalización en tu caso, considera las siguientes prácticas recomendadas para la desnormalización en BigQuery, así como las técnicas para manejar cambios de esquema.

¿Qué sigue?

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

También puedes obtener información sobre cómo pasar de tecnologías de almacenamiento de datos específicas a BigQuery: