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
Deze tabel vergelijkt gegevensarchieven zoals magazijn, lakehouse, Power BI-datamart en eventhouse op basis van gegevensvolume, type, persona voor ontwikkelaars, vaardighedenset, bewerkingen. en andere mogelijkheden.
| Magazijn | Lakehouse | Power BI Datamart | Eventhouse | |
|---|---|---|---|---|
| Gegevensvolume | Onbeperkt | Onbeperkt | Maximaal 100 GB | Onbeperkt |
| Type gegevens | gestructureerd | Ongestructureerd, semi-gestructureerd, gestructureerd | gestructureerd | Ongestructureerd, semi-gestructureerd, gestructureerd |
| Primaire persona voor ontwikkelaars | Datawarehouse-ontwikkelaar, SQL-engineer | Data engineer, data scientist | Burgerontwikkelaar | Citizen Data scientist, Data Engineer, Data scientist, SQL Engineer |
| Vaardighedenset voor primaire ontwikkelaars | SQL | Spark(Scala, PySpark, Spark SQL, R) | Geen code, SQL | Geen code, KQL, SQL |
| Gegevens geordend op | Databases, schema's en tabellen | Mappen en bestanden, databases en tabellen | Database, tabellen, query's | Databases, schema's en tabellen |
| Leesbewerkingen | T-SQL, Spark (ondersteunt het lezen van tabellen met behulp van snelkoppelingen, biedt nog geen ondersteuning voor het openen van weergaven, opgeslagen procedures, functies, enzovoort) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| Schrijfbewerkingen | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Gegevensstromen, T-SQL | KQL, Spark, connectorecosysteem |
| Transacties met meerdere tabellen | Ja | No | Nr. | Ja, voor opname met meerdere tabellen. Zie updatebeleid. |
| Primaire ontwikkelinterface | SQL-scripts | Spark-notebooks, Spark-taakdefinities | Power BI | KQL-queryset, KQL-database |
| Beveiliging | Objectniveau (tabel, weergave, functie, opgeslagen procedure, enzovoort), kolomniveau, rijniveau, DDL/DML, dynamische gegevensmaskering | Rijniveau, kolomniveau (voor Lakehouse toegankelijk via een SQL Analytics-eindpunt), tabelniveau (bij gebruik van T-SQL), geen voor Spark | Ingebouwde RLS-editor | Beveiliging op rijniveau |
| Toegang tot gegevens via snelkoppelingen | Ja, via een lakehouse met driedelige namen | Ja | No | Ja |
| Kan een bron zijn voor snelkoppelingen | Ja (tabellen) | Ja (bestanden en tabellen) | Nr. | Ja |
| Query uitvoeren op meerdere items | Ja, query's uitvoeren op lakehouse- en magazijntabellen | Ja, query's uitvoeren op lakehouse- en magazijntabellen; query's uitvoeren op lakehouses (inclusief snelkoppelingen met Spark) | Nee | Ja, query's uitvoeren op KQL-databases, lakehouses en magazijnen met snelkoppelingen |
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 datawarehouse 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 lakehouse en heeft toegang tot de datawarehouse-mogelijkheden met het sql-analyse-eindpunt van Lakehouse. Met behulp van de Fabric-portal maakt u snelkoppelingen naar de externe gegevenstabellen en plaatst u deze in de /Tables map. Susan kan nu T-SQL-query's schrijven die verwijzen naar snelkoppelingen om query's uit te voeren op Delta Lake-gegevens in het lakehouse. De snelkoppelingen worden automatisch weergegeven als tabellen in het SQL Analytics-eindpunt en kunnen worden opgevraagd met T-SQL met behulp van driedelige namen.
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 gebruikers van deze gegevens analisten kunnen 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.