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.
Eigenschappen van gegevensarchief
Gebruik deze informatie om Fabric-gegevensarchieven, zoals warehouse, lakehouse, Eventhouse, SQL Database en Power BI datamart, te vergelijken op basis van gegevensvolume, type, persona voor ontwikkelaars, vaardighedenset, bewerkingen en andere mogelijkheden. Deze vergelijkingen zijn ingedeeld in de volgende twee tabellen:
| Lakehouse | Magazijn | Eventhouse | |
|---|---|---|---|
| Gegevensvolume | Onbeperkt | Onbeperkt | Onbeperkt |
| Type gegevens | Ongestructureerde semi-gestructureerd, gestructureerd |
Gestructureerd semi-gestructureerd (JSON) |
Ongestructureerde semi-gestructureerd, gestructureerd |
| Primaire persona voor ontwikkelaars | Data engineer, data scientist | Datawarehouse-ontwikkelaar, dataarchitect, data engineer, databaseontwikkelaar | App-ontwikkelaar, data scientist, data engineer |
| Primaire dev-vaardigheid | Spark (Scala, PySpark, Spark SQL, R) | SQL | Geen code, KQL, SQL |
| Gegevens geordend op | Mappen en bestanden, databases en tabellen | Databases, schema's en tabellen | Databases, schema's en tabellen |
| Leesbewerkingen | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Schrijfbewerkingen | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, connectorecosysteem |
| Transacties met meerdere tabellen | Nr. | Ja | Ja, voor opname met meerdere tabellen |
| Primaire ontwikkelinterface | Spark-notebooks, Spark-taakdefinities | SQL-scripts | KQL-queryset, KQL-database |
| Beveiliging | RLS, CLS**, tabelniveau (T-SQL), geen voor Spark | Objectniveau, RLS, CLS, DDL/DML, dynamische gegevensmaskering | Beveiliging op rijniveau |
| Toegang tot gegevens via snelkoppelingen | Ja | Ja | Ja |
| Kan een bron zijn voor snelkoppelingen | Ja (bestanden en tabellen) | Ja (tabellen) | Ja |
| Query uitvoeren op meerdere items | Ja | Ja | Ja |
| Advanced analytics (Geavanceerde analyse) | Interface voor grootschalige gegevensverwerking, ingebouwde gegevensparallellisme en fouttolerantie | Interface voor grootschalige gegevensverwerking, ingebouwde gegevensparallellisme en fouttolerantie | Systeemeigen time series-elementen, volledige georuimtelijke en querymogelijkheden |
| Ondersteuning voor geavanceerde opmaak | Tabellen die zijn gedefinieerd met behulp van PARQUET, CSV, AVRO, JSON en een apache Hive-compatibele bestandsindeling | Tabellen die zijn gedefinieerd met behulp van PARQUET, CSV, AVRO, JSON en een apache Hive-compatibele bestandsindeling | Volledige indexering voor vrije tekst en semi-gestructureerde gegevens zoals JSON |
| Opnamelatentie | Direct beschikbaar voor het uitvoeren van query's | Direct beschikbaar voor het uitvoeren van query's | Opname in de wachtrij, streamingopname heeft een latentie van een paar seconden |
* Spark ondersteunt het lezen van tabellen met behulp van snelkoppelingen, biedt nog geen ondersteuning voor het openen van weergaven, opgeslagen procedures, functies, enzovoort.
| Fabric SQL-database | Power BI Datamart | |
|---|---|---|
| Gegevensvolume | 4 TB | Maximaal 100 GB |
| Type gegevens | Gestructureerd semi-gestructureerd, Ongestructureerde |
gestructureerd |
| Primaire persona voor ontwikkelaars | AI-ontwikkelaar, app-ontwikkelaar, databaseontwikkelaar, DB-beheerder | Data scientist, gegevensanalist |
| Primaire dev-vaardigheid | SQL | Geen code, SQL |
| Gegevens geordend op | Databases, schema's, tabellen | Database, tabellen, query's |
| Leesbewerkingen | T-SQL | Spark, T-SQL |
| Schrijfbewerkingen | T-SQL | Gegevensstromen, T-SQL |
| Transacties met meerdere tabellen | Ja, volledige ACID-naleving | Nr. |
| Primaire ontwikkelinterface | SQL-scripts | Power BI |
| Beveiliging | Objectniveau, RLS, CLS, DDL/DML, dynamische gegevensmaskering | Ingebouwde RLS-editor |
| Toegang tot gegevens via snelkoppelingen | Ja | Nr. |
| Kan een bron zijn voor snelkoppelingen | Ja (tabellen) | Nr. |
| Query uitvoeren op meerdere items | Ja | Nr. |
| Advanced analytics (Geavanceerde analyse) | Analytische T-SQL-mogelijkheden, gegevens die worden gerepliceerd naar Delta Parquet in OneLake voor analyse | Interface voor gegevensverwerking met geautomatiseerde afstemming van prestaties |
| Ondersteuning voor geavanceerde opmaak | Tabelondersteuning voor OLTP, JSON, vector, grafiek, XML, ruimtelijke, sleutelwaarde | Tabellen die zijn gedefinieerd met behulp van PARQUET, CSV, AVRO, JSON en een apache Hive-compatibele bestandsindeling |
| Opnamelatentie | Direct beschikbaar voor het uitvoeren van query's | Direct beschikbaar voor het uitvoeren van query's |
** Beveiliging op kolomniveau die beschikbaar is in Lakehouse via een SQL-analyse-eindpunt met behulp van T-SQL.
Scenario's
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 alle 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 T-SQL-query's van het team 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 om een lakehouse te gebruiken, waardoor het data engineering-team hun diverse vaardigheden ten opzichte van de gegevens kan gebruiken, terwijl de teamleden die zeer ervaren zijn in T-SQL de gegevens kunnen gebruiken.
Scenario 3
Ash, een burgerontwikkelaar, is een Power BI-ontwikkelaar. Ze zijn bekend met Excel, Power BI en Office. Ze moeten een gegevensproduct bouwen voor een bedrijfseenheid. Ze weten dat ze niet helemaal de vaardigheden hebben om een datawarehouse of een lakehouse te bouwen, en die lijken te veel voor hun behoeften en gegevensvolumes. Ze bekijken de details in de vorige tabel en zien dat de primaire beslissingspunten hun eigen vaardigheden zijn en hun behoefte aan een selfservice, geen codemogelijkheid en gegevensvolume onder 100 GB.
Ash werkt samen met bedrijfsanalisten die bekend zijn met Power BI en Microsoft Office en weet dat ze al een Premium-capaciteitsabonnement hebben. Als ze denken aan hun grotere team, realiseren ze zich dat de primaire consumenten van deze gegevens analisten zijn, vertrouwd met no-code en SQL analytical tools. Ash besluit een Power BI-datamart te gebruiken, waardoor het team snel de mogelijkheid kan ontwikkelen, met behulp van een ervaring zonder code. Query's kunnen worden uitgevoerd via Power BI en T-SQL, terwijl eventuele Spark-gebruikers in de organisatie ook toegang hebben tot de gegevens.
Scenario 4
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 5
Kirby is een toepassingsarchitect die ervaring heeft met het ontwikkelen van .NET-toepassingen voor operationele gegevens. Ze hebben een database met hoge gelijktijdigheid nodig met volledige ACID-transactienaleving en sterk afgedwongen refererende 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 besparen de primaire operationele database op basis van de overhead 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 gegevenspijplijnen met Fabric Data Factory om gegevens te importeren in de Fabric SQL-database.