Los datos tienen un ciclo de vida. Los archivos de registro creados hoy se consultarán con frecuencia mañana, pero los registros de hace tres años rara vez se abren. Almacenar ambos en el mismo nivel de almacenamiento de alto costo es un desperdicio. La gestión del ciclo de vida de los datos consiste en planificar cuánto tiempo conservar los datos y en qué forma. La evolución del esquema es el conjunto de técnicas que permiten cambiar las estructuras de datos sin romper los datos existentes. Las preguntas del examen DEA-C01 sobre estos temas se centran en la optimización de costos y la estabilidad operativa.
Políticas de ciclo de vida de S3
S3 ofrece múltiples clases de almacenamiento. Mover datos a clases más baratas a medida que disminuye la frecuencia de acceso puede reducir drásticamente los costos de almacenamiento.
| Clase de almacenamiento | Características | Mejor para | |------------------------|----------------|------------| | S3 Standard | Acceso rápido, mayor costo | Datos recientes de acceso frecuente | | S3 Standard-IA | Acceso ocasional, costo medio | Datos después de 30 días | | S3 Glacier Instant Retrieval | Acceso raro, bajo costo, recuperación instantánea | Datos después de 90 días | | S3 Glacier Flexible Retrieval | Acceso muy raro, muy bajo costo, recuperación en minutos u horas | Archivo a largo plazo | | S3 Glacier Deep Archive | Casi sin acceso, menor costo, recuperación en 12 horas | Datos de cumplimiento retenidos por años |
Las políticas de ciclo de vida automatizan estas transiciones. Por ejemplo:
Después de 30 días: Standard → Standard-IA automáticamente Después de 90 días: Standard-IA → Glacier Instant Retrieval Después de 365 días: Glacier Deep Archive Después de 2.555 días (7 años): Eliminación automática
La transición mueve datos a una clase más barata. La expiración elimina datos automáticamente. Las políticas de ciclo de vida pueden aplicarse a un bucket completo, un prefijo específico (ruta de carpeta) u objetos con etiquetas específicas.
DynamoDB TTL — Expiración automática de registros
DynamoDB es una base de datos NoSQL comúnmente usada para datos de sesión, tokens temporales, carritos de compra y otros datos que se vuelven irrelevantes después de cierto tiempo.
TTL (Time To Live) le permite establecer un tiempo de expiración en elementos individuales. Cuando pasa el tiempo de expiración de un elemento, DynamoDB lo elimina automáticamente, sin necesidad de código de eliminación de su parte.
Cómo funciona: Designe un atributo en su tabla para almacenar el tiempo de expiración (por ejemplo, ) Almacene una marca de tiempo Unix en ese atributo para cada elemento DynamoDB busca elementos expirados en segundo plano y los elimina La eliminación normalmente ocurre dentro de las 48 horas posteriores a la expiración
Notas importantes: La eliminación por TTL es gratuita (no consume capacidad de escritura) Los elementos no se eliminan exactamente en el momento de expiración, por lo que su aplicación debe verificar el campo de expiración Combine DynamoDB Streams con TTL para capturar eventos de eliminación y procesamiento adicional
Gestión de datos en Redshift
Redshift es un almacén de datos a escala de petabytes. Cargar datos eficientemente y exportarlos es fundamental.
El comando COPY carga datos en masa desde S3, DynamoDB, EMR y otras fuentes hacia Redshift. Es mucho más rápido que instrucciones INSERT individuales.
El comando UNLOAD exporta datos de Redshift a S3. Úselo para guardar resultados de análisis o transferir datos a otro sistema.
Las instantáneas (snapshots) son copias de seguridad completas de un clúster de Redshift. Las instantáneas automáticas se ejecutan cada 8 horas o cada 5 GB de cambios. Las instantáneas manuales se ejecutan a demanda. Use instantáneas para restaurar un clúster en otra región para recuperación ante desastres.
Principios de diseño de esquemas
Cómo organiza los datos tiene un enorme impacto en el rendimiento de las consultas.
DISTKEY y SORTKEY de Redshift:
Redshift distribuye datos entre múltiples nodos. DISTKEY especifica qué columna usar como clave de distribución. Cuando dos tablas se unen en una columna que es el DISTKEY para ambas, las filas coincidentes ya están en el mismo nodo: no se requiere transferencia de red, lo que acelera significativamente los joins.
SORTKEY especifica el orden en que se almacenan los datos dentro de cada bloque en disco. Si sus consultas filtran frecuentemente por rango de fechas, hacer de la columna de fecha el SORTKEY permite a Redshift omitir bloques enteros fuera del rango objetivo, acelerando dramáticamente las consultas por rango.
Clave de partición de DynamoDB: DynamoDB distribuye datos entre particiones según la clave de partición. Si demasiados datos caen en un valor de clave de partición, esa partición se convierte en una partición caliente, causando cuellos de botella de rendimiento. Elija una clave de partición con alta cardinalidad (muchos valores únicos). El ID de usuario es una clave de partición mucho mejor que el género.
Particionamiento en S3: Decida cómo organizar sus carpetas S3 al escribir datos. Cuando Athena consulta datos particionados, omite particiones irrelevantes por completo, reduciendo los datos escaneados, lo que reduce tanto el costo como el tiempo de consulta.
Ejemplo:
Evolución del esquema — Cuando cambia su estructura de datos
Los negocios cambian. La estructura de datos que diseña hoy puede no ser adecuada en seis meses. La evolución del esquema es la capacidad de cambiar un esquema sin romper los datos almacenados existentes.
Apache Iceberg: Una capa de formato de tabla que se sitúa sobre archivos de datos en S3. Admite agregar columnas, cambiar tipos de columnas y eliminar columnas. También proporciona consultas de viaje en el tiempo, permitiéndole consultar datos tal como existían en un momento pasado. Soportado nativamente por AWS Glue y Athena.
Apache Avro: Un formato de serialización que almacena el esquema junto con los datos. Incluso cuando el esquema cambia, los datos escritos con el esquema antiguo aún pueden leerse correctamente. Frecuentemente combinado con Kafka para la evolución del esquema en pipelines de streaming.
SCT (Schema Conversion Tool) y DMS (Database Migration Service): Usados para migraciones entre diferentes motores de base de datos. SCT convierte esquemas de Oracle, SQL Server y otros a formatos compatibles con Redshift o Aurora. DMS luego migra los datos reales de la base de datos antigua a la nueva.
Linaje de datos — Rastreando el viaje de sus datos
El linaje de datos rastrea de dónde vienen los datos, qué transformaciones atravesaron y adónde fueron a parar. Es esencial para el cumplimiento regulatorio, la auditoría y la depuración.
Imagine que un informe muestra un número incorrecto. Sin linaje, debe verificar cada paso: ¿fue el dato fuente? ¿La transformación ETL? ¿La consulta de agregación? Con linaje, puede rastrear el camino de los datos hacia atrás y encontrar el problema rápidamente.
Servicios de AWS que ayudan a implementar el linaje: AWS Glue: Registra automáticamente el historial de ejecución de trabajos y los pasos de transformación Amazon DataZone: Visualiza el linaje en todo el catálogo de datos de la organización CloudTrail: Registro de auditoría a nivel de llamada API Lake Formation: Registros de acceso en todo el data lake
Puntos clave del examen
"Mover automáticamente datos antiguos a almacenamiento más barato" → Políticas de ciclo de vida S3 "Eliminación automática de elementos DynamoDB expirados" → TTL "Carga masiva de datos de S3 a Redshift" → Comando COPY "Exportar datos de Redshift a S3" → Comando UNLOAD "Optimizar el rendimiento de joins en Redshift" → DISTKEY "Optimizar consultas por rango en Redshift" → SORTKEY "Leer datos antiguos después de cambios de esquema" → Apache Iceberg o Avro "Migrar BD local a AWS" → SCT + DMS "Rastrear el historial de movimiento y transformación de datos" → Data Lineage