Jaa


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.