DEV Community: Alvaro Garcia

Cómo armé un Pit Wall con AWS IoT Core (y por qué este patrón sirve para cualquier industria)

Alvaro Garcia — Sat, 12 Sep 2026 03:45:43 +0000

Hola a todos! Hace unos meses me surgio la idea de empezar a correr en simrace nuevamente, en pandemia me compré el volante y lo usé un rato pero perdi la motivación cuando me di cuenta de lo dificil que es manejar deportivamente y mucho más dificil es mejorar sin tener un experto que te de indicaciones claras sobre que estás haciendo mal, por eso durante un tiempo investigue bastante y vi que si queria mejorar necesitaba si o si un coach, pero como en cloudhesive tengo una cuenta de aws para poder investigar me puse a la tarea de crear un sistema que me ayude a mejorar mis tiempos de vuelta y me puse a armar un pit wall digital para sim racing y mostrar el resultado en el AWS Community Day Argentina, el 12 de septiembre de 2026.

⭐ Todo el material de mis charlas — slides, código, diagramas — vive en github.com/alvarongg/charlas-pub. Si le tirás una estrella al repo te va a llegar una notificación cada vez que suba contenido nuevo. No spam, solo técnica.

La idea

La idea es simple — quiero mejorar como piloto, y para eso necesito ver mi telemetría en vivo, tener un historial de mis vueltas, y que un experto me diga en qué me estoy equivocando (y en donde). Para esta primera etapa elegi Assetto Corsa (el simulador) ya que tiene una funcionalidad que se llama "Shared Memory" la genera toda esa información en tiempo real, pero se queda ahí, en la memoria compartida de mi PC. Nadie más la ve, y cuando cierro el juego, se pierde.

Luego de un trabajo de investigación de un par de dias, ya tenia mi primera fase completada, logré leer la memoria del simulador de forma correcta, sin romper el juego y sin problemas de offset o padding. (Gracias a la comunidad de asseto por toda la ingenieria inversa que hicieron sobre el juego ya que la documentación es basatnte pobre en este sentido.

Ahora ya tenia como capturar los datos, necesitaba una forma de enviarlos a aws para poder procesarlso, Así que terminé usando esto como excusa para meterme de lleno en AWS IoT Core. Y cuanto más avanzaba, más me daba cuenta de que el problema que estaba resolviendo no tiene nada que ver con autos: es el mismo problema que tiene cualquiera que necesite sacar datos de un dispositivo que no vive dentro de tu infraestructura — un sensor en una planta, un camión de una flota, un wearable médico, una máquina en una línea de producción.

En todos esos casos el desafío es idéntico: cómo hacés que ese dispositivo te mande datos de forma segura, sin que tenga que confiar ciegamente en tu backend, y cómo procesás eso en tiempo real sin que se te caiga todo con el primer pico de tráfico.

Este post es sobre eso. Voy a usar el pit wall como caso de estudio porque es el que tengo andando, pero el hilo conductor es entender el patrón: capturar información de un dispositivo fuera de AWS, y procesarla con AWS IoT.

El problema, en términos generales

Antes de meterme en el proyecto, pensemos el problema sin autos de por medio. Tenés N dispositivos, en cualquier lado, generando datos todo el tiempo. Necesitás:

Que cada dispositivo pueda mandarte datos sin que vos tengas que confiar en él más de lo necesario — si se compromete uno, no querés que ese dispositivo pueda hacerse pasar por otro, ni leer los datos de los demás.
Que la conexión no dependa de que tu backend esté "escuchando" activamente — el dispositivo tiene que poder mandar datos aunque tu Lambda esté fría, aunque tu API esté de mantenimiento, aunque haya 10.000 dispositivos mandando al mismo tiempo.
Procesar esos datos apenas llegan, sin que cada dispositivo tenga que saber nada de tu arquitectura interna — el dispositivo publica, y listo. Lo que pase después (guardar en una base, avisar a alguien, calcular algo) es responsabilidad tuya, no suya.

Ese es, casi textual, el problema que resuelve AWS IoT Core.

Por qué no "le pego un POST a un API Gateway"

La primera pregunta que me hice fue esa: ¿por qué no simplemente expongo un endpoint HTTP y que cada dispositivo me mande un POST? Funcionaría para pocos dispositivos, pero se rompe rápido en varios frentes:

Autenticación por certificado, no por API key. Cada dispositivo se identifica con un certificado X.509 propio. Si alguien saca la PC de un simulador del evento y le copia el certificado, ese certificado solo sirve para ese simulador — nunca para publicar en nombre de otro. Con una API key compartida, perdés esa contención.
MQTT, no HTTP. El protocolo mantiene una conexión persistente y liviana, pensada para dispositivos con recursos limitados y redes poco confiables — reconecta solo, con backoff, y no perdés el mensaje si la conexión se corta a mitad de camino.
El "Rules Engine" desacopla al dispositivo de tu backend. El dispositivo no sabe que existe una Lambda, ni una tabla, ni nada. Publica en un topic y se desentiende. Vos decidís, del lado de AWS, qué Lambda se invoca, con qué filtro, y podés cambiar esa lógica sin tocar una sola línea del dispositivo.

Ese último punto es el que más me voló la cabeza cuando lo entendí: la lógica de "qué hacer con el dato" vive completamente separada de la lógica de "cómo llega el dato". Podés agregar un procesamiento nuevo sin redeployar nada en los dispositivos.

Identidad de dispositivo: mínimo privilegio, en serio

Acá está la primera parte del código. Cada simulador (pit_wall-sim-01, 02, 03, 04) tiene su propio Thing en IoT Core, con su propia política. La política no es un checkbox de "puede publicar" — define exactamente en qué topics puede publicar y a cuáles se puede suscribir:

def policy_document(sim_id: str, *, topic_prefix: str = "sim") -> dict:
    base = f"{topic_prefix}/{sim_id}"
    return {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Connect",
                "Effect": "Allow",
                "Action": "iot:Connect",
                "Resource": [f"arn:aws:iot:...:client/{sim_id}"],
            },
            {
                "Sid": "PublishOutbound",
                "Effect": "Allow",
                "Action": "iot:Publish",
                "Resource": [
                    f"arn:aws:iot:...:topic/{base}/{topic}"
                    for topic in ("telemetry", "event", "lap", "session", "status", "log")
                ],
            },
            {
                "Sid": "SubscribeCommandAsAgent",
                "Effect": "Allow",
                "Action": ["iot:Subscribe", "iot:Receive"],
                "Resource": [f"arn:aws:iot:...:topic/{base}/command"],
            },
        ],
    }

Fijate lo que no puede hacer este certificado: no puede publicar en sim/pit-wall-sim-02/telemetry (el topic de otro simulador), y no puede suscribirse a nada que no sea su propio topic de comandos. Si mañana alguien clona el certificado de un simulador, el radio de daño queda contenido a ese único dispositivo — nunca escala al resto de la flota.

Esto es literalmente lo mismo que harías con un sensor de humedad en una planta agrícola, o con la tablet de un camión de reparto: un certificado por dispositivo, un permiso mínimo por dispositivo, sin excepciones.

IoT Rules: el corazón del procesamiento

Una vez que el dato entra por MQTT, ¿quién lo agarra? Ahí entran las IoT Rules: consultas SQL que corren sobre cada mensaje que pasa por un topic, y que disparan una o más acciones.

DATA_TOPICS = ("telemetry", "event", "lap", "session", "status")

def _crear_regla(self, topic: str):
    regla = iot.CfnTopicRule(
        self, f"Rule{topic}",
        topic_rule_payload=iot.CfnTopicRule.TopicRulePayloadProperty(
            sql=f"SELECT * FROM '{self.topic_prefix}/+/{topic}'",
            actions=[
                iot.CfnTopicRule.ActionProperty(
                    lambda_=iot.CfnTopicRule.LambdaActionProperty(
                        function_arn=self.ingest_function.function_arn
                    )
                ),
                iot.CfnTopicRule.ActionProperty(
                    lambda_=iot.CfnTopicRule.LambdaActionProperty(
                        function_arn=self.broadcast_function.function_arn
                    )
                ),
            ],
        ),
    )

Lo interesante acá no es el SQL (SELECT * FROM 'sim/+/telemetry', con el + como wildcard de un nivel — cualquier simulador, ese topic puntual). Lo interesante es que una sola regla dispara dos acciones en paralelo, sobre el mismo mensaje:

Una Lambda de ingesta, que persiste el dato (más sobre esto abajo).
Una Lambda de broadcast, que reenvía el mismo mensaje por WebSocket a quien esté mirando ese simulador en vivo.

No hay una segunda suscripción al mismo topic, ni una cola intermedia, ni el ingesta reenviándole el dato al broadcast. Es la misma regla, la misma invocación de IoT Core, dos acciones independientes. Si mañana el broadcast se cae, la ingesta sigue funcionando — y viceversa.

Este es el patrón que más me sirvió entender de todo el proyecto: una IoT Rule no es "un trigger", es un punto de fan-out. Podés colgar tantas acciones como necesites (otra Lambda, un tópico SNS, un stream de Kinesis, otra regla) sin tocar nada del lado del dispositivo ni de las reglas existentes.

El desafío real: reconstruir algo coherente a partir de pedacitos

Acá viene la parte menos obvia. MQTT tiene un límite de tamaño de payload, y la telemetría de un simulador genera muestras varias veces por segundo — no entra todo en un solo mensaje. El agente en la PC del simulador arma lotes (batches) de muestras y los publica de a poco, con un número de secuencia cada uno.

Del lado de AWS, eso significa que la Lambda de ingesta nunca recibe "una vuelta completa" — recibe fragmentos, que van a staging en DynamoDB con un TTL (si una sesión nunca cierra una vuelta, ese staging se autodestruye solo). Cuando llega el mensaje que dice "esta vuelta se cerró", ahí sí, la Lambda junta todos los lotes que tiene en staging para esa sesión y reconstruye la traza completa:

class CoberturaIncompletaError(ReconstructionError):
    """La cobertura de lotes en staging no alcanza — todavía.

    Las IoT Rules invocan la Lambda una vez por mensaje, sin ninguna
    garantía de orden entre invocaciones concurrentes: el mensaje de
    "vuelta cerrada" puede llegar antes de que termine de guardarse
    su último lote de telemetría. Acá se reintenta unos segundos
    dentro de la misma invocación, en vez de descartar la vuelta.
    """

Este tipo de problema — datos que llegan en desorden, sin garantía de que el último pedacito ya esté cuando lo necesitás — es el problema clásico de cualquier pipeline de IoT en tiempo real. No es específico de telemetría de autos: es lo mismo que te pasa reconstruyendo el recorrido de un camión a partir de puntos GPS sueltos, o el estado de una máquina a partir de eventos de sensores que no llegan en orden.

Guardado: una tabla, un bucket, y ya

Del lado del guardado no hay demasiada magia, pero vale la pena nombrarlo porque es donde termina el dato una vez procesado:

DynamoDB, en una tabla única (single-table design): sesiones, vueltas, recomendaciones, todo con PK/SK pensados para que cada consulta sea una Query barata sobre un prefijo, nunca un Scan de toda la tabla.
S3, para lo pesado: la telemetría reconstruida, los archivos de audio, cualquier blob que no tenga sentido meter en DynamoDB.

Nada de esto es exclusivo de IoT — es el mismo par de servicios que usarías para cualquier backend serverless. Lo importante es que para cuando el dato llega acá, ya pasó por todo el trabajo pesado de identidad, transporte y reconstrucción, así que esta capa queda simple.

De IoT a "en vivo": el otro lado del fan-out

Contaba arriba que la misma IoT Rule dispara dos Lambdas en paralelo. La segunda (broadcast) es la que arma la parte "en vivo" del dashboard: mantiene un índice chico de qué conexión de WebSocket está mirando qué simulador, y cuando llega un mensaje nuevo, lo reenvía tal cual a esas conexiones.

Fijate que este Lambda no procesa nada — no interpreta, no clasifica, no llama a ningún otro servicio. Solo reenvía. Esa separación entre "el camino que persiste" y "el camino que muestra en vivo" es la que permite que uno pueda evolucionar sin romper al otro: si un día quiero agregar un análisis con IA arriba de la ingesta (spoiler: lo hice, es tema de otro post), el WebSocket en vivo ni se entera.

Generalizando el patrón

Volvamos a la idea del principio: esto no es sobre autos. La misma arquitectura, con los mismos cuatro bloques (identidad por dispositivo → IoT Rules → procesamiento → guardado/consumo), sirve para:

Industria	El "dispositivo"	El dato	Qué reemplaza al pit wall
Agro	Sensor de humedad/temperatura en el campo	Lecturas periódicas	Un dashboard de riego automatizado
Logística	Tablet o GPS de un camión de reparto	Posición, velocidad, paradas	Seguimiento de flota en vivo
Industria	PLC o sensor de una línea de producción	Vibración, temperatura, ciclos	Mantenimiento predictivo
Salud	Wearable de un paciente	Frecuencia cardíaca, pasos	Alertas en tiempo real al equipo médico

En todos los casos cambia el dominio, pero no cambia la pregunta que tenés que responder: ¿cómo identifico a cada dispositivo sin que uno pueda hacerse pasar por otro, y cómo proceso lo que manda sin acoplar mi lógica de negocio a los detalles del transporte? Esa pregunta la responde AWS IoT Core, la resuelvas con autos, camiones o sensores de humedad.

Próximos pasos

Terminé este proyecto sabiendo mucho más de IoT que de lo que sabía de simracing cuando arranqué, que ya es decir bastante. Todo lo de acá es la base: una vez que tenés el dato capturado, identificado y procesado, podés poner arriba lo que quieras. En mi caso fue un ingeniero de carrera que te habla por voz mientras manejás, generado con Amazon Bedrock y Amazon Polly — de eso hablo en el próximo post.

Una última cosa antes de cerrar:

Todo el material de esta charla — slides, código, diagramas — está en github.com/alvarongg/charlas-pub. Voy a estar subiendo contenido nuevo seguido: más posts como este, ejemplos de código ejecutable y arquitecturas de referencia.

Si le tirás una ⭐ al repo GitHub te avisa automáticamente cuando haya novedades. Es la forma más fácil de no perderte nada — sin newsletter, sin formularios, sin nada raro.

Abrazo grande. Hasta la próxima 🚀

Cualquier pregunta sobre IoT Core, certificados, o el diseño de la tabla, la dejo abierta en los comentarios. ¡Nos vemos en la pista! 🏎️

Introducción a los Data Lakes Parte 3

Alvaro Garcia — Fri, 11 Sep 2026 15:21:57 +0000

Hola a todos! Llegamos al final de la serie. En la primera parte vimos qué es un Data Lake y por qué importa. En la segunda parte conocimos los 5 servicios que forman el núcleo: S3, Glue, Athena, Lake Formation y Lambda.

Hoy dejamos la teoría de lado. Vamos a construir el Data Lake completo, con todo el código disponible en un repo abierto para que lo despliegues en tu propia cuenta de AWS en minutos.

Acá estamos. Manos a la obra.

Qué vamos a construir

El escenario es simple y realista: una empresa con varias sucursales que suben sus ventas diarias como archivos CSV. Cada vez que llega un archivo nuevo, el pipeline se dispara solo y transforma esos datos crudos en datos consultables con SQL.

El flujo de punta a punta:

Un CSV llega a la raw zone de S3
El evento PutObject dispara una función Lambda
Lambda lanza un Glue Job que transforma el CSV a Parquet y lo escribe en la processed zone
Un Glue Crawler mantiene actualizado el Data Catalog
Athena consulta los datos procesados con SQL estándar
Lake Formation controla quién puede ver qué

Todo lo que vimos en los posts anteriores, funcionando junto. Y lo mejor: todo el código está en un repo público, definido como infraestructura con AWS CDK en Python.

El repo: infraestructura como código con CDK

En lugar de armar todo a mano desde la consola (clic acá, clic allá, y dentro de 6 meses nadie se acuerda de qué configuró), todo el Data Lake está definido como código con AWS CDK en Python.

📦 Repo: github.com/alvarongg/serverless-datalake-aws

¿Por qué CDK y no la consola? Tres razones:

Reproducible: lo despliegas en cualquier cuenta con un solo comando
Versionado: cada cambio en la infraestructura queda en el historial de Git
Documentación viva: el código es la arquitectura — no hay un diagrama desactualizado en un wiki

Si estás arrancando con Data Lakes, hacer todo por consola una vez es un buen ejercicio para entender las piezas. Pero para cualquier cosa que vaya a producción, infraestructura como código no es opcional.

Cómo está organizado el proyecto

La estructura del repo es deliberadamente simple — un solo stack de CDK que contiene todo el Data Lake:

serverless-datalake-aws/
├── app.py                      # Entry point de CDK
├── datalake/
│   └── datalake_stack.py       # El stack completo: S3, Lambda, Glue, Athena, Lake Formation
├── lambda_src/
│   └── trigger_pipeline.py     # La función que escucha eventos de S3
├── glue_src/
│   └── transform_job.py        # El script del Glue Job (CSV → Parquet)
├── sample_data/
│   └── generate_ventas.py      # Generador de CSVs de ejemplo
├── requirements.txt
└── README.md

¿Por qué un solo stack? Para un proyecto de este tamaño, separar en múltiples stacks agrega complejidad sin beneficio. Un cdk deploy y tenés el Data Lake entero corriendo. Cuando el proyecto crece (múltiples equipos, múltiples ambientes), ahí sí tiene sentido separar — pero ese es un problema que vas a tener recién cuando lo tengas.

Las piezas del stack

Veamos qué define el stack, pieza por pieza.

El bucket con sus zonas

El bucket de S3 se crea con las tres zonas que ya conocemos de la parte 2, separadas por prefijos:

bucket = s3.Bucket(
    self, "DataLakeBucket",
    encryption=s3.BucketEncryption.S3_MANAGED,
    block_public_access=s3.BlockPublicAccess.BLOCK_ALL,
    versioned=True,
)

Fijate dos decisiones que no son negociables: cifrado activado y acceso público bloqueado. Son dos líneas de código que te ahorran un incidente de seguridad.

La Lambda que dispara el pipeline

La función Lambda es la misma idea que vimos en la parte 2, pero ahora desplegada de verdad, con su trigger configurado en el código:

trigger_fn = _lambda.Function(
    self, "TriggerPipelineFn",
    runtime=_lambda.Runtime.PYTHON_3_12,
    handler="trigger_pipeline.lambda_handler",
    code=_lambda.Code.from_asset("lambda_src"),
)

bucket.add_event_notification(
    s3.EventType.OBJECT_CREATED,
    s3n.LambdaDestination(trigger_fn),
    s3.NotificationKeyFilter(prefix="raw/"),
)

El detalle importante es el NotificationKeyFilter: solo los archivos que llegan a raw/ disparan el pipeline. Si Lambda escuchara todo el bucket, el propio Glue Job escribiendo en processed/ volvería a disparar el pipeline... y bienvenido al loop infinito que te explota la factura.

El filtro de prefijo no es un detalle estético. Es la diferencia entre un pipeline event-driven y un loop infinito que procesa sus propias salidas.

El Glue Job: de CSV a Parquet

El Glue Job toma el CSV crudo y lo escribe como Parquet particionado por fecha en la processed zone. ¿Por qué Parquet? Lo adelanté en el post anterior: Athena cobra por datos escaneados, y Parquet es un formato columnar comprimido que puede reducir el escaneo hasta un 80%.

El Crawler y la base de datos

El stack también define la base de datos del Glue Data Catalog y un Crawler apuntando a la processed zone. Cada vez que el job termina, el catálogo se actualiza y las tablas nuevas (o las particiones nuevas) quedan disponibles para Athena sin intervención manual.

Lake Formation y los permisos

Por último, el stack registra el bucket en Lake Formation y define los permisos sobre la base de datos. En un proyecto real acá es donde definirías qué equipo ve qué tablas y qué columnas — en el repo dejé el esqueleto con un permiso de ejemplo para que veas el patrón y lo extiendas según tu caso.

Desplegarlo en tu cuenta

Con el repo clonado y tus credenciales de AWS configuradas:

# Instalar dependencias
pip install -r requirements.txt

# Bootstrap de CDK (solo la primera vez en la cuenta/región)
cdk bootstrap

# Desplegar el Data Lake completo
cdk deploy

Eso es todo. Un comando y CDK crea el bucket, la Lambda, el job, el crawler, la base de datos y los permisos. Al terminar, el output del deploy te muestra el nombre del bucket para que empieces a subir archivos.

El momento mágico

Ahora viene la mejor parte. Generamos datos de ejemplo y los subimos a la raw zone:

# Generar un CSV de ventas de ejemplo
python sample_data/generate_ventas.py

# Subirlo a la raw zone
aws s3 cp ventas_2026-06-10.csv s3://<tu-bucket>/raw/ventas/

Y... no hacemos nada más. El archivo llega, Lambda lo detecta, el Glue Job lo transforma, el Crawler actualiza el catálogo. Todo solo.

Unos minutos después, abrimos Athena y consultamos:

SELECT
    sucursal,
    SUM(monto) AS total_ventas
FROM datalake_db.ventas
WHERE fecha = '2026-06-10'
GROUP BY sucursal
ORDER BY total_ventas DESC;

Subiste un CSV y unos minutos después lo estás consultando con SQL. Sin servidores, sin clusters, sin conexiones. Eso es un Data Lake serverless funcionando.

¿Cuánto costó la demo?

Les debo el número porque es de los más compartibles del post: correr esta demo completa — deploy, varios archivos procesados, queries en Athena — cuesta centavos de dólar. El desglose:

Servicio	Uso en la demo	Costo aproximado
S3	Algunos MB almacenados	< USD 0.01
Lambda	Un puñado de invocaciones	USD 0 (free tier)
Glue Job	Pocos minutos de DPU	USD 0.10–0.50
Glue Crawler	Ejecuciones cortas	< USD 0.05
Athena	KBs escaneados (gracias, Parquet)	< USD 0.01

Importante: cuando termines de experimentar, cdk destroy elimina todo el stack. No dejes recursos huérfanos dando vueltas — el Glue Crawler con schedule es el clásico que te aparece en la factura del mes siguiente.

Cierre de la serie

Recapitulemos el camino que hicimos en estos tres posts:

Parte 1: qué es un Data Lake, sus desafíos y cómo fluyen los datos
Parte 2: los 5 servicios de AWS que forman el núcleo serverless
Parte 3: el pipeline completo, construido como código y desplegable en minutos

El repo queda abierto: github.com/alvarongg/serverless-datalake-aws. Si lo desplegás, lo rompés o lo mejorás, los issues y pull requests son bienvenidos.

¿Y ahora qué? Tener el Data Lake funcionando es la mitad del trabajo. La otra mitad es evitar que con el tiempo se convierta en un Data Swamp — y de eso, justamente, viene el próximo post.

Si tienen preguntas, las leo en los comentarios.

Abrazo grande, hasta la próxima 🚀

Introducción a los Data Lakes Parte 2

Alvaro Garcia — Wed, 19 Aug 2026 15:54:09 +0000

En el post anterior exploramos qué es un Data Lake y por qué son tan importantes en el ecosistema de datos actual. Ahora es momento de ensuciarnos las manos y ver exactamente qué servicios de AWS necesitamos para construir un Data Lake completamente serverless y cómo orquestarlos.

Los Servicios Fundamentales

Un Data Lake serverless en AWS se construye sobre cinco pilares fundamentales que trabajan en conjunto para crear una solución escalable y costo-eficiente:

Storage
Procesamiento
Catalogo
Seguridad
Explotación

Amazon S3 - El Corazón del Storage

S3 no es solo nuestro sistema de archivos, es la piedra angular del Data Lake. Aquí almacenamos tanto los datos crudos como los procesados, y su organización es crucial para el rendimiento y los costos.

Estructura de carpetas de un data lake estandar:

data-lake-bucket/
├── raw/                    # Datos sin procesar
│   ├── year=2024/
│   ├── month=12/
│   └── day=15/
├── processed/              # Datos transformados
│   ├── bronze/             # Limpieza básica
│         ├── year=2024/
│         ├── month=12/
│         └── day=15/           
│   ├── silver/            # Transformaciones de negocio
│         ├── year=2024/
│         ├── month=12/
│         └── day=15/         
│   └── gold/              # Datos listos para consumo
│         ├── year=2024/
│         ├── month=12/
│         └── day=15/        
└── athena-results/        # Resultados de queries

Notarás que todo el data lake se encuentra en un mismo bucket, esto es lo más recomendable ya que S3 tiene un límite de 100 bucket que podemos crear por cuenta (no importa la región, ya que S3 es un servicio global)

Configuraciones clave en S3:

Versionado habilitado para auditoría y rollback
Lifecycle policies para optimizar costos (Standard → IA → Glacier)
Server-side encryption con KMS para seguridad si es necesario.
Cross-region replication para disaster recovery

AWS Glue - El Motor de Transformación

Glue es suite de servicios de data serverless que maneja tanto el descubrimiento de esquemas como las transformaciones de datos.

Componentes principales:

Glue Jobs: Herramienta predilecta para ejecutar ETLs, nos permite procesar y transformar los datos de forma paralela, serverless y escalable usando Spark (en general Pyspark)
Glue Catalog: Metastore centralizado que actúa como nuestro "diccionario o catálogo de datos"
Glue Crawlers: Descubren automáticamente la estructura de los datos que dejamos en el storage que para este ejemplo es S3.

Un Glue Job típico se ve así:

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# Leer datos del catálogo
datasource = glueContext.create_dynamic_frame.from_catalog(
    database="mi_database",
    table_name="raw_data"
)

# Transformar datos
transformed = ApplyMapping.apply(
    frame=datasource,
    mappings=[
        ("old_column", "string", "new_column", "string"),
        ("timestamp", "string", "processed_date", "timestamp")
    ]
)

# Escribir a S3 en formato Parquet
glueContext.write_dynamic_frame.from_options(
    frame=transformed,
    connection_type="s3",
    connection_options={"path": "s3://mi-bucket/processed/"},
    format="parquet"
)

job.commit()

Amazon Athena - La Ventana de Consultas

Athena nos permite consultar nuestros datos directamente desde S3 usando SQL estándar (ANSI SQL), sin necesidad de provisionar servidores y como si estuvieramos utilizando PrestoDB como motór de consultas.

Ventajas clave:

Pay-per-query: Solo pagas por los datos escaneados
Integración nativa con Glue Catalog
Soporte para múltiples formatos: Parquet, ORC, JSON, CSV
Particionado automático para optimizar performance
Limitación a usuarios: Se puede limitar la cantidad de querys, tiempo de consultas y volumen escaneado por usuario y grupo.
Seguridad integrada: Se integra a otros servicios especialmente LakeFormation para la facil gobernanza de los datos.

Ejemplo de query optimizada:

SELECT 
    region,
    COUNT(*) as total_events,
    AVG(revenue) as avg_revenue
FROM processed_sales
WHERE year = '2024' 
    AND month = '12'
    AND event_type = 'purchase'
GROUP BY region
ORDER BY avg_revenue DESC;

Importante - Nunca hagas un Select * From porque va a ser la consulta más cara de tu vida.

AWS Lambda - La Automatización Inteligente

Lambda actúa como el pegamento que conecta todos los servicios, respondiendo a eventos y orquestando workflows complejos.

Casos de uso comunes:

Triggers de S3: Procesar archivos automáticamente al llegar
Validación de datos: Verificar calidad antes del procesamiento
Notificaciones: Alertar sobre fallos o completitud de procesos
Orquestación: Coordinar múltiples Glue Jobs

Ejemplo de función Lambda que se ejecuta cuando llega un archivo:

import boto3
import json

def lambda_handler(event, context):
    glue_client = boto3.client('glue')

    # Extraer información del evento S3
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # Iniciar Glue Job si es un archivo de datos
    if key.startswith('raw/') and key.endswith('.json'):
        response = glue_client.start_job_run(
            JobName='process-raw-data',
            Arguments={
                '--input_path': f's3://{bucket}/{key}',
                '--output_path': f's3://{bucket}/processed/'
            }
        )

        return {
            'statusCode': 200,
            'body': json.dumps(f'Job iniciado: {response["JobRunId"]}')
        }

AWS CDK - Infrastructure as Code

CDK nos permite definir toda nuestra infraestructura usando Python, manteniendo versionado y reproducibilidad.

from aws_cdk import (
    Stack,
    aws_s3 as s3,
    aws_glue as glue,
    aws_lambda as lambda_,
    aws_s3_notifications as s3n
)

class DataLakeStack(Stack):
    def __init__(self, scope, construct_id, **kwargs):
        super().__init__(scope, construct_id, **kwargs)

        # S3 Bucket para el Data Lake
        data_lake_bucket = s3.Bucket(
            self, "DataLakeBucket",
            versioned=True,
            lifecycle_rules=[
                s3.LifecycleRule(
                    id="move-to-ia",
                    transitions=[
                        s3.Transition(
                            storage_class=s3.StorageClass.INFREQUENT_ACCESS,
                            transition_after=Duration.days(30)
                        )
                    ]
                )
            ]
        )

        # Glue Database
        database = glue.CfnDatabase(
            self, "DataLakeDatabase",
            catalog_id=self.account,
            database_input=glue.CfnDatabase.DatabaseInputProperty(
                name="data_lake_db",
                description="Database for Data Lake"
            )
        )

Flujo de Datos Completo

El flujo típico en nuestro Data Lake serverless sigue este patrón:

Ingesta: Los datos llegan a S3/raw/ desde diversas fuentes
Detección: S3 Event Notification dispara una Lambda
Catalogación: Glue Crawler descubre el esquema
Procesamiento: Glue Job transforma los datos
Almacenamiento: Datos procesados van a S3/processed/
Consulta: Athena permite análisis ad-hoc
Visualización: Herramientas de BI consumen desde Athena

Optimización de Costos

Formatos de Archivo

Parquet para análisis columnar (reduce costos de Athena hasta 90%)
Compresión GZIP o Snappy para reducir storage
Particionado inteligente por fecha/región/categoría

Estrategias de Storage

S3 Intelligent Tiering para archivos con patrones de acceso variables
Lifecycle policies para mover datos antiguos automáticamente
Spot instances en Glue para workloads no críticas

Monitoreo y Alertas

# CloudWatch Custom Metrics en Lambda
import boto3

cloudwatch = boto3.client('cloudwatch')

def put_custom_metric(metric_name, value, unit='Count'):
    cloudwatch.put_metric_data(
        Namespace='DataLake/Processing',
        MetricData=[
            {
                'MetricName': metric_name,
                'Value': value,
                'Unit': unit
            }
        ]
    )

Seguridad y Governance

IAM Roles y Políticas

Cada servicio necesita permisos específicos y mínimos:

Glue Role: Acceso a S3 y CloudWatch Logs
Lambda Role: Triggers de S3 y inicio de Glue Jobs
Athena Users: Solo lectura en tablas específicas

Encriptación End-to-End

S3: Server-side encryption con KMS
Glue: Encriptación en jobs y catálogo
Athena: Encriptación de resultados

Próximos Pasos

En el siguiente post profundizaremos en AWS Glue en la práctica, incluyendo:

Optimización de Glue Jobs para grandes volúmenes
Testing y debugging de transformaciones
Patrones avanzados de ETL
Integración con herramientas de CI/CD

Un Data Lake serverless en AWS no es solo una colección de servicios, es un ecosistema integrado que, bien diseñado, puede escalar desde gigabytes hasta petabytes manteniendo costos controlados y performance óptimo.

¿Implementaste alguna de estas arquitecturas? ¿Qué desafíos te encontraste?

Contame en los comentarios tu experiencia con tus Data Lakes.

Introducción a los Data Lakes

Alvaro Garcia — Sun, 21 Jan 2024 23:36:23 +0000

Hola a todos como post inaugural en esta comunidad me gustaría contarles un poco sobre Data Lakes de una forma un poco más general.

Que es un DATA LAKE ?

Un data lake es un gran repositorio de datos estructurados y no estructurados, es donde podemos volcar todos los datos que genera la compañia.

En general los data lakes son estructuras bastante mas grandes en cuanto a volumen y capacidad de procesamiento que una base de datos normal.

Los data lakes y especialmente los data lakes en aws cobraron una notoriedad muy grande en los ultimos años, ya que nos permiten escalar en volumen de datos y capacidad de procesamiento de manera eficiente y a costos sensiblemente más bajos que con los métodos tradicionales.

Flujo de los datos

Como gran sistema de procesamiento y almacenamiento de información el data lake tiene 3 objetivos principales.

Crecimiento de los datos

Otra cuestión importante que tienen los data lakes es el crecimiento de los datos, en un data lake podemos almacenar datos de practicamente cualquier formato:

Actividad de los usuarios/clientes
Sensores IOT
Mensajeria y Redes sociales
Emails
Fotos
Videos

Estos datos pueden crecer muchisimo dependiendo del rubro y caso de uso, pero uno siempre piensa que tiene muchos menos datos de los que cree.

Desafios en la administración de un Data Lake

Algunos de los desafios que plantea la administración de un Data Lake se pueden ver a simple vista, mientras que otros surgen de el descontrol de los primeros.

En primer lugar tenemos que un data lake está en constante crecimiento y de manera exponencial algo que al final del día debe estar ordenado y aplicado de manera costo eficiente.

Luego tenemos las fuentes de datos, sistemas de archivos, apis, bases de datos, sistemas enlatados, streaming de video, redes sociales. No hay límite en cuanto desde donde podemos recibir información lo que nos obliga a mantenernos versátiles.

Como tercer punto tenemos la diversidad de esos mismos datos como vimos anteriormente, cualquier tipo de archivo del que podamos extraer un dato califica para ingresar a un data lake.

y como último desafio tenemos los más importantes a mi parecer, la cantidad de usuarios que van a utilizar el data lake y luego la capacidad de integración que requiera nuestro lago de datos con sistemas externos ya sea para analizar y/o visualizar información.

Arquitectura de un Data Lake en AWS

Ahora que ya sabemos que es y porqué es tan importante un data lake hoy en día, vemos cual es la arquitectura mínima que debemos crear para que nuestro proyecto califique como un data lake.

Canalización del análisis de datos

Definamos entonces cual es el proceso que debe seguir un dato al momento de ingresar en un data lake y como este debe actuar para que al final de todo ese camino obtengamos información.

Como pueden ver el proceso está separado en pocos pasos:

Recopilar: Aqui es donde aplicamos las tecnicas necesaria para que el dato viaje a nuestra infraestructura, ya sea que nosotros tengamos que ir a buscarla como tambien proveer un método que le permita a los proveedores de datos enviarlos al data lake. Una vez que el dato llega se almacena crudo.
Procesar y Analizar: En esta estapa vamos a tomar los datos crudos y los trabajaremos de manera que podamos obtener finalmente información relevante donde nuevamente vamos a almacenar la información en el repositorio correspondiente.
Visualizar: Por ultimo una vez que ya tenemos información debemos utilizar algun tipo de herramienta que permita al usuario visualizarla y analizarla de una manera que se ajuste a su caso de uso. Quizá con una herramienta de BI para un usuario mas ejecutivo o algo más potente como una jpyter notebook para un analista de datos.

La clave de este proceso es entender segun el dato y el caso de uso con que velocidad necesitamos tenerlo disponible desde su momento de creación. Así definiremos el balance entre costo y latencia/rendimiento.

Próximos pasos

En el siguiente post vamos a repasar los servicios de aws que necesitamos minimamente para montar un Data Lake completamente Serverless.