Migrar flujos de procesamiento de datos

En este documento se describe cómo puedes migrar tus flujos de procesamiento de datos ascendentes, que cargan datos en tu almacén. Puedes usar este documento para entender mejor qué es un flujo de datos, qué procedimientos y patrones puede emplear un flujo y qué opciones y tecnologías de migración están disponibles para migrar un almacén de datos.

¿Qué es una canalización de datos?

En informática, un pipeline de datos es un tipo de aplicación que procesa datos mediante una secuencia de pasos de procesamiento conectados. En general, los flujos de procesamiento de datos se pueden aplicar, por ejemplo, a la transferencia de datos entre sistemas de información, a los procesos de extracción, transformación y carga (ETL), al enriquecimiento de datos y al análisis de datos en tiempo real. Normalmente, los flujos de procesamiento de datos se ejecutan como un proceso por lotes que se ejecuta y procesa los datos cuando se inicia, o como un proceso de streaming que se ejecuta de forma continua y procesa los datos a medida que están disponibles en el flujo.

En el contexto de los almacenes de datos, los flujos de procesamiento de datos se suelen usar para leer datos de sistemas transaccionales, aplicar transformaciones y, a continuación, escribir datos en el almacén de datos. Cada transformación se describe mediante una función, y la entrada de cualquier función es la salida de la función o funciones anteriores. Estas funciones conectadas se describen como un grafo, que a menudo se denomina grafo acíclico dirigido (DAG). Es decir, el grafo sigue una dirección (de origen a destino) y es acíclico: la entrada de cualquier función no puede depender de la salida de otra función posterior en el DAG. Es decir, no se permiten bucles. Cada nodo del gráfico es una función y cada arista representa los datos que fluyen de una función a la siguiente. Las funciones iniciales son las fuentes o las conexiones a sistemas de datos de origen. Las funciones finales son los sinks o las conexiones a los sistemas de datos de destino.

En el contexto de las canalizaciones de datos, los orígenes suelen ser sistemas transaccionales (por ejemplo, un RDBMS) y el receptor se conecta a un almacén de datos. Este tipo de gráfico se denomina DAG de flujo de datos. También puedes usar DAGs para orquestar el movimiento de datos entre las canalizaciones de datos y otros sistemas. Este uso se denomina orquestación o DAG de flujo de control.

Cuándo migrar las canalizaciones de datos

Cuando migras un caso práctico a BigQuery, puedes descargar o migrar por completo.

Por un lado, cuando externalizas un caso de uso, no tienes que migrar sus pipelines de datos upstream por adelantado. Primero, migra el esquema y los datos del caso práctico de tu almacén de datos a BigQuery. Después, crea una copia incremental del antiguo al nuevo almacén de datos para mantener los datos sincronizados. Por último, migra y valida los procesos posteriores, como las secuencias de comandos, las consultas, los paneles de control y las aplicaciones empresariales.

En este punto, tus flujos de procesamiento de datos ascendentes no han cambiado y siguen escribiendo datos en tu almacén de datos. Puedes volver a incluir los casos prácticos descargados en la lista de tareas pendientes de la migración para que se migren por completo en una iteración posterior.

Por otro lado, cuando migras por completo un caso práctico, las canalizaciones de datos de origen necesarias para ese caso práctico se migran a Google Cloud. Para realizar una migración completa, primero debes descargar el caso práctico. Una vez completada la migración, puede retirar las tablas antiguas correspondientes del almacén de datos local, ya que los datos se insertan directamente en BigQuery.

Durante una iteración, puedes elegir una de las siguientes opciones:

• Descarga solo tu caso práctico.
• Migrar por completo un caso práctico que se haya descargado anteriormente.
• Migrar por completo un caso práctico desde cero descargándolo primero en la misma iteración.

Cuando todos tus casos prácticos se hayan migrado por completo, puedes desactivar el antiguo almacén, lo que supone un paso importante para reducir los gastos generales y los costes.

Cómo migrar las canalizaciones de datos

En el resto de este documento se explica cómo migrar tus pipelines de datos, incluido el enfoque y los procedimientos que debes usar, así como las tecnologías que debes emplear. Las opciones van desde reutilizar las canalizaciones de datos (redirigiéndolas para que carguen datos en BigQuery) hasta reescribirlas para aprovechar los servicios gestionados de Google Cloud.

Procedimientos y patrones de flujos de datos

Puedes usar flujos de procesamiento de datos para ejecutar varios procedimientos y patrones. Estos flujos de datos son los que se usan con más frecuencia en los almacenes de datos. Puede que tengas flujos de procesamiento de datos por lotes o de datos en streaming. Las canalizaciones de datos por lotes se ejecutan con los datos recogidos durante un periodo (por ejemplo, una vez al día). Los flujos de procesamiento de datos de streaming gestionan los eventos en tiempo real que generan tus sistemas operativos. Por ejemplo, los cambios de filas de CDC que generan tus bases de datos de procesamiento de transacciones online (OLTP).

Proceso de extracción, transformación y carga (ETL)

En el contexto de los almacenes de datos, los flujos de datos suelen ejecutar un procedimiento de extracción, transformación y carga (ETL). Las tecnologías ETL se ejecutan fuera del almacén de datos, lo que significa que los recursos del almacén de datos se pueden usar principalmente para realizar consultas simultáneas, en lugar de para preparar y transformar datos. Una de las desventajas de que la transformación se ejecute fuera del almacén de datos es que requiere que aprendas herramientas y lenguajes adicionales (distintos de SQL) para expresar las transformaciones.

En el siguiente diagrama se muestra un procedimiento ETL típico.

Imagen 1. Un procedimiento de ETL habitual.

Nota: Las flechas indican la dirección del flujo de datos. Las fuentes del DAG suelen extraer sus datos de los sistemas de origen.

Un flujo de procesamiento de datos de ETL típico extrae datos de uno o varios sistemas de origen (preferiblemente, de los menos posibles para evitar fallos causados por problemas como sistemas no disponibles). A continuación, la canalización realiza una serie de transformaciones, como limpiar los datos, aplicarles reglas de negocio, comprobar su integridad y crear agregaciones o desagregaciones. Para obtener más información, consulta el ciclo de ETL en situaciones reales.

Es habitual tener varias canalizaciones de datos. El primer flujo de datos se centra en copiar datos del sistema de origen al almacén de datos. Las siguientes canalizaciones aplican la lógica empresarial y transforman los datos para usarlos en varios mercados de datos, que son subconjuntos del almacén de datos centrados en una unidad de negocio o un enfoque empresarial específicos.

Cuando tienes varias canalizaciones de datos, debes orquestarlas. En el siguiente diagrama se muestra cómo podría ser este proceso de orquestación.

Imagen 2. Proceso de orquestación de varios flujos de procesamiento de datos.

En el diagrama, cada canalización de datos se considera un sub-DAG del DAG de orquestación. Cada DAG de orquestación abarca varias canalizaciones de datos para ajustarse al objetivo general, como preparar datos para una unidad de negocio de forma que los analistas de negocio puedan ejecutar sus paneles de control o informes.

Proceso de extracción, carga y transformación (ELT)

ELT es una alternativa a ETL. Con ELT, el flujo de datos se divide en dos partes. En primer lugar, una tecnología ELT extrae los datos del sistema de origen y los carga en el almacén de datos. En segundo lugar, las secuencias de comandos SQL sobre el almacén de datos realizan las transformaciones. La ventaja de este enfoque es que puedes usar SQL para expresar las transformaciones. El inconveniente es que puede consumir recursos del almacén de datos que se necesiten para realizar consultas simultáneas. Por este motivo, los lotes de ELT suelen ejecutarse por la noche (o en horas de menor actividad) cuando los recursos del sistema del almacén de datos tienen menos demanda.

En el siguiente diagrama se muestra un procedimiento de ELT típico.

Imagen 3. Un procedimiento ELT habitual.

Cuando adoptas un enfoque ELT, es habitual separar la extracción y la carga en un DAG y las transformaciones en sus propios DAGs. Los datos se cargan en el almacén de datos una vez y, a continuación, se transforman varias veces para crear las diferentes tablas que se usan más adelante en los informes, etc. Estos DAGs se convierten en sub-DAGs de un DAG de orquestación más grande (como se muestra en la sección ETL).

Cuando migras flujos de procesamiento de datos de un almacén de datos on-premise congestionado a la nube, es importante recordar que los sistemas de almacén de datos en la nube, como BigQuery, son tecnologías de procesamiento de datos masivamente paralelas. De hecho, en el caso de BigQuery, puedes comprar más recursos para satisfacer las crecientes demandas de ELT y de consultas simultáneas. Para obtener más información, consulta la introducción a la optimización del rendimiento de las consultas.

Extracción y carga (EL)

Puedes usar el procedimiento de extracción y carga (EL) por sí solo o seguido de transformaciones, en cuyo caso se convierte en ELT. Se menciona por separado porque hay varios servicios automatizados que realizan esta tarea, lo que reduce la necesidad de crear tu propia canalización de datos de ingestión. Para obtener más información, consulta BigQuery Data Transfer Service.

Captura de datos de cambios (CDC)

La captura de datos de cambios (CDC) es uno de los varios patrones de diseño de software que se usan para monitorizar los cambios en los datos. Se suele usar en el almacenamiento de datos, ya que el almacén de datos se utiliza para recopilar y monitorizar datos y sus cambios de varios sistemas de origen a lo largo del tiempo.

En el siguiente diagrama se muestra un ejemplo de cómo funciona CDC con ELT.

Imagen 4. Cómo funciona CDC con ELT.

CDC funciona bien con ELT porque quieres almacenar el registro original antes de hacer cambios en los sistemas posteriores.

Para llevar a cabo la parte de EL, puedes procesar los registros de la base de datos con software de CDC, como Datastream, o herramientas de código abierto, como Debezium, y escribir los registros en BigQuery con Dataflow. Después, puedes usar una consulta SQL para determinar la versión más reciente antes de aplicar más transformaciones. Veamos un ejemplo:

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

Cuando refactorices o crees nuevas canalizaciones de datos, considera la posibilidad de usar el patrón de CDC aplicado como un procedimiento ELT. De esta forma, tendrás un historial completo de los cambios en los datos de origen y se proporcionará una buena separación de responsabilidades. Por ejemplo:

• Los equipos del sistema de origen se aseguran de que sus registros estén disponibles y de que se publiquen sus eventos de datos.
• El equipo de la plataforma de datos se asegura de que la ordenación de la ingestión de los registros originales incluya marcas de tiempo en el almacén de datos.
• Los equipos de ingeniería y análisis de datos programan una serie de transformaciones para rellenar sus marts de datos.

Bucles de retroalimentación con flujos de procesamiento de datos operativos

Los pipelines de datos operativos son pipelines de tratamiento de datos que toman datos del almacén de datos, los transforman si es necesario y escriben el resultado en sistemas operativos.

Los sistemas operativos hacen referencia a los sistemas que procesan las transacciones diarias de la organización, como las bases de datos OLTP, los sistemas de gestión de relaciones con clientes (CRM) y los sistemas de gestión de catálogos de productos (PCM), entre otros. Como estos sistemas suelen actuar como fuente de datos, los flujos de procesamiento de datos operativos implementan un patrón de bucle de retroalimentación.

El patrón de la canalización de datos operativos se muestra en el siguiente diagrama.

Imagen 5. Patrón de un flujo de datos operativo.

En el siguiente ejemplo se describe una canalización de datos operativa que escribe precios de productos en un sistema PCM. Un sistema PCM es el sistema autorizado para la información de producto relacionada con las ventas, como los colores, los canales de venta, el precio y la estacionalidad. Este es el flujo de datos de extremo a extremo:

• Los datos relacionados con los precios están disponibles en varias fuentes. Estos datos pueden incluir el precio actual por región del PCM, los precios de la competencia de un servicio de terceros, las previsiones de demanda y la fiabilidad de los proveedores de sistemas internos, etc.
• Un proceso de ETL extrae los datos de las fuentes, los transforma y escribe el resultado en el almacén de datos. En este caso, la transformación es un cálculo complejo que implica todas las fuentes con el objetivo de generar un precio base óptimo para cada producto del PCM.
• Por último, la canalización operativa toma los precios base del almacén de datos, realiza transformaciones sencillas para ajustar los precios de los eventos de temporada y vuelve a escribir los precios finales en el PCM.

Imagen 6. Una canalización de datos operativa que escribe los precios de los productos en un sistema PCM.

Un flujo de procesamiento de datos operativo es un tipo de proceso posterior, mientras que los flujos de procesamiento de datos que implementan ETL, ELT o CDC son procesos anteriores. Sin embargo, las herramientas utilizadas para implementar ambas pueden coincidir. Por ejemplo, puedes usar Dataflow para definir y ejecutar todos los DAG de procesamiento de datos, GoogleSQL para definir transformaciones que se ejecuten en BigQuery y Cloud Composer para orquestar el flujo de datos de principio a fin.

Elegir un método de migración

En esta sección se describen diferentes enfoques que puedes adoptar para migrar tus pipelines de datos.

Redirigir flujos de procesamiento de datos para que escriban en BigQuery

En las siguientes condiciones, puedes plantearte si la tecnología que usas ofrece un receptor de BigQuery integrado (conector de escritura):

• El almacén de datos antiguo se alimenta de flujos de procesamiento de datos que ejecutan un procedimiento de ETL.
• La lógica de transformación se ejecuta antes de que los datos se almacenen en el almacén de datos.

Los proveedores de software independientes (ISVs) ofrecen tecnologías de tratamiento de datos con conectores de BigQuery, entre los que se incluyen los siguientes:

• Informatica: Guía del conector de BigQuery
• Talend: Escribir datos en BigQuery

Nota: Es importante comprobar que el software de procesamiento de datos aprovecha los mecanismos de ingesta a gran escala de BigQuery, como las inserciones en streaming o las cargas por lotes desde Cloud Storage. JDBC o ODBC de Magnitude Simba para BigQuery no es adecuado para operaciones de ingesta a gran escala, ya que estos controladores implementan la interfaz de consulta. Aunque los controladores pueden realizar inserciones, esta interfaz está diseñada para consultar y usar instrucciones del lenguaje de manipulación de datos (DML) en BigQuery, no para realizar inserciones o actualizaciones a gran escala.

Si la tecnología de la canalización de datos no admite la ingestión de datos en BigQuery, puedes usar una variación de este enfoque que escriba los datos temporalmente en archivos que BigQuery ingiera posteriormente.

Imagen 7. Reescribir o reconfigurar la última función de una canalización de datos para escribir datos en BigQuery.

A grandes rasgos, el trabajo consiste en reescribir o reconfigurar la última función de la canalización de datos para escribir datos en BigQuery. Sin embargo, tienes varias opciones que pueden requerir cambios adicionales o nuevo trabajo. Por ejemplo:

Funcional

• Asignaciones de datos: dado que el esquema de la tabla de la base de datos de destino puede cambiar, es posible que tengas que volver a configurar estas asignaciones.
• Validación de métricas: debe validar los informes antiguos y los nuevos, ya que tanto el esquema como las consultas pueden cambiar.

No funciona

• Es posible que los firewalls deban configurarse para permitir la transferencia de datos saliente desde las instalaciones locales a BigQuery.
• Es posible que tengas que hacer cambios en la red para crear más ancho de banda y poder transferir datos de salida.

Redirigir las canalizaciones de datos usando archivos como vehículo intermedio

Si la tecnología de la canalización de datos local no admite las APIs de Google o no puedes usarlas, puedes usar archivos como medio intermedio para que tus datos lleguen a BigQuery.

Este enfoque es similar al de redirección, pero, en lugar de usar un sumidero nativo que pueda escribir en BigQuery, se usa un sumidero que pueda escribir en un sistema de archivos local. Cuando los datos estén en el sistema de archivos, copie los archivos en Cloud Storage. Para obtener más información, consulta la descripción general de las opciones de ingesta de Cloud Storage y los criterios que se tienen en cuenta para elegir una opción de ingesta.

El último paso es cargar los datos de Cloud Storage en BigQuery siguiendo las directrices de Cargar datos por lotes.

En el siguiente diagrama se muestra el enfoque descrito en esta sección.

Imagen 8. Redirigir las canalizaciones de datos usando archivos como vehículo intermedio.

En cuanto a la orquestación de la canalización ETL, debes seguir dos pasos independientes:

1. Reutiliza la orquestación de la canalización local para escribir los datos transformados en el sistema de archivos. Amplía esta orquestación para copiar los archivos de tu sistema de archivos local en Cloud Storage o crea una secuencia de comandos adicional que se ejecute periódicamente para realizar el paso de copia.
2. Cuando los datos estén en Cloud Storage, usa una transferencia de Cloud Storage para programar cargas periódicas de Cloud Storage a BigQuery. Las alternativas a las transferencias de Cloud Storage son los activadores de Cloud Storage y Cloud Composer.

En la figura 8, se muestra cómo la orquestación deGoogle Cloud también puede usar un modelo de extracción para recuperar los archivos mediante un protocolo como SFTP.

Migrar flujos de procesamiento de ELT a BigQuery

Los flujos de procesamiento ELT constan de dos partes: la que carga los datos en tu almacén de datos y la que transforma los datos mediante SQL para que se puedan usar más adelante. Cuando migras las canalizaciones ELT, cada una de estas partes tiene su propio enfoque de migración.

En la parte que carga datos en tu almacén de datos (la parte de extracción y carga), puedes seguir las directrices de la sección Redirigir flujos de procesamiento de datos, sin tener en cuenta los consejos sobre las transformaciones, que no forman parte de un flujo de procesamiento de datos de extracción y carga.

Si tus fuentes de datos son compatibles con BigQuery Data Transfer Service (DTS) directamente o a través de integraciones de terceros, puedes usar DTS para sustituir tu flujo de procesamiento EL.

Migrar flujos de procesamiento de datos de OSS a Dataproc

Cuando migras tu canalización de datos a Google Cloud, es posible que quieras migrar algunas tareas antiguas escritas con un framework de software libre, como Apache Hadoop, Apache Spark o Apache Flink.

Dataproc te permite desplegar clústeres de Hadoop y Spark rápidos, fáciles de usar y totalmente gestionados de una forma sencilla y rentable. Dataproc se integra con el conector de BigQuery, una biblioteca de Java que permite que Hadoop y Spark escriban datos directamente en BigQuery mediante versiones abstractas de las clases InputFormat y OutputFormat de Apache Hadoop.

Dataproc facilita la creación y eliminación de clústeres para que, en lugar de usar un clúster monolítico, puedas usar muchos clústeres efímeros. Este enfoque tiene varias ventajas:

• Puedes usar diferentes configuraciones de clúster para cada trabajo, lo que elimina la carga administrativa de gestionar herramientas en varios trabajos.
• Puedes escalar clústeres para adaptarlos a trabajos concretos o a grupos de trabajos.
• Solo pagas por los recursos cuando tus trabajos los utilizan.
• No tienes que mantener los clústeres a lo largo del tiempo, ya que se configuran de nuevo cada vez que los usas.
• No es necesario mantener una infraestructura independiente para el desarrollo, las pruebas y la producción. Puedes usar las mismas definiciones para crear tantas versiones diferentes de un clúster como necesites.

Cuando migres tus tareas, te recomendamos que adoptes un enfoque incremental. Si migras de forma incremental, podrás hacer lo siguiente:

• Aísla tareas concretas en tu infraestructura de Hadoop de la complejidad inherente a un entorno maduro.
• Analiza cada tarea de forma aislada para evaluar sus necesidades y determinar la mejor ruta de migración.
• Gestiona los problemas inesperados a medida que surjan sin retrasar las tareas dependientes.
• Crea una prueba de concepto para cada proceso complejo sin que afecte a tu entorno de producción.
• Migra tus trabajos al modelo efímero recomendado de forma meditada y deliberada.

Cuando migras tus tareas de Hadoop y Spark a Dataproc, puedes comprobar que las dependencias de tus tareas se cubren con las versiones de Dataproc compatibles. Si necesitas instalar software personalizado, puedes crear tu propia imagen de Dataproc, usar alguna de las acciones de inicialización disponibles (por ejemplo, para Apache Flink), escribir tu propia acción de inicialización o especificar requisitos de paquetes de Python personalizados.

Para empezar, consulta las guías de inicio rápido de Dataproc y los códigos de ejemplo del conector de BigQuery.

Volver a alojar las canalizaciones de datos de terceros para que se ejecuten en Google Cloud

Un caso habitual al crear flujos de procesamiento de datos en las instalaciones es usar software de terceros para gestionar la ejecución del flujo y la asignación de recursos informáticos.

Para mover estas canalizaciones a la nube, tienes varias alternativas, en función de las funciones del software que estés usando y de los términos de licencia, asistencia y mantenimiento.

En las siguientes secciones se presentan algunas de estas alternativas.

A grandes rasgos, tienes las siguientes alternativas para ejecutar tu software de terceros en Google Cloud, de menor a mayor complejidad:

• Tu proveedor de software se ha asociado con Google Cloud para ofrecer su software en Google Cloud Marketplace.
• Tu proveedor de software de terceros puede ejecutarse en Kubernetes.
• Tu software de terceros se ejecuta en una o varias máquinas virtuales.

Si tu software de terceros proporciona una solución de Cloud Marketplace, el trabajo que debes hacer es el siguiente:

• Despliega tu software de terceros desde la consola de Cloud Marketplace.
• Selecciona y migra tus casos prácticos siguiendo el enfoque iterativo que se explica en el artículo Migrar con un enfoque iterativo.

Esta alternativa es la más sencilla, ya que incorpora sus pipelines de datos a la nube mediante la plataforma que le proporciona su proveedor. También es posible que puedas usar herramientas propias de tu proveedor para facilitar la migración entre tu entorno original y tu nuevo entorno en Google Cloud.

Si tu proveedor no ofrece una solución de Cloud Marketplace, pero su producto se puede ejecutar en Kubernetes, puedes usar Google Kubernetes Engine (GKE) para alojar tus canalizaciones. Esto implica lo siguiente:

• Crea un clúster de GKE siguiendo las recomendaciones de tu proveedor para asegurarte de que el producto de terceros pueda aprovechar la paralelización de tareas que ofrece Kubernetes.
• Instala el software de terceros en tu clúster de GKE siguiendo las recomendaciones del proveedor.
• Selecciona y migra tus casos prácticos siguiendo el enfoque iterativo que se explica en el artículo Migrar almacenes de datos a BigQuery: información general.

Esta alternativa ofrece un punto intermedio en cuanto a complejidad. Aprovecha la compatibilidad nativa de tu proveedor con Kubernetes para escalar y paralelizar la ejecución de tus flujos de procesamiento. Sin embargo, requiere que crees y gestiones un clúster de GKE.

Si tu proveedor no admite Kubernetes, debes instalar su software en un grupo de máquinas virtuales para habilitar el escalado horizontal y paralelizar el trabajo. Si el software de tu proveedor admite de forma nativa la distribución del trabajo en varias VMs, utiliza las funciones que ofrece. También puedes agrupar las instancias de VM en un grupo de instancias administradas (MIG) para aumentar o reducir la escala según sea necesario.

Gestionar la paralelización del trabajo no es tarea fácil. Si tu proveedor no ofrece funciones para distribuir tareas a diferentes VMs, te recomendamos que uses un patrón de granja de tareas para distribuir el trabajo a las VMs de un MIG. En el siguiente diagrama se ilustra este enfoque.

Imagen 9. Un grupo de instancias gestionado con tres VMs.

En este diagrama, cada VM del MIG ejecuta el software de la canalización de terceros. Puedes activar la ejecución de una canalización de varias formas:

• Automáticamente, mediante Cloud Scheduler, Cloud Composer o un activador de Cloud Storage cuando llegan datos nuevos a un segmento de Cloud Storage.
• De forma programática, llamando a un endpoint de Cloud o a una función de Cloud, o bien usando la API Pub/Sub.
• Manualmente, colocando un mensaje nuevo en un tema de Pub/Sub con la CLI de Google Cloud.

En esencia, todos estos métodos envían un mensaje a un tema de Pub/Sub predefinido. Crea un agente sencillo para instalarlo en cada VM. El agente escucha uno o varios temas de Pub/Sub. Cada vez que llega un mensaje al tema, el agente extrae el mensaje del tema, inicia una canalización en tu software de terceros y espera a que se complete. Cuando se completa la canalización, el agente obtiene el siguiente mensaje de los temas que está escuchando.

En todos los casos, te recomendamos que trabajes con tu proveedor para cumplir los términos de licencia adecuados para que tus pipelines funcionen en Google Cloud.

Reescribir las canalizaciones de datos para usar servicios gestionados por Google Cloud

En algunos casos, puede que decidas reescribir algunas de tus canalizaciones de datos para usar nuevos frameworks y servicios totalmente gestionados en Google Cloud. Esta opción es adecuada si tus pipelines se implementaron originalmente con tecnologías que ahora están obsoletas o si crees que sería demasiado poco práctico o costoso migrar y mantener esos pipelines sin modificar en la nube.

En las siguientes secciones se presentan servicios totalmente gestionados Google Cloud que le permiten realizar transformaciones de datos avanzadas a gran escala: Cloud Data Fusion y Dataflow.

Cloud Data Fusion

Cloud Data Fusion, que se ha desarrollado en el proyecto de software libre CDAP, es un servicio de integración de datos totalmente gestionado que permite crear y gestionar flujos de procesamiento de datos mediante una interfaz gráfica.

Los flujos de datos se desarrollan en la interfaz de usuario de Cloud Data Fusion conectando fuentes a transformaciones, receptores y otros nodos para formar un DAG. Cuando implementas tu flujo de procesamiento de datos, el planificador de Cloud Data Fusion transforma este DAG en una serie de cálculos paralelos que se ejecutarán como una tarea de Apache Spark en Dataproc.

Cuando usas Cloud Data Fusion, puedes conectarte a la base de datos de un sistema de origen mediante los controladores de Java Database Connectivity (JDBC) para leer datos, transformarlos y cargarlos en el destino que elijas (por ejemplo, BigQuery) sin tener que escribir código. Para ello, debes subir un controlador JDBC a tu instancia de Cloud Data Fusion y configurarlo para poder usarlo en tus flujos de procesamiento de datos. Para obtener más información, consulta la guía sobre cómo usar controladores JDBC con Cloud Data Fusion.

Cloud Data Fusion expone los complementos de fuentes, transformaciones, agregaciones, sumideros, recopiladores de errores, editores de alertas, acciones y acciones posteriores a la ejecución como componentes personalizables. Los complementos precompilados ofrecen acceso a una amplia gama de fuentes de datos. Si no existe un complemento, puedes crear el tuyo propio con las APIs de complementos de Cloud Data Fusion. Para obtener más información, consulta el resumen de los complementos.

Con los flujos de procesamiento de Cloud Data Fusion, puedes crear flujos de procesamiento de datos por lotes y de streaming. Al proporcionar acceso a registros y métricas, las canalizaciones de datos también ofrecen a los administradores formas de poner en práctica sus flujos de trabajo de procesamiento de datos sin necesidad de usar herramientas personalizadas.

Para empezar, consulta la información general conceptual de Cloud Data Fusion. Para ver ejemplos prácticos, consulta la guía de inicio rápido y el tutorial sobre cómo crear una pipeline de campañas de segmentación.

Dataflow

Dataflow es un servicio totalmente gestionado para ejecutar trabajos de Apache Beam a gran escala. Apache Beam es un framework de código abierto que proporciona un amplio conjunto de primitivas de análisis de ventanas y sesiones, así como un ecosistema de conectores de origen y de destino, incluido un conector para BigQuery. Apache Beam te permite transformar y enriquecer datos tanto en streaming (en tiempo real) como por lotes (histórico) con la misma fiabilidad y expresividad.

El enfoque sin servidor de Dataflow elimina la sobrecarga operativa, ya que el rendimiento, el escalado, la disponibilidad, la seguridad y el cumplimiento normativo se gestionan de forma automática. De esta forma, puedes centrarte en la programación en lugar de en la gestión de clústeres de servidores.

Puedes enviar tareas de Dataflow de diferentes formas: a través de la interfaz de línea de comandos, el SDK de Java o el SDK de Python. Además, estamos desarrollando un framework de portabilidad para que todos los SDKs y runners sean totalmente interoperables.

Si quieres migrar tus consultas de datos y tus flujos de procesamiento de otros frameworks a Apache Beam y Dataflow, consulta el modelo de programación de Apache Beam y la documentación oficial de Dataflow.

Para ver ejemplos prácticos, consulta las guías de inicio rápido y los tutoriales de Dataflow.

Orquestación y programación

A grandes rasgos, la orquestación es la coordinación automatizada de varios sistemas, mientras que la programación se refiere a la activación automatizada del trabajo de orquestación.

• Ampliación: un flujo de procesamiento de datos es en sí mismo una orquestación de transformaciones de datos descritas por un DAG, que es un DAG de procesamiento de datos.
• Reducir la vista: cuando un flujo de procesamiento de datos depende de la salida de otros flujos de procesamiento de datos, necesitas orquestar varios flujos. Cada flujo de trabajo constituye un sub-DAG en un DAG más grande, que es un DAG de orquestación.

Esta configuración es habitual en el almacenamiento de datos. En la imagen 1 de la sección ETL se muestra un ejemplo de configuración. En las siguientes secciones se explica cómo orquestar varios flujos de procesamiento de datos.

Dependencias

Las dependencias pueden ser de entrada, donde varios flujos de procesamiento de datos se combinan en un vértice de un DAG de orquestación, o de salida, donde un solo flujo de procesamiento de datos activa varios flujos, o bien de ambos tipos, como se muestra en el siguiente diagrama.

Imagen 10. Dependencias de entrada y salida usadas en combinación.

En entornos no óptimos, algunas dependencias se deben a limitaciones en la cantidad de recursos disponibles. Por ejemplo, un flujo de datos se ejecuta y genera algunos datos comunes como subproducto. Otras canalizaciones de datos dependen de estos datos comunes simplemente para evitar tener que volver a calcularlos, pero no están relacionadas con la canalización de datos que creó los datos. Si esta primera canalización tiene algún problema funcional o no funcional, los errores se propagarán a las canalizaciones de datos dependientes, lo que, en el mejor de los casos, las obligará a esperar o, en el peor, les impedirá ejecutarse, como se muestra en el siguiente diagrama.

Imagen 11. Si se producen errores en cascada en una canalización de datos, las canalizaciones dependientes no se podrán ejecutar.

En Google Cloud, tienes a tu disposición una gran cantidad de recursos de computación y herramientas especializadas para optimizar la ejecución de tus flujos de trabajo y su orquestación. En las secciones restantes se describen estos recursos y herramientas.

Trabajo de migración implicado

Es una práctica recomendada simplificar tus necesidades de orquestación. La orquestación se vuelve más compleja a medida que aumenta el número de dependencias entre tus pipelines de datos. Migrar a Google Cloud te ofrece la oportunidad de examinar tus DAGs de orquestación, identificar tus dependencias y determinar cómo optimizarlas.

Te recomendamos que optimices tus dependencias de forma incremental, de la siguiente manera:

1. En una primera iteración, mueve tu orquestación tal cual a Google Cloud.
2. En iteraciones posteriores, analiza tus dependencias y paralelízalas si es posible.
3. Por último, reorganiza la orquestación extrayendo las tareas comunes en sus propios DAGs.

En la siguiente sección se explica este método con un ejemplo práctico.

Ejemplo práctico

Supongamos que una organización tiene dos pipelines relacionados:

• La primera canalización calcula los beneficios y las pérdidas de toda la organización. Se trata de una canalización compleja que implica muchas transformaciones. Una parte de la canalización consiste en calcular las ventas mensuales, que se usan en pasos de transformación posteriores y, finalmente, se escriben en una tabla.
• La segunda canalización calcula el crecimiento de las ventas interanual y mensual de diferentes productos para que el departamento de marketing pueda ajustar sus campañas publicitarias. Esta canalización necesita los datos de ventas mensuales que ha calculado previamente la canalización de datos de pérdidas y ganancias.

La organización considera que la canalización de datos de pérdidas y ganancias tiene más prioridad que la canalización de marketing. Lamentablemente, como el P&L es un flujo de datos complejo, consume una gran cantidad de recursos, lo que impide que otros flujos se ejecuten simultáneamente. Además, si falla el flujo de procesamiento de ingresos y gastos, el flujo de procesamiento de marketing y otros flujos de procesamiento dependientes no tendrán los datos necesarios para ejecutarse y deberán esperar a que se vuelva a intentar el flujo de procesamiento de ingresos y gastos. En el siguiente diagrama se ilustra esta situación.

Imagen 12. Las canalizaciones de datos complejas pueden impedir que se ejecuten las de menor prioridad.

La organización está migrando a BigQuery. Ha identificado los dos casos prácticos (pérdidas y ganancias, y crecimiento de las ventas de marketing) y los ha incluido en la lista de tareas pendientes de la migración. Al planificar la siguiente iteración, la organización prioriza el caso práctico de la cuenta de resultados y lo incluye en la lista de tareas pendientes de la iteración porque está muy limitado por los recursos locales actuales y provoca retrasos con frecuencia. También se incluyen algunos de sus casos prácticos dependientes, entre los que se encuentra el caso práctico de marketing.

El equipo de migración ejecuta la primera iteración. Deciden migrar tanto los casos prácticos de pérdidas y ganancias como los de marketing a Google Cloud mediante un enfoque de redirección. No hacen ningún cambio en los pasos ni en la orquestación de la canalización. Una diferencia importante es que ahora la canalización de pérdidas y ganancias puede disponer de una potencia de cálculo casi ilimitada y, por lo tanto, se ejecuta mucho más rápido que en las instalaciones locales. La canalización escribe los datos mensuales de ventas en una tabla de BigQuery que usa la canalización de crecimiento de marketing. En el siguiente diagrama se muestran estos cambios.

Imagen 13. Acelerar un flujo de procesamiento de datos complejo mediante un enfoque de redirección.

Aunque Google Cloud ha ayudado con los problemas de la cuenta de resultados no funcionales, siguen existiendo problemas funcionales. A menudo, algunas tareas no relacionadas que preceden al cálculo de las ventas mensuales provocan errores que impiden que se lleve a cabo ese cálculo y que las canalizaciones dependientes no puedan iniciarse.

En una segunda iteración, el equipo espera mejorar el rendimiento incluyendo ambos casos prácticos en la cartera de iteraciones. El equipo identifica los pasos del flujo de trabajo para calcular las ventas mensuales en el flujo de trabajo de la cuenta de resultados. Los pasos constituyen un sub-DAG, tal como se muestra en el siguiente diagrama. El equipo de migración copia el sub-DAG en la canalización de marketing para que esta pueda ejecutarse de forma independiente a la de pérdidas y ganancias. Si tienes suficiente potencia de computación, Google Cloud ambas canalizaciones se pueden ejecutar simultáneamente.

Imagen 14. Pipelines que se ejecutan simultáneamente mediante un sub-DAG.

El inconveniente es que duplicar la lógica del sub-DAG genera una sobrecarga de gestión del código, ya que ahora el equipo tiene que mantener sincronizadas ambas copias de la lógica del sub-DAG.

En una tercera iteración, el equipo vuelve a analizar los casos prácticos y extrae el sub-DAG de ventas mensuales en una canalización independiente. Cuando se completa la nueva previsión de ventas mensual, se activa o se ramifica en la cuenta de resultados, el crecimiento del marketing y otras previsiones dependientes. Esta configuración crea un nuevo DAG de orquestación general, en el que cada una de las canalizaciones es uno de sus sub-DAGs.

Imagen 15. DAG de orquestación general con cada flujo de procesamiento en su propio sub-DAG.

En las iteraciones posteriores, el equipo de migración puede resolver los problemas funcionales que queden y migrar las canalizaciones para que usen los siguientes servicios gestionados porGoogle Cloud, entre otros:

• Dataflow: te permite definir cada flujo de procesamiento de datos como un DAG independiente mediante el modelo de Beam.
• Cloud Composer: te permite definir la orquestación más amplia como uno o varios DAGs de Airflow.

Aunque Airflow admite sub-DAGs de forma nativa, esta función puede limitar su rendimiento, por lo que no se recomienda. En su lugar, usa DAGs independientes con el operador TriggerDagRunOperator.

Siguientes pasos

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

• Información general sobre la migración
• Evaluación de la migración
• Información general sobre la transferencia de esquemas y datos
• Traducción de SQL por lotes
• Traducción interactiva de SQL
• Gobierno y seguridad de los datos
• Herramienta de validación de datos

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

• Migrar desde Netezza
• Migrar desde Oracle
• Migrar desde Amazon Redshift
• Migrar desde Teradata
• Migrar desde Snowflake