Migra almacenes de datos a BigQuery: descripción general de la transferencia del esquema y los datos

Este documento es parte de una serie que te ayuda a pasar de un almacén de datos local a BigQuery en Google Cloud. En esta parte, se analizan los conceptos y las tareas para transferir el esquema y los datos desde tu almacén de datos existente hasta BigQuery.

Los documentos de la serie incluyen las partes siguientes:

Introducción

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. En este documento, se explora el primer paso en la fase de ejecución de la migración, es decir, el movimiento de tu esquema y datos. También se analiza cómo otras iteraciones de este paso pueden mejorar el resultado.

Para obtener una descripción general de las diferentes fases de la migración, consulta el documento Introducción y descripción general de esta serie.

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 heredado 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 heredado 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.

Migra los datos y el esquema del sistema local a BigQuery

En la fase de evaluación y planificación de la migración, identificas los casos prácticos 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:

  1. 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 heredado, como se muestra en los flujos que tienen la etiqueta A.

    Los procesos ascendentes realizan el feed en el almacén heredado. Algunos van a procesos descendentes, pero otros van a BigQuery mediante el Servicio de transferencia de datos de BigQuery y, desde allí, a diferentes procesos descendentes.

  2. Configura algunos procesos ascendentes de prueba para escribir datos en tablas de BigQuery en lugar (o además) de la base de datos heredada.

    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 Google Data Studio y Dataflow.

    En este punto, tienes los tres flujos de datos siguientes:

    1. Heredado. Los datos y procesos no se modifican y aún se centran en tu almacén de datos heredado.
    2. Descargado. Los procesos ascendentes realizan el feed de tu almacén de datos heredado, 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 heredado.

      El diagrama siguiente muestra un sistema con los tres flujos siguientes:

      Flujo de cargas de trabajo a través de varias rutas de acceso
  3. 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 prácticos que se migraron por completo, considera continuar el proceso de evolución según las pautas relativas a la evolución de tu esquema en BigQuery.

    Último paso de los casos prácticos migrados

Evoluciona tu esquema en BigQuery

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.

  1. Transfiere un caso práctico como está a BigQuery. Sigue los pasos descritos en la sección anterior para un caso práctico determinado.

    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.

    Los procesos ascendentes realizan el feed en las tablas de BigQuery y, a partir de allí, en los procesos descendentes.

  2. 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.
  3. 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.

  4. 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 heredado de BigQuery, como se muestra en el diagrama siguiente:

    Los procesos ascendentes realizan el feed en las tablas de BigQuery. Algunos realizan el feed en procesos posteriores. Otros realizan el feed en vistas de fachada que, a su vez, lo hacen en procesos evolutivos descendentes.

    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.

  5. 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 heredado, 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:

    Los procesos ascendentes realizan el feed en las tablas de BigQuery, pero ya no lo hacen en los procesos descendentes. En cambio, las tablas BigQuery realizan el feed en vistas de fachada que, a su vez, lo hacen en procesos evolutivos descendentes.

    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.

  6. 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 heredado. A continuación, puedes retirar las tablas del modelo heredado del flujo de datos. El diagrama siguiente muestra el estado en el que ya no se usan las tablas heredadas.

    Los procesos ascendentes originales ya no están en uso. Solo quedan procesos ascendentes evolucionados, que realizan el feed en tablas evolucionadas; estas, en vistas de fachada; y las vistas de fachada, en todos los procesos descendentes.

    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:

    En la configuración final, tanto las tablas de BigQuery como las evolucionadas realizan el feed en vistas de fachada, que son la única fuente para los procesos descendentes.

Transfiere tus datos

En esta sección, se analizan consideraciones prácticas para migrar tus datos desde un almacén de datos heredado hasta BigQuery.

Transferencia de datos inicial

Puedes realizar la transferencia de datos inicial mediante uno de varios enfoques.

Uso del Servicio de transferencia de datos de BigQuery

El Servicio de transferencia de datos de BigQuery es un producto completamente administrado que está respaldado por un ANS de tiempo de actividad y un ANS de entrega de datos. Para transferir tus datos con el Servicio de transferencia de datos de BigQuery, completa los pasos siguientes:

  1. En Google Cloud, crea un proyecto, habilita las API necesarias y configura los permisos y un conjunto de datos de destino.
  2. En BigQuery, configura una transferencia del Servicio de transferencia de datos de BigQuery, en la que especifiques el conjunto de datos de destino y otros parámetros, y obtiene un nombre de recurso como identificador de transferencia.
  3. En las instalaciones, instala el agente de migración de BigQuery. A continuación, inicialízalo con el nombre del recurso para que el agente apunte a la transferencia del Servicio de transferencia de datos de BigQuery que acabas de configurar.
  4. Ejecuta el agente de forma local. El agente se comunica automáticamente a través de JDBC con tu almacén de datos, extrae el esquema y los datos, y los entrega al Servicio de transferencia de datos de BigQuery que, a su vez, los escribe en el conjunto de datos de BigQuery correspondiente.

En el diagrama siguiente, se muestra una descripción general de la transferencia mediante el Servicio de transferencia de datos de BigQuery:

El almacén heredado utiliza el agente de migración local de BigQuery y el Servicio de transferencia de datos de BigQuery en Google Cloud para transferir datos a BigQuery.

El Servicio de transferencia de datos de BigQuery no solo puede extraer, transferir y cargar datos, sino también crear las tablas necesarias en el conjunto de datos de destino de BigQuery mediante la duplicación del esquema desde la fuente. Esta es una función conveniente para una transferencia rápida y completamente automatizada durante las iteraciones de migración iniciales.

Para obtener un instructivo paso a paso sobre cómo ejecutar una transferencia de datos mediante el Servicio de transferencia de datos de BigQuery, consulta el esquema y la guía de inicio rápido de la transferencia de datos.

Usa otras herramientas de ETL

Para los casos en los que no es posible o no deseas instalar el agente de migración local, Google Cloud ofrece numerosas alternativas para transferir tus datos a BigQuery. El patrón es el siguiente:

  1. Extraes los datos desde tu fuente hasta un almacenamiento local intermedio.
  2. Utilizas una herramienta de tu elección para transferir los datos hasta un bucket de staging de Cloud Storage.
  3. Usas una herramienta nativa de Google Cloud para cargar datos desde el bucket a BigQuery.

El diagrama siguiente muestra este flujo:

El almacén heredado copia los datos en el almacenamiento temporal local. Una herramienta de transferencia de datos copia los datos en un bucket de Cloud Storage. Una herramienta de transformación de datos realiza la comunicación entre el bucket y BigQuery.

Según tu formato de extracción de datos y si deseas recortar o enriquecer tus datos antes de cargarlos en BigQuery, es posible que necesites un paso de transformación de datos en la canalización. El paso de transformación se puede ejecutar localmente o en Google Cloud:

  • Si el paso de transformación se ejecuta localmente, considera cómo la capacidad de cálculo y las herramientas disponibles pueden limitar el rendimiento. Además, si el proceso de transformación enriquece los datos, considera la necesidad de tiempo de transferencia adicional o el ancho de banda de red.
  • Si el paso de transformación se ejecuta en Google Cloud, puedes aprovechar una herramienta administrada como Dataflow o usar tus propias herramientas junto con Compute Engine o Google Kubernetes Engine (GKE). Sin embargo, si la transformación necesita acceder a recursos locales, debes establecer una conectividad híbrida para que tus recursos locales sean accesibles desde tu VPC de Google Cloud.

En las siguientes secciones, se supone que las transformaciones se realizan en Google Cloud.

Extrae los datos de la fuente

Es posible que la fuente proporcione una herramienta para exportar datos a un formato independiente del proveedor, como CSV o Apache AVRO. Si eliges CSV o un formato de datos delimitado simple similar, también debes extraer y transferir las definiciones de esquema de la tabla. Para reducir la complejidad de la transferencia, recomendamos utilizar AVRO o sistemas de serialización similares, en los que el esquema ya está incorporado con los datos. Por ejemplo, en el caso de Teradata, puedes definir una secuencia de comandos de exportación de Transportador paralelo (TPT) para extraer archivos Avro o CSV de las tablas de Teradata.

Como parte de este proceso, copia los archivos extraídos de tu fuente en el almacenamiento de staging de tu entorno local.

Transfiere los datos

Después de extraer los datos, transfiérelos a un bucket temporal en Cloud Storage. Según la cantidad de datos que transfieras y el ancho de banda de red disponible, puedes elegir entre las opciones de transferencia siguientes:

  • 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 gsutil. La herramienta 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 los datos en BigQuery

Tus datos se encuentran ahora en un bucket de Cloud Storage, más cerca de su destino. Hay varias opciones para subir los datos a BigQuery, según la cantidad de transformación que los datos deban atravesar. Estas opciones se pueden clasificar en los dos casos amplios siguientes:

  • El primer caso es cuando los datos están listos para transferirse desde Cloud Storage.

    Esto es común cuando se pueden extraer datos desde la fuente y no se requieren más transformaciones. También es común después de procesos de ETL complejos, en los que la transformación ya se ha realizado antes de transferir los datos a la nube.

    Como práctica recomendada en ambas situaciones, te sugerimos que produzcas los datos en un formato autodescriptivo como AVRO, ORC o Parquet. En ese caso, BigQuery admite directamente la transferencia de tus datos. Si no es posible producir datos en uno de esos formatos, puedes usar un formato no autodescriptivo, como CSV o JSON. Sin embargo, debes proporcionar una definición de esquema o usar la detección automática de esquemas de BigQuery.

    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.

  • El segundo caso es cuando aún se deben transformar los datos para poder cargarlos en BigQuery. Google y sus socios disponen, entre otras, de las herramientas de ETL siguientes:

    • 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 heredado 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. Y luego pueden redirigir tus fuentes de datos ascendentes para eliminar la necesidad de mantener tu almacén de datos heredado. Estos temas se exploran en la sección siguiente.

Aumenta la huella

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. Pasaste por las etapas posteriores con el objetivo de traducir y optimizar tus consultas. También modificaste tus casos prácticos en sentido descendente a fin de producir algunos informes y análisis con datos provenientes de 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 heredado.

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 a 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. Si deseas obtener más información, consulta sobre cómo configurar una transferencia en la documentación de BigQuery.

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:

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 fuente de datos heredada. Por lo tanto, usa las iteraciones iniciales sabiamente. No gastes una gran cantidad de recursos para perfeccionar las canalizaciones de transferencia de tu almacén de datos heredado en BigQuery; en última instancia, deberás adaptar las canalizaciones para no usar esa fuente de datos.

Transfiere tu esquema

El esquema del almacén de datos define cómo están estructurados tus datos y cuáles son 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.

¿Deberías planear la transformación de tu esquema cuando se mueva a la nube, o deberías mantenerlo sin cambios? Ambas opciones son posibles en BigQuery. Si tienes un esquema probado y verdadero que deseas conservar tal como está, te ofrecemos una ruta rápida y fácil. En ese caso, aún recomendamos optimizaciones ligeras para tu esquema que pueden generar beneficios tangibles de costo y rendimiento.

Por otro lado, si decides cambiar tu esquema para aprovechar al máximo las características de BigQuery, el esquema actualizado abre oportunidades adicionales para la optimización. Ofrecemos pautas sobre cómo hacer que esta transformación sea perfecta.

Transferencia de esquema inicial

Como se explica en la descripción general del proceso de migración, te recomendamos que realices la migración en iteraciones de etapas. Para el esquema, te sugerimos que, durante las iteraciones iniciales de la migración, transfieras el esquema sin ningún cambio. Este método tiene, entre otras, las ventajas siguientes:

  • 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.

El Servicio de transferencia de datos de BigQuery es ideal para automatizar el esquema y la migración de datos. Este Servicio puede leer datos de Teradata, Amazon S3, Google Ads, YouTube y otras fuentes, y transferirlos a BigQuery con el mínimo esfuerzo de tu parte.

Si no te es posible utilizar el Servicio de transferencia de datos de BigQuery, puedes exportar datos a un formato autodescriptivo independiente del proveedor, como Apache Avro y, luego, subirlo a Cloud Storage. BigQuery puede importar el esquema y crear las tablas requeridas. Para obtener más información sobre este enfoque, consulta la sección Transferencia de datos inicial de este documento.

Optimizaciones de luz

La migración de las tablas como están a BigQuery ya 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 heredados 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.

Esta sección presenta dos optimizaciones posibles para tu esquema. Están catalogadas como "ligeras" porque no requieren ninguna modificación en la estructura de tus tablas. Sin embargo, deben aplicarse durante la creación de la tabla.

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. Para obtener más información sobre las optimizaciones de consultas mediante particiones, consulta el documento sobre optimización del rendimiento de esta serie.

Agrupamiento en clústeres

En BigQuery, no se utilizan índices para consultar tus datos. El rendimiento de la consulta producido por BigQuery se debe al modelo subyacente, las técnicas de almacenamiento y consulta, y la arquitectura masivamente paralela de BigQuery. 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. Para obtener más información sobre las optimizaciones de consultas mediante la agrupación en clústeres, consulta el documento sobre la optimización del rendimiento.

Por ejemplo, en Teradata puedes usar Database Query Logging para analizar el uso mediante consultas de bases de datos, tablas, columnas, índices, vistas, etcétera. Estos datos se registran en la tabla DBQLObjTbl.

Desnormalización

La migración de datos es un proceso iterativo, como se explica en Introducción y descripción general. 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.

A fin de decidir el mejor enfoque de desnormalización en tu caso, ten en cuenta las prácticas recomendadas para la desnormalización en BigQuery, así como las técnicas que permiten manejar los cambios de esquema.

Pasos siguientes