Continuando con la segunda parte del tutorial, explicare los pasos para crear un rastreador un job.
Dentro del panel de AWS Glue observaremos diferentes opciones, para comenzar con nuestro ETL, debemos hacer uso de los rastreadores (crawler) para crear nuestra base de datos, el rastreador hará un map del esquema de datos de una forma inteligente y creará replicas de estos esquemas a modo de tablas.
Crawler o Rastreador
Seleccionaremos la opción de “Añadir Rastreador” (crawler), y observaremos la primera pantalla de configuración.
En esta pantalla podemos ingresar el nombre de nuestro crawler, asignar algunos tags para agrupar u obtener algún detalle, y agregar una descripción y configuración de seguridad, esta última nos permitirá cifrar datos on rest, a los registros que se envíen a través de cloudwatch. Para ser este ejemplo simple solo ingresaremos un nombre.
A continuación configuraremos nuestras fuentes de información, podemos elegir entre dos tipos de fuentes, catálogos de datos ya existentes o Data stores, también tenemos una configuración adicional para que nuestro crawler solo mapee datos nuevos desde su última ejecución.
Nuestra primera fuente a configurar será nuestro bucket de S3 donde existe la opción de utilizar un bucket alojado en nuestra cuenta u otra, también tenemos la posibilidad de ignorar archivos que no deseamos dentro de una carpeta en nuestro bucket, o de seleccionar archivos solo con cierta extensión.
En nuestro ejemplo seleccionaremos la carpeta donde se ubica nuestro archivo, dependiendo de la lógica de negocio, podríamos mapear solo un archivo o de ser necesario podemos mapear varios archivos dentro de una carpeta.
En este ejemplo también haremos uso de una tabla de DynamoDB para lo cual también vamos a realizar su respectivo mapping.
Podemos utilizar otros tipos de bases de datos u otras fuentes de información cada una con su respectiva configuración.
Es necesario configurar un rol de IAM para que este pueda acceder a nuestro bucket y a nuestra tabla de Dynamo además de ejecutar el ETL job que será explicado oportunamente.
Dicho rol contendrá 3 policies, la primera un rol administrado por AWS, el cual contendrá varios permisos ya definidos
Los otros dos serán de nuestra tabla de dynamo con las acciones de DescribeTable y Scan
Cómo también tendrá las acciones de GetObject y PutObject en nuestro bucket
Si deseamos re-utilizar el mismo role para otros jobs, solo añadiriamos nuestras tablas o buckets en la sección de Resource.
Nuestro crawler también permite la opción de poder programarlo a modo calendarizado para que se ejecute en un tiempo específico, el rango varia entre horas, días, semanas, meses o expresiones cron.
Nuestro último paso será el de crear nuestra base de datos en el catálogo, donde se ubicarán nuestras tablas convertidas con el esquema obtenido del archivo csv y de la tabla de DynamoDB, es posible utilizar una base de datos en un catálogo perteneciente a otra cuenta de AWS.
Al verificar que todos los pasos anteriores estén correctos procederemos a ejecutar nuestro crawler, para ello identificaremos la ejecución actual de nuestro crawler en la columna estado la cual detala tres tipos (Running, Stopping, Ready). La ejecución del crawler puede variar en un rango de tiempo de 1 a 5 minutos dependiendo de la cantidad de información y el grado de complejidad del esquema de nuestras fuentes.
Finalizado la ejecución del crawler con el estado “Ready”, podemos acceder a nuestras tablas recientemente creadas en nuestra base de datos.
Con nuestras tablas listas para ser utilizadas procederemos a crear nuestro job ETL
Jobs o Trabajos
Dentro de nuestro job ETL, contamos con una gran cantidad de configuraciones, los dos primeros campos corresponden al nombre que tendrá nuestro job y el segundo el IAM role que hemos creado anteriormente.
Tipos de jobs
Hay tres tipos de jobs:
- Spark: Un job de Spark se ejecuta en un entorno Apache Spark administrado por AWS Glue. Procesa los datos en lotes.
- Spark Streaming: Un job ETL de streaming es similar a un trabajo de Spark, excepto que realiza ETL en las transmisiones de datos. Utiliza el marco Apache Spark Structured Streaming.
Algunas características de trabajo de Spark no están disponibles para los trabajos ETL de streaming.
Python Shell: Un job de shell de Python ejecuta scripts de Python como shell y admite una versión de Python que depende de la versión de AWS Glue que esté utilizando. Estos trabajos pueden utilizarse para programar y ejecutar tareas que no requieren un entorno de Apache Spark.
Para nuestro ejemplo utilizaremos un job de tipo Spark.
Es importante seleccionar con cuidado nuestra versión de Glue deseada, debido a que cada versión de Glue presenta un esquema de precio diferente, como también difiere en velocidad y la versión del lenguaje de programación que utilicemos.
Versiones de AWS Glue
| Caracteristicas | Glue 0.9 | Glue 1.0 | Glue 2.0 |
|---|---|---|---|
| Versiones de Spark y Python admitidas | Spark 2.2.1, Python 2.7 | Spark 2.4.3, Python 2.7, Python 3.6 | Spark 2.4.3, Python 3.7 |
| Precio por ejecución | $0.44 per DPU-Hour,10-minute minimum (Glue version 0.9/1.0) for each ETL job of type Apache Spark, $0.44 per DPU-Hour, billed per second, with a 1-minute minimum for each ETL job of type Python shell, $0.44 per DPU-Hour, billed per second, with a 10-minute minimum for each provisioned development endpoint | $0.44 per DPU-Hou,10-minute minimum (Glue version 0.9/1.0) for each ETL job of type Apache Spark, $0.44 per DPU-Hour, billed per second, with a 1-minute minimum for each ETL job of type Python shell, $0.44 per DPU-Hour, billed per second, with a 10-minute minimum for each provisioned development endpoint | $0.44 per DPU-Hour, billed per second, with a 1-minute minimum, $0.44 per DPU-Hour, billed per second, with a 1-minute minimum for each ETL job of type Python shell, $0.44 per DPU-Hour, billed per second, with a 10-minute minimum for each provisioned development endpoint |
| Velocidad de ejecución | Ejecución entre 5-20 minutos | Ejecución entre 5-20 minutos | Warm up x 10 (Ejecución entre 1-10 minutos) |
AWS Glue realiza el seguimiento de los datos que han sido procesados durante la ejecución anterior de un trabajo de ETL, y almacena la información de estado a partir de la ejecución del trabajo. Esta información de estado persistente se denomina marcador de trabajo. Los marcadores de trabajo ayudan a AWS Glue a mantener la información de estado y evitar la re-procesamiento de datos antiguos.
Job Marker
Existen tres tipos de estados para el marcador de trabajo
- Enable: Realiza un seguimiento de los datos procesados anteriormente. Cuando se ejecuta un flujo de trabajo, procesar los datos nuevos desde el último punto de comprobación.
- Pause: Procesar los datos incrementales desde la última ejecución correcta o los datos en el rango identificado por las siguientes sub-opciones, sin actualizar el estado del último marcador.
- Disable: Procesar siempre todo el conjunto de datos.
En nuestro ejemplo utilizaremos la opción deshabilitar.
Configuraciones
| column 1 | column 2 |
|---|---|
| Configuración de seguridad | Opción para especificar la credencial de encriptación KMS para los datos en tránsito. |
| Ruta de la biblioteca Python | En el caso de utilizar python como lenguaje y se desea añadir una libreria externa |
| Ruta de archivos JAR dependientes | En el caso de utilizar scala como lenguaje y se desea añadir una libreria externa |
| Ruta de archivos a la que se hace referencia | En el caso de querer importar un script personalizado |
| Worker type | El tipo de proceso de trabajo predefinido que se asigna cuando se ejecuta un job. Admite un valor de Standard, G.1X o G.2X. Para el tipo de proceso de trabajo Standard, cada proceso de trabajo proporciona 4 vCPU, 16 GB de memoria y un disco de 50 GB y 2 ejecutores por proceso de trabajo. Para el tipo de proceso de trabajo G.1X, cada proceso de trabajo se asocia a 1 DPU (4 vCPU, 16 GB de memoria, disco de 64 GB) y proporciona 1 ejecutor por proceso de trabajo. Le recomendamos este tipo de proceso de trabajo para trabajos con un uso intensivo de la memoria. Para el tipo de proceso de trabajo G.2X, cada proceso de trabajo se asocia a 2 DPU (8 vCPU, 32 GB de memoria, disco de 128 GB) y proporciona 1 ejecutor por proceso de trabajo. Le recomendamos este tipo de proceso de trabajo para trabajos con un uso intensivo de la memoria. |
| Number of workers | El número de procesos de trabajo de workerType definido que se asignan cuando se ejecuta un trabajo. El número máximo de procesos de trabajo que puede definir son 299 para G.1X y 149 para G.2X. |
| Simultaneidad máxima | El número máximo de ejecuciones simultáneas que están permitidas para el flujo de trabajo. El valor predeterminado es 1. Se produce un error cuando se llega a este umbral. El valor máximo que puede especificar se controla mediante un límite de servicio. |
| Tiempo de espera del trabajo en minutos (Timeout) | El tiempo de espera del flujo de trabajo en minutos. Es el tiempo máximo que una ejecución de trabajo puede consumir recursos antes de que se termine y cambie al estado TIMEOUT. El valor predeterminado es 2880 minutos (48 horas). |
| Umbral de notificación de retraso en minutos | Después de que comience una ejecución de flujo de trabajo, el número de minutos que se debe esperar antes de enviar una notificación de retraso de ejecución de un flujo de trabajo. |
| Número de re-intentos | Número máximo de re-intentos permitidos para esta tarea sí se genera un error. |
| Párametros de trabajo | Párametros que se pueden mandar al ejecutar un job son leídos a través de sysArgs se los debe especificar como --llave valor. |
| Non-overrideable Job parameters | Párametros que se pueden mandar al ejecutar un job pero que no pueden ser sobre-escribidos, son leídos a través de sysArgs se los debe especificar como --llave valor. |
En esta sección podemos seleccionar un script creado anteriormente o un script auto-generado por glue en el que tendremos que configurar el tipo de transformación, el target al que deseamos agregar y el esquema final de los datos al finalizar AWS Glue nos generará un script en el lenguaje y versión que hayamos especificado listo para correr, para nuestro ejemplo seleccionaremos la opción “Un nuevo script”.
En la pantalla conexiones podremos configurar conectores JDBC en el caso de que estemos utilizando una base de datos externa, en el caso de este ejemplo no es necesario.
Finalmente, visualizaremos el lienzo donde podemos empezar a escribir nuestro código en la Parte 3 de este tutorial.
Top comments (0)