El Dominio 3 del temario oficial de DP-900 incluye "Describir las capacidades de Azure Storage", con Blob Storage, Azure Files y Table Storage como elementos. Las preguntas no se quedan en los nombres, como "las imágenes van a Blob". A menudo bajan un nivel más y preguntan por los periodos mínimos de retención de cada nivel, las políticas de ciclo de vida, PartitionKey y RowKey o los protocolos de los recursos compartidos de archivos.
Este artículo es un complemento de Fundamentos de datos no relacionales de nuestra serie de estudio de DP-900. Partiendo de lo básico sobre tipos de blob, niveles de acceso y redundancia que vimos allí, recorre las reglas detalladas que pregunta el examen: la estructura de la cuenta de almacenamiento, la administración del ciclo de vida de Blob, el espacio de nombres jerárquico de Data Lake Storage Gen2, los protocolos y la capacidad de Azure Files y el diseño de claves en Table Storage.
---
Cuentas de almacenamiento: el punto de partida de todo Azure Storage
Imagina una urbanización. Dentro hay un trastero para guardar pertenencias, una oficina compartida que usan varios vecinos y un libro de registro en la conserjería. En Azure Storage, la cuenta de almacenamiento hace de urbanización, y dentro viven los contenedores de blobs, los recursos compartidos de archivos, las tablas y las colas.
| Servicio | Jerarquía | Cómo se accede | |------|------|------| | Blob Storage | Cuenta de almacenamiento → contenedor → blob | API de Blob sobre HTTP(S) | | Data Lake Storage Gen2 | Cuenta de almacenamiento (espacio de nombres jerárquico activado) → sistema de archivos → directorio → archivo | API de Blob más un controlador de sistema de archivos para análisis | | Azure Files | Cuenta de almacenamiento → recurso compartido → directorio → archivo | Montaje SMB y NFS | | Table Storage | Cuenta de almacenamiento → tabla → entidad | API REST basada en claves |
La redundancia, que define cómo se replican los datos, se establece por cuenta de almacenamiento. LRS guarda tres copias en un solo centro de datos, y ZRS guarda copias en tres zonas de disponibilidad de la misma región. GRS y GZRS replican de forma asíncrona a una región secundaria a cientos de kilómetros, y si eliges RA-GRS o RA-GZRS (RA de acceso de lectura) puedes leer desde la región secundaria incluso antes de una conmutación por error. Azure Files, sin embargo, no admite lecturas desde la región secundaria.
Consejo para el examen: "Protegerse frente a una caída regional y leer desde la región secundaria incluso antes de la conmutación por error" → RA-GRS o RA-GZRS. "Los datos deben seguir admitiendo escrituras aunque caiga un centro de datos de la región" → ZRS.
---
Blob Storage: niveles de acceso y administración del ciclo de vida
Tipos de blob y tamaños máximos
Los blobs se guardan en contenedores, y el acceso se controla a nivel de contenedor. Las carpetas dentro de un contenedor son carpetas virtuales creadas con el carácter "/" en el nombre del blob, así que no puedes asignar permisos ni hacer operaciones masivas a nivel de carpeta.
| Tipo | Estructura | Tamaño máximo | Uso | |------|------|------|------| | Blob en bloques | Hasta 50 000 bloques de hasta 4000 MiB cada uno | Unos 190,7 TiB | Archivos grandes que cambian poco, como imágenes, vídeos y documentos | | Blob en páginas | Páginas fijas de 512 bytes | 8 TiB | Discos de máquinas virtuales, lecturas y escrituras aleatorias | | Blob en anexos | Solo se pueden añadir bloques al final | Unos 195 GiB | Datos que no paran de crecer por el final, como registros |
Niveles de acceso y cargo por eliminación anticipada
Los cuatro niveles, Hot, Cool, Cold y Archive, equilibran de forma distinta el coste de almacenamiento y el coste de acceso. Hot es el predeterminado y, cuanto más abajo vas, más barato es almacenar y más caro es leer los datos. Los datos deben permanecer al menos 30 días en Cool, 90 en Cold y 180 en Archive. Si los eliminas o los mueves a otro nivel antes, se aplica de forma prorrateada un cargo por eliminación anticipada de los días restantes. Por ejemplo, si eliminas un blob 21 días después de pasarlo a Cool, pagas los nueve días de almacenamiento que faltaban.
!Niveles de acceso de Blob y ciclo de vida
Archive es un nivel sin conexión, así que no puedes leer ni modificar un blob directamente allí. Primero tienes que rehidratarlo cambiando su nivel a Hot, Cool o Cold. La prioridad estándar puede tardar hasta 15 horas para objetos de menos de 10 GB, mientras que la prioridad alta, más cara, puede terminar en menos de una hora y está pensada para restauraciones urgentes.
Políticas de administración del ciclo de vida
Los datos recién creados se usan mucho y, con el tiempo, casi nada. Una política de administración del ciclo de vida usa reglas escritas en JSON para mover blobs a niveles más baratos o eliminarlos automáticamente.
Condiciones: días desde la creación, la última modificación o el último acceso (si el seguimiento de acceso está activado) Acciones: cambiar el nivel a Cool, Cold o Archive; eliminar versiones actuales, versiones anteriores o instantáneas Filtros: seleccionar blobs por prefijo de nombre o etiquetas de índice de blob Coste: la política en sí es gratuita y solo pagas las operaciones de cambio de nivel. Tras cambiar las reglas, pueden pasar hasta 24 horas hasta que se apliquen.
Consejo para el examen: "Mover automáticamente los blobs a Cool 30 días después de subirlos, a Archive a los 180 días y eliminarlos a los siete años" → política de administración del ciclo de vida. "Un blob en Archive no se puede leer de inmediato" → primero hay que rehidratarlo.
---
Data Lake Storage Gen2: lo que cambia el espacio de nombres jerárquico
Data Lake Storage Gen2 no es un servicio aparte. Es Blob Storage con la opción de espacio de nombres jerárquico activada en la cuenta de almacenamiento. Puedes activarla al crear la cuenta o actualizar una cuenta existente, pero la actualización es de un solo sentido: después no puedes volver a un espacio de nombres plano.
Cuando las carpetas que solo se imitaban con "/" en los nombres pasan a ser directorios reales, cambian dos cosas.
Operaciones atómicas de directorio: renombrar, mover o eliminar un directorio pasa a ser una sola actualización de la entrada del directorio principal. Con un espacio de nombres plano había que procesar uno a uno millones de blobs. Spark y Hive renombran las carpetas de salida temporales al final de cada trabajo, así que los trabajos de análisis terminan mucho antes. ACL compatibles con POSIX: además del RBAC de Azure, puedes asignar permisos detallados de lectura, escritura y ejecución a cada archivo y carpeta.
| Aspecto | Blob Storage (espacio de nombres plano) | Data Lake Storage Gen2 (espacio de nombres jerárquico) | |------|------|------| | Carpetas | Carpetas virtuales creadas con "/" en los nombres | Directorios reales | | Renombrar un directorio | Se procesan los blobs uno a uno | Una sola operación atómica | | Permisos detallados | Sobre todo a nivel de contenedor | ACL de POSIX por archivo y carpeta | | Uso principal | Almacenamiento de objetos que leen y escriben las aplicaciones | Análisis a gran escala con Databricks, Spark y herramientas similares |
Los niveles de acceso y la administración del ciclo de vida de Blob siguen funcionando, y OneLake de Microsoft Fabric está construido sobre Data Lake Storage Gen2.
Consejo para el examen: "Almacenamiento para análisis de big data que necesita permisos por carpeta y operaciones de directorio" → Data Lake Storage Gen2 con el espacio de nombres jerárquico activado.
---
Azure Files: recursos compartidos de archivos en la nube
Azure Files es el servidor de archivos de la oficina llevado a la nube. Varios equipos montan el mismo recurso compartido como una unidad de red y trabajan con él a la vez.
| Protocolo | Clientes compatibles | Requisitos | |------|------|------| | SMB | Windows, Linux, macOS | Disponible en HDD y en SSD | | NFS | Linux | Solo en el nivel de soporte SSD, con acceso mediante un punto de conexión privado o de servicio en una red virtual |
Hay dos niveles de soporte, SSD y HDD. Usa SSD cuando necesitas latencias de milisegundos de un solo dígito y HDD cuando importa más el coste. Los recursos compartidos HDD de pago por uso se dividen además en tres niveles de acceso: optimizado para transacciones, frecuente (hot) y esporádico (cool); cuanto más frío es el nivel, más bajo es el precio de almacenamiento y más alto el de las transacciones.
Capacidad: un solo archivo puede llegar a 4 TiB, y un recurso compartido de pago por uso puede crecer hasta 100 TiB. Azure File Sync: almacena en caché en un Windows Server local los archivos que más se usan y los sincroniza con el recurso compartido de Azure, de modo que las sucursales tienen acceso local rápido mientras los datos viven en la nube. Instantáneas: puedes crear hasta 200 copias de solo lectura a un momento dado por recurso compartido.
Consejo para el examen: "Un recurso compartido que los servidores Linux montan por NFS" → Azure Files en el nivel SSD. "Mantener en local los archivos más usados en el servidor de una sucursal mientras la copia maestra vive en Azure" → Azure File Sync.
---
Table Storage: PartitionKey y RowKey
Una tabla de Table Storage solo comparte el nombre con una tabla relacional. Es un almacén clave-valor sin esquema en el que cada fila (entidad) puede tener columnas distintas, y no tiene claves externas, relaciones, procedimientos almacenados ni vistas. Por eso los datos se suelen guardar desnormalizados, con todos los teléfonos y direcciones de un cliente en una sola fila.
Una entidad puede contener hasta 255 propiedades, incluidas las tres propiedades del sistema (PartitionKey, RowKey y Timestamp), y hasta 1 MiB de datos en total. Timestamp registra la hora de la última modificación; lo administra el servidor y los usuarios no pueden cambiarlo.
Diseño de claves y rendimie