Guía de decisiones de Microsoft Fabric: selección de un almacén de datos
Use esta guía de referencia y los escenarios de ejemplo para ayudarle a elegir entre el almacén de datos para las cargas de trabajo de Microsoft Fabric.
Propiedades del almacén de datos
Use esta información para comparar almacenes de datos de Fabric, como almacén de datos, almacén de lago de datos, centro de eventos,base de datos SQL y datamart de Power BI, en función del volumen de datos, el tipo, el rol de desarrollador, el conjunto de aptitudes, las operaciones y otras funcionalidades. Estas comparaciones se organizan en las dos tablas siguientes:
| Lakehouse | Almacén | Eventhouse | |
|---|---|---|---|
| Volumen de datos | Sin límite | Sin límite | Sin límite |
| Tipo de datos | Datos no estructurados, semiestructurados, estructurados |
Estructurados | Datos no estructurados, semiestructurados, estructurados |
| Rol de desarrollador principal | Ingeniero de datos, científico de datos | Desarrollador de almacenamiento de datos, arquitecto de datos, desarrollador de bases de datos | Desarrollador de aplicaciones, científico de datos, ingeniero de datos |
| Aptitud de desarrollo principal | Spark(Scala, PySpark, Spark SQL, R) | SQL | Sin código, KQL, SQL |
| Datos organizados por | Carpetas y archivos, bases de datos y tablas | Bases de datos, esquemas y tablas | Bases de datos, esquemas y tablas |
| Lee operaciones. | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Operaciones de escritura | Spark(Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, ecosistema de conectores |
| Transacciones de varias tablas | No | Sí | Sí, para la ingesta de varias tablas. |
| Interfaz de desarrollo principal | Cuadernos de Spark, definiciones de trabajo de Spark | Scripts de SQL | Conjunto de consultas KQL, base de datos KQL |
| Seguridad | RLS, CLS**, nivel de tabla (T-SQL), ninguno para Spark | Nivel de objeto, RLS, CLS, DDL/DML, enmascaramiento dinámico de datos | RLS |
| Acceso a datos a través de accesos directos | Sí | Sí | Sí |
| Puede ser un origen para los accesos directos | Sí (archivos y tablas) | Sí (tablas) | Sí |
| Consulta entre elementos | Sí | Sí | Sí |
| Análisis avanzado | Interfaz para el procesamiento de datos a gran escala, paralelismo de datos integrado y tolerancia a errores | Interfaz para el procesamiento de datos a gran escala, paralelismo de datos integrado y tolerancia a errores | Elementos nativos de serie temporal, funcionalidades de consulta y geoespaciales completas |
| Soporte de formato avanzado | Las tablas definidas mediante PARQUET, CSV, AVRO, JSON y cualquier formato de archivo compatible con Apache Hive. | Las tablas definidas mediante PARQUET, CSV, AVRO, JSON y cualquier formato de archivo compatible con Apache Hive. | Indexación completa para texto libre y datos semiestructurados, como JSON |
| Latencia de la ingesta | Disponible al instante para realizar consultas | Disponible al instante para realizar consultas | La ingesta en cola y la ingesta de streaming tienen un par de segundos de latencia |
*Spark admite la lectura desde tablas mediante accesos directos, no admite aún el acceso a vistas, procedimientos almacenados, funciones, etc.
| Base de datos SQL de Fabric | DataMart de Power BI | |
|---|---|---|
| Volumen de datos | 4 TB | Hasta 100 GB |
| Tipo de datos | Estructurados, semiestructurados, no estructurado |
Estructurados |
| Rol de desarrollador principal | Desarrollador de IA, desarrollador de aplicaciones, desarrollador de bases de datos, administrador de base de datos | Científico de datos, analista de datos |
| Aptitud de desarrollo principal | SQL | Sin código, SQL |
| Datos organizados por | Bases de datos, esquemas, tablas | Base de datos, tablas, consultas |
| Lee operaciones. | T-SQL | Spark, T-SQL |
| Operaciones de escritura | T-SQL | Flujos de datos, T-SQL |
| Transacciones de varias tablas | Sí, cumplimiento completo de ACID | No |
| Interfaz de desarrollo principal | Scripts de SQL | Power BI |
| Seguridad | Nivel de objeto, RLS, CLS, DDL/DML, enmascaramiento dinámico de datos | Editor RLS integrado |
| Acceso a datos a través de accesos directos | Sí | No |
| Puede ser un origen para los accesos directos | Sí (tablas) | No |
| Consulta entre elementos | Sí | No |
| Análisis avanzado | Funcionalidades analíticas de T-SQL, datos replicados en parquet delta en OneLake para análisis | Interfaz para el procesamiento de datos con optimización automatizada del rendimiento |
| Soporte de formato avanzado | Compatibilidad de tablas con OLTP, JSON, vector, grafo, XML, espacial, clave-valor | Las tablas definidas mediante PARQUET, CSV, AVRO, JSON y cualquier formato de archivo compatible con Apache Hive. |
| Latencia de la ingesta | Disponible al instante para realizar consultas | Disponible al instante para realizar consultas |
**Seguridad de nivel de columna disponible en almacén de lago a través de un punto de conexión de análisis SQL mediante T-SQL.
Escenarios
Revise estos escenarios para obtener ayuda con la elección de un almacén datos en Fabric.
Escenario 1
Susan, desarrolladora profesional, es nueva en Microsoft Fabric. Están listos para empezar a limpiar, modelar y analizar datos, pero deben decidir si crear un almacenamiento de datos o un almacén de lago. Después de revisar los detalles de la tabla anterior, los puntos de decisión principales son el conjunto de aptitudes disponible y la necesidad de transacciones de varias tablas.
Susan ha dedicado muchos años a crear almacenes de datos en motores de base de datos relacionales y está familiarizado con la funcionalidad y sintaxis de SQL. Pensando en el equipo más grande, los principales consumidores de estos datos también están cualificados con SQL y las herramientas analíticas de SQL. Susan decide usar un almacenamiento de datos de Fabric, que permite al equipo interactuar principalmente con T-SQL, a la vez que permite a los usuarios de Spark de la organización acceder a los datos.
Susan crea una nueva instancia de almacén de lago y accede a las funcionalidades del almacenamiento de datos con el punto de conexión de análisis SQL de almacén de lago. Mediante el portal de Fabric, crea accesos directos a las tablas de datos externos y los coloca en la carpeta /Tables. Susan ya puede escribir consultas de T-SQL que hagan referencia a los accesos directos para consultar los datos de Delta Lake en el almacén de lago. Los accesos directos aparecen automáticamente como tablas en el punto de conexión de análisis SQL y se pueden consultar con T-SQL mediante nombres de tres partes.
Escenario 2
Rob, ingeniero de datos, necesita almacenar y modelar varios terabytes de datos en Fabric. El equipo tiene una combinación de aptitudes de PySpark y T-SQL. La mayoría de los equipos que ejecutan consultas de T-SQL son consumidores y, por lo tanto, no es necesario escribir instrucciones INSERT, UPDATE o DELETE. Los desarrolladores restantes están cómodos trabajando en cuadernos y, dado que los datos se almacenan en Delta, pueden interactuar con una sintaxis SQL similar.
Rob decide usar un almacén de lago, el cual permite al equipo de ingeniería de datos usar sus diversas aptitudes con respecto a los datos, al tiempo que permite a los miembros del equipo altamente cualificados en T-SQL consumir los datos.
Escenario 3
Ash, desarrollador civil, es un desarrollador de Power BI. Están familiarizados con Excel, Power BI y Office. Necesitan crear un producto de datos para una unidad de negocio. Saben que no tienen las aptitudes para crear un almacenamiento de datos o un almacén de lago, y parecen demasiado para sus necesidades y volúmenes de datos. Revisan los detalles de la tabla anterior y ven que los puntos de decisión principales son sus propias aptitudes y su necesidad de autoservicio, sin capacidad de programar y volumen de datos inferior a 100 GB.
Ash trabaja con analistas de negocios familiarizados con Power BI y Microsoft Office, y sabe que ya tienen una suscripción de capacidad Premium. A medida que piensan en que su equipo sea más grande, se dan cuenta de que los consumidores principales de estos datos son analistas, familiarizados con herramientas analíticas de SQL y que no programan. Ash decide usar un datamart de Power BI, que permite al equipo interactuar rápidamente con la compilación de la capacidad a través de una experiencia sin código. Las consultas se pueden ejecutar a través de Power BI y T-SQL, al mismo tiempo que permiten a los usuarios de Spark de la organización acceder también a los datos.
Escenario 4
Daisy es una analista de negocios con experiencia en el uso de Power BI para analizar los cuellos de botella de la cadena de suministro para una gran cadena minorista global. Necesitan crear una solución de datos escalable que pueda controlar miles de millones de filas de datos y se puedan usar para crear paneles e informes y tomar decisiones empresariales. Los datos proceden de plantas, proveedores, transportistas y otras fuentes en diversos formatos estructurados, semiestructurados y no estructurados.
Daisy decide usar un centro de eventos debido a su escalabilidad, tiempo de respuesta rápido, funcionalidades de análisis avanzadas, como análisis de series temporales, funciones geoespaciales y el modo de consulta directa rápida en Power BI. Las consultas se pueden ejecutar mediante Power BI y KQL para comparar entre los períodos actuales y anteriores, identificar rápidamente problemas emergentes o proporcionar análisis geoespaciales de rutas terrestres y marítimas.
Escenario 5
Kirby es un arquitecto de aplicaciones experimentado en el desarrollo de aplicaciones .NET para datos operativos. Necesitan una base de datos de alta simultaneidad con cumplimiento completo de transacciones ACID y claves externas fuertemente aplicadas para la integridad relacional. Kirby quiere la ventaja del ajuste automático del rendimiento para simplificar la administración de bases de datos diarias.
Kirby se decanta por una base de datos SQL en Fabric, con el mismo motor de base de datos SQL que la base de datos de Azure SQL. Las bases de datos SQL de Fabric se escalan automáticamente para satisfacer la demanda durante todo el día laborable. Tienen la capacidad completa de las tablas transaccionales y la flexibilidad de los niveles de aislamiento de transacciones de serializables a instantáneas confirmadas de lectura. La base de datos SQL en Fabric crea y quita automáticamente índices no agrupados en función de señales seguras de los planes de ejecución observados a lo largo del tiempo.
En el escenario de Kirby, los datos de la aplicación operativa deben unirse a otros datos de Fabric: en Spark, en un almacenamiento y desde eventos en tiempo real en un centro de eventos. Cada base de datos de Fabric incluye un punto de conexión de análisis SQL, por lo que los datos a los que se accede en tiempo real desde Spark o con consultas de Power BI mediante el modo DirectLake. Estas soluciones de informes ahorran a la base de datos operativa principal la sobrecarga de las cargas de trabajo analíticas y evitan la desnormalización. Kirby también tiene datos operativos existentes en otras bases de datos SQL y necesita importar esos datos sin transformación. Para importar datos operativos existentes sin ninguna conversión de tipos de datos, Kirby diseña canalizaciones de datos con Fabric Data Factory para importar datos en la base de datos SQL de Fabric.