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

Informationslager Sjöhus Power BI Datamart KQL-databas (Eventhouse)
Datavolym Obegränsat Obegränsat Upp till 100 GB Obegränsat
Typ av data Strukturerade Ostrukturerad, halvstrukturerad, strukturerad Strukturerade Ostrukturerad, halvstrukturerad, strukturerad
Primär utvecklarpersona Utvecklare av informationslager, SQL-tekniker Datatekniker, dataexpert Medborgarutvecklare Citizen Data Scientist, Data engineer, Data scientist, SQL Engineer
Primär kompetensuppsättning för utvecklare SQL Spark(Scala, PySpark, Spark SQL, R) Ingen kod, SQL Ingen kod, KQL, SQL
Data ordnade efter Databaser, scheman och tabeller Mappar och filer, databaser och tabeller Databas, tabeller, frågor Databaser, scheman och tabeller
Läsåtgärder T-SQL, Spark (stöder läsning från tabeller med genvägar, har ännu inte stöd för åtkomst till vyer, lagrade procedurer, fuctions osv.) Spark,T-SQL Spark,T-SQL,Power BI KQL, T-SQL, Spark, Power BI
Skrivåtgärder T-SQL Spark(Scala, PySpark, Spark SQL, R) Dataflöden, T-SQL KQL, Spark, anslutningsekosystem
Transaktioner med flera tabeller Ja No Nej Ja, för inmatning med flera tabeller. Se uppdateringsprincip.
Primärt utvecklingsgränssnitt SQL-skript Spark Notebooks,Spark-jobbdefinitioner Power BI KQL-frågeuppsättning, KQL-databas
Säkerhet Objektnivå (tabell, vy, funktion, lagrad procedur osv.), kolumnnivå, radnivå, DDL/DML, dynamisk datamaskering Radnivå, tabellnivå (när du använder T-SQL), ingen för Spark Inbyggd RLS-redigerare Säkerhet på radnivå
Få åtkomst till data via genvägar Ja (indirekt genom sjöhuset) Ja No Ja
Kan vara en källa för genvägar Ja (tabeller) Ja (filer och tabeller) Nej Ja
Fråga mellan objekt Ja, fråga över lakehouse- och lagertabeller Ja, fråga över lakehouse- och lagertabeller. fråga över lakehouses (inklusive genvägar med Spark) Nej Ja, fråga över KQL-databaser, lakehouses och lager med genvägar
Avancerad analys Inbyggda element i Time Series, fullständig geospatial lagring och frågefunktioner
Stöd för avancerad formatering Fullständig indexering för fritext och halvstrukturerade data som JSON
Svarstid för inmatning Inmatning i kö, streaminginmatning har ett par sekunders svarstid

Kommentar

Eventhouse är en arbetsyta för flera KQL-databaser. KQL Database är allmänt tillgänglig, medan Eventhouse är i förhandsversion. Mer information finns i Översikt över Eventhouse (förhandsversion).

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 informationslager som gör att teamet främst kan interagera med T-SQL, samtidigt som alla Spark-användare i organisationen kan komma åt data.

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 kan vara 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 KQL-databas 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.