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
Ezekkel az információkkal összehasonlíthatja a Fabric-adattárakat, például a warehouse- és lakehouse-adattárakat, az Eventhouse-t, az SQL Database-t és a Power BI-adatmartot az adatmennyiség, a típus, a fejlesztői személy, a képességkészlet, a műveletek és egyéb képességek alapján. Ezek az összehasonlítások a következő két táblázatba vannak rendezve:
| 1/2. táblázat | Lakehouse | Raktár | Eventhouse |
|---|---|---|---|
| Adatmennyiség | Korlátlan | Korlátlan | Korlátlan |
| adattípus | Strukturálatlan félig strukturált, strukturált |
Strukturált félig strukturált (JSON) |
Strukturálatlan félig strukturált, strukturált |
| elsődleges fejlesztői szerep | Adatmérnök, adattudós | Adatraktár-fejlesztő, adatmérnök, adatmérnök, adatbázis-fejlesztő | Alkalmazásfejlesztő, adatelemző, adatszakértő |
| elsődleges fejlesztési készség | Spark (Scala, PySpark, Spark SQL, R) | SQL | Nincs kód, KQL, SQL |
| által szervezett adatok | Mappák és fájlok, adatbázisok és táblák | Adatbázisok, sémák és táblák | Adatbázisok, sémák és táblák |
| olvasási műveletek | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| írási műveletek | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, összekötő-ökoszisztéma |
| Többtáblás tranzakciók | Nem | Igen | Igen, többtáblás adatbetöltés |
| elsődleges fejlesztési felület | Spark-jegyzetfüzetek, Spark-feladatdefiníciók | SQL-szkriptek | KQL-lekérdezéskészlet, KQL-adatbázis |
| biztonság | RLS, CLS**, táblaszintű (T-SQL), Spark esetén egyik sem | objektumszintű, RLS, CLS, DDL/DML, dinamikus adatmaszkolás | Nyugtalan láb szindróma (RLS) |
| Adatok elérése billentyűparancsokkal | Igen | Igen, SQL Analytics-végponton keresztül | Igen |
| A parancsikonok forrása lehet | Igen (fájlok és táblák) | Igen (táblák) | Igen |
| Lekérdezés az elemek között | Igen | Igen | Igen |
| Fejlett analitika | Interfész nagy léptékű adatfeldolgozáshoz, beépített adat-párhuzamossághoz és hibatűréshez | Interfész nagy léptékű adatfeldolgozáshoz, beépített adat-párhuzamossághoz és hibatűréshez | Time Series natív elemek, teljes geotérbeli és lekérdezési képességek |
| Speciális formázás támogatása | PARQUET, CSV, AVRO, JSON és bármely Apache Hive-kompatibilis fájlformátum használatával definiált táblák | PARQUET, CSV, AVRO, JSON és bármely Apache Hive-kompatibilis fájlformátum használatával definiált táblák | Teljes indexelés szabad szövegekhez és félig strukturált adatokhoz, például JSON-hoz |
| betöltési késés | Azonnal elérhető a lekérdezéshez | Azonnal elérhető a lekérdezéshez | Várakozási sorba helyezett betöltés, a streamelési betöltés néhány másodperces késéssel rendelkezik |
* A 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.
| 2. táblázat 2-ből | Fabric SQL-adatbázis | Power BI Datamart |
|---|---|---|
| adatmennyiség | 4 TB | Legfeljebb 100 GB |
| adattípus | Strukturált félig strukturált, Strukturálatlan |
Strukturált |
| elsődleges fejlesztői személyiség | AI-fejlesztő, alkalmazásfejlesztő, adatbázis-fejlesztő, adatbázis-rendszergazda | Adatkutató, adatelemző |
| elsődleges fejlesztői készség | SQL | Nincs kód, SQL |
| által szervezett adatok | Adatbázisok, sémák, táblák | Adatbázis, táblák, lekérdezések |
| olvasási műveletek | T-SQL | Spark, T-SQL |
| írási műveletek | T-SQL | Adatfolyamok, T-SQL |
| többtáblás tranzakciók | Igen, teljes ACID-megfelelőség | Nem |
| elsődleges fejlesztési felület | SQL-szkriptek | Power BI |
| Biztonság | Objektumszint, RLS, CLS, DDL/DML, dinamikus adatmaszkolás | Beépített RLS-szerkesztő |
| Adatok elérése billentyűparancsokkal | Igen | Nem |
| A parancsikonok forrása lehet | Igen (táblák) | Nem |
| Lekérdezés az elemek között | Igen | Nem |
| Fejlett analitika | T-SQL elemzési képességek, a Delta Parquetbe replikált adatok a OneLake-ben elemzés céljából | Adatfeldolgozási felület automatizált teljesítményhangolással |
| Speciális formázás támogatása | Táblatámogatás OLTP, JSON, vektor, gráf, XML, térbeli, kulcsérték esetén | PARQUET, CSV, AVRO, JSON és bármely Apache Hive-kompatibilis fájlformátum használatával definiált táblák |
| betöltési késés | Azonnal elérhető a lekérdezéshez | Azonnal elérhető a lekérdezéshez |
** Oszlopszintű biztonság érhető el a Lakehouse-on egy SQL Analytics-végponton keresztül, T-SQL használatával.
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. forgatókönyv
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 úgy kell dönteniük, hogy adattárházat vagy tóházat építenek. 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 Fabric-raktár-t használ, amely lehetővé teszi a csapat számára, hogy elsősorban T-SQL-t használva kommunikáljon, ugyanakkor a szervezet minden Spark-felhasználójának hozzáférést biztosít az adatokhoz.
Susan létrehoz egy új adattárházat, és a többi SQL Server-adatbázishoz hasonlóan a T-SQL használatával is kommunikál vele. A meglévő T-SQL-kód nagy része, amelyet a raktár SQL Serveren való buildeléséhez írt, a Fabric adattárházban fog működni, ami megkönnyíti az átállást. Ha úgy dönt, akár ugyanazokat az eszközöket is használhatja, amelyek más adatbázisokkal, például az SQL Server Management Studióval működnek. A Fabric portál SQL-szerkesztőjével Susan és a csapat többi tagja olyan elemző lekérdezéseket ír, amelyek más adattárházakra és lakehouse-okon belüli Delta-táblákra hivatkoznak, egyszerűen háromrészes nevek alkalmazásával az adatbázisok közötti lekérdezésekhez.
2. forgatókönyv
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 lakehousehasznál, amely lehetővé teszi az adatmérnöki csapat számára, hogy különböző készségeiket az adatok kezelésére használják, és hogy a T-SQL-ben magasan képzett csapattagok is felhasználhassák az adatokat.
3. forgatókönyv
Ash egy civil fejlesztő és 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 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-adatmarthasznál, amely lehetővé teszi a csapat számára, hogy kódolás nélküli élménnyel gyorsan fejlesszék a képességeiket. 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. forgatókönyv
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, fuvarozókból és más forrásokból származnak.
Daisy úgy dönt, hogy egy Eventhouse-at használ a méretezhetősége, gyors reakcióidők, fejlett elemzési képességei, például az idősorozat-elemzés, térinformatikai függvények, valamint a Power BI-ban elérhető gyors közvetlen lekérdezési mód miatt. 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.
5. forgatókönyv
Kirby egy olyan alkalmazástervező, aki jártos a .NET-alkalmazások operatív adatokhoz való fejlesztésében. A relációs integritás érdekében magas egyidejűségi adatbázisra van szükségük, teljes ACID-tranzakciómegfelelőséggel és szigorúan kikényszerített idegen kulcsokkal. Kirby az automatikus teljesítményhangolás előnyeit szeretné egyszerűsíteni a napi adatbázis-kezelés érdekében.
Kirby egy SQL-adatbázist hoz létre a Fabric-ban, ugyanazzal az SQL Database-motorral, mint az Azure SQL Database. A Fabric SQL-adatbázisai automatikusan méretezhetőek, hogy kielégítsék az igényeket a munkanap folyamán. A tranzakciós táblák teljes funkcionalitásával és a tranzakcióelkülönítési szintek rugalmasságával rendelkeznek a szerializálhatótól a véglegesített pillanatképek olvasásaig. A Fabric SQL-adatbázisa automatikusan létrehoz és töröl nem klaszterezett indexeket az erős jelzésekkel bíró végrehajtási tervek megfigyelése alapján.
Kirby forgatókönyvében az operatív alkalmazásból származó adatokat más adatokkal kell összekapcsolni a Fabricben: a Sparkban, egy raktárban és egy eventhouse valós idejű eseményeiből. Minden Fabric-adatbázis tartalmaz egy SQL Analytics-végpontot, így az adatok valós időben érhetők el a Sparkból vagy Power BI-lekérdezésekkel DirectLake módban. Ezek a jelentéskészítési megoldások megkímélik az elsődleges operatív adatbázist az elemzési számítási feladatok terhelésétől, és elkerülik a denormalizálást. A Kirby más SQL-adatbázisokban is rendelkezik meglévő üzemeltetési adatokkal, és átalakítás nélkül kell importálnia az adatokat. Ha a meglévő operatív adatokat adattípus-átalakítás nélkül szeretné importálni, a Kirby adatfolyamokat tervez a Fabric Data Factoryvel, hogy adatokat importáljon a Fabric SQL-adatbázisba.