Tema 1 de 4
Azure Blob Storage y Data Lake Storage
Muchas aplicaciones no necesitan la estructura rígida de una base relacional: guardan imágenes, videos, copias de seguridad o archivos para analizar. Azure Blob Storage es el servicio para eso, y sobre él se construyen los data lakes. El examen pregunta los tipos de blob, los niveles de acceso y qué aporta Data Lake Storage Gen2.
Contenido
¿Qué es Azure Blob Storage?
Un servicio para guardar en la nube cantidades masivas de datos no estructurados como objetos binarios grandes, o blobs.
Los blobs son una forma eficiente de guardar archivos en un formato optimizado para la nube, y las aplicaciones los leen y escriben con la API de Azure Blob Storage. Azure Storage es un servicio básico de Azure que además ofrece recursos compartidos de archivos (Azure Files) y tablas clave-valor (Azure Table Storage).
Cuentas, contenedores y carpetas virtuales
Cuenta de almacenamiento: El recurso de Azure que contiene los datos.
Contenedor: Agrupa blobs relacionados. Quién puede leer y escribir se controla a nivel de contenedor.
Blob: El objeto en sí: una imagen, un video, un archivo.
- El método de inicio de sesión recomendado es la autenticación con Microsoft Entra ID, que permite asignar permisos precisos con Azure RBAC (control de acceso basado en roles).
- Dentro de un contenedor se pueden organizar los blobs en carpetas virtuales, pero por defecto son solo un «/» en el nombre del blob: no permiten controlar el acceso ni hacer operaciones masivas a nivel de carpeta.
Tipos de blob
| Tipo | Cómo se organiza | Tamaño máximo | Mejor para |
|---|---|---|---|
| En bloques (block) | Conjunto de bloques de hasta 4000 MiB cada uno | 190,7 TiB (4000 MiB × 50 000 bloques) | Objetos binarios grandes y discretos que cambian poco |
| En páginas (page) | Páginas fijas de 512 bytes, lectura y escritura aleatoria | 8 TiB | Discos virtuales de las VM |
| En anexos (append) | Bloques de hasta 4 MiB que solo se añaden al final | Algo más de 195 GiB | Operaciones de anexado, como registros |
En un blob en bloques, el bloque es la unidad mínima que se lee o escribe. En un blob en anexos no se pueden actualizar ni eliminar bloques existentes.
Niveles de acceso
Equilibran la latencia de acceso y el coste de almacenamiento:
Hot
Nivel por defecto, para blobs de acceso frecuente. Se guardan en medios de alto rendimiento.
Cool
Menor coste de almacenamiento y mayor coste de acceso que Hot. Para datos poco frecuentes. Mínimo 30 días para evitar penalización por borrado anticipado.
Cold
Para datos que rara vez se leen pero deben recuperarse rápido: copias a corto plazo, recuperación ante desastres. Mínimo 90 días.
Archive
El coste de almacenamiento más bajo y la mayor latencia. Para históricos que no pueden perderse pero casi no se usan. Mínimo 180 días.
Rehidratación
En Hot, Cool y Cold la lectura tarda milisegundos. Los blobs en Archive están, en la práctica, sin conexión: para leerlos hay que cambiarlos a Hot, Cool o Cold y esperar a que termine la rehidratación, que puede tardar hasta 15 horas.
Es habitual crear un blob en Hot y pasarlo a Cool cuando se consulta menos; también puede volver de Cool a Hot.
Directivas de administración del ciclo de vida
Una directiva de ciclo de vida puede mover automáticamente un blob de Hot a Cool, después a Cold y por último a Archive a medida que envejece y se usa menos. La regla se basa en el número de días desde la última modificación. También puede eliminar blobs obsoletos.
Hot
→ Cool
→ Cold
→ Archive
→ Eliminar
Opciones de redundancia
| Opción | Dónde se guardan las copias | Protege frente a |
|---|---|---|
| LRS | Tres copias en un solo centro de datos | Fallos de hardware |
| ZRS | Copias en tres zonas de disponibilidad de la región primaria | La caída de una zona |
| GRS / GZRS | Replicación asíncrona a una región secundaria a cientos de kilómetros | Desastres regionales |
| RA-GRS / RA-GZRS | Como GRS/GZRS, con lectura en la secundaria | Leer antes de una conmutación por error |
Azure Data Lake Storage Gen2
Solución de data lake a escala de nube integrada en Azure Storage. Combina la escalabilidad y el control de costes de Blob Storage (niveles y ciclo de vida incluidos) con un sistema de archivos jerárquico compatible con los principales sistemas de análisis.
- Sistemas como Azure Databricks se conectan a los datos de Data Lake Storage Gen2 para procesar grandes volúmenes.
- El espacio de nombres jerárquico permite listas de control de acceso (ACL) compatibles con POSIX: permisos de lectura, escritura y ejecución por archivo y carpeta, aparte de Azure RBAC.
- Para crearlo hay que habilitar el espacio de nombres jerárquico de la cuenta de almacenamiento, al crearla o actualizando una existente.
Solo de ida
Actualizar una cuenta al espacio de nombres jerárquico no tiene vuelta atrás: después no se puede volver a un espacio de nombres plano.
OneLake
Cada tenant de Microsoft Fabric aprovisiona automáticamente OneLake, un data lake unificado para toda la organización que está construido sobre Azure Data Lake Storage. Admite las API de ADLS Gen2, así que las aplicaciones y servicios existentes pueden conectarse a él. El dominio D4 lo explica dentro de Fabric.
Escenarios de examen
| Situación | Respuesta | Por qué |
|---|---|---|
| Guardar archivos binarios grandes que cambian poco, como videos | Blob en bloques | Objetos discretos y grandes. |
| Discos virtuales de máquinas virtuales | Blob en páginas | Lectura y escritura aleatoria en páginas de 512 bytes. |
| Registros que solo se van añadiendo al final | Blob en anexos | Solo se añaden bloques al final. |
| Datos consultados a diario | Nivel Hot | Medios de alto rendimiento, nivel por defecto. |
| Copias de seguridad que se leen pocas veces pero deben recuperarse rápido | Nivel Cold | Barato y con lectura en milisegundos. |
| Históricos que casi nunca se leen y pueden tardar horas en recuperarse | Nivel Archive | El más barato, sin conexión hasta rehidratar. |
| Mover blobs a niveles más baratos automáticamente según su antigüedad | Directiva de ciclo de vida | Basada en días desde la modificación. |
| Data lake con carpetas reales y permisos por archivo | Data Lake Storage Gen2 | Espacio de nombres jerárquico y ACL POSIX. |
| Seguir leyendo datos aunque falle una región entera | RA-GRS o RA-GZRS | Lectura en la región secundaria. |
Trampas frecuentes del examen
❓ ¿Qué tipo de blob usa Azure para los discos de las máquinas virtuales?
Blobs en páginas, optimizados para lectura y escritura aleatoria.
❓ ¿Se puede leer un blob en Archive al instante?
No. Hay que cambiarlo a Hot, Cool o Cold y esperar la rehidratación, que puede tardar hasta 15 horas.
❓ ¿Cuál es el nivel de acceso por defecto?
Hot.
❓ ¿Las carpetas de Blob Storage permiten aplicar permisos por carpeta?
Por defecto no: son virtuales. Con el espacio de nombres jerárquico de Data Lake Storage Gen2 sí, mediante ACL POSIX.
❓ ¿Se puede desactivar el espacio de nombres jerárquico después de habilitarlo?
No. Es un proceso de un solo sentido.
❓ ¿En qué se basa una directiva de ciclo de vida para mover blobs?
En el número de días desde la última modificación.
❓ ¿Cuántos días mínimos debe estar un blob en Cool, Cold y Archive?
30, 90 y 180 días respectivamente, para evitar la penalización por borrado anticipado.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa debe conservar durante 7 años registros de auditoría que casi nunca consulta. Si los necesita, puede esperar varias horas. Quiere el menor coste de almacenamiento. ¿Qué nivel usa?
¿Listo para poner a prueba "Blob Storage y Data Lake Storage"?
Preguntas originales, cada una con su explicación.
Empezar un simulacro