Guía de decisiones de Microsoft Fabric: selección de un almacén de datos

  • Artículo

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

Almacenamiento de datos Lakehouse DataMart de Power BI Base de datos KQL (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 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í (indirectamente a través del almacén de lago) 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 (incluyendo los accesos directos mediante Spark) No Sí, consultar las bases de datos de KQL, los almacenes de lago y el almacenamiento con accesos directos
Análisis avanzado Elementos nativos de serie temporal, funcionalidades de consulta y almacenamiento geoespaciales completas
Soporte de formato avanzado Indexación completa para texto libre y datos semiestructurados, como JSON
Latencia de la ingesta La ingesta en cola y la ingesta de streaming tienen un par de segundos de latencia

Nota:

Eventhouse es un área de trabajo para varias bases de datos KQL. La base de datos KQL está disponible con carácter general, mientras que Eventhouse está en versión preliminar. Para más información, consulta Información general sobre Eventhouse (vista previa).

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.

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 una base de datos KQL 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.

Contenido relacionado