En este documento se describen los principios y las técnicas para implementar un flujo de trabajo repetible que le ayude a integrar los cambios de datos en su almacén de datos (DWH) basado en BigQuery. Estos cambios pueden incluir nuevos conjuntos de datos, nuevas fuentes de datos o actualizaciones y cambios en los conjuntos de datos que ya haya. El documento también describe una arquitectura de referencia para esta tarea.
Este documento está dirigido a arquitectos de software y de datos, así como a ingenieros de datos que usan BigQuery como almacén de datos. En este documento se da por supuesto que conoces los conceptos básicos de CI/CD o prácticas similares de gestión del ciclo de vida de las aplicaciones.
Introducción
La integración y la entrega continuas (CI/CD) se han convertido en una técnica esencial en el ciclo de vida del desarrollo de software. Si los equipos adoptan los principios de CI/CD, pueden ofrecer un mejor software con menos problemas que si integran funciones y las implementan manualmente. La integración y la entrega continuas también pueden formar parte de una estrategia de gestión de datos cuando modernizas tu 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 con estado inherente para gestionar 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 de funciones de BigQuery que ayudan con la integración continua en BigQuery.
Este documento se centra en la integración continua, ya que la integración tiene más consideraciones específicas de los datos para un equipo de almacenamiento de datos que la entrega continua.
Cuándo usar la integración continua en un almacén de datos de BigQuery
En este documento, la integración de datos es una tarea que suele llevar a cabo el equipo del DWH, que incluye la incorporación de nuevos datos al DWH. Esta tarea puede implicar la incorporación de una nueva fuente de datos en el DWH o el cambio de la estructura de una tabla que ya esté en el DWH.
Integrar datos nuevos en el DWH es una tarea similar a integrar una nueva función en un software ya existente. Puede introducir errores y afectar negativamente a la experiencia del usuario final. Cuando integra datos en BigQuery, los consumidores de los datos (por ejemplo, aplicaciones, paneles de control de BI y usuarios individuales) pueden tener problemas debido a discrepancias en el esquema. O bien, los consumidores podrían usar datos incorrectos que no reflejen los datos de la fuente de datos original.
La integración continua de DWH es útil cuando quieres hacer lo siguiente:
- Describe los puntos clave de la integración continua de un sistema de DWH.
- Diseñar e implementar una estrategia de integración continua para tu entorno de BigQuery.
- Consulta cómo usar las funciones de BigQuery para implementar la integración continua.
En esta guía no se describe cómo gestionar la integración continua de productos que no son de DWH, incluidos los productos de datos como Dataflow y Bigtable.
Caso de ejemplo
Example Company es una gran empresa de comercio minorista que mantiene su almacén de datos en BigQuery. El año que viene, la empresa quiere integrar nuevas fuentes de datos en su DWH procedentes de empresas que ha adquirido recientemente. Las nuevas fuentes de datos que se van a integrar tienen esquemas diferentes. Sin embargo, el DWH debe mantener su esquema y proporcionar una gran coherencia y completitud de los datos para que los consumidores de datos posteriores no se vean afectados negativamente.
Actualmente, el equipo del almacén de datos de Example Company se encarga de la integración de datos. La integración se basa en que las fuentes de datos tengan un esquema predefinido. Este flujo de trabajo incluye procesos de importación de datos antiguos, bases de datos adquiridas y servicios de aplicaciones.
Para actualizar sus procesos de integración de datos y adaptarse a las nuevas fuentes de datos, el equipo del DWH debe rediseñar su enfoque de la integración de datos para cumplir los requisitos que se han mencionado anteriormente, como la coherencia de los datos. El equipo debe implementar los cambios de forma aislada para que se puedan probar y medir antes de que los consumidores posteriores tengan acceso a los datos.
Una vez que el equipo del DWH adopte el nuevo flujo de trabajo, tendrá un proceso repetible. Cada desarrollador puede crear un entorno de desarrollo aislado basado en datos de producción. Con estos entornos aislados, los desarrolladores pueden hacer cambios, probarlos, someterlos a revisión y aplicar los cambios necesarios en el entorno de producción. Si los cambios provocan errores o problemas imprevistos, se pueden deshacer fácilmente.
Qué significa la integración continua para un DWH
La integración continua (CI) es un conjunto de prácticas que permite a los equipos de desarrollo acortar los ciclos de desarrollo y detectar problemas en el código más rápido que con los sistemas manuales. La principal ventaja de adoptar un enfoque de integración continua es la capacidad de desarrollar rápidamente, lo que reduce los riesgos de interferencia entre los desarrolladores. Para conseguir este objetivo, nos aseguramos de que el proceso se pueda repetir y, al mismo tiempo, permitimos que cada desarrollador trabaje de forma aislada de los demás.
Estos principios también se aplican cuando una organización debe integrar datos en un DWH, aunque con algunas diferencias. En el contexto del desarrollo de software habitual, la integración continua aísla los cambios en el código fuente, que no tiene estado. En el contexto de la CI en los datos, la CI integra los datos en un sistema de DWH. Sin embargo, los datos tienen estado por definición. Esta diferencia tiene implicaciones en la forma en que la CI se aplica a los escenarios de DWH, tal como se describe en este documento.
Otros casos que no se tratan en este documento
Aunque este documento se centra en aislar los cambios de desarrollo del entorno de producción, no aborda los siguientes aspectos de la integración de datos:
- Pruebas de datos: ¿puede verificar que los datos que tiene se ajustan a los requisitos empresariales? ¿Son fiables los datos como fuente de información principal? Para aumentar tu nivel de confianza en los datos que proporcionas desde tu DWH, es importante probarlos. Para hacer pruebas, puedes ejecutar un conjunto de consultas y comprobar que los datos no tienen valores que faltan o que contienen valores incorrectos.
- Linaje de datos: ¿puedes ver alguna tabla en su contexto? Por ejemplo, ¿puedes ver de dónde se han recogido los datos y qué conjuntos de datos se han precalculado para generar la tabla? En las arquitecturas de DWH modernas, los datos se dividen en muchos sistemas que usan estructuras de datos diferentes y especializadas. Entre ellas, se incluyen bases de datos relacionales, bases de datos NoSQL y fuentes de datos externas. Para comprender completamente los datos que tienes, debes hacer un seguimiento de ellos. También debes saber cómo se han generado los datos y de dónde proceden.
Estos temas no se tratan en esta guía. Sin embargo, te resultará útil para tu estrategia de datos planificar estos temas al diseñar un flujo de trabajo para tu equipo.
Configuración habitual de BigQuery como DWH
En el siguiente diagrama se muestra un diseño de DWH típico para BigQuery. Muestra cómo se ingieren los datos de fuentes externas en el DWH y cómo los consumidores los usan.
Los datos se inician en las fuentes de datos, donde se encuentran en bases de datos transaccionales convencionales o de baja latencia, como las bases de datos SQL OLTP y las bases de datos NoSQL. Un proceso programado copia los datos en un área de almacenamiento temporal.
Los datos se almacenan temporalmente en el área de ensayo. Si es necesario, los datos se transforman para que se ajusten a un sistema analítico antes de cargarse en las tablas del DWH. En este diagrama, el área de almacenamiento temporal está dentro de Google Cloud, pero no tiene por qué ser así. Las transformaciones pueden incluir la desnormalización, el enriquecimiento de determinados conjuntos de datos o la gestión de entradas con formato incorrecto (por ejemplo, entradas con valores que faltan).
Desde la zona de almacenamiento temporal, los nuevos datos se cargan en las tablas del DWH. Las tablas se pueden organizar de diferentes formas en función del diseño del DWH y suelen denominarse tablas principales. Algunos ejemplos de paradigmas de diseño de tablas son el paradigma de esquema de estrella, el paradigma desnormalizado y las agregaciones de varios niveles.
Independientemente del diseño de la tabla, estas tablas guardan datos a lo largo del tiempo. Las tablas deben cumplir el esquema y se presupone que contienen la fuente de información veraz para todos los fines analíticos. Este rol de las tablas implica que los datos de estas tablas deben ser completos, coherentes y ajustarse a los esquemas predefinidos.
Estas tablas no proporcionan datos directamente a los consumidores. En su lugar, los datos se sirven a través de una capa de acceso, 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 el cálculo de una métrica para cada registro o el filtrado y la agrupación de los datos.
Los consumidores de los datos pueden conectarse a la capa de acceso al DWH y leer datos de ella. Entre los consumidores de datos se pueden incluir sistemas como los siguientes:
- Paneles de control de inteligencia empresarial (BI)
- Blocs de notas para la 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 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 los procesos posteriores. Dada la naturaleza cambiante de las plataformas de datos modernas, es posible que el equipo del almacén de datos tenga que hacer esos cambios sin dejar de cumplir estrictamente los acuerdos de nivel de servicio. Para que el equipo cumpla estos acuerdos de nivel de servicio y mantenga actualizado el almacén de datos, necesita un flujo de trabajo que permita integrar los datos y, al mismo tiempo, minimizar los problemas que puedan surgir a raíz de estos cambios.
Recursos para la integración continua en un DWH
Al igual que cualquier otro equipo de desarrollo o de TI, el equipo del DWH debe mantener los recursos que son esenciales para sus responsabilidades. Estos recursos se pueden dividir en las siguientes categorías:
La base de código de las canalizaciones de datos: estos recursos suelen estar formados por código fuente en un lenguaje de programación de alto nivel, como Python o Java. Para esos tipos de recursos, los procesos de CI/CD se crean con herramientas como Git y Jenkins, o con soluciones deGoogle Cloud como Cloud Source Repositories y Cloud Build.
Secuencias de comandos SQL: estos recursos describen la estructura y la lógica empresarial encapsuladas en el DWH. Dentro de esta categoría, los recursos se pueden dividir en las siguientes subcategorías:
- Lenguaje de definición de datos (DDL): estos recursos se usan para definir el esquema de las tablas y las vistas.
- Lenguaje de manipulación de datos (DML): estos recursos se usan para manipular datos en una tabla. Los comandos DML también se usan para crear tablas nuevas basadas en tablas ya creadas.
- Lenguaje de control de datos (DCL): estos recursos se usan para controlar los permisos y el acceso a las tablas. En BigQuery, puedes controlar el acceso mediante SQL y la
bqherramienta de línea de comandos o la API REST de BigQuery. Sin embargo, te recomendamos que uses IAM.
Estos recursos, así como otros, como las secuencias de comandos de Terraform que se usan para crear componentes, se mantienen en repositorios de código. Herramientas como Dataform pueden ayudarte a crear un flujo de procesamiento de CI/CD que valide tus secuencias de comandos SQL y compruebe las reglas de validación predefinidas en las tablas creadas por secuencias de comandos 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 a las herramientas y los procesos, el recurso principal de un equipo de DWH son los datos. Los datos no se pueden monitorizar con sistemas de seguimiento de activos como Git, que está diseñado para monitorizar el código fuente. En este documento se abordan los problemas asociados al seguimiento de datos.
Problemas con la integración de datos
Debido a la posible complejidad de las relaciones entre tablas en un DWH (por ejemplo, en uno de los paradigmas de diseño de tablas mencionados anteriormente), mantener el estado de los datos de producción aislado de un entorno de pruebas es un reto. Las prácticas estándar de desarrollo de software no se pueden aplicar al escenario 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 | Integración de datos | |
|---|---|---|
| Desarrollo local | El código fuente se puede clonar fácilmente debido a su tamaño relativamente pequeño. Por lo general, el código se adapta a la mayoría de los equipos de los usuarios finales (excepto en los casos de monorrepositorios, que tienen otras soluciones). | La mayoría de las tablas de un DWH no caben en una máquina de desarrollo debido a su tamaño. |
| Pruebas centralizadas | Se clonan diferentes estados del código fuente en un sistema central (un servidor de integración continua) para someterlos a pruebas automatizadas. Tener diferentes estados del código te permite comparar los resultados entre una versión estable y una versión de desarrollo. | Crear diferentes estados de los datos en un entorno aislado no es sencillo. Mover datos fuera del DWH es una operación que requiere muchos recursos y tiempo. 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 nueva versión, puedes volver a una versión segura. | Hacer copias de seguridad de las tablas de DWH es una práctica habitual por si tienes que restaurar una versión anterior. Sin embargo, debes asegurarte de que todas las tablas afectadas se reviertan al mismo momento. De esta forma, las tablas relacionadas serán coherentes entre sí. |
Integrar 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 clones de tablas. Puedes combinar estas funciones para conseguir 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, así como deshacer un cambio si es necesario.
Una instantánea de una tabla de BigQuery es una representación de solo lectura de una tabla (denominada tabla base) en un momento determinado. Del mismo modo, un clon de una tabla de BigQuery es una representación de lectura y escritura de una tabla en un momento dado. En ambos casos, los costes de almacenamiento se minimizan porque solo se almacenan las diferencias con respecto a la tabla base. Los clones de tablas empiezan a generar costes cuando cambia la tabla base o cuando cambian los clones de tablas. Como las instantáneas de tablas son de solo lectura, solo se incurre en costes cuando cambia la tabla base.
Para obtener más información sobre los precios de las instantáneas y los clones de tablas, consulta los artículos Introducción a las instantáneas de tablas y Introducción a los clones de tablas.
Puedes crear copias de tablas y copias de seguridad de tablas con la función Viaje en el tiempo de BigQuery (hasta siete días atrás). Esta función te permite capturar copias de varias tablas en el mismo momento, lo que hace que tu entorno de trabajo y las copias sean coherentes entre sí. Usar esta función puede ser útil para las tablas que se actualizan con frecuencia.
Cómo usar clones y capturas de tablas para permitir el aislamiento
Para ilustrar el flujo de trabajo de integración de CI en un DWH, vamos a imaginar la siguiente situación. Se te asigna la tarea de integrar un nuevo conjunto de datos en el DWH. La tarea puede consistir en crear tablas de DWH, actualizar tablas, cambiar la estructura de las tablas o cualquier combinación de estas tareas. El flujo de trabajo podría ser similar a la siguiente secuencia:
- Identifica las tablas que pueden verse afectadas por los cambios y las tablas adicionales que quieras comprobar.
- Crea un conjunto de datos de BigQuery para incluir los recursos de este cambio. Este conjunto de datos ayuda a aislar los cambios y separa esta tarea de otras 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 cumplir los requisitos de seguridad y facturación de tu organización.
En cada una de las tablas, crea una clon y una instantánea en el nuevo conjunto de datos, posiblemente en el mismo momento. Este enfoque ofrece las siguientes ventajas:
- La clonación de la tabla puede actuar como una copia de trabajo en la que puedes hacer cambios libremente sin que afecten a la tabla de producción. Puedes crear varias réplicas de la misma tabla base para probar diferentes rutas de integración al mismo tiempo con una sobrecarga mínima.
- La instantánea puede servir como punto de restauración y de referencia, un punto en el que se sabe que los datos funcionaban antes de que se produjera ningún cambio. Esta instantánea te permite restaurar la versión anterior si se detecta algún problema más adelante en el proceso.
Usa los clones de la tabla para implementar los cambios necesarios en las tablas. De esta forma, se creará una versión actualizada de los clones de la tabla, que podrá probar en un conjunto de datos aislado.
Opcionalmente, al final de la fase de implementación, puede presentar un conjunto de datos que se puede usar para las siguientes tareas:
- Pruebas unitarias con una herramienta de validación como Dataform. Las pruebas unitarias son independientes, lo que significa que el recurso se prueba de forma aislada. En este caso, el recurso es la tabla de BigQuery. Las pruebas unitarias pueden comprobar si hay valores nulos, verificar que todas las cadenas cumplen los requisitos de longitud y asegurarse de que determinados agregados producen resultados útiles. Las pruebas unitarias pueden incluir cualquier prueba de confianza que asegure que la tabla mantiene las reglas de negocio de la organización.
- Pruebas de integración con consumidores posteriores.
- Revisión por pares.
Este flujo de trabajo te permite hacer pruebas con datos de producción sin que afecte a los consumidores posteriores.
Antes de combinar los nuevos datos en BigQuery, puede crear otra instantánea. Esta instantánea es útil como otra opción de restauració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 quiera adoptar tu organización y de los cambios que sean necesarios. Por ejemplo, si se modifica una secuencia de comandos SQL, el nuevo conjunto de datos puede ir acompañado de una solicitud de extracción al código base estándar. Si el cambio se limita a los datos de una tabla concreta, puedes copiar los datos con los métodos estándar de BigQuery.
Puede usar una secuencia de comandos de procedimientos almacenados para encapsular y automatizar los pasos para crear un conjunto de datos, así como los clones y las copias de seguridad. Automatizar estas tareas reduce el riesgo de error humano. Para ver un ejemplo de una secuencia de comandos que puede ayudarte a automatizar los procesos, consulta el repositorio de GitHub de la utilidad de CLI de integración continua para datos en BigQuery.
Ventajas de usar clones y capturas de tablas
Si usas el flujo de trabajo descrito en la sección anterior, tus desarrolladores podrán trabajar de forma aislada y en paralelo sin interferir con sus compañeros. Los desarrolladores pueden probar y revisar los cambios y, si hay algún problema, deshacerlos. Como trabajas con capturas de tablas y no con tablas completas, puedes minimizar los costes y el almacenamiento en comparación con el trabajo con tablas completas.
En esta sección se ofrece más información sobre cómo permiten a los desarrolladores conseguir este flujo de trabajo las copias de la tabla y las copias de seguridad de la tabla. En el siguiente diagrama se muestra la relación entre las copias de la tabla y los clones de la tabla con los datos del 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. Todos los desarrolladores pueden crear un conjunto de datos para su propio entorno de desarrollo. En el diagrama se muestran dos conjuntos de datos de desarrollador, denominados Conjunto de datos de desarrollo 1 y Conjunto de datos de desarrollo 2. Al usar estos conjuntos de datos de desarrollador, los desarrolladores pueden trabajar simultáneamente en las mismas tablas sin interferir entre sí.
Una vez que los desarrolladores han creado un conjunto de datos, pueden crear clones y copias de las tablas en las que están trabajando. Los clones y las instantáneas representan los datos en un momento concreto. En este punto, los desarrolladores pueden cambiar los clones de la tabla, ya que los cambios no se ven en la tabla base.
Un desarrollador puede revisar los clones de la tabla, compararlos con la instantánea y probar si son compatibles con los consumidores posteriores. Otros desarrolladores pueden trabajar con otros clones y copias de la tabla sin interferencias y sin crear demasiadas copias de la tabla base que consuman recursos.
Los desarrolladores pueden combinar los cambios en la tabla base y mantener la instantánea segura para usarla como opción de reversión si es necesario. Este proceso también se puede repetir en diferentes entornos, como los de desarrollo, prueba y producción.
Alternativas a los clones y las capturas de tablas
Hay alternativas a los clones y las copias de tablas que te permiten obtener un resultado similar. Estos métodos alternativos suelen usarse de forma diferente a los clones y las copias de seguridad. Es importante entender las diferencias entre estos métodos y en qué situaciones puede ser preferible uno u otro.
Copiar tablas completas en otro conjunto de datos
Otra opción es usar otro conjunto de datos y copiar las tablas en él. Este método es similar al uso de clones y copias de tablas, pero se copia todo el conjunto de tablas. En función del tamaño de los datos que se copien, los costes de almacenamiento pueden ser elevados. Algunas organizaciones usaban este método antes de que los clones de tablas estuvieran disponibles en BigQuery. Sin embargo, este método no ofrece ninguna ventaja con respecto al uso de clones y copias de seguridad.
Exportar e importar tablas a Cloud Storage
Otra alternativa es mover los datos a través de Cloud Storage. Este método también es similar al uso de clones y capturas de tablas. Sin embargo, incluye el paso adicional de exportar los datos a un segmento de Cloud Storage. Una de las ventajas de este método es que te proporciona una copia de seguridad adicional de tus datos. Puedes elegir este método si quieres una copia de seguridad para la recuperación tras desastres o soluciones híbridas.
Usar la función para compartir de BigQuery
BigQuery sharing (antes Analytics Hub) te permite compartir conjuntos de datos tanto fuera como dentro de la organización de forma segura. Ofrece muchas funciones que te permiten publicar conjuntos de datos para proporcionar a los suscriptores acceso de solo lectura controlado a esos conjuntos de datos. Sin embargo, aunque puedes usar la función Compartir para exponer conjuntos de datos e implementar cambios, un desarrollador debe crear clones de tablas para trabajar con ellas.
Resumen de las opciones de integración continua de almacén de datos
En la siguiente tabla se resumen las diferencias, las ventajas y los posibles inconvenientes de las opciones de integración continua de DWH. (La función de compartir ofrece un conjunto de funciones diferente y, por lo tanto, no se puede medir con los parámetros que se indican en la tabla).
| Costes | Restauraciones | Riesgos | |
|---|---|---|---|
| Capturas y clones de tablas | Mínima. Solo pagas por la diferencia entre la instantánea o el clon y la tabla base. | La instantánea actúa como copia de seguridad a la que puedes volver si es necesario. | Tú controlas el nivel de riesgo. Se pueden hacer capturas en un momento dado de todas las tablas, lo que reduce las incoherencias incluso si se produce una reversión. |
| Copia de tabla | Los costes son más elevados que si se usan capturas y clones de tablas. Se duplican todos los datos. Para admitir las restauraciones, necesitas varias copias de la misma tabla. | Es posible, pero requiere dos copias de la tabla: una copia para que sirva de copia de seguridad y otra para trabajar con ella y hacer cambios. | Es más difícil clonar un momento concreto. Si es necesario revertir los cambios, no todas las tablas se toman del mismo momento. |
| Exportar e importar | Los costes son más elevados que si se usan capturas y clones de tablas. Los datos están duplicados. Para admitir la reversión, necesitas varias copias de la misma tabla. | Los datos exportados sirven como copia de seguridad. | Los datos exportados no corresponden a un momento concreto de varias tablas. |
Siguientes pasos
- Consulte información sobre las copias de las tablas de BigQuery en el artículo Introducción a las copias de las tablas.
- Consulta más información sobre la integración continua para el desarrollo de software en Tecnología de DevOps: integración continua.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.