Migra canalizaciones de datos

En este documento, se describe cómo migrar las canalizaciones de datos ascendentes, que cargan datos en tu almacén de datos. Puedes usar este documento a fin de comprender mejor qué es una canalización de datos, qué procedimientos y patrones puedes usar y qué opciones y tecnologías de migración están disponibles para una migración del almacén de datos.

¿Qué es una canalización de datos?

En informática, una canalización de datos es un tipo de aplicación que procesa datos a través de una secuencia de pasos de procesamiento conectados. Como concepto general, las canalizaciones de datos se pueden aplicar, por ejemplo, a la transferencia de datos entre sistemas de información, la extracción, transformación y carga (ETL), el enriquecimiento de datos y el análisis de datos en tiempo real. Por lo general, las canalizaciones de datos se operan como un proceso por lotes que genera y procesa datos cuando se ejecuta, o como un proceso de transmisión que se lleva a cabo de forma continua y procesa datos a medida que están disponibles para la canalización.

En el contexto del almacenamiento de datos, las canalizaciones suelen usarse para leer datos desde sistemas transaccionales, aplicar transformaciones y, luego, escribir datos en el almacén. Cada una de las transformaciones se describe con una función, y la entrada para cualquier función dada es la salida de la función o las funciones anteriores. Estas funciones conectadas se describen como un grafo, y este grafo se conoce como grafo acíclico dirigido (DAG): se lo llama "dirigido" porque el grafo sigue una dirección (desde la fuente hasta el destino) y "acíclico" porque la entrada para cualquier función no puede depender del resultado de otra función descendente en el DAG. En otras palabras, no se permiten los bucles. Cada nodo del grafo es una función, y cada borde representa los datos que fluyen de una función a la siguiente. Las funciones iniciales son fuentes o conexiones a sistemas de datos de origen. Las funciones finales son receptores o conexiones a sistemas de datos de destino.

En el contexto de las canalizaciones de datos, las fuentes suelen ser sistemas transaccionales (por ejemplo, un RDBMS) y el receptor se conecta a un almacén de datos. Este tipo de grafo se denomina DAG de flujo de datos. También puedes usar DAG para organizar el movimiento de datos entre canalizaciones de datos y otros sistemas. Este uso se conoce como DAG de flujo de control o de organización.

Cuándo migrar las canalizaciones de datos

Cuando migras un caso de uso a BigQuery, puedes optar por descargarlo o migrarlo por completo.

Por un lado, cuando descargas un caso práctico, no necesitas migrar las canalizaciones de datos ascendentes por adelantado. Primero, migra el esquema del caso práctico y los datos desde tu almacén de datos existente hasta BigQuery. Luego, establece una copia incremental desde el almacén de datos antiguo hasta el nuevo para mantener los datos sincronizados. Finalmente, migra y valida los procesos descendentes, como secuencias de comandos, consultas, paneles y aplicaciones de negocios.

En este punto, las canalizaciones de datos ascendentes no han cambiado y aún escriben datos en tu almacén de datos existente. Puedes volver a incluir los casos prácticos descargados en el trabajo pendiente de migración para migrarlos por completo en una iteración posterior.

Por otro lado, cuando migras por completo un caso práctico, las canalizaciones de datos ascendentes requeridas para el caso práctico se migran a Google Cloud. Para la migración completa, se requiere que primero descargues el caso práctico. Después de la migración completa, puedes hacer que las tablas heredadas correspondientes queden obsoletas en el almacén de datos local porque los datos se transfieren directamente a BigQuery.

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

• Descarga solo tu caso práctico.
• Migra completamente un caso práctico que se descargó con anterioridad.
• Migra completamente un caso práctico desde cero cuando primero lo descargas en la misma iteración.

Cuando todos tus casos prácticos se migran por completo, puedes optar por desconectar el antiguo almacén, lo que es un paso importante para reducir los gastos generales y los costos.

Cómo migrar las canalizaciones de datos

En el resto de este documento, se aborda cómo migrar tus canalizaciones de datos, así como qué enfoque, procedimientos y tecnologías usar. Las opciones abarcan desde la reutilización de las canalizaciones de datos existentes (se redireccionan para cargar BigQuery) hasta la reescritura de las canalizaciones de datos a fin de aprovechar los servicios administrados por GCP.

Procedimientos y patrones para canalizaciones de datos

Puedes usar canalizaciones de datos para ejecutar una serie de procedimientos y patrones. Estas canalizaciones son las más utilizadas en el almacenamiento de datos. Es posible que tengas canalizaciones de datos por lotes o canalizaciones de datos de transmisión. Las canalizaciones de datos por lotes se ejecutan en los datos recopilados durante un período (por ejemplo, una vez al día). Las canalizaciones de datos de transmisión controlan los eventos en tiempo real generados por tus sistemas operativos, por ejemplo, en los cambios de fila de CDC producidos por tus bases de datos de procesamiento de transacciones en línea (OLTP).

Extracción, transformación y carga (ETL)

En el contexto del almacenamiento de datos, las canalizaciones de datos a menudo ejecutan un procedimiento de extracción, transformación y carga (ETL). Las tecnologías de ETL se ejecutan fuera del almacén de datos, lo que significa que los recursos del almacén de datos se pueden usar principalmente con el fin de realizar consultas simultáneas, en lugar de hacerlo para preparar y transformar datos. Una desventaja de las transformaciones fuera del almacén de datos es que requieren conocimientos sobre herramientas y lenguajes adicionales (además de SQL) para expresarlas.

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

Figura 1. Procedimiento de ETL típico.

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

Una canalización de datos ETL típica extrae datos de uno o más sistemas de origen (preferentemente, de la menor cantidad posible para evitar fallas causadas por problemas como sistemas no disponibles). Luego, la canalización realiza una serie de transformaciones, que incluyen la limpieza de datos, la aplicación de reglas comerciales, la verificación de la integridad de los datos y la creación de agregados o desagregados. Para saber más, consulta información sobre el ciclo de ETL en la vida real.

Es común tener varias canalizaciones de datos. La primera canalización se enfoca en copiar datos desde el sistema de origen hasta el almacén de datos. Las canalizaciones posteriores aplican la lógica empresarial y transforman los datos para su uso en varios data marts, que son subconjuntos del almacén de datos centrados en una unidad de negocios o un enfoque comercial específicos.

Cuando tienes varias canalizaciones de datos, debes organizarlas. En el diagrama siguiente, se muestra cómo se vería el proceso de organización.

Figura 2. Proceso de organización para varias canalizaciones de datos.

En el diagrama, cada canalización de datos se considera un DAG secundario del DAG de organización. Cada DAG de organización abarca varias canalizaciones de datos a fin de alinearse con el objetivo más amplio, por ejemplo, preparar datos para una unidad de negocios a fin de que los analistas de negocios puedan ejecutar sus paneles o informes.

Extracción, carga y transformación (ELT)

ELT es una alternativa a ETL. Con ELT, la canalización de datos se divide en dos partes. En primer lugar, una tecnología ETL extrae los datos del sistema de origen y los carga en el almacén de datos. En segundo lugar, las secuencias de comandos de SQL en la parte superior del almacén de datos realizan las transformaciones. La ventaja de este enfoque es que puedes usar SQL para expresar las transformaciones. La desventaja es que esto podría consumir los recursos del almacén de datos que se necesitan para las consultas simultáneas. Por esta razón, los lotes de ELT a menudo se ejecutan durante la noche (o fuera del horario pico) cuando los recursos del sistema del almacén de datos tienen una demanda menor.

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

Figura 3. Procedimiento de ELT típico

Cuando adoptas un enfoque de ELT, es común separar el extracto y la carga en un DAG y las transformaciones en sus propios DAG. Los datos se cargan en el almacén de datos una vez y, luego, se transforman varias veces para crear las diferentes tablas que se utilizan en los informes posteriores, y así sucesivamente. Estos DAG, a su vez, se convierten en DAG secundarios respecto de un DAG de organización más grande (como se muestra en la sección sobre ETL).

Cuando migras las canalizaciones de datos desde un almacén de datos local congestionado hasta la nube, es importante recordar que los sistemas de almacenamiento 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 respaldar las crecientes demandas de ELT y las consultas simultáneas. Para obtener más información, consulta 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) solo o seguido de transformaciones, en cuyo caso se convierte en ELT. EL se menciona por separado porque hay varios servicios automatizados disponibles que realizan esta tarea, lo que evita que debas crear tu propia canalización de datos de transferencia. Para obtener más detalles, consulta esta página sobre el Servicio de transferencia de datos de BigQuery.

Captura de datos modificados (CDC)

La captura de datos modificados (CDC) es uno de los diversos patrones de diseño de software que se usan para realizar un seguimiento de los cambios en los datos. A menudo, se utiliza en el almacenamiento de datos porque el almacén de datos se usa para recopilar y hacer un seguimiento de los datos y sus cambios desde varios sistemas de origen a lo largo del tiempo.

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

Figura 4. Cómo funciona la CDC con ELT.

La CDC funciona bien con ELT porque deseas almacenar el registro original antes de realizar cualquier cambio descendente.

Para que la parte de EL suceda, 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 a BigQuery mediante Dataflow. Luego, puedes usar una consulta de SQL para determinar la última versión antes de aplicar más transformaciones. A continuación, se presenta 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 usar el patrón de CDC aplicado como un procedimiento de ELT. Este enfoque garantiza que tengas un historial completo de los datos modificados en sentido ascendente y proporciona una buena segregación de responsabilidades, como la siguiente:

• Los equipos del sistema de origen garantizan la disponibilidad de sus registros y la publicación de sus eventos de datos.
• El equipo de la plataforma de datos se asegura de que la intercalación de la transferencia de los registros originales incluya marcas de tiempo en el almacén de datos.
• Los equipos de análisis y de ingeniería de datos programan una serie de transformaciones para propagar sus data marts.

Ciclos de reacción con canalizaciones de datos operativos

Las canalizaciones de datos operacionales son canalizaciones de procesamiento 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 se refieren a los sistemas que procesan las transacciones diarias de la organización, como las bases de datos de OLTP, los sistemas de administración de las relaciones con los clientes (CRM), los sistemas de administración de catálogos de productos (PCM), etcétera. Debido a que estos sistemas a menudo actúan como una fuente de datos, las canalizaciones de datos operacionales implementan un patrón de ciclo de retroalimentación.

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

Figura 5. Patrón para una canalización de datos operativos

En el ejemplo siguiente, se describe una canalización de datos operativos que escribe los precios de los productos en un sistema PCM. El sistema PCM es el sistema autorizado para la información de productos relacionados con las ventas, como colores, canales de venta, precios y temporadas. El siguiente es el flujo de datos de extremo a extremo:

• Los datos relacionados con el precio están disponibles desde varias fuentes. Estos datos pueden incluir el precio actual por región del sistema PCM, los precios de la competencia desde un servicio de terceros, la previsión de la demanda y la confiabilidad del proveedor desde los sistemas internos, etcétera.
• Una canalización de ETL extrae los datos de las fuentes, los transforma y escribe el resultado en el almacén de datos. La transformación en este caso es un cálculo complejo que involucra a todas las fuentes con el objetivo de producir un precio base óptimo para cada producto en el sistema PCM.
• Por último, la canalización operativa toma los precios base del almacén de datos, realiza transformaciones pequeñas para ajustar los precios de los eventos de temporada y escribe los precios finales en el sistema PCM.

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

Una canalización de datos operacionales es un tipo de proceso descendente, mientras que las canalizaciones de datos que implementan ETL, ELT o CDC son procesos ascendentes. Sin embargo, las herramientas usadas para implementar ambos tipos de procesos pueden superponerse. Por ejemplo, puedes usar Cloud Dataflow para definir y ejecutar todos los DAG de procesamiento de datos; GoogleSQL a fin de definir transformaciones que se ejecutan dentro de BigQuery, y Cloud Composer con el objetivo de organizar el flujo de datos de extremo a extremo.

Elige un enfoque de migración

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

Redirecciona canalizaciones de datos para escribir en BigQuery

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

• El almacén de datos heredado realiza el feed por las canalizaciones de datos que ejecutan un procedimiento 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 (ISV) ofrecen las tecnologías de procesamiento de datos con conectores BigQuery, incluidos los siguientes:

• Informatica: guía del conector de BigQuery
• Talend: escritura de datos en BigQuery

Nota: Es importante verificar que el software de procesamiento de datos aproveche los mecanismos de transferencia a gran escala de BigQuery, como las inserciones de transmisión o cargas por lotes desde Cloud Storage. Un enfoque que emplee los controladores para BigQuery de Magnitude Simba, ODBC o JDBC no es adecuado en operaciones de transferencia a gran escala, ya que estos controladores implementan la interfaz de consulta. Si bien los controladores pueden realizar inserciones, esta interfaz está diseñada para las declaraciones de lenguaje de manipulación de datos (DML) y consulta en BigQuery, sin incluir inserciones ni actualizaciones a gran escala.

Si la tecnología de canalización de datos no admite la transferencia de datos a BigQuery, considera usar una variante de este enfoque que escriba de forma temporal los datos en archivos que BigQuery transfiere luego.

Figura 7. Reescritura o reconfiguración de la última función de una canalización de datos para escribir datos en BigQuery.

En un nivel alto, el trabajo involucra la reescritura o la reconfiguración de la última función de la canalización de datos para escribir datos en BigQuery. Sin embargo, tienes una serie de opciones que pueden requerir cambios adicionales o nuevos trabajos, por ejemplo:

Problemas funcionales

• Asignaciones de datos: Dado que el esquema de la tabla de la base de datos de destino podría cambiar, es posible que necesites volver a configurar estas asignaciones.
• Validación métrica: Debes validar tanto los informes históricos como los nuevos, ya que tanto el esquema como las consultas pueden cambiar.

Problemas no funcionales

• Es posible que los firewalls necesiten configurarse para permitir la transferencia de datos salientes desde las instalaciones locales hacia BigQuery.
• Probablemente se requieran cambios de red a fin de crear ancho de banda adicional para incorporar la transferencia de datos salientes.

Redirecciona canalizaciones de datos mediante el uso de archivos como un vehículo intermedio

Cuando la tecnología de canalización de datos local existente no es compatible con las API de Google, o si tienes restricciones para usar las API de Google, puedes usar archivos como un vehículo intermedio a fin de que tus datos lleguen a BigQuery.

Este enfoque es similar al de redireccionamiento, pero en lugar de usar un receptor nativo que puede escribir en BigQuery, utilizas un receptor que puede escribir en un sistema de archivos local. Cuando tus datos están en tu sistema de archivos, copias los archivos a Cloud Storage. Si deseas obtener más detalles, consulta la descripción general de las opciones de transferencia para Cloud Storage y los criterios que se usan con el fin de elegir una opción de transferencia.

El último paso es cargar los datos de Cloud Storage en BigQuery según las pautas indicadas en Datos de carga por lotes.

El diagrama siguiente muestra el enfoque que se describe en esta sección.

Figura 8. Redireccionamiento de canalizaciones de datos mediante el uso de archivos como vehículo intermedio.

Con respecto a la organización de la canalización ETL, debes realizar los dos pasos separados siguientes:

1. Vuelve a usar la organización de la canalización local existente para escribir los datos transformados en el sistema de archivos. Extiende esta organización para copiar los archivos de tu sistema de archivos local en Cloud Storage, o crea una secuencia de comandos adicional que se ejecute regularmente para realizar el paso de copia.
2. Cuando los datos estén en Cloud Storage, usa una transferencia de Cloud Storage para programar cargas recurrentes 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, observa cómo también es posible que la organización en GCP use un modelo de extracción mediante la recuperación de los archivos con un protocolo como SFTP.

Migra canalizaciones de ELT existentes a BigQuery

Las canalizaciones de ELT constan de dos partes: la parte que carga los datos en tu almacén de datos y la que transforma los datos mediante SQL para que se puedan consumir en sentido descendente. Cuando migras las canalizaciones ELT, cada una de estas partes tiene su propio enfoque para la migración.

Para la parte que carga datos en tu almacén de datos (la parte EL), puedes seguir las pautas indicadas en la sección de redireccionamiento de canalizaciones de datos, a excepción del asesoramiento sobre transformaciones, las cuales no son parte de una canalización EL.

Si tus fuentes de datos son compatibles con el Servicio de transferencia de datos de BigQuery (DTS) directamente o mediante integraciones de terceros, puedes usar DTS para reemplazar tu canalización de EL.

Migra canalizaciones de datos OSS existentes a Dataproc

Cuando migres tu canalización de datos a Google Cloud, es posible que también desees migrar algunos trabajos heredados que se escriben con un framework de software de código abierto como Apache Hadoop, Apache Spark o Apache Flink.

Dataproc te permite implementar clústeres de Hadoop y Spark rápidos, fáciles de usar y completamente administrados de una manera simple y rentable. Dataproc se integra con el conector de BigQuery, una biblioteca de Java que permite a Hadoop y Spark escribir datos directamente en BigQuery mediante el uso de 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 trabajos individuales, lo que borra la carga de administrar herramientas entre trabajos.
• Puedes escalar clústeres para adaptarse a trabajos individuales o a grupos de trabajos.
• Solo pagas por los recursos cuando tus trabajos los utilizan.
• No necesitas mantener los clústeres a lo largo del tiempo, ya que se configuran de nuevo cada vez que los usas.
• No necesitas mantener una infraestructura separada para el desarrollo, las pruebas ni la producción. Puedes usar las mismas definiciones para crear tantas versiones diferentes de un clúster como y cuando sea necesario.

Cuando migres tus trabajos, te recomendamos que adoptes un enfoque gradual. Si realizas la migración de forma incremental, puedes hacer lo siguiente:

• Aislar trabajos individuales en tu infraestructura existente de Hadoop de la complejidad inherente a un entorno maduro
• Examinar cada trabajo de forma aislada a fin de evaluar sus necesidades y determinar la mejor ruta para la migración
• Manejar problemas inesperados a medida que surjan sin retrasar las tareas dependientes
• Crear una prueba de concepto para cada proceso complejo sin afectar tu entorno de producción
• Trasladar tus trabajos al modelo efímero recomendado de manera inteligente y deliberada

Cuando migras tus trabajos existentes de Hadoop y Spark a Dataproc, puedes verificar que las dependencias de tus trabajos estén cubiertas por las versiones de Dataproc compatibles. Si necesitas instalar software personalizado, puedes crear tu propia imagen de Dataproc, usar algunas 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 personalizados de Python.

Para comenzar, consulta las guías de inicio rápido de Dataproc y los ejemplos de código del conector de BigQuery. Consulta también cómo migrar trabajos locales de Hadoop a Dataproc.

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

Una situación común cuando se compilan canalizaciones de datos en el sistema local es usar software de terceros para administrar la ejecución de la canalización y la asignación de recursos de procesamiento.

Para mover estas canalizaciones a la nube, tienes varias alternativas, según las capacidades del software que usas y tus condiciones de licencia, asistencia y mantenimiento.

En las secciones siguientes, se presentan algunas de estas alternativas.

En un nivel superior, tienes las alternativas siguientes para ejecutar tu software de terceros en Google Cloud, de menor a mayor complejidad:

• Tu proveedor de software se asoció con Google Cloud para ofrecer su software en Google Cloud Marketplace.
• El proveedor de software de terceros puede ejecutarse en Kubernetes.
• El software de terceros se ejecuta en una o más máquinas virtuales (VM).

Si el software de terceros proporciona una solución de Cloud Marketplace, debes hacer lo siguiente:

• Implementa el software de terceros desde la consola de Cloud Marketplace.
• Selecciona y migra tus casos de uso a partir del enfoque iterativo que se explica en Migra con un enfoque iterativo.

Esta alternativa es la más simple, ya que incorpora tus canalizaciones de datos a la nube mediante la plataforma conocida que proporciona tu proveedor. También puedes usar herramientas propietarias de tu proveedor para facilitar la migración entre el entorno original y el entorno nuevo en Google Cloud.

Si tu proveedor no proporciona una solución de Cloud Marketplace, pero su producto puede ejecutarse en Kubernetes, puedes usar Google Kubernetes Engine (GKE) para alojar tus canalizaciones. Para ello, haz lo siguiente:

• Crea un clúster de GKE según las recomendaciones de tu proveedor para asegurarte de que el producto de terceros pueda aprovechar la paralelización de tareas que ofrece Kubernetes.
• Instala tu software de terceros en tu clúster de GKE de acuerdo con las recomendaciones del proveedor.
• Selecciona y migra tus casos de uso en función del enfoque iterativo explicado en Migra almacenes de datos a BigQuery: descripción general.

Esta alternativa se encuentra en un punto medio en términos de complejidad. Aprovecha la compatibilidad de clústeres nativos del proveedor con Kubernetes para escalar y paralelizar la ejecución de tus canalizaciones. Sin embargo, debes crear y administrar un clúster de GKE.

Si tu proveedor no es compatible con Kubernetes, debes instalar el software en un grupo de VM para habilitar el escalamiento horizontal y la paralelización del trabajo. Si el software de tu proveedor admite la distribución del trabajo en varias VM, usa las instalaciones proporcionadas, posiblemente mediante la unión de las instancias de VM en un grupo de instancias administrado (MIG) para el escalamiento horizontal o vertical según sea necesario.

El manejo de la paralelización del trabajo no es trivial. Si tu proveedor no proporciona capacidades para distribuir tareas a diferentes VM, recomendamos usar un patrón de asignación de tareas en paralelo a fin de distribuir el trabajo a las VM en un MIG. En el siguiente diagrama, se ilustra este enfoque.

Figura 9. Un grupo de instancias administrado (MIG) con tres VM.

En este diagrama, cada VM en el MIG ejecuta el software de canalización de terceros. Puedes activar una ejecución de canalización de las maneras siguientes:

• De forma automática, con Cloud Scheduler, Cloud Composer o un activador de Cloud Storage cuando llegan datos nuevos a un bucket de Cloud Storage
• De manera programática, mediante la llamada a un Cloud Endpoint o Cloud Function, o con la API de Cloud Pub/Sub
• De forma manual, mediante la colocación de un nuevo mensaje en un tema de Pub/Sub con Google Cloud CLI

En esencia, todos estos métodos envían un mensaje a un tema de Pub/Sub predefinido. Debes crear un agente simple para instalar en cada VM. El agente escucha uno o más temas de Pub/Sub. Cada vez que llega un mensaje al tema, el agente lo extrae del tema, inicia una canalización en tu software de terceros y escucha hasta que finalice. Cuando se completa la canalización, el agente recupera el mensaje siguiente de los temas que escucha.

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

Reescribe canalizaciones de datos para usar los servicios administrados por Google Cloud

En algunos casos, puedes optar por reescribir algunas de tus canalizaciones de datos existentes para usar nuevos marcos de trabajo y servicios completamente administrados en Google Cloud. Esta opción funciona bien si tus canalizaciones existentes se implementaron en un principio con tecnologías que ahora son obsoletas, o si anticipas que portar y mantener esas canalizaciones sin modificar en la nube sería demasiado costoso o poco práctico.

En las siguientes secciones, se presentan servicios de Google Cloud completamente administrados que te permiten realizar transformaciones de datos avanzadas a gran escala: Cloud Data Fusion y Cloud Dataflow.

Cloud Data Fusion

Cloud Data Fusion, que se basa en el proyecto de código abierto de CDAP, es un servicio de integración de datos completamente administrado que se usa para crear y administrar canalizaciones de datos a través de una interfaz gráfica.

Puedes desarrollar las canalizaciones de datos en la IU de Cloud Data Fusion mediante la conexión de fuentes a transformaciones, receptores y otros nodos para formar un DAG. Cuando implementas tu canalización de datos, el planificador de Cloud Data Fusion transforma este DAG en una serie de cálculos paralelos que se ejecutarán como un trabajo de Apache Spark en Dataproc.

Cuando usas Cloud Data Fusion, puedes emplear los controladores de conectividad de bases de datos de Java para leer datos, transformarlos y cargarlos en un destino de tu elección (por ejemplo, BigQuery), sin tener que escribir código. Para ello, debes subir un controlador de JDBC a tu instancia de Cloud Data Fusion y configurarlo de modo que puedas usarlo en tus canalizaciones de datos. Para obtener más detalles, consulta la guía sobre el uso de controladores de JDBC con Cloud Data Fusion.

Cloud Data Fusion expone complementos para fuentes, transformaciones, agregados, receptores, recopiladores de errores, publicadores de alertas, acciones y acciones posteriores a la ejecución como componentes personalizables. Los complementos previamente compilados ofrecen acceso a una amplia variedad de fuentes de datos. Si un complemento no existe, puedes compilar tu propio complemento con las API de complemento de Cloud Data Fusion. Para obtener más información, consulta Descripción general de los complementos.

Con las canalizaciones de Cloud Data Fusion, puedes crear canalizaciones de datos por lotes y de transmisión. Cuando proporcionas acceso a registros y métricas, las canalizaciones de datos también ofrecen formas para que los administradores pongan en funcionamiento sus flujos de trabajo de procesamiento de datos sin necesidad de herramientas personalizadas.

Para comenzar, consulta la descripción general del concepto de Cloud Data Fusion. Para ver ejemplos prácticos, consulta la guía de inicio rápido y el instructivo sobre cómo crear una canalización de campaña de orientación.

Dataflow

Dataflow es un servicio completamente administrado que se usa para ejecutar trabajos de Apache Beam a gran escala. Apache Beam es un marco de trabajo de código abierto que proporciona un amplio conjunto de primitivas de análisis de sesiones y sistema de ventanas, además de un ecosistema de conectores fuente y receptores, incluido un conector para BigQuery. Apache Beam te permite transformar y enriquecer datos en modo de transmisión (en tiempo real) y por lotes (histórico) con la misma confiabilidad y expresividad.

El enfoque sin servidores de Dataflow quita la sobrecarga operacional, ya que el rendimiento, el escalamiento, la disponibilidad, la seguridad y el cumplimiento se administran de forma automática. Esto te permite enfocarte en la programación en lugar de administrar los clústeres de servidores.

Puedes enviar trabajos de Dataflow de diferentes maneras, ya sea 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 lograr la interoperabilidad completa entre todos los SDK y los ejecutores.

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

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

Organización y programación

En un nivel alto, la organización es la coordinación automatizada de varios sistemas, mientras que la programación se refiere a la activación automática del trabajo de organización.

• Acercamiento: Una canalización de datos es en sí misma una organización de transformaciones de datos descrita por un DAG, que es un DAG de procesamiento de datos.
• Alejamiento: Cuando una canalización de datos depende de la salida de otras canalizaciones de datos, necesitas la organización de varias canalizaciones. Cada canalización constituye un DAG secundario en un DAG más grande, que es un DAG de organización.

Esta configuración es típica en el almacenamiento de datos. En la sección ETL de la Figura 1, se muestra un ejemplo de configuración. Las secciones siguientes se enfocan en la organización de varias canalizaciones de datos.

Dependencias

Las dependencias pueden consistir en convergencias (fan-in), en las que varias canalizaciones de datos se fusionan en un vértice de un DAG de organización, o divergencias (fan-out), en las que una sola canalización de datos activa otras. Además, puede haber ambos tipos, como se muestra en el diagrama siguiente.

Figura 10. Fan-in y fan-out de dependencias que se utilizan en combinación.

En entornos no óptimos, algunas dependencias son el resultado de limitaciones en la cantidad de recursos disponibles. Por ejemplo, una canalización de datos se ejecuta y produce algunos datos comunes como un subproducto. Otras canalizaciones de datos dependen de estos datos comunes simplemente para evitar volver a calcularlos, pero no están relacionados con la canalización de datos que creó los datos. Si esta primera canalización encuentra problemas funcionales o no funcionales, las fallas caen en cascada a sus canalizaciones de datos dependientes y, en el mejor de los casos, las obliga a esperar; o bien, en el peor de los casos, evita que se ejecuten, como se muestra en el diagrama siguiente.

Figura 11. Las fallas en cascada en una canalización de datos impiden la ejecución de canalizaciones dependientes.

En Google Cloud, hay una gran cantidad de recursos de procesamiento y herramientas especializadas disponibles para permitirte optimizar la ejecución de tus canalizaciones y su organización. En las secciones restantes, se analizan estos recursos y herramientas.

Trabajo de migración involucrado

Simplificar tus necesidades de organización es una práctica recomendada. Tu organización aumenta en complejidad con la cantidad de dependencias entre tus canalizaciones de datos. La migración a Google Cloud presenta una oportunidad para examinar los DAG de organización, identificar tus dependencias y determinar cómo optimizarlas.

Te recomendamos que optimices tus dependencias de manera gradual, como se indica a continuación:

1. En una primera iteración, mueve tu organización a Google Cloud.
2. En iteraciones posteriores, analiza tus dependencias y paralelízalas si es posible.
3. Finalmente, reorganiza tu organización mediante la extracción de tareas comunes en sus propios DAG.

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

Un ejemplo práctico

Supongamos que una organización posee las dos canalizaciones relacionadas siguientes:

• La primera canalización calcula las ganancias y pérdidas (P&L) para toda la organización. Es una canalización compleja que implica muchas transformaciones. Parte de la canalización consiste en calcular las ventas mensuales, que se utilizan en los pasos de transformación posteriores y, finalmente, se escriben en una tabla.
• La segunda canalización calcula el crecimiento de ventas año tras año y mes a mes para diferentes productos a fin de que el Departamento de Marketing pueda ajustar sus esfuerzos de campaña publicitaria. Para esta canalización, se necesitan los datos de ventas mensuales calculados anteriormente por la canalización de datos de P&L.

La organización considera que la canalización de datos de P&L tiene más prioridad que la canalización de marketing. Por desgracia, debido a que P&L es una canalización de datos compleja, consume una gran cantidad de recursos y evita que otras canalizaciones se ejecuten de forma simultánea. Además, si la canalización de P&L falla, la canalización de marketing y otras canalizaciones dependientes no tienen los datos necesarios para poder ejecutarse y deben esperar un nuevo intento de P&L. En el diagrama siguiente, se ilustra esta situación.

Figura 12. Las canalizaciones de datos complejas pueden evitar que se ejecuten canalizaciones de menor prioridad

La organización migra a BigQuery. Ha identificado los dos casos prácticos —P&L y crecimiento de las ventas de marketing— y los incluyó en el trabajo pendiente de migración. Cuando se planifica la próxima iteración, la organización prioriza el caso práctico de P&L y lo incluye en el trabajo pendiente de iteraciones porque está muy limitado por los recursos locales actuales y, con frecuencia, causa demoras. También se incluyen algunos de sus casos prácticos dependientes; entre ellos, el caso práctico de marketing.

El equipo de migración ejecuta la primera iteración. Eligen migrar los casos prácticos de P&L y de marketing a Google Cloud mediante un enfoque de redireccionamiento. No realizan cambios en los pasos de la canalización ni en la organización. Una diferencia importante es que ahora la canalización de P&L puede disponer de una potencia de cómputo casi ilimitada y, por lo tanto, se ejecuta mucho más rápido que en el sistema local. La canalización escribe los datos mensuales de ventas en una tabla de BigQuery que utiliza la canalización de crecimiento del marketing. En el siguiente diagrama, se ilustran estos cambios.

Figura 13. Aceleración de una canalización de datos compleja mediante el uso de un enfoque de redireccionamiento.

Aunque Google Cloud ayudó con los problemas de P&L no funcionales, aún quedan problemas funcionales. Algunas tareas no relacionadas que preceden al cálculo de las ventas mensuales a menudo causan errores que impiden que se realice ese cálculo y hacen que las canalizaciones dependientes no puedan comenzar.

En una segunda iteración, el equipo espera mejorar el rendimiento cuando incluye ambos casos prácticos en el trabajo pendiente de iteraciones. El equipo identifica los pasos de la canalización para calcular las ventas mensuales en la canalización de P&L. Los pasos constituyen un DAG secundario, como se muestra en el diagrama siguiente. El equipo de migración copia el DAG secundario en la canalización de marketing para que esa canalización pueda ejecutarse independientemente de la de P&L. Tener suficiente potencia de procesamiento en Google Cloud permite que ambas canalizaciones se ejecuten al mismo tiempo.

Figura 14. Las canalizaciones se ejecutan simultáneamente mediante un DAG secundario

La desventaja es que duplicar la lógica del DAG secundario crea una sobrecarga en la administración del código, porque ahora el equipo necesita mantener sincronizadas ambas copias de la lógica del DAG secundario.

En una tercera iteración, el equipo revisa los casos prácticos y extrae el DAG secundario de ventas mensuales en una canalización independiente. Cuando se completa la nueva canalización de ventas mensuales, se activa o se hace fan-out en las P&L, el crecimiento del marketing y otras canalizaciones dependientes. Con esta configuración, se crea un nuevo DAG de organización general, con cada una de las canalizaciones como uno de sus DAG secundarios.

Figura 15. DAG de organización general con cada canalización en su propio DAG secundario

En las siguientes iteraciones, el equipo de migración puede resolver cualquier problema funcional restante y migrar las canalizaciones para usar, entre otros, los siguientes servicios administrados por Google Cloud:

• Dataflow: Te permite definir cada canalización de datos como un DAG autónomo mediante el modelo Beam.
• Cloud Composer: Te permite definir la organización más amplia como uno o más DAG de Airflow.

Si bien Airflow es compatible de forma nativa con los DAG secundarios, esta funcionalidad podría limitar su rendimiento y, por lo tanto, no se recomienda. En su lugar, usa DAG independientes con el operador TriggerDagRunOperator.

¿Qué sigue?

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

• Descripción general de la migración
• Evaluación de la migración
• Descripción general de transferencia de datos y esquemas
• Traducción de SQL por lotes
• Traducción de SQL interactiva
• Seguridad y administración de los datos
• Herramienta de validación de datos

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

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