datalake Tag

ETL

ETL: up to date

¿Cómo puede ocurrir que tengamos tanta información y sepamos tan poco?
— Noam Chomsky

 

Es fácil ponerse creativo a la hora de pensar en los insights que extraemos de nuestros datos, pensar en esa información que se obtiene de cruzar unas fuentes con otras y, a su vez, con datos propios. El problema fundamental es que hay que desplegar una ETL –Extracción de datos de una fuente, Transformación o formateo de los mismos y Carga en otro destino– para ingerir esos datos, montar un Datalake y, después, mantener ambos en funcionamiento.

Llevamos programando tareas ETL desde tiempos inmemoriales. Al principio aprendimos a hacer muescas en palos para contar las reses de una manada, transportábamos la información del mundo real al palo. Tiempo después recolectamos datos de agrimensura y crecidas del Nilo para estimar la cuantía de las cosechas. A día de hoy aplicamos esta técnica extensivamente. A continuación veremos diferentes enfoques que podemos tener al respecto.

Delegar o Gestionar
Trasladándonos ahora a los alrededores del presente más inmediato, las herramientas que tenemos a nuestra disposición para esta tarea son un tanto diferentes. En lugar de un bifaz o una lasca deberemos elegir primero si queremos hacernos cargo de los entresijos de este proceso o, por el contrario, delegarlo. En este segundo caso, también habrá que decidir en qué grado delegar.

 

ETLaaS (ETL as a Service)

Hay herramientas que proveen ya esta funcionalidad. Teradata, Informática, Pega y otras compañías proveen este tipo de servicios. Pero como empresas que son, lo hacen a un precio. El sufijo “aaS”, tan popular últimamente, indica que no tenemos que inmovilizar capital en forma de máquina para hacer funcionar nuestra ETL, sino que otra persona posee esa máquina y nos presta un servicio con ella. Un ejemplo de estas serían las mencionadas antes Teradata e Informática que no requieren excesivo conocimiento técnico para ser operadas.

 

CaaS (Cloud as a Service)

Otro enfoque sería utilizar los módulos ya disponibles de una cloud para implementar cada una de las tres fases (Extracción, Transformación y Carga). En DIVISADERO utilizamos extensivamente Google Cloud que tiene diferentes herramientas en función de cómo queramos implementar cada fase.

  1. Extracción: Storage nos proporciona almacenamiento escalable y procesos programables de ingesta. Algo que hace 10 años requería un script ejecutado periódicamente empleando Cron y Rsync (herramienta para transferir datos), ¡o incluso ejecutado a mano!
  2. Transformación: con cada archivo nuevo se dispara un mensaje en PubSub. En ese momento se dispara una Cloud Function que nos permite, preprocesar si el dato es ligero, o disparar un proceso más intensivo del entorno GCP (AutoML, un trabajo Spark, un trabajo Dataflow/Beam).
  3. Carga: una vez terminado, podemos insertar el dato en nuestro Datalake (BigQuery si es estructurado o Datastore sí no).

 

Lo interesante de esta aproximación es que, aunque la tarea de carga sea síncrona (batch), todo el proceso dentro de nuestra nube ocurre en streaming. De esta forma si ocurriese un error al procesar algún archivo no afectaría al resto del batch, es más fácil de escalar y por tanto los costes se ajustan mucho más al uso que se le da, y el dato a la salida es más fresco.

Como alternativa GCP cuenta desde hace poco tiempo con Airflow semi-gestionado. Una herramienta para la creación y gestión de ETLs en batch de código abierto que se ha constituido últimamente como estándar de facto.

Interfaz de Airflow

A modo de nota a futuro, Google ha liberado CRMint. Una herramienta que en apariencia es similar a Airflow pero que podría ser operada fácilmente sin necesidad de programar ninguna ETL.

 

PaaS (Platform as a Service)

Esta aproximación cuenta un menor nivel de abstracción, se asemeja más a lo que se vendría ejecutando tradicionalmente. La diferencia radica en que no nos haremos cargo de la infraestructura, eliminando así la capa de IT. Podríamos considerar dos opciones en función del nivel de complejidad de la tarea.

  • Bajo: se pueden suplir tareas sencillas desarrollando un script en local, haciendo que se repita empleando el cron (planificador de tareas de un ordenador) de un VPS (Servidor Privado Virtual, lo que llamaríamos una máquina virtual en la nube). Como ventajas, el tiempo de implementación depende únicamente del de desarrollo del script. El inconveniente es que si queremos algún tipo de reporting sobre su ejecución se deberá construir ad-hoc.
  • Alto: como mencionaba antes, Airflow se ha convertido en una suerte de estándar en cuanto a lo que automatización de tareas y ETLs se refiere. Se puede ejecutar en un VPS e ir añadiendo potencia según sea necesario por medio de workers, o incluso configurar algún tipo de auto-escalado.

 

Sin este trabajo previo, estaremos limitados a los análisis por fuente. Remitiéndome a la cita del principio, tendremos toda la información pero no podremos “conocerla”.

*Fuente de las imágenes: Freepick (principal) y Airflow.

0
0

¡Suscríbete a nuestra newsletter mensual Stay Sharp!

Para más información

CONTÁCTANOS