Beslutsguide för Microsoft Fabric: välj ett datalager
Använd den här referensguiden och exempelscenarier som hjälper dig att välja ett datalager för dina Microsoft Fabric-arbetsbelastningar.
Egenskaper för datalager
Använd den här informationen för att jämföra Infrastrukturdatalager som lager, lakehouse, Eventhouse, SQL-databas och Power BI-datamart, baserat på datavolym, typ, utvecklarpersona, kompetensuppsättning, åtgärder och andra funktioner. Dessa jämförelser är ordnade i följande två tabeller:
| Sjöhus | Dist.lager | Händelsehus | |
|---|---|---|---|
| Datavolym | Obegränsat | Obegränsat | Obegränsat |
| Typ av data | Ostrukturerat halvstrukturerad, strukturerad |
Strukturerad halvstrukturerad (JSON) |
Ostrukturerat halvstrukturerad, strukturerad |
| Primär utvecklarpersona | Datatekniker, dataexpert | Datalagerutvecklare, dataarkitekt, datatekniker, databasutvecklare | Apputvecklare, dataexpert, datatekniker |
| Primär utvecklingsfärdighet | Spark (Scala, PySpark, Spark SQL, R) | SQL | Ingen kod, KQL, SQL |
| Data ordnade efter | Mappar och filer, databaser och tabeller | Databaser, scheman och tabeller | Databaser, scheman och tabeller |
| Läsåtgärder | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Skrivåtgärder | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, anslutningsekosystem |
| Transaktioner med flera tabeller | Nej | Ja | Ja, för inmatning med flera tabeller |
| Primärt utvecklingsgränssnitt | Spark-notebook-filer, Spark-jobbdefinitioner | SQL-skript | KQL-frågeuppsättning, KQL-databas |
| Säkerhet | RLS, CLS**, tabellnivå (T-SQL), ingen för Spark | Objektnivå, RLS, CLS, DDL/DML, dynamisk datamaskering | RLS |
| Få åtkomst till data via genvägar | Ja | Ja | Ja |
| Kan vara en källa för genvägar | Ja (filer och tabeller) | Ja (tabeller) | Ja |
| Fråga mellan objekt | Ja | Ja | Ja |
| Avancerad analys | Gränssnitt för storskalig databearbetning, inbyggd dataparallellitet och feltolerans | Gränssnitt för storskalig databearbetning, inbyggd dataparallellitet och feltolerans | Inbyggda element i Time Series, fullständiga geo-spatiala funktioner och frågefunktioner |
| Stöd för avancerad formatering | Tabeller som definieras med PARQUET, CSV, AVRO, JSON och alla Apache Hive-kompatibla filformat | Tabeller som definieras med PARQUET, CSV, AVRO, JSON och alla Apache Hive-kompatibla filformat | Fullständig indexering för fritext och halvstrukturerade data som JSON |
| Svarstid för inmatning | Tillgänglig direkt för frågor | Tillgänglig direkt för frågor | Inmatning i kö, strömmande inmatning har ett par sekunders svarstid |
* Spark stöder läsning från tabeller med hjälp av genvägar, har ännu inte stöd för åtkomst till vyer, lagrade procedurer, funktioner osv.
| Infrastruktur för SQL-databas | Power BI Datamart | |
|---|---|---|
| Datavolym | 4 TB | Upp till 100 GB |
| Typ av data | Strukturerad halvstrukturerad, ostrukturerat |
Strukturerade |
| Primär utvecklarpersona | AI-utvecklare, apputvecklare, databasutvecklare, DB-administratör | Dataexpert, dataanalytiker |
| Primär utvecklingsfärdighet | SQL | Ingen kod, SQL |
| Data ordnade efter | Databaser, scheman, tabeller | Databas, tabeller, frågor |
| Läsåtgärder | T-SQL | Spark, T-SQL |
| Skrivåtgärder | T-SQL | Dataflöden, T-SQL |
| Transaktioner med flera tabeller | Ja, fullständig ACID-efterlevnad | Nej |
| Primärt utvecklingsgränssnitt | SQL-skript | Power BI |
| Säkerhet | Objektnivå, RLS, CLS, DDL/DML, dynamisk datamaskering | Inbyggd RLS-redigerare |
| Få åtkomst till data via genvägar | Ja | Nej |
| Kan vara en källa för genvägar | Ja (tabeller) | Nej |
| Fråga mellan objekt | Ja | Nej |
| Avancerad analys | T-SQL-analysfunktioner, data som replikeras till deltaparquet i OneLake för analys | Gränssnitt för databearbetning med automatiserad prestandajustering |
| Stöd för avancerad formatering | Tabellstöd för OLTP, JSON, vektor, graf, XML, rumslig, nyckelvärde | Tabeller som definieras med PARQUET, CSV, AVRO, JSON och alla Apache Hive-kompatibla filformat |
| Svarstid för inmatning | Tillgänglig direkt för frågor | Tillgänglig direkt för frågor |
** Säkerhet på kolumnnivå som är tillgänglig på Lakehouse via en SQL-analysslutpunkt med hjälp av T-SQL.
Scenarier
Läs de här scenarierna om du vill ha hjälp med att välja ett datalager i Fabric.
Scenario 1
Susan, en professionell utvecklare, är ny i Microsoft Fabric. De är redo att komma igång med att rensa, modellera och analysera data, men de måste bestämma sig för att skapa ett informationslager eller ett sjöhus. Efter granskning av informationen i föregående tabell är de primära beslutspunkterna den tillgängliga kunskapsuppsättningen och behovet av transaktioner med flera tabeller.
Susan har ägnat många år åt att skapa informationslager på relationsdatabasmotorer och är bekant med SQL-syntax och funktioner. När man tänker på det större teamet är de primära konsumenterna av dessa data också skickliga med SQL- och SQL-analysverktyg. Susan bestämmer sig för att använda ett Infrastrukturlager, vilket gör att teamet främst kan interagera med T-SQL, samtidigt som alla Spark-användare i organisationen kan komma åt data.
Susan skapar ett nytt informationslager och interagerar med det med hjälp av T-SQL precis som sina andra SQL Server-databaser. Det mesta av den befintliga T-SQL-kod som hon har skrivit för att bygga sitt lager på SQL Server fungerar på infrastrukturdatalagret, vilket gör övergången enkel. Om hon väljer att göra det kan hon till och med använda samma verktyg som fungerar med hennes andra databaser, till exempel SQL Server Management Studio. Med SQL-redigeraren i Fabric-portalen skriver Susan och andra teammedlemmar analytiska frågor som refererar till andra datavaruhus och Delta-tabeller i lakehouses genom att använda tredelade namn för att utföra frågor mellan databaser.
Scenario 2
Rob, en datatekniker, måste lagra och modellera flera terabyte data i Fabric. Teamet har en blandning av PySpark- och T-SQL-kunskaper. De flesta i teamet som kör T-SQL-frågor är konsumenter och behöver därför inte skriva INSERT-, UPDATE- eller DELETE-instruktioner. De återstående utvecklarna är bekväma med att arbeta i notebook-filer, och eftersom data lagras i Delta kan de interagera med en liknande SQL-syntax.
Rob bestämmer sig för att använda ett lakehouse, vilket gör att datateknikteamet kan använda sina olika kunskaper mot data, samtidigt som teammedlemmarna som är mycket skickliga i T-SQL kan använda data.
Scenario 3
Ash, en medborgarutvecklare, är power BI-utvecklare. De är bekanta med Excel, Power BI och Office. De måste skapa en dataprodukt för en affärsenhet. De vet att de inte riktigt har färdigheter för att bygga ett informationslager eller ett sjöhus, och de verkar vara för mycket för deras behov och datavolymer. De granskar informationen i föregående tabell och ser att de primära beslutspunkterna är deras egna kunskaper och deras behov av självbetjäning, ingen kodfunktion och datavolym under 100 GB.
Ash arbetar med affärsanalytiker som är bekanta med Power BI och Microsoft Office och vet att de redan har en Premium-kapacitetsprenumeration. När de tänker på sitt större team inser de att de primära konsumenterna av dessa data är analytiker, bekanta med verktyg utan kod och SQL-analysverktyg. Ash bestämmer sig för att använda en Power BI-datamart, vilket gör att teamet kan interagera snabbt och skapa funktionen med hjälp av en upplevelse utan kod. Frågor kan köras via Power BI och T-SQL, samtidigt som alla Spark-användare i organisationen även kan komma åt data.
Scenario 4
Daisy är affärsanalytiker med erfarenhet av att använda Power BI för att analysera flaskhalsar i leveranskedjan för en stor global detaljhandelskedja. De måste skapa en skalbar datalösning som kan hantera miljarder rader med data och som kan användas för att skapa instrumentpaneler och rapporter som kan användas för att fatta affärsbeslut. Data kommer från anläggningar, leverantörer, speditörer och andra källor i olika strukturerade, halvstrukturerade och ostrukturerade format.
Daisy bestämmer sig för att använda en Eventhouse på grund av dess skalbarhet, snabba svarstider, avancerade analysfunktioner, inklusive tidsserieanalys, geospatiala funktioner och snabbt direktfrågeläge i Power BI. Frågor kan köras med Hjälp av Power BI och KQL för att jämföra aktuella och tidigare perioder, snabbt identifiera nya problem eller tillhandahålla geo-spatial analys av land- och sjövägar.
Scenario 5
Kirby är en programarkitekt med erfarenhet av att utveckla .NET-program för driftdata. De behöver en databas med hög samtidighet med fullständig ACID-transaktionsefterlevnad och starkt framtvingade sekundärnycklar för relationsintegritet. Kirby vill ha fördelen med automatisk prestandajustering för att förenkla den dagliga databashanteringen.
Kirby bestämmer sig för en SQL-databas i Fabric med samma SQL Database-motor som Azure SQL Database. SQL-databaser i Fabric skalas automatiskt för att möta efterfrågan under hela arbetsdagen. De har fullständig kapacitet för transaktionstabeller och flexibiliteten i transaktionsisoleringsnivåer från serialiserbar till läsbar ögonblicksbild. SQL-databasen i Fabric skapar och släpper automatiskt icke-illustrerade index baserat på starka signaler från körningsplaner som observerats över tid.
I Kirbys scenario måste data från det operativa programmet kopplas till andra data i Infrastruktur: i Spark, i ett lager och från realtidshändelser i ett Eventhouse. Varje Fabric-databas innehåller en SQL-analysslutpunkt, så att data kan nås i realtid från Spark eller med Power BI-frågor med DirectLake-läge. De här rapporteringslösningarna besparar den primära driftdatabasen från kostnaderna för analytiska arbetsbelastningar och undviker avnormalisering. Kirby har också befintliga driftdata i andra SQL-databaser och måste importera dessa data utan transformering. Om du vill importera befintliga driftdata utan någon datatypkonvertering utformar Kirby datapipelines med Fabric Data Factory för att importera data till Fabric SQL-databasen.