Beslissingshandleiding voor Microsoft Fabric: een gegevensarchief kiezen

Gebruik deze referentiehandleiding en de voorbeeldscenario's om u te helpen bij het kiezen van een gegevensarchief voor uw Microsoft Fabric-workloads, die allemaal beschikbaar zijn in een geïntegreerde opslag in OneLake.

Persona's en vaardighedensets

Scenariën

Bekijk deze scenario's voor hulp bij het kiezen van een gegevensarchief in Fabric.

Scenario 1

Susan, een professionele ontwikkelaar, is nieuw in Microsoft Fabric. Ze zijn klaar om aan de slag te gaan met het opschonen, modelleren en analyseren van gegevens, maar moeten beslissen om een datawarehouse of een lakehouse te bouwen. Na beoordeling van de details in de vorige tabel zijn de belangrijkste beslissingspunten de beschikbare vaardighedenset en de behoefte aan transacties met meerdere tabellen.

Susan heeft vele jaren datawarehouses gebouwd op relationele database-engines en is bekend met sql-syntaxis en -functionaliteit. Denk na over het grotere team, de primaire gebruikers van deze gegevens zijn ook ervaren met SQL- en SQL-analytische hulpprogramma's. Susan besluit een Fabric-magazijn te gebruiken, waardoor het team voornamelijk kan communiceren met T-SQL, terwijl ook spark-gebruikers in de organisatie toegang hebben tot de gegevens.

Susan maakt een nieuw datawarehouse en communiceert ermee met behulp van T-SQL, net als haar andere SQL Server-databases. De meeste bestaande T-SQL-code die ze heeft geschreven om haar magazijn op SQL Server te bouwen, werkt in het datawarehouse fabric, waardoor de overgang eenvoudig is. Als ze ervoor kiest, kan ze zelfs dezelfde hulpprogramma's gebruiken die met haar andere databases werken, zoals SQL Server Management Studio. Met behulp van de SQL-editor in de Fabric-portal schrijven Susan en andere teamleden analytische query's die verwijzen naar andere datawarehouses en Delta-tabellen in lakehouses door gebruik te maken van driedelige namen om query's tussen databases uit te voeren.

Scenario 2

Rob, een data engineer, moet verschillende terabytes aan gegevens opslaan en modelleren in Fabric. Het team heeft een combinatie van PySpark- en T-SQL-vaardigheden. De meeste teamleden die T-SQL-query's uitvoeren zijn consumenten en hoeven daarom geen INSERT-, UPDATE- of DELETE-instructies te schrijven. De resterende ontwikkelaars werken in notebooks en omdat de gegevens zijn opgeslagen in Delta, kunnen ze communiceren met een vergelijkbare SQL-syntaxis.

Rob besluit een lakehousete gebruiken, waardoor het data engineering-team hun uiteenlopende vaardigheden op de gegevens kan toepassen, terwijl het voor de teamleden die zeer ervaren zijn in T-SQL mogelijk is de gegevens te benutten.

Scenario 3

Daisy is bedrijfsanalist die ervaring heeft met het gebruik van Power BI voor het analyseren van knelpunten in de toeleveringsketen voor een grote wereldwijde retailketen. Ze moeten een schaalbare gegevensoplossing bouwen die miljarden rijen met gegevens kan verwerken en kan worden gebruikt om dashboards en rapporten te bouwen die kunnen worden gebruikt om zakelijke beslissingen te nemen. De gegevens zijn afkomstig van planten, leveranciers, verzenders en andere bronnen in verschillende gestructureerde, semi-gestructureerde en ongestructureerde indelingen.

Daisy besluit een Eventhouse- te gebruiken vanwege de schaalbaarheid, snelle reactietijden, geavanceerde analysemogelijkheden, waaronder tijdreeksanalyse, georuimtelijke functies en snelle directe querymodus in Power BI. Query's kunnen worden uitgevoerd met Behulp van Power BI en KQL om te vergelijken tussen de huidige en vorige perioden, snel opkomende problemen te identificeren of geo-ruimtelijke analyses van land- en maritieme routes te bieden.

Scenario 4

Kirby is een toepassingsarchitect die ervaring heeft met het ontwikkelen van .NET-toepassingen voor operationele gegevens. Ze hebben een database met hoge concurrentie nodig, met volledige naleving van ACID-transacties en sterk afgedwongen vreemde sleutels voor relationele integriteit. Kirby wil het voordeel van automatische afstemming van prestaties om het dagelijkse databasebeheer te vereenvoudigen.

Kirby besluit over een SQL-database in Fabric, met dezelfde SQL Database Engine als Azure SQL Database. SQL-databases in Fabric worden automatisch geschaald om te voldoen aan de vraag gedurende de hele werkdag. Ze hebben de volledige mogelijkheid van transactionele tabellen en de flexibiliteit van transactieisolatieniveaus van serializeerbaar tot het lezen van vastgelegde momentopnamen. SQL Database in Fabric maakt en verwijdert automatisch niet-geclusterde indexen op basis van sterke signalen van uitvoeringsplannen die in de loop van de tijd zijn waargenomen.

In het scenario van Kirby moeten gegevens uit de operationele toepassing worden gekoppeld aan andere gegevens in Fabric: in Spark, in een magazijn en vanuit realtime gebeurtenissen in een Eventhouse. Elke Fabric-database bevat een SQL-analyse-eindpunt, zodat gegevens in realtime kunnen worden geopend vanuit Spark of met Power BI-query's met behulp van de DirectLake-modus. Deze rapportageoplossingen ontlasten de primaire operationele database van de belasting van analytische workloads en voorkomen denormalisatie. Kirby heeft ook bestaande operationele gegevens in andere SQL-databases en moet die gegevens importeren zonder transformatie. Als u bestaande operationele gegevens wilt importeren zonder conversie van gegevenstypen, ontwerpt Kirby pijplijnen met Fabric Data Factory om gegevens te importeren in de Fabric SQL-database.

Volgende stap