Diario de una builder: Preparándonos para AWS Machine Learning desde cero

Source: Dev.to

Introducción

Me gusta compartir mi experiencia en la preparación de certificaciones, especialmente cuando el objetivo es construir criterio y no únicamente aprobar un examen. Al final, el valor no está en la certificación en sí, sino en el conocimiento que se adquiere durante el proceso y en cómo este se traduce en crecimiento profesional.

Actualmente estoy enfocada en obtener las certificaciones Machine Learning y AI Developer en AWS y, siguiendo las buenas prácticas, recorro con cuidado las guías oficiales de cada examen.

En este diario documento el camino que sigo para aterrizar conceptos que suelen parecer abstractos cuando se estudian de manera aislada. En más de una ocasión, durante un examen de certificación, aparece alguno de esos detalles trabajados previamente, y es ahí donde confirmo que aprender construyendo realmente marca la diferencia.

A través de esta serie de artículos comparto ese proceso para que, si estás comenzando en Machine Learning en AWS, puedas apoyarte en experiencias reales y en un enfoque práctico para transitar este camino de aprendizaje.

¿Por qué los formatos de datos son importantes?

Quiero comenzar por un tema que suele parecer secundario –incluso aburrido– de abordar, pero que tiene un impacto directo tanto en los laboratorios, en el entrenamiento de modelos y, por supuesto, en las certificaciones: los formatos de datos.

Es común encontrar preguntas en el examen donde no se evalúa un algoritmo, sino la capacidad de elegir cómo almacenar, procesar y consumir los datos dentro de un flujo de Machine Learning en AWS. En escenarios prácticos, la elección del formato impacta directamente en:

• El rendimiento de los procesos
• Los costos asociados
• La capacidad de escalar una solución

El primer dominio del examen está relacionado con Data Preparation for Machine Learning, lo que incluye actividades como la ingesta y el almacenamiento de datos. En este contexto aparecen conceptos como formatos de datos validados y no validados, tal como se describen en la guía oficial del examen.

Más allá de memorizar definiciones, este dominio busca que desarrolles criterio para:

• Cuándo escoger un formato de datos sobre otro
• Para qué tipos de cargas de trabajo son más efectivos
• En qué casos de uso aplican dentro de un flujo de ML
• Con qué servicios y herramientas de AWS son compatibles o no

Entender estos puntos no solo te ayudará a responder preguntas del examen, sino también a tomar mejores decisiones cuando construyas soluciones reales de Machine Learning en AWS.

Conceptos clave

Antes de profundizar en los distintos formatos de datos y sus fortalezas, es importante aclarar algunos conceptos que aparecen de forma recurrente en el examen de AWS Machine Learning.

Analogía práctica: tarjetas Pokémon

Ejemplo cotidiano – Mi hijo es coleccionista de tarjetas Pokémon. Utilizo su afición para ilustrar la diferencia entre formatos row‑based y column‑based.

Enfoque orientado a filas (row‑based)

Cada tarjeta se almacena como una unidad completa, con todos sus atributos juntos:

Ideal cuando:

• Se quiere revisar una tarjeta específica.
• Necesita conocerse todas las características de una carta en particular.
• Se agregan nuevas cartas una por una.

Este enfoque es eficiente para trabajar con registros individuales, pero no es óptimo para analizar grandes volúmenes de tarjetas al mismo tiempo.

Enfoque orientado a columnas (column‑based)

Los atributos de las tarjetas se almacenan por separado:

Ideal cuando:

• Se quiere encontrar todas las cartas de cierto tipo.
• Se desea analizar la distribución de rarezas en la colección.
• Se buscan patrones o tendencias dentro de un conjunto grande de cartas.

Es como reorganizar la colección para analizarla: en lugar de ver carta por carta, se agrupan los atributos para poder comparar rápidamente.

Tabla comparativa de formatos de datos en AWS

Nota: La fila de Parquet está incompleta en el material original; se mantiene tal cual para preservar la integridad del contenido.

Conclusión

Dominar los diferentes formatos de datos y saber cuándo utilizarlos es esencial tanto para aprobar el examen de certificación como para diseñar soluciones de Machine Learning eficientes y rentables en AWS. En los próximos artículos profundizaremos en cada formato, sus ventajas, limitaciones y mejores prácticas de uso dentro del ecosistema AWS. ¡Continúa acompañándonos en este viaje de aprendizaje práctico!

Resumen de formatos de datos en AWS

A continuación se muestra una tabla comparativa de los formatos más habituales en los pipelines de Machine Learning y análisis de datos en AWS. La tabla mantiene la información original pero está estructurada en Markdown para una mejor legibilidad.

Nota: No todos los algoritmos built‑in de SageMaker soportan directamente todos los formatos; por ejemplo, algunos esperan datos en Parquet o CSV.

Tabla de criterios de evaluación (examen)

Esta tabla resume uno de los criterios más importantes que evalúa el examen: no todos los formatos sirven para todo. Elegir correctamente implica entender el volumen de datos, el tipo de procesamiento y el servicio de AWS involucrado.

Caso práctico: Selección de formato para entrenamiento de ML

Enunciado
Una empresa está construyendo un pipeline de Machine Learning en AWS para entrenar un modelo de clasificación utilizando un dataset de varios terabytes almacenado en Amazon S3. El equipo necesita reducir el tiempo de entrenamiento y minimizar los costos de I/O, ya que el modelo solo utiliza un subconjunto de las columnas disponibles en el dataset.

Respuesta correcta

C. Parquet

Justificación
Parquet es un formato column‑based y comprimido, lo que permite que los procesos de entrenamiento y análisis lean únicamente las columnas requeridas por el modelo. Esto reduce significativamente el I/O, mejora el rendimiento y disminuye los costos, especialmente cuando se trabaja con grandes volúmenes de datos en Amazon S3 y servicios como Amazon SageMaker, Athena o AWS Glue.

Otros escenarios posibles

• Eventos en tiempo real / ingestión → En este caso, un formato row‑based con soporte de streaming (por ejemplo, Avro) sería más apropiado que Parquet.
• Transformación ligera antes del entrenamiento → CSV o JSON pueden ser útiles si la transformación es mínima y la compatibilidad es prioritaria.

Mapa mental rápido (para el examen y proyectos reales)

[Formato] → [Orientación] → [Uso principal] → [Servicios compatibles]
CSV      → Row‑based   → Tablas simples          → S3, SageMaker, Athena, Glue
JSON     → Row‑based   → Semi‑estructurados      → S3, SageMaker, Athena, Glue
Parquet  → Column‑based→ Análisis/ML a gran escala → S3, Glue, Athena, SageMaker
Avro     → Row‑based   → Streaming / intercambio → S3, Kafka (MSK), Glue

Conclusión

Entender cuándo usar un formato orientado a filas o a columnas, distinguir entre formatos validados y no validados, y reconocer el propósito de cada uno dentro de un pipeline permite desarrollar el criterio que el examen busca evaluar. Ese mismo criterio se traduce en decisiones técnicas más acertadas al diseñar soluciones de Machine Learning en entornos productivos.

Este es solo el primer paso del diario. A partir de aquí, el foco estará en cómo transformar, preparar y consumir estos datos.