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 de 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.
Formatos de datos: un tema menos glamoroso, pero crítico
Quiero comenzar por un tema que suele parecer secundario hasta 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.
¿Por qué debe importarnos el formato de los 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 comienzan a aparecer 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.
Iniciando con algo de teoría
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.
Formatos validados
Son aquellos formatos que AWS soporta de manera nativa para procesos de entrenamiento, procesamiento o inferencia, y cuyo uso está documentado oficialmente en los servicios correspondientes, como Amazon SageMaker.
Formatos no validados
Son formatos que, aunque pueden almacenarse en Amazon S3 u otros servicios de AWS, requieren transformaciones adicionales antes de poder ser utilizados dentro de un flujo de Machine Learning.
Una vez clara esta distinción, es necesario repasar otro concepto fundamental: la forma en que los datos se organizan internamente. A grandes rasgos, los formatos de datos pueden clasificarse según si almacenan la información por filas (row-based) o por columnas (column-based), una diferencia que tiene un impacto directo en el rendimiento y en los costos cuando trabajamos con Machine Learning.
Una analogía de la vida real: tarjetas coleccionables
Me gusta mucho trabajar con analogías y ejemplos prácticos. Últimamente, mi hijo se ha convertido en un coleccionista experto de tarjetas Pokemon, así que permíteme compartir un ejemplo de mi vida cotidiana.
Para un coleccionista, cada tarjeta es un elemento único que consta de varios atributos importantes para definir su valor: nombre, código, tipo y rareza (créeme, hay muchos más atributos como brillo, edición o estado, pero no nos compliquemos).
Enfoque orientado a filas (Row-based)
En un enfoque orientado a filas, cada tarjeta se almacena como una unidad completa, con todos sus atributos juntos:
- Tarjeta A: tipo eléctrico, rareza común
- Tarjeta B: tipo dragón, rareza rara
- Tarjeta C: tipo psíquico, rareza especial
Desde la perspectiva del coleccionista, este enfoque es ideal cuando:
- Quiere revisar una tarjeta específica
- Necesita conocer todas las características de una carta en particular
- Agrega nuevas cartas a su colección una por una
En los álbumes de mis hijos, cada compartimiento contiene una carta completa. Este enfoque es eficiente cuando se trabaja con registros individuales, pero no es óptimo para analizar grandes volúmenes de tarjetas al mismo tiempo.
Enfoque orientado a columnas (Column-based)
En un enfoque orientado a columnas, los atributos de las tarjetas se almacenan por separado:
- Todos los nombres juntos
- Todos los tipos juntos
- Todas las rarezas juntas
- Todos los niveles juntos
Desde la perspectiva del coleccionista, este enfoque resulta ideal cuando quiere:
- Encontrar todas las cartas de cierto tipo
- Analizar la distribución de rarezas en su colección
- Identificar 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.
| Formato | Organización | ¿Validado? | Casos de uso típicos | ¿Comprimido? | Servicios AWS comunes | Observaciones |
|---|---|---|---|---|---|---|
| JSON | Row-based | Sí | Ingesta de eventos, datos semi-estructurados, APIs | No por defecto (puede comprimirse) | S3, Kinesis, Lambda, SageMaker | Legible para humanos. Soporta datos estructurados y semi-estructurados. Mayor latencia de parsing y overhead de tamaño. |
| CSV | Row-based | Sí | Datasets pequeños, prototipos, carga inicial | No por defecto (puede comprimirse) | S3, SageMaker, Glue | No soporta esquema ni estructuras complejas. Fácil de producir y consumir, pero poco eficiente a gran escala. |
| RecordIO | Binario | Sí | Entrenamiento optimizado en SageMaker | Sí | SageMaker | Serializado binario, eficiente y secuencial. No legible para humanos. Requiere procesamiento previo. |
| Parquet | Column-based | Sí | Big Data, entrenamiento ML, análisis | Sí (compresión columnar) | S3, Glue, Athena, SageMaker | Muy eficiente para consultas y ML. Ideal para grandes volúmenes. No todos los algoritmos built-in lo soportan directamente. |
| Avro | Row-based | No | Streaming, intercambio de datos | Sí | S3, Kafka (MSK), Glue | Común en pipelines con Kafka. Requiere transformación previa. No recomendado para entrenamiento directo en SageMaker. |
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.
Practiquemos para el examen
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.
¿Cuál es el formato de datos más adecuado para este escenario?
A. CSV, porque es fácil de producir y compatible con la mayoría de los servicios de AWS
B. JSON, porque permite manejar datos semi-estructurados de forma flexible
C. Parquet, porque almacena los datos de forma columnar y permite leer solo las columnas necesarias
D. Avro, porque es eficiente para intercambio de datos en sistemas distribuidos
Respuesta correcta
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.
Otra historia hubiera sido si la pregunta estuviera enfocada en eventos en tiempo real, si no se enfocara en entrenamiento directo sino en ingesta.
Este pequeño mapa mental puede servir como recordatorio rápido del propósito de los principales formatos de datos, tanto para el examen como para la toma de decisiones en proyectos reales.
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 es el que luego se traduce en mejores decisiones técnicas cuando diseñamos 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.
Top comments (0)