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.
Relaterat innehåll
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för