En este documento, se describen los principios y las técnicas para implementar un flujo de trabajo repetible que te ayudará a integrar cambios de datos en tu almacén de datos basado en BigQuery (DWH). Estos cambios pueden incluir nuevos conjuntos de datos, nuevas fuentes de datos o actualizaciones y cambios en conjuntos de datos existentes. En el documento, también se describe una arquitectura de referencia para esta tarea.
El público de este documento son los arquitectos de datos y de software, y los ingenieros de datos que usan BigQuery como un DWH. En este documento, se supone que estás familiarizado con los conceptos básicos de CI/CD o con las prácticas similares de administración de ciclos de vida de aplicaciones.
Introducción
La integración continua y la entrega continua (CI/CD) se convirtieron en una técnica esencial en el ciclo de vida del desarrollo de software. Adoptar los principios de CI/CD permite que los equipos entreguen un mejor software con menos problemas que mediante la integración de funciones y su implementación manual. La CI/CD también puede ser parte de una estrategia para la administración de datos cuando modernizas el almacenamiento de datos.
Sin embargo, cuando trabajas con un DWH como BigQuery, hay diferencias en la forma de implementar CI/CD en comparación con la implementación de CI/CD en el código fuente. Estas diferencias se deben en parte a que el almacenamiento de datos es un sistema inherentemente con estado para administrar los datos subyacentes.
En este documento, se proporciona la siguiente información:
- Técnicas para implementar una estrategia de integración continua (CI) en BigQuery.
- Orientación y métodos que te ayudan a evitar errores.
- Sugerencias para las funciones de BigQuery que ayudan con la CI en BigQuery.
Este documento se centra en la CI, ya que la integración tiene más consideraciones específicas para un equipo de almacenamiento de datos que la entrega continua (CD).
Cuándo usar la CI para un DWH de BigQuery
En este documento, la integración de datos es una tarea que suele realizar el equipo de DWH, que incluye la incorporación de datos nuevos en el DWH. Esta tarea puede implicar incorporar una fuente de datos nueva al DWH o cambiar la estructura de una tabla que ya está dentro del DWH.
La integración de datos nuevos en el DWH es una tarea similar a la integración de una función nueva en el software existente. Puede introducir errores y afectar de forma negativa la experiencia del usuario final. Cuando integras datos en BigQuery, los consumidores posteriores de los datos (por ejemplo, aplicaciones, paneles de IE y usuarios individuales) pueden experimentar problemas debido a discrepancias de esquemas. O los consumidores pueden usar datos incorrectos que no reflejan los datos de la fuente de datos original.
La CI para DWH es útil cuando deseas hacer lo siguiente:
- Describir los puntos clave en la CI para un sistema DWH.
- Diseñar e implementar una estrategia de CI para tu entorno de BigQuery.
- Aprender a usar las funciones de BigQuery para implementar CI.
En esta guía, no se describe cómo administrar la CI para productos que no son DWH, incluidos los productos de datos como Dataflow y Bigtable.
Situación de ejemplo
Example Company es una gran empresa minorista que mantiene su DWH en BigQuery. En el próximo año, la empresa desea integrar fuentes de datos nuevas en su DWH de empresas que Example Company compró recientemente. Las nuevas fuentes de datos que se integrarán tienen diferentes esquemas. Sin embargo, el DWH debe mantener su esquema existente y proporcionar integridad y coherencia sólida de los datos para que los consumidores posteriores de los datos no se vean afectados de forma negativa.
Actualmente, el equipo de DWH de Example Company realiza la integración de datos. La integración depende de tener las fuentes de datos existentes en un esquema predefinido. Este flujo de trabajo implica procesos de importación de datos heredados, bases de datos adquiridas y servicios de aplicación.
A fin de actualizar sus procesos de integración de datos para adaptarse a las nuevas fuentes de datos, el equipo de DWH debe rediseñar su enfoque de integración de datos a fin de cumplir con los requisitos mencionados antes, como la coherencia de datos sólida. El equipo debe implementar los cambios de forma aislada, de modo que los cambios de datos puedan probarse y medirse antes de que los datos estén disponibles para los consumidores posteriores.
Después de que el equipo de DWH adopta el flujo de trabajo nuevo, tiene un proceso repetible. Cada desarrollador puede crear un entorno de desarrollo aislado que se base en los datos de producción. Mediante estos entornos aislados, los desarrolladores pueden realizar cambios, probarlos, revisarlos y entregar los cambios necesarios al entorno de producción. Si los cambios generan errores o problemas imprevistos, los cambios se pueden revertir con facilidad.
Qué significa la integración continua para un DWH
La integración continua (CI) es un conjunto de prácticas que permiten a los equipos de desarrollo acortar los ciclos de desarrollo y encontrar problemas en el código más rápido que con los sistemas manuales. El beneficio principal de adoptar un enfoque de CI es la capacidad de desarrollar con rapidez y reducir los riesgos de interferencia entre los desarrolladores. Este objetivo se logra asegurándose de que el proceso sea repetible y permita que cada desarrollador trabaje de forma aislada de otros desarrolladores.
Estos principios también se aplican cuando una organización debe integrar datos en un DWH, con algunas diferencias. En el contexto del desarrollo de software típico, la CI aísla los cambios en el código fuente, que es sin estado. En el contexto de la CI en los datos, la CI integra los datos a un sistema DWH. Sin embargo, los datos tienen estado por definición. Esta diferencia tiene implicaciones sobre cómo se aplica la CI a las situaciones de DWH, como se describe en este documento.
Situaciones adicionales que no se tratan en este documento
Si bien este documento se centra en aislar los cambios de desarrollo del entorno de producción, no abarca los siguientes aspectos de la integración de datos:
- Pruebas de datos: ¿Puedes verificar que los datos que tienes cumplen con los requisitos de la empresa? ¿Los datos son confiables como fuente de información? Para aumentar tu nivel de confianza en los datos que entregas desde tu DWH, es importante probar los datos. Para probar, puedes ejecutar un conjunto de consultas a fin de confirmar que a los datos no les faltan valores o que contienen valores “incorrectos”.
- Linaje de datos: ¿Puedes ver cualquier tabla en su contexto? Por ejemplo, ¿puedes ver de dónde se recopilaron los datos y qué conjuntos de datos se procesaron con anterioridad para generar la tabla? En las arquitecturas de DWH modernas, los datos se dividen en muchos sistemas que usan estructuras de datos especializadas diferentes. Esto incluye bases de datos relacionales, bases de datos NoSQL y fuentes de datos externas. Para comprender completamente los datos que tienes, debes realizar un seguimiento de ellos. También debes comprender cómo se generaron los datos y desde dónde se generaron.
Estos temas no se incluyen en esta guía. Sin embargo, planificar una estrategia para estos temas será beneficioso cuando diseñes un flujo de trabajo para tu equipo.
Configuración típica de BigQuery como un DWH
En el siguiente diagrama, se ilustra un diseño típico de DWH para BigQuery. Muestra cómo los datos de las fuentes externas se transfieren al DWH y cómo los consumidores consumen datos del DWH.
Los datos comienzan en las fuentes de datos, en las que se encuentran en bases de datos convencionales o de baja latencia, como las bases de datos de OLTP SQL y de NoSQL. Un proceso programado copia los datos en un área de etapa de pruebas.
Los datos se almacenan de forma temporal en el área de etapa de pruebas. Si es necesario, los datos se transforman para ajustarse a un sistema analítico antes de que se carguen en las tablas del DWH. (En este diagrama, el área de etapa de pruebas se encuentra dentro de Google Cloud, pero no es necesario). Las transformaciones pueden incluir la desnormalización, el enriquecimiento de ciertos conjuntos de datos o el manejo de entradas con formato incorrecto (por ejemplo, entradas con valores faltantes).
Desde el área de etapa de pruebas, los datos nuevos se cargan en las tablas del DWH. Las tablas se pueden organizar de diferentes maneras según el diseño del DWH y, por lo general, se las conoce como tablas principales. Algunos ejemplos de paradigmas de diseño de tablas son el paradigma de esquema en estrella, el paradigma desnormalizado y las agregaciones de varios niveles.
Sin importar el diseño de la tabla, estas tablas ahorran datos con el tiempo. Las tablas deben cumplir con el esquema y se supone que contienen la fuente de información para todos los propósitos analíticos. Este rol de las tablas significa que los datos en ellas deben estar completos, ser coherentes y cumplir con los esquemas predefinidos.
Estas tablas no entregan datos directamente a los consumidores. En cambio, los datos se entregan a través de una capa de acceso, que está diseñada para encapsular la lógica empresarial que se debe aplicar a los datos subyacentes. Algunos ejemplos de este tipo de lógica empresarial son calcular una métrica para cada registro o filtrar y agrupar los datos.
Los consumidores de datos pueden conectarse a la capa de acceso del DWH y leer datos desde ella. Estos consumidores de datos pueden incluir sistemas como los siguientes:
- Paneles de inteligencia empresarial (IE)
- Cuadernos de ciencia de datos
- Sistemas operativos que dependen de los datos calculados en el DWH
- Usuarios humanos para consultas ad-hoc
Los consumidores de datos dependen en gran medida del DWH para proporcionar esquemas coherentes y de la lógica empresarial que encapsula el DWH. Estos esquemas y la lógica empresarial se pueden considerar como los Acuerdos de Nivel de Servicio (ANS) de la plataforma de DWH. Cualquier cambio en la lógica empresarial, en el esquema o en la integridad de los datos puede tener grandes implicaciones en etapas posteriores. Debido a la naturaleza cambiante de las plataformas de datos modernas, es posible que el equipo de DWH deba realizar esos cambios, a la vez que cumple de forma estricta con los ANS. Para que el equipo cumpla con estos ANS y también mantenga actualizado el DWH, necesita un flujo de trabajo que permita la integración de datos y, al mismo tiempo, minimice los inconvenientes que podrían generar estos cambios.
Recursos para la integración continua en un DWH
Al igual que con cualquier otro equipo de TI o de desarrollo, el equipo de DWH debe mantener los elementos que son esenciales para sus responsabilidades. Por lo general, estos elementos se pueden dividir en las siguientes categorías:
La base de código para las canalizaciones de datos: Por lo general, estos elementos constan de un código fuente en un lenguaje de programación de alto nivel, como Python o Java. Para esos tipos de elementos, los procesos de IC/EC se compilan mediante herramientas como Git y Jenkins, o mediante las soluciones de Google Cloud, como Cloud Source Repositories y Cloud Build.
Secuencias de comandos de SQL: Estos elementos describen la estructura y la lógica empresarial que se encapsula dentro del DWH. Dentro de esta categoría, los recursos se pueden dividir aún más en las siguientes subcategorías:
- Lenguaje de definición de datos (DDL): Estos elementos se usan para definir el esquema de tablas y vistas.
- Lenguaje de manipulación de datos (DML): Estos elementos se usan para manipular datos dentro de una tabla. Los comandos DML también se usan para crear tablas nuevas basadas en tablas existentes.
- Lenguaje de control de datos (DCL): Estos elementos se usan para controlar los permisos y el acceso a las tablas. En BigQuery, puedes controlar el acceso mediante SQL y la herramienta de línea de comandos de
bq, o mediante la API de REST de BigQuery. Sin embargo, te recomendamos que uses IAM.
Estos elementos y otros como las secuencias de comandos de Terraform que se usan para compilar componentes se mantienen dentro de los repositorios de código. Las herramientas como Dataform pueden ayudarte a construir una canalización de CI/CD que valide tus secuencias de comandos de SQL y verifique las reglas de validación predefinidas en tablas creadas por secuencias de comandos de DDL. Estas herramientas te permiten aplicar procesos de compilación y prueba para SQL, que en la mayoría de los contextos no tiene un entorno de prueba natural.
Además de los recursos asociados con las herramientas y los procesos, el recurso principal de un equipo de DWH son los datos. No se puede realizar un seguimiento de los datos mediante sistemas de seguimiento de elementos como Git, que está diseñado para realizar un seguimiento del código fuente. En este documento, se abordan los problemas asociados con los datos de seguimiento.
Problemas con la integración de datos
Debido a la posible complejidad de las relaciones de tabla dentro de un DWH (por ejemplo, en uno de los paradigmas de diseño de tabla mencionados antes), mantener el estado de los datos de producción aislado de un entorno de pruebas es un desafío. Las prácticas estándar en el desarrollo de software no se pueden aplicar a la situación de integración de datos.
En la siguiente tabla, se resumen las diferencias entre las prácticas para integrar código y las prácticas para integrar datos.
| Integrar código | Integrar datos | |
|---|---|---|
| Desarrollo local | El código fuente se puede clonar con facilidad debido a su tamaño relativamente pequeño. Por lo general, el código se adapta a la mayoría de las máquinas de usuario final (excepto los casos de monorepos, que tienen otras soluciones). | La mayoría de las tablas en un DWH no pueden caber en una máquina de desarrollo debido a su tamaño. |
| Pruebas centrales | Los diferentes estados del código fuente se clonan en un sistema central (un servidor de CI) para ejecutar pruebas automatizadas. Tener diferentes estados del código te permite comparar resultados entre una versión estable y una de desarrollo. | Crear estados diferentes de los datos en un entorno aislado no es sencillo. El movimiento de datos fuera de DWH es una operación que consume una gran cantidad de tiempo y recursos. No es práctico hacerlo con la frecuencia necesaria para las pruebas. |
| Versiones anteriores | Durante el proceso de lanzamiento de nuevas versiones de software, puedes hacer un seguimiento de las versiones anteriores. Si detectas un problema en una versión nueva, puedes revertir a una versión segura. | Crear copias de seguridad de tablas dentro de DWH es una práctica estándar en caso de que debas revertir. Sin embargo, debes asegurarte de que todas las tablas afectadas se reviertan al mismo momento. De esta manera, las tablas relacionadas son coherentes entre sí. |
Integra datos en tablas de BigQuery
BigQuery tiene dos funciones que pueden ayudarte a diseñar un flujo de trabajo para la integración de datos: instantáneas de tablas y clonaciones de tablas. Puedes combinar estas características para lograr un flujo de trabajo que te proporcione un entorno de desarrollo rentable. Los desarrolladores pueden manipular los datos y su estructura de forma aislada del entorno de producción, y pueden revertir un cambio si es necesario.
Una instantánea de tabla de BigQuery es una representación de solo lectura de una tabla (llamada tabla base) en un momento determinado. Del mismo modo, una clonación de una tabla de BigQuery es una representación de lectura y escritura de una tabla en un momento determinado. En ambos casos, los costos de almacenamiento se minimizan porque solo se almacenan las diferencias de la tabla base. Las clonaciones de las tablas comienzan a generar costos cuando cambia la tabla base o cuando las clonaciones de la tabla cambian. Debido a que las instantáneas de la tabla son de solo lectura, generan costos solo cuando cambia la tabla base.
Para obtener más información sobre los precios de las instantáneas y las clonaciones de las tablas, consulta Introducción a las instantáneas de tablas e Introducción a las clonaciones de tablas.
Puedes tomar instantáneas de tablas y clonaciones de tablas con la función de viaje en el tiempo de BigQuery (hasta siete días al pasado). Esta función te permite capturar instantáneas y clonaciones de varias tablas al mismo tiempo, lo que hace que las instantáneas y el entorno de trabajo sean coherentes entre sí. Usar esta función puede ser útil para las tablas que se actualizan con frecuencia.
Cómo usar clonaciones de tablas e instantáneas de tablas para permitir el aislamiento
A fin de ilustrar el flujo de trabajo de integración para la CI en un DWH, imagina la siguiente situación. Se te asigna la tarea de integrar un nuevo conjunto de datos en el DWH. La tarea puede ser crear tablas de DWH nuevas, actualizar tablas existentes, cambiar la estructura de las tablas o cualquier combinación de estas tareas. El flujo de trabajo podría verse como la siguiente secuencia:
- Identifica las tablas que pueden verse afectadas por los cambios y las tablas adicionales que deseas verificar.
- Creas un conjunto de datos nuevo de BigQuery que contiene los recursos de este cambio. Este conjunto de datos ayuda a aislar los cambios y separa esta tarea de otras tareas en las que trabajan otros miembros del equipo. El conjunto de datos debe estar en la misma región que el conjunto de datos de origen. Sin embargo, el proyecto se puede separar del proyecto de producción para ayudar a cumplir con los requisitos de seguridad y facturación de tu organización.
Para cada una de las tablas, debes crear una clonación y una instantánea en el conjunto de datos nuevo, potencialmente para el mismo momento. Este enfoque ofrece las siguientes ventajas:
- La clonación de la tabla puede funcionar como una copia de trabajo en la que puedes realizar cambios libremente sin afectar la tabla de producción. Puedes crear varias clonaciones de la misma tabla base para probar diferentes rutas de integración al mismo tiempo, con una sobrecarga mínima.
- La instantánea puede actuar como un punto de restablecimiento y referencia, un punto en el que se sabe que los datos funcionaron antes de que se realizara cualquier cambio. Tener esta instantánea te permite realizar una reversión en caso de que se detecte un problema más adelante en el proceso.
Usa las clonaciones de las tablas para implementar los cambios necesarios. Esta acción da como resultado una versión actualizada de las clonaciones de la tabla, que puedes probar en un conjunto de datos aislado.
De manera opcional, al final de la fase de implementación, puedes presentar un conjunto de datos que se pueda usar para las siguientes tareas:
- Pruebas de unidades con una herramienta de validación como Dataform. Las pruebas de unidades son independientes, lo que significa que el elemento se prueba en aislamiento. En este caso, el elemento es la tabla en BigQuery. Las pruebas de unidades pueden detectar valores nulos, pueden verificar que todas las strings cumplan con los requisitos de longitud y pueden garantizar que ciertos agregados produzcan resultados útiles. Las pruebas de unidades pueden incluir cualquier prueba de confianza que garantice que la tabla mantenga las reglas empresariales de la organización.
- Pruebas de integración con consumidores posteriores
- Revisión de los pares.
Este flujo de trabajo te permite realizar pruebas con datos de producción, sin afectar a los consumidores posteriores.
Antes de combinar los datos nuevos en BigQuery, puedes crear otra instantánea. Esta instantánea es útil como otra opción de reversión en caso de que los datos de la tabla base hayan cambiado.
El proceso de combinación de los cambios depende del proceso que tu organización desee adoptar y de qué cambios se requieran. Por ejemplo, para un cambio en las secuencias de comandos SQL, el nuevo conjunto de datos puede ir acompañado de una solicitud de extracción a la base de código estándar. Si el cambio se limita a un cambio en los datos dentro de una tabla determinada, puedes copiar datos con métodos estándar de BigQuery.
Puedes usar una secuencia de comandos de procedimientos almacenados para encapsular y automatizar los pasos a fin de crear un conjunto de datos y crear las clonaciones y las instantáneas. La automatización de estas tareas reduce el riesgo de errores humanos. Si deseas ver un ejemplo de una secuencia de comandos que pueda ayudar a automatizar los procesos, consulta el repositorio de GitHub de la utilidad de la CLI de CI para Datos en BigQuery.
Beneficios de usar las clonaciones y las instantáneas de tablas
Cuando usas el flujo de trabajo descrito en la sección anterior, los desarrolladores pueden trabajar de forma aislada y en paralelo, sin interferir en sus colegas. Los desarrolladores pueden probar y revisar los cambios y, si hay un problema, revertirlos. Debido a que trabajas con instantáneas de tabla y no con tablas completas, puedes minimizar los costos y el almacenamiento en comparación con trabajar con tablas completas.
En esta sección, se proporcionan más detalles sobre cómo las instantáneas y las clonaciones de tablas permiten que los desarrolladores logren este flujo de trabajo. En el siguiente diagrama, se muestra cómo se relacionan las instantáneas y las clonaciones de tablas con los datos en el conjunto de datos de producción.
En el diagrama, el conjunto de datos de producción contiene todas las tablas que se usan en producción. Cada desarrollador puede crear un conjunto de datos para su propio entorno de desarrollo. En el diagrama, se muestran dos conjuntos de datos de desarrollador, que están etiquetados como Dev Dataset 1 y Dev Dataset 2. Mediante estos conjuntos de datos, los desarrolladores pueden trabajar simultáneamente en las mismas tablas sin interferir entre sí.
Después de que los desarrolladores hayan creado un conjunto de datos, pueden crear instantáneas y clonaciones de las tablas en las que trabajan. Las clonaciones y las instantáneas representan los datos en un momento particular. En este punto, los desarrolladores son libres de cambiar las clonaciones de las tablas, ya que los cambios no son visibles en la tabla base.
Un desarrollador puede revisar las clonaciones de las tablas, compararlas con la instantánea y probarlas para verificar su compatibilidad con los consumidores posteriores. Otros desarrolladores pueden trabajar con otras clonaciones e instantáneas, sin interferencias y sin crear demasiadas copias de la tabla base que consumen muchos recursos.
Los desarrolladores pueden combinar cambios en la tabla base y mantener la instantánea segura como opción de reversión, si es necesario. Este proceso también se puede repetir para diferentes entornos, como desarrollo, prueba y producción.
Alternativas a las clonaciones y las instantáneas de tablas
Existen alternativas al uso de clonaciones e instantáneas de tablas que te permiten lograr un resultado similar. Estos métodos alternativos suelen usarse de manera diferente de los clones y las instantáneas. Es importante comprender las diferencias entre estos métodos y dónde podrías preferir un método sobre otro.
Copiar tablas completas en un conjunto de datos diferente
Un método alternativo es usar un conjunto de datos diferente y copiar las tablas en ese conjunto de datos. El uso de este método es similar al uso de instantáneas y clonaciones de tablas, pero copias todo el conjunto de tablas. Según los tamaños de los datos que se copian, los costos de almacenamiento pueden ser altos. Algunas organizaciones usaron este método antes de que las clonaciones de las tablas estuvieran disponibles en BigQuery. Sin embargo, este método no presenta ninguna ventaja en comparación con las instantáneas y los clones.
Importa y exporta tablas a Cloud Storage
Otro método alternativo es mover los datos a través de Cloud Storage. Este método también es similar al uso de clonaciones de tablas e instantáneas de tablas. Sin embargo, se incluye el paso adicional de exportar los datos a un bucket de Cloud Storage. Una ventaja de este método es que te brinda una copia de seguridad adicional de tus datos. Puedes elegir este método si deseas una copia de seguridad para la recuperación ante desastres o soluciones híbridas.
Usa Analytics Hub
Analytics Hub te permite compartir conjuntos de datos fuera y dentro de la organización de una manera diseñada para ser segura. Ofrece muchas funciones que te permiten publicar conjuntos de datos para proporcionar a los suscriptores acceso controlado de solo lectura a esos conjuntos de datos. Sin embargo, aunque puedes usar Analytics Hub a fin de exponer conjuntos de datos para implementar cambios, un desarrollador debe crear clonaciones de tablas a fin de trabajar con las tablas.
Resumen de opciones de integración continua de DWH
En la tabla siguiente, se resumen las diferencias, las ventajas y las posibles desventajas entre las opciones de integración continua de DWH. (Analytics Hub ofrece un conjunto de atributos diferente y, por lo tanto, no se puede medir con los parámetros enumerados en la tabla).
| Costos | Reversiones | Riesgos | |
|---|---|---|---|
| Instantáneas y clonaciones de tablas | Es mínimo. Solo pagas por la diferencia entre la instantánea o la clonación y la tabla base. | La instantánea actúa como una copia de seguridad para revertirse si es necesario. | Tú controlas la cantidad de riesgo. Las instantáneas se pueden tomar en un momento determinado para todas las tablas, lo que reduce las inconsistencias incluso si hay una reversión. |
| Copia de tabla | Costos mayores que usar las instantáneas y las clonaciones de tablas Toda la información está duplicada. Para admitir reversiones, necesitas varias copias de la misma tabla. | Es posible, pero requiere dos copias de la tabla: una que funcione como copia de seguridad y otra para trabajar en ella y realizar cambios. | La clonación es más difícil de hacer en un momento determinado. Si es necesario realizar una reversión, no todas las tablas se toman del mismo momento. |
| Importar y exportar | Costos mayores que usar las instantáneas y las clonaciones de tablas Los datos están duplicados. Para admitir reversiones, necesitas varias copias de la misma tabla. | Los datos exportados sirven como copia de seguridad. | Los datos exportados no son una exportación de un momento determinado para varias tablas. |
¿Qué sigue?
- Obtén información sobre las instantáneas de tablas de BigQuery en Introducción a las instantáneas de tablas.
- Obtén más información sobre la integración continua para el desarrollo de software en Tecnología de DevOps: Integración continua.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.