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
En esta tabla se comparan almacenes de datos como Warehouse, Lakehouse, DataMart de Power BI y Eventhouse en función del volumen de datos, tipo, rol de desarrollador, conjunto de aptitudes, operaciones. y otras capacidades.
| Almacén | Lakehouse | DataMart de Power BI | Eventhouse | |
|---|---|---|---|---|
| Volumen de datos | Sin límite | Sin límite | Hasta 100 GB | Sin límite |
| Tipo de datos | Estructurados | No estructurados, semiestructurados, estructurados | Estructurados | No estructurados, semiestructurados, estructurados |
| Rol de desarrollador principal | Desarrollador de almacenamiento de datos, ingeniero de SQL | Ingeniero de datos, científico de datos | Desarrollador civil | Científico de datos civil, ingeniero de datos, científico de datos, ingeniero de SQL |
| Conjunto de aptitudes de desarrollador principal | SQL | Spark(Scala, PySpark, Spark SQL, R) | Sin código, SQL | Sin código, KQL, SQL |
| Datos organizados por | Bases de datos, esquemas y tablas | Carpetas y archivos, bases de datos y tablas | Base de datos, tablas, consultas | Bases de datos, esquemas y tablas |
| Lee operaciones. | T-SQL, Spark (admite la lectura de tablas mediante accesos directos, aún no admite el acceso a vistas, procedimientos almacenados, funciones, etc.) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| Operaciones de escritura | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Flujos de datos, T-SQL | KQL, Spark, ecosistema de conectores |
| Transacciones de varias tablas | Sí | No | No | Sí, para la ingesta de varias tablas. Consulte la directiva de actualización. |
| Interfaz de desarrollo principal | Scripts de SQL | Cuadernos de Spark, definiciones de trabajos de Spark | Power BI | Conjunto de consultas KQL, base de datos KQL |
| Seguridad | Nivel de objeto (tabla, vista, función, procedimiento almacenado, etc.), nivel de columna, nivel de fila, DDL/DML, enmascaramiento de datos dinámico | Nivel de fila, nivel de columna (para el lakehouse al que se accede a través de un punto de conexión de análisis SQL), nivel de tabla (cuando se usa T-SQL), ninguno para Spark | Editor RLS integrado | Seguridad de filas |
| Acceso a datos a través de accesos directos | Sí, a través de un almacén de lago con nombres de tres partes | Sí | No | Sí |
| Puede ser un origen para los accesos directos | Sí (tablas) | Sí (archivos y tablas) | No | Sí |
| Consulta entre elementos | Sí, consultar tablas de almacén de lago y almacenamiento | Sí, consultar tablas de almacén de lago y almacenamiento; consultar entre los almacenes de lago (incluidos los accesos directos mediante Spark) | No | Sí, consultar las bases de datos de KQL, los almacenes de lago y el almacenamiento con accesos directos |
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, 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 del lakehouse y accede a las capacidades del almacenamiento de datos con el punto de conexión de análisis SQL del lakehouse. 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 podrían ser 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 almacén 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.