Microsoft Fabric -päätöksenteko-opas: valitse tietosäilö
Tämän viiteoppaan ja esimerkkiskenaarioiden avulla voit valita tietosäilön Microsoft Fabric -kuormituksia varten.
Tietosäilön ominaisuudet
Varasto | Lakehouse | Power BI -tietomarssi | Eventhouse | |
---|---|---|---|---|
Tietojen määrä | Ei rajoitettu | Ei rajoitettu | Enintään 100 Gt | Ei rajoitettu |
Tietojen tyyppi | Jäsennetty | Rakenteeton, puolirakenteinen, jäsennetty | Jäsennetty | Rakenteeton, puolirakenteinen, jäsennetty |
Ensisijainen kehittäjäpersona | Tietovaraston kehittäjä, SQL-insinööri | Tietoteknikko, datatieteilijä | Citizen developer | Citizen Data scientist, Data engineer, Data scientist, SQL engineer |
Ensisijainen kehittäjän taitojoukko | SQL | Spark(Scala, PySpark, Spark SQL, R) | Ei koodia, SQL | Ei koodia, KQL, SQL |
Tiedot järjestetty | Tietokannat, rakenteet ja taulukot | Kansiot ja tiedostot, tietokannat ja taulukot | Tietokanta, taulukot, kyselyt | Tietokannat, rakenteet ja taulukot |
Lukutoiminnot | T-SQL, Spark (tukee taulukoiden lukemista pikanäppäimillä, ei vielä tue näkymien, tallennettujen toimintosarjojen ja funktioiden käyttöä). | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
Kirjoitustoiminnot | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Tietovuot, T-SQL | KQL-, Spark-, liitinekosysteemi |
Usean taulukon tapahtumat | Kyllä | No | En | Kyllä, usean taulukon käsittelylle. Katso käytännön päivittäminen. |
Ensisijainen kehitysliittymä | SQL-komentosarjat | Spark-muistikirjat, Spark-työmääritykset | Power BI | KQL-kyselyjoukko, KQL-tietokanta |
Suojaus | Objektitaso (taulukko, näkymä, funktio, tallennettu toimintosarja jne.), saraketaso, rivitaso, DDL/DML, dynaaminen tietojen peittäminen | Rivitaso, taulukkotaso (käytettäessä T-SQL:ää), ei mitään Sparkille | Sisäinen RLS-editori | Rivitason suojaus |
Tietojen käyttäminen pikanäppäimillä | Kyllä, lakehousen kautta käyttämällä kolmiosaisia nimiä | Kyllä | No | Kyllä |
Voi olla pikakuvakkeiden lähde | Kyllä (taulukot) | Kyllä (tiedostot ja taulukot) | Ei | Kyllä |
Kysely kohteista | Kyllä, kysely Lakehouse- ja varastotaulukoissa | Kyllä, kysely Lakehouse- ja varastotaulukoiden välillä; kysely lakehouseissa (mukaan lukien spark-pikakuvakkeet) | En | Kyllä, kysely KQL-tietokannoissa, lakehouseissa ja varastoissa, joissa on pikakuvakkeita |
Skenaariot
Tutustu näihin skenaarioihin, joiden avulla voit valita tietosäilön Fabricissa.
Tilanne 1
Ammattikehittäjä Susan on Microsoft Fabricin uusi käyttäjä. Ne ovat valmiita aloittamaan tietojen siistimisen, mallinnuksen ja analysoinnin, mutta heidän on päätettävä tietovaraston tai lakehousen rakentamisesta. Edellisen taulukon tietojen tarkastelun jälkeen ensisijaiset päätöspisteet ovat käytettävissä oleva taitojoukko ja tarve monitaulukkoisille tapahtumille.
Susan on monien vuosien ajan luonut tietovarastoja relaatiotietokantamoottoreille, ja hän tuntee SQL-syntaksin ja toiminnallisuuden. Kun ajattelet suurempaa tiimiä, näiden tietojen pääkuluttajat ovat myös SQL- ja SQL-analyysityökalujen osaamista. Susan päättää käyttää tietovarastoa, jonka avulla tiimi voi käyttää ensisijaisesti T-SQL:ää ja samalla antaa organisaation Spark-käyttäjille pääsyn tietoihin.
Susan luo uuden lakehousen. Fabric-portaalin avulla voit luoda ulkoisten tietotaulukoiden pikakuvakkeita ja sijoittaa ne kansioon /Tables
. Susan voi nyt kirjoittaa T-SQL-kyselyitä, jotka viittaavat pikakuvakkeisiin Delta Lake -tietojen kyselyssä Lakehousessa. Pikakuvakkeet näkyvät automaattisesti taulukoina SQL-analytiikan päätepisteessä, ja niitä voidaan kysellä T-SQL:llä kolmiosaisilla nimillä.
Tilanne 2
Tietoteknikko Rob tallentaa ja mallintaa useita teratavuja tietoja Fabricissa. Tiimissä on sekä PySpark- että T-SQL-taitoja. Suurin osa T-SQL-kyselyitä suorittavasta tiimistä on kuluttajia, joten heidän ei tarvitse kirjoittaa INSERT-, UPDATE- tai DELETE-lausekkeita. Jäljellä olevat kehittäjät työskentelevät mielellään muistikirjoissa, ja koska tiedot on tallennettu Delta-kohteeseen, he voivat käyttää samankaltaista SQL-syntaksia.
Rob päättää käyttää Lakehousea, jolloin tietotekniikkatiimi voi käyttää monipuolisia taitojaan tietojen kanssa ja antaa T-SQL:n erittäin taitavien tiimin jäsenten käyttää tietoja.
Skenaario 3
Citizen Developer, Ash on Power BI -kehittäjä. Excel, Power BI ja Office ovat heille tuttuja. Heidän on luotava tietotuote liiketoimintayksikölle. He tietävät, ettei heillä ole aivan taitoja rakentaa tietovarastoa tai lakehousea, ja ne vaikuttavat liikaa heidän tarpeisiinsa ja tietomääriinsä. He tarkastelevat edellisen taulukon tietoja ja huomaavat, että ensisijaiset päätöspisteet ovat heidän omat taitonsa ja tarve omatoimiseen palveluun, ei koodiominaisuutta ja alle 100 gigatavun tietojen määrä.
Ash työskentelee Power BI:hin ja Microsoft Officeen perehtyneiden yritysanalyytikoiden kanssa ja tietää, että heillä on jo Premium-kapasiteettitilaus. Kun he ajattelevat suurempaa tiimiään, he tajuavat, että näiden tietojen pääkuluttajat voivat olla analyytikoita, jotka tuntevat koodittomuustyökalut ja SQL-analyysityökalut. Ash päättää käyttää Power BI -tietomarssia, jonka avulla tiimi voi kehittää ominaisuutta nopeasti ilman koodaamista. Kyselyt voidaan suorittaa Power BI:n ja T-SQL:n kautta. Samalla kuka tahansa organisaation Spark-käyttäjä voi käyttää myös tietoja.
Skenaario 4
Daisy on yritysanalyytikko, joka on käyttänyt Power BI:tä toimitusketjun pullonkaulojen analysointiin suuressa globaalissa jälleenmyyntiketjussa. Heidän on luotava skaalattava tietoratkaisu, joka pystyy käsittelemään miljardeja tietorivejä ja jonka avulla voidaan luoda koontinäyttöjä ja raportteja, joita voidaan käyttää liiketoimintapäätösten tekemiseen. Tiedot ovat peräisin toimipisteistä, toimittajista, lähettäjistä ja muista lähteistä erilaisissa jäsennettyissä, puolirakenteisissa ja jäsentämättömissä muodoissa.
Daisy päättää käyttää tapahtumataloa skaalattavuuden, nopeiden vasteaikojen, kehittyneiden analytiikkaominaisuuksien, kuten aikasarja-analyysin, geospatiaalisten funktioiden ja Power BI:n nopean suoran kyselytilan, vuoksi. Kyselyitä voidaan suorittaa Power BI:n ja KQL:n avulla nykyisten ja aiempien jaksojen vertailuun, uusien ongelmien nopeaan tunnistamiseen tai maa- ja merireittien sijaintikohtaiseen analysointiin.
Liittyvä sisältö
Palaute
https://aka.ms/ContentUserFeedback.
Tulossa pian: Vuoden 2024 aikana poistamme asteittain GitHub Issuesin käytöstä sisällön palautemekanismina ja korvaamme sen uudella palautejärjestelmällä. Lisätietoja on täällä:Lähetä ja näytä palaute kohteelle