Guía

Los datos están organizados en un diseño tabular fijo con un esquema predefinido (filas y columnas), como un catálogo de productos o registros financieros.

→Representar como Datos Estructurados.

Por qué: Los datos estructurados se ajustan a un esquema rígido, ideal para bases de datos relacionales (OLTP). Contrastar con semiestructurados (JSON/XML) y no estructurados (imágenes/audio).

Los datos tienen cierta estructura organizativa (etiquetas, claves) pero carecen de un esquema rígido. Cada registro puede tener diferentes campos, como documentos JSON de sensores IoT.

→Representar como Datos Semi-estructurados (por ejemplo, JSON, XML).

Por qué: JSON y XML son autodescriptivos, ofreciendo flexibilidad sobre los esquemas fijos de los datos estructurados. Ideales para bases de datos NoSQL y data lakes.

Almacenar archivos grandes sin un esquema predefinido o estructura organizativa, como resonancias magnéticas, vídeos o grabaciones de audio.

→Representar como Datos No Estructurados.

Por qué: Este tipo de datos no puede almacenarse en bases de datos tradicionales de filas/columnas. Requiere almacenamiento de objetos como Azure Blob Storage.

Diferenciar entre cargas de trabajo para operaciones diarias versus análisis histórico.

→Utilizar OLTP (Online Transaction Processing) para transacciones de alto volumen y baja latencia (por ejemplo, pedidos de e-commerce). Utilizar OLAP (Online Analytical Processing) para consultas complejas sobre grandes conjuntos de datos históricos (por ejemplo, análisis de tendencias de ventas).

Por qué: Los sistemas OLTP están normalizados y optimizados para escrituras rápidas. Los sistemas OLAP están desnormalizados (esquema estrella) y optimizados para lecturas y agregaciones rápidas.

Elegir un patrón de integración de datos para un data warehouse.

→Utilizar ETL (Extract, Transform, Load) cuando la lógica de transformación es compleja y se realiza en un servidor de staging antes de la carga. Utilizar ELT (Extract, Load, Transform) para cargar datos brutos en un sistema de destino potente (por ejemplo, Synapse Analytics) y aprovechar su capacidad de cómputo para las transformaciones.

Por qué: ELT es el patrón de nube moderno, que aprovecha el cómputo escalable en el almacén de datos de destino (data warehouse/lakehouse) y simplifica la ingesta.

Asignación de responsabilidades para tareas de la plataforma de datos.

→Ingeniero de Datos: Construye y mantiene pipelines ETL/ELT. Administrador de Bases de Datos: Gestiona la seguridad, el rendimiento y la disponibilidad de la base de datos. Analista de Datos: Crea informes y visualizaciones (por ejemplo, Power BI) para obtener información de negocio.

Por qué: Los roles claramente definidos son esenciales. La distinción clave es construir (Ingeniero), gestionar (DBA) y analizar (Analista).

Procesar grandes volúmenes de datos con diferentes requisitos de latencia.

→Utilizar Procesamiento por Lotes para datos en reposo, procesados a intervalos programados (por ejemplo, informes nocturnos). Utilizar Procesamiento de Flujos para datos en movimiento, procesados continuamente a medida que llegan (por ejemplo, detección de fraude en tiempo real).

Por qué: La compensación clave es latencia vs. costo/rendimiento. El procesamiento de flujos proporciona baja latencia pero requiere recursos siempre activos. El procesamiento por lotes tiene alta latencia pero es rentable para grandes volúmenes.

Diseñar un esquema para un data warehouse que soporte consultas analíticas.

→Utilizar un Esquema en Estrella que consiste en una tabla de hechos central (que contiene medidas numéricas) conectada a múltiples tablas de dimensiones (que contienen atributos descriptivos).

Por qué: Esta estructura desnormalizada minimiza las uniones para consultas analíticas, mejorando el rendimiento en comparación con un esquema normalizado (OLTP). Es más simple y rápido para la mayoría de las herramientas de BI que un esquema de copo de nieve.

Elegir un repositorio central para análisis.

→Utilizar un Data Lake (por ejemplo, Azure Data Lake Storage) para almacenar grandes cantidades de datos brutos en su formato nativo (schema-on-read). Utilizar un Data Warehouse (por ejemplo, Synapse Dedicated SQL Pool) para almacenar datos estructurados y procesados para BI y reporting (schema-on-write).

Por qué: Los data lakes ofrecen flexibilidad para la ciencia de datos y la exploración de datos brutos. Los data warehouses proporcionan alto rendimiento y estructura para la inteligencia de negocio.

Necesita una base de datos relacional completamente administrada para una nueva aplicación nativa de la nube sin gestionar la infraestructura subyacente.

→Utilizar Azure SQL Database.

Por qué: Es una oferta PaaS con aplicación de parches, copias de seguridad y alta disponibilidad automáticas. Ideal para cargas de trabajo SQL estándar donde no se necesita acceso a nivel de sistema operativo.

Referencia↗

Migración lift-and-shift de una carga de trabajo de SQL Server local que utiliza características con ámbito de instancia como SQL Server Agent, consultas entre bases de datos o Service Broker.

→Utilizar Azure SQL Managed Instance.

Por qué: SQL MI proporciona una compatibilidad cercana al 100% con el motor de SQL Server local, minimizando los cambios de migración. Azure SQL Database no soporta estas características a nivel de instancia.

Referencia↗

Migrar una base de datos de SQL Server a Azure que requiere control total sobre el sistema operativo, versiones específicas de SQL Server o características con soporte PaaS limitado (por ejemplo, ciertos ensamblados CLR).

→Utilizar SQL Server en Máquinas Virtuales de Azure.

Por qué: Esta opción IaaS proporciona máxima compatibilidad y control, pero requiere que el usuario gestione el sistema operativo, la aplicación de parches y las copias de seguridad, a diferencia de las ofertas PaaS.

Una aplicación tiene patrones de uso intermitentes e impredecibles con largos periodos de inactividad. Es necesario minimizar los costos durante la inactividad.

→Utilizar el nivel de cómputo Serverless para Azure SQL Database.

Por qué: Serverless escala automáticamente el cómputo según la demanda y puede pausar automáticamente la base de datos, facturando solo el almacenamiento durante los períodos de inactividad. Ideal para cargas de trabajo variables.

Referencia↗

Alojar múltiples bases de datos pequeñas para diferentes inquilinos (SaaS) con cargas de trabajo variables. Es necesario compartir recursos para reducir costos.

→Utilizar grupos elásticos de Azure SQL Database.

Por qué: Los grupos elásticos permiten que múltiples bases de datos compartan un conjunto preasignado de recursos (DTU o vCores), proporcionando una solución rentable para aplicaciones multiinquilino.

Se espera que una base de datos crezca más allá de 4 TB (hasta 100 TB) y requiera un escalado rápido y copias de seguridad y restauraciones casi instantáneas, independientemente del tamaño.

→Utilizar el nivel de servicio Hyperscale para Azure SQL Database.

Por qué: Hyperscale utiliza una arquitectura distribuida única para bases de datos muy grandes (VLDBs), rompiendo los límites de tamaño de otros niveles y proporcionando operaciones de base de datos en tiempo constante.

Desplegar una base de datos PostgreSQL administrada para una aplicación de microservicios, que requiere alta disponibilidad redundante de zona y escalado independiente de cómputo y almacenamiento.

→Utilizar Azure Database for PostgreSQL - Flexible Server.

Por qué: Flexible Server es la oferta recomendada, proporcionando HA redundante de zona, ventanas de mantenimiento personalizadas y una mejor optimización de costos en comparación con el modelo Single Server anterior.

Proteger datos sensibles (por ejemplo, números de tarjetas de crédito) para que permanezcan cifrados en reposo, en tránsito Y en uso (en memoria) en el servidor. Incluso los DBAs no deberían ver los datos en texto claro.

→Utilizar Always Encrypted.

Por qué: Always Encrypted es una tecnología de cifrado del lado del cliente donde las claves son retenidas por el cliente, asegurando que los datos nunca se descifran en el servidor. TDE solo protege los datos en reposo.

Necesidad de ocultar datos sensibles a usuarios no privilegiados en los resultados de las consultas (por ejemplo, mostrar solo los últimos cuatro dígitos de un número de seguridad social) sin cambiar los datos almacenados.

→Utilizar Dynamic Data Masking.

Por qué: DDM aplica reglas de enmascaramiento en el momento de la consulta basadas en los permisos del usuario. Es una característica de seguridad para limitar la exposición de datos, no una característica de cifrado.

Asegurar la continuidad del negocio para un grupo de Azure SQL Databases habilitando la conmutación por error automática a una región secundaria en caso de una interrupción regional.

→Configurar un grupo de auto-conmutación por error.

Por qué: Los grupos de auto-conmutación por error proporcionan un endpoint de escucha unificado que redirige automáticamente el tráfico después de la conmutación por error, simplificando el diseño de la aplicación para DR. Proporciona un RPO/RTO más bajo que la restauración desde copias de seguridad geo-redundantes.

Necesidad de almacenar cantidades masivas de datos no estructurados, como archivos de vídeo, imágenes, copias de seguridad y registros, de una manera rentable.

→Utilizar Azure Blob Storage.

Por qué: Blob Storage es un servicio de almacenamiento de objetos optimizado para almacenar petabytes de datos no estructurados. No es adecuado para cargas de trabajo de consulta estructuradas.

Referencia↗

Optimizar los costos de almacenamiento para datos con patrones de acceso variables.

→Utilizar los niveles de acceso de Azure Blob Storage: Hot (acceso frecuente), Cool (acceso infrecuente, >30 días), Archive (acceso raro, >180 días).

Por qué: Los niveles ofrecen una compensación de costos: Hot tiene el costo de almacenamiento más alto pero el costo de acceso más bajo. Archive tiene el costo de almacenamiento más bajo pero el costo de acceso y la latencia de recuperación más altos (horas).

Mover blobs automáticamente entre los niveles Hot, Cool y Archive según su antigüedad o la última vez que se accedió a ellos para optimizar los costos.

→Configurar una política de gestión del ciclo de vida en la cuenta de almacenamiento.

Por qué: Esto automatiza el proceso de niveles, asegurando que los datos estén siempre en el nivel más rentable sin intervención manual.

Migrar una aplicación local que utiliza recursos compartidos de archivos SMB. Múltiples máquinas virtuales necesitan montar y acceder a la misma carpeta compartida.

→Utilizar Azure File Storage.

Por qué: Azure Files proporciona recursos compartidos de archivos completamente administrados en la nube accesibles a través de los protocolos SMB y NFS, lo que lo convierte en un reemplazo directo para los servidores de archivos locales.

Construir un data lake para análisis de big data que requiere operaciones eficientes a nivel de directorio y control de acceso granular similar a POSIX.

→Utilizar Azure Data Lake Storage Gen2.

Por qué: ADLS Gen2 se basa en Blob Storage añadiendo un espacio de nombres jerárquico (para operaciones atómicas de directorio) y soporte para ACLs compatibles con POSIX, que son críticas para el rendimiento y la seguridad en frameworks de big data como Spark.

Una aplicación global requiere latencia de lectura/escritura de un solo dígito de milisegundo, replicación automática multi-región y escalado horizontal para una base de datos NoSQL.

→Utilizar Azure Cosmos DB.

Por qué: Cosmos DB está diseñado para aplicaciones distribuidas globalmente y de misión crítica, proporcionando distribución global llave en mano, SLAs de baja latencia garantizada y múltiples modelos de consistencia.

Referencia↗

Elegir un modelo de datos y una API para una nueva aplicación de Cosmos DB.

→Utilizar API for NoSQL (documento), MongoDB API (documento), Apache Gremlin API (grafo), Table API (clave-valor) o Apache Cassandra API (columna ancha).

Por qué: Seleccionar la API que mejor se adapte a su modelo de datos y pila de aplicaciones existente. Utilizar NoSQL para nuevas aplicaciones basadas en JSON, Gremlin para datos con muchas relaciones y otras para migrar cargas de trabajo existentes (MongoDB, Cassandra, Table Storage).

Equilibrar la consistencia de lectura, la disponibilidad y el rendimiento para una aplicación de Cosmos DB.

→Elegir entre cinco niveles de consistencia: Strong, Bounded Staleness, Session (predeterminado), Consistent Prefix, Eventual.

Por qué: Strong proporciona la mayor consistencia pero la mayor latencia. Eventual proporciona la menor latencia pero la consistencia más débil. Session es el más común, garantizando que un usuario lea sus propias escrituras dentro de su sesión.

Un servicio descendente necesita reaccionar casi en tiempo real a cualquier dato creado o actualizado en un contenedor de Cosmos DB (por ejemplo, para actualizar un índice de búsqueda).

→Utilizar el feed de cambios de Cosmos DB.

Por qué: El feed de cambios proporciona un registro persistente y ordenado de los cambios. Comúnmente es consumido por una Azure Function para construir arquitecturas basadas en eventos sin sondear la base de datos.

Necesidad de ejecutar consultas analíticas complejas sobre datos operativos de Cosmos DB sin afectar el rendimiento de la carga de trabajo transaccional (HTAP).

→Habilitar el almacén analítico de Azure Cosmos DB y utilizar Azure Synapse Link.

Por qué: El almacén analítico es una representación columnar de sus datos transaccionales, completamente aislada y sincronizada automáticamente. Permite consultas analíticas a través de Synapse sin consumir Request Units (RUs) transaccionales.

Almacenar grandes cantidades de datos no relacionales simples y estructurados (por ejemplo, telemetría de dispositivos) para búsquedas rápidas basadas en claves a un costo muy bajo.

→Utilizar Azure Table Storage.

Por qué: Table Storage es un almacén de clave-valor NoSQL optimizado para búsquedas simples y de alto volumen con un PartitionKey y RowKey. Es significativamente más barato que Cosmos DB cuando no se requieren SLAs de baja latencia y distribución global.

Necesita un sistema de mensajería simple y confiable para desacoplar componentes de la aplicación, donde los mensajes se procesan asincrónicamente.

→Utilizar Azure Queue Storage.

Por qué: Queue Storage proporciona una cola de mensajes simple, rentable y confiable para patrones de comunicación asíncronos básicos.

Necesidad de construir, programar y monitorear flujos de trabajo complejos de integración de datos que mueven y transforman datos de diversas fuentes locales y en la nube.

→Utilizar Azure Data Factory (ADF).

Por qué: ADF es un servicio de orquestación en la nube administrado para construir y gestionar pipelines ETL/ELT a escala, con amplias capacidades de conectividad y monitoreo.

Referencia↗

Un pipeline de Azure Data Factory necesita acceder a una fuente de datos ubicada localmente detrás de un firewall corporativo.

→Instalar un Integration Runtime (IR) autoalojado en una máquina dentro de la red local.

Por qué: El IR autoalojado actúa como una puerta de enlace segura, permitiendo que ADF en la nube se conecte y mueva datos desde fuentes locales sin exponerlas a internet público.

Necesidad de una plataforma única e integrada para data warehousing (SQL), análisis de big data (Spark), exploración de datos (SQL sin servidor) e integración de datos.

→Utilizar Azure Synapse Analytics.

Por qué: Synapse proporciona un espacio de trabajo unificado (Synapse Studio) que reúne estos diferentes motores analíticos, reduciendo la complejidad y la sobrecarga de integración.

Elegir un motor de consultas SQL dentro de Synapse Analytics.

→Utilizar el pool de SQL Serverless para consultas ad-hoc y exploratorias sobre datos en el data lake con un modelo de pago por consulta. Utilizar el pool de SQL Dedicado para cargas de trabajo de data warehousing de alto rendimiento y predecibles con recursos aprovisionados.

Por qué: Serverless es para exploración y descubrimiento impredecibles. Dedicated es para BI de producción y reporting con SLAs de rendimiento.

Necesidad de procesar y analizar datos de streaming de alto volumen en tiempo real desde fuentes como IoT Hub o Event Hubs para alimentar dashboards en vivo o disparar alertas.

→Utilizar Azure Stream Analytics.

Por qué: Stream Analytics es un motor de procesamiento de eventos en tiempo real que utiliza un lenguaje de consulta simple similar a SQL para analizar datos en movimiento con baja latencia.

Un equipo de ciencia de datos necesita un entorno colaborativo basado en notebooks para ingeniería de datos a gran escala y aprendizaje automático utilizando Apache Spark.

→Utilizar Azure Databricks.

Por qué: Databricks proporciona un tiempo de ejecución de Spark optimizado, notebooks colaborativos y capacidades de ML integradas (MLflow), convirtiéndolo en la plataforma principal para análisis avanzados y ML en Azure.

Necesidad de ingerir millones de eventos por segundo desde fuentes como aplicaciones móviles, telemetría web o dispositivos IoT para procesamiento en tiempo real.

→Utilizar Azure Event Hubs.

Por qué: Event Hubs es una plataforma de streaming de big data diseñada para la ingesta de eventos de alto rendimiento. Actúa como la "puerta de entrada" para los datos de streaming, desacoplando productores de consumidores.

Una organización desea una plataforma de análisis SaaS única y unificada que combine ingeniería de datos, ciencia de datos, data warehousing y BI con una gestión mínima de la infraestructura.

→Utilizar Microsoft Fabric.

Por qué: Fabric proporciona una experiencia de análisis de extremo a extremo basada en SaaS, construida sobre un único data lake (OneLake). Simplifica la arquitectura y reduce la sobrecarga de integración en comparación con la construcción con servicios PaaS separados.

Referencia↗

Dentro de Microsoft Fabric, se necesita un único artefacto para almacenar datos en formato abierto Delta Lake que pueda ser accedido tanto por motores Spark (para ingeniería de datos) como por motores SQL (para BI).

→Utilizar un Microsoft Fabric Lakehouse.

Por qué: El Lakehouse es el patrón arquitectónico central en Fabric. Combina la escalabilidad y flexibilidad de un data lake con las garantías transaccionales y las capacidades de consulta SQL de un data warehouse.

Un informe de Power BI en Microsoft Fabric necesita consultar grandes volúmenes de datos directamente desde OneLake con el rendimiento del modo de importación pero la frescura de los datos de DirectQuery.

→Utilizar el modo Direct Lake en Power BI.

Por qué: Direct Lake es una característica única de Fabric que carga archivos Parquet/Delta directamente en la memoria del motor de Power BI bajo demanda, evitando la duplicación de datos y la latencia de las consultas, al tiempo que proporciona acceso a datos casi en tiempo real.

Los usuarios de negocio necesitan conectarse a diversas fuentes de datos, crear dashboards e informes interactivos y compartir información en toda la organización.

→Utilizar Power BI.

Por qué: Power BI es el servicio de análisis de negocio de Microsoft para construir visualizaciones de datos interactivas. Utilizar Power BI Desktop para la creación y Power BI Service para compartir y colaborar.

Diferenciar entre un análisis interactivo de varias páginas y una visión general de alto nivel de una sola página en Power BI.

→Un Informe es una colección de varias páginas de elementos visuales detallados e interactivos construidos a partir de un único conjunto de datos. Un Dashboard es un lienzo único de mosaicos anclados de uno o más informes, que proporciona una vista de un vistazo.

Por qué: Los informes son para análisis en profundidad. Los dashboards son para monitorear métricas clave.

Un único informe de Power BI debe compartirse con varios usuarios, pero cada usuario solo debe ver los datos relevantes para ellos (por ejemplo, un gerente de ventas ve solo los datos de su región).

→Implementar Seguridad a Nivel de Fila (RLS).

Por qué: RLS define reglas de filtro basadas en roles de usuario, aplicando la seguridad de los datos a nivel del modelo de datos para que los usuarios que acceden al mismo informe vean diferentes subconjuntos de datos.

Necesidad de generar informes altamente formateados y con una precisión de píxel (como facturas o estados financieros) optimizados para impresión o exportación a PDF.

→Utilizar Power BI Paginated Reports.

Por qué: Los informes paginados están diseñados para diseños listos para imprimir con control preciso sobre encabezados, pies de página y saltos de página, a diferencia de los informes interactivos estándar de Power BI que son para exploración en pantalla.

Un conjunto de datos de Power BI que contiene miles de millones de filas tarda demasiado en actualizarse. Solo los últimos días de datos cambian con frecuencia.

→Configurar la actualización incremental en el conjunto de datos.

Por qué: La actualización incremental particiona los datos (generalmente por fecha) y solo actualiza las particiones más recientes, reduciendo drásticamente el tiempo de actualización y el uso de recursos para grandes conjuntos de datos.

Un único informe de Power BI necesita combinar datos precargados de alto rendimiento (modo Import) con datos en tiempo real de una fuente operativa (modo DirectQuery).

→Utilizar modelos compuestos de Power BI.

Por qué: Los modelos compuestos permiten que un único conjunto de datos mezcle tablas con diferentes modos de almacenamiento, proporcionando la flexibilidad para equilibrar el rendimiento y la frescura de los datos.

Una organización necesita descubrir, clasificar y catalogar todos los activos de datos en su patrimonio de datos híbrido para permitir la gobernanza y el descubrimiento de datos.

→Utilizar Microsoft Purview.

Por qué: Purview es un servicio unificado de gobernanza de datos que proporciona escaneo automático de datos, un glosario de negocio, clasificación de datos y visualización de linaje de datos de extremo a extremo.