A Microsoft Fabric döntési útmutatója: válasszon egy adattárat
Ez a referencia-útmutató és a példaforgatókönyvek segítségével kiválaszthatja a Microsoft Fabric számítási feladataihoz tartozó adattárat.
Adattár tulajdonságai
Ez a táblázat összehasonlítja az olyan adattárakat, mint a warehouse, a lakehouse, a Power BI datamart és az eventhouse az adatmennyiség, a típus, a fejlesztői személy, a képességkészlet és a műveletek alapján. és egyéb képességeket.
Raktár | Lakehouse | Power BI Datamart | Eventhouse | |
---|---|---|---|---|
Adatkötet | Korlátlan | Korlátlan | Legfeljebb 100 GB | Korlátlan |
Adattípus | Strukturált | Strukturálatlan, félig strukturált, strukturált | Strukturált | Strukturálatlan, félig strukturált, strukturált |
Elsődleges fejlesztői személy | Adattárház-fejlesztő, SQL-mérnök | Adatmérnök, adattudós | Állampolgári fejlesztő | Citizen Data scientist, Data engineer, Data scientist, SQL engineer |
Elsődleges fejlesztői képességkészlet | SQL | Spark(Scala, PySpark, Spark SQL, R) | Nincs kód, SQL | Nincs kód, KQL, SQL |
Az adatok rendszerezése: | Adatbázisok, sémák és táblák | Mappák és fájlok, adatbázisok és táblák | Adatbázis, táblák, lekérdezések | Adatbázisok, sémák és táblák |
Olvasási műveletek | T-SQL, Spark (billentyűparancsokkal támogatja a táblázatokból való olvasást, még nem támogatja a nézetek, a tárolt eljárások, a függvények stb. elérését) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
Írási műveletek | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Adatfolyamok, T-SQL | KQL, Spark, összekötő-ökoszisztéma |
Többtáblás tranzakciók | Igen | Nem | Nem | Igen, többtáblás betöltéshez. Lásd a frissítési szabályzatot. |
Elsődleges fejlesztési felület | SQL-szkriptek | Spark-jegyzetfüzetek,Spark-feladatdefiníciók | Power BI | KQL-lekérdezéskészlet, KQL-adatbázis |
Biztonság | Objektumszint (táblázat, nézet, függvény, tárolt eljárás stb.), oszlopszint, sorszint, DDL/DML, dinamikus adatmaszkolás | Sorszint, oszlopszint (SQL Analytics-végponton keresztül elérhető Lakehouse esetén), táblaszint (T-SQL használata esetén), Spark esetében egyik sem | Beépített RLS-szerkesztő | Sorszintű biztonság |
Adatok elérése billentyűparancsokkal | Igen, egy tóparton keresztül, háromrészes nevek használatával | Igen | Nem | Igen |
A billentyűparancsok forrása lehet | Igen (táblák) | Igen (fájlok és táblák) | Nem | Igen |
Lekérdezés elemek között | Igen, lekérdezés a lakehouse és a raktártáblák között | Igen, lekérdezés a lakehouse és a raktártáblák között; lekérdezés a tóházak között (beleértve a Sparkot használó billentyűparancsokat is) | Nem | Igen, kQL-adatbázisok, lakehouse-k és raktárak lekérdezése billentyűparancsokkal |
Forgatókönyvek
Tekintse át ezeket a forgatókönyveket, ha segítségre van szüksége egy adattár kiválasztásához a Fabricben.
1. eset
Susan, egy profi fejlesztő, új a Microsoft Fabricben. Készen állnak az adatok tisztítására, modellezésére és elemzésére, de el kell dönteniük, hogy létrehoznak egy adattárházat vagy egy tóházat. Az előző táblázatban szereplő adatok áttekintése után az elsődleges döntési pontok a rendelkezésre álló képességkészlet és a többtáblás tranzakciók szükségessége.
Susan sok éve készít adattárházakat relációs adatbázismotorokon, és ismeri az SQL szintaxisát és funkcióit. A nagyobb csapatra gondolva az adatok elsődleges felhasználói az SQL- és SQL-elemzési eszközökkel is jártasak. Susan úgy dönt, hogy egy adattárházat használ, amely lehetővé teszi a csapat számára, hogy elsősorban a T-SQL-sel kommunikáljon, ugyanakkor lehetővé teszi a szervezet összes Spark-felhasználójának, hogy hozzáférjenek az adatokhoz.
Susan létrehoz egy új lakehouse-t, és hozzáfér az adattárház képességeihez a lakehouse SQL Analytics-végponttal. A Háló portál használatával parancsikonokat hozhat létre a külső adattáblákhoz, és elhelyezheti őket a /Tables
mappában. Susan most már írhat olyan T-SQL-lekérdezéseket, amelyek parancsikonokra hivatkoznak a Delta Lake-adatok lekérdezéséhez a lakehouse-ban. A billentyűparancsok automatikusan táblákként jelennek meg az SQL Analytics-végponton, és háromrészes nevek használatával kérdezhetők le a T-SQL-lel.
2. eset
Robnak, az adatszakértőnek több terabájtnyi adatot kell tárolnia és modelleznie a Fabricben. A csapat a PySpark és a T-SQL készségek kombinációjával rendelkezik. A T-SQL-lekérdezéseket futtató csapatok többsége fogyasztó, ezért nem kell INSERT, UPDATE vagy DELETE utasítást írnia. A többi fejlesztő kényelmesen dolgozik a jegyzetfüzetekben, és mivel az adatokat a Delta tárolja, hasonló SQL-szintaxist használhatnak.
Rob úgy dönt, hogy egy tóházat használ, amely lehetővé teszi az adatmérnöki csapat számára, hogy az adatokkal szemben használják a különböző készségeiket, miközben lehetővé teszi a T-SQL-ben magasan képzett csapattagok számára az adatok felhasználását.
3. eset
Ash, egy civil fejlesztő, Egy Power BI fejlesztő. Ismerik az Excelt, a Power BI-t és az Office-t. Adatterméket kell létrehozniuk egy üzleti egységhez. Tudják, hogy nem igazán rendelkeznek az adattárház vagy egy tóház felépítéséhez szükséges készségekkel, és ezek túl soknak tűnnek az igényeik és adatmennyiségük szempontjából. Áttekintik az előző táblázatban szereplő részleteket, és látják, hogy az elsődleges döntési pontok a saját képességeik, valamint az önkiszolgáló, a kódképesség nélküli és a 100 GB-nál nagyobb adatmennyiség iránti igényük.
Ash a Power BI-t és a Microsoft Office-t ismerő üzleti elemzőkkel dolgozik, és tudja, hogy már rendelkezik Prémium szintű kapacitás-előfizetéssel. Ahogy a nagyobb csapatra gondolnak, rájönnek, hogy az adatok elsődleges felhasználói lehetnek elemzők, akik ismerik a kód nélküli és az SQL-elemzési eszközöket. Ash úgy dönt, hogy egy Power BI-adatmartot használ, amely lehetővé teszi a csapat számára a képesség gyors, kód nélküli használatát. A lekérdezések a Power BI-on és a T-SQL-en keresztül is végrehajthatók, miközben a szervezet bármely Spark-felhasználója is hozzáférhet az adatokhoz.
4\. példa
Daisy üzleti elemző, aki a Power BI használatával elemezte az ellátási lánc szűk keresztmetszeteit egy nagy globális kiskereskedelmi lánc esetében. Olyan méretezhető adatmegoldást kell létrehozniuk, amely több milliárd adatsort képes kezelni, és felhasználhatók olyan irányítópultok és jelentések készítésére, amelyek üzleti döntések meghozatalához használhatók. Az adatok különböző strukturált, részben strukturált és strukturálatlan formátumban származó üzemekből, szállítókból, szállítókból és más forrásokból származnak.
Daisy úgy dönt, hogy egy eseményházat használ a méretezhetősége, a gyors válaszidők, a fejlett elemzési képességek, például az idősorozat-elemzés, a térinformatikai függvények és a gyors közvetlen lekérdezési mód miatt a Power BI-ban. A lekérdezések a Power BI és a KQL használatával végrehajthatók a jelenlegi és az előző időszakok összehasonlítása, a felmerülő problémák gyors azonosítása vagy a szárazföldi és tengeri útvonalak geo-térbeli elemzésének biztosítása érdekében.