Průvodce rozhodováním Microsoft Fabric: Volba úložiště dat
Tento referenční průvodce a ukázkové scénáře vám pomůžou zvolit úložiště dat pro vaše úlohy Microsoft Fabric.
Vlastnosti úložiště dat
Tyto informace slouží k porovnání úložišť dat Fabric, jako jsou sklad, jezero, Eventhouse, databáze SQL a datový diagram Power BI, na základě objemu dat, typu, osoby vývojáře, sady dovedností, operací a dalších funkcí. Tato porovnání jsou uspořádaná do následujících dvou tabulek:
| Tabulka 1 ze 2 | Jezero | Sklad | Eventhouse |
|---|---|---|---|
| Objem dat | Bez omezení | Bez omezení | Bez omezení |
| Typ dat | Nestrukturovaný částečně strukturovaná, strukturovaný |
Strukturovaný částečně strukturovaná (JSON) |
Nestrukturovaný částečně strukturovaná, strukturovaný |
| Primární osoba vývojáře | Datový inženýr, datový vědec | Vývojář datového skladu, datový architekt, datový inženýr, vývojář databáze | Vývojář aplikací, datový vědec, datový inženýr |
| Primární dovednosti pro vývoj | Spark (Scala, PySpark, Spark SQL, R) | SQL | Žádný kód, KQL, SQL |
| Data uspořádaná podle | Složky a soubory, databáze a tabulky | Databáze, schémata a tabulky | Databáze, schémata a tabulky |
| Operace čtení | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Operace zápisu | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, ekosystém konektorů |
| Transakce s více tabulkami | No | Ano | Ano, pro příjem dat s více tabulkami |
| Primární vývojové rozhraní | Poznámkové bloky Sparku, definice úloh Sparku | Skripty SQL | Sada dotazů KQL, databáze KQL |
| Zabezpečení | RLS, CLS**, úroveň tabulky (T-SQL), žádná pro Spark | Úroveň objektů, RLS, CLS, DDL/DML, dynamické maskování dat | Zabezpečení na úrovni řádků |
| Přístup k datům prostřednictvím zástupců | Ano | Ano | Ano |
| Může to být zdroj pro klávesové zkratky. | Ano (soubory a tabulky) | Ano (tabulky) | Ano |
| Dotazování napříč položkami | Ano | Ano | Ano |
| Pokročilé analýzy | Rozhraní pro rozsáhlé zpracování dat, integrovaný paralelismus dat a odolnost proti chybám | Rozhraní pro rozsáhlé zpracování dat, integrovaný paralelismus dat a odolnost proti chybám | Nativní prvky Time Series, úplné geografické prostorové a dotazovací funkce |
| Podpora rozšířeného formátování | Tabulky definované pomocí souborů PARQUET, CSV, AVRO, JSON a libovolného formátu souboru kompatibilního s Apache Hivem | Tabulky definované pomocí souborů PARQUET, CSV, AVRO, JSON a libovolného formátu souboru kompatibilního s Apache Hivem | Úplné indexování pro volný text a částečně strukturovaná data, jako je JSON |
| Latence příjmu dat | K dispozici okamžitě pro dotazování | K dispozici okamžitě pro dotazování | Příjem dat ve frontě, příjem dat streamování má několik sekund latence. |
* Spark podporuje čtení z tabulek pomocí klávesových zkratek, zatím nepodporuje přístup k zobrazením, uloženým procedurám, funkcím atd.
| Tabulka 2 ze 2 | Databáze SQL infrastruktury | Power BI Datamart |
|---|---|---|
| Objem dat | 4 TB | Až 100 GB |
| Typ dat | Strukturovaný částečně strukturovaná, nestrukturovaný |
Strukturovaná |
| Primární osoba vývojáře | Vývojář umělé inteligence, vývojář aplikací, vývojář databáze, správce databáze | Datový vědec, datový analytik |
| Primární dovednosti pro vývoj | SQL | Žádný kód, SQL |
| Data uspořádaná podle | Databáze, schémata, tabulky | Databáze, tabulky, dotazy |
| Operace čtení | T-SQL | Spark, T-SQL |
| Operace zápisu | T-SQL | Toky dat, T-SQL |
| Transakce s více tabulkami | Ano, úplné dodržování předpisů ACID | No |
| Primární vývojové rozhraní | Skripty SQL | Power BI |
| Zabezpečení | Úroveň objektů, RLS, CLS, DDL/DML, dynamické maskování dat | Integrovaný editor zabezpečení na úrovni řádků |
| Přístup k datům prostřednictvím zástupců | Ano | No |
| Může to být zdroj pro klávesové zkratky. | Ano (tabulky) | No |
| Dotazování napříč položkami | Ano | No |
| Pokročilé analýzy | Analytické možnosti T-SQL, data replikovaná do delta parquet v OneLake pro účely analýzy | Rozhraní pro zpracování dat s automatizovaným laděním výkonu |
| Podpora rozšířeného formátování | Podpora tabulek PRO OLTP, JSON, vector, graph, XML, spatial, key-value | Tabulky definované pomocí souborů PARQUET, CSV, AVRO, JSON a libovolného formátu souboru kompatibilního s Apache Hivem |
| Latence příjmu dat | K dispozici okamžitě pro dotazování | K dispozici okamžitě pro dotazování |
** Zabezpečení na úrovni sloupců dostupné v Lakehouse prostřednictvím koncového bodu analýzy SQL pomocí T-SQL.
Scénáře
V těchto scénářích najdete pomoc s výběrem úložiště dat v prostředcích infrastruktury.
Scénář 1
Susan, profesionální vývojář, je pro Microsoft Fabric novinkou. Jsou připravení začít s čištěním, modelováním a analýzou dat, ale musí se rozhodnout vytvořit datový sklad nebo jezero. Po kontrole podrobností v předchozí tabulce jsou primární rozhodovací body dostupnou sadou dovedností a potřebou transakcí s více tabulkami.
Susan strávila mnoho let sestavováním datových skladů na relačních databázových strojích a je obeznámena se syntaxí a funkcemi SQL. Když uvažujete o větším týmu, primární uživatelé těchto dat mají také zkušenosti s analytickými nástroji SQL a SQL. Susan se rozhodne použít sklad Fabric, který týmu umožňuje pracovat primárně s T-SQL a zároveň umožnit všem uživatelům Sparku v organizaci přístup k datům.
Susan vytvoří nový datový sklad a komunikuje s ním pomocí T-SQL stejně jako ostatní databáze SQL Serveru. Většina existujícího kódu T-SQL, který napsala pro sestavení svého skladu na SQL Serveru, bude fungovat na datovém skladu Fabric, což usnadňuje přechod. Pokud se rozhodne, může dokonce používat stejné nástroje, které fungují s ostatními databázemi, jako je SQL Server Management Studio. Pomocí editoru SQL na portálu Fabric zapisují Susan a další členové týmu analytické dotazy, které odkazují na jiné datové sklady a tabulky Delta v lakehouses, jednoduše pomocí třídílných názvů k provádění dotazů napříč databázemi.
Scénář 2
Rob, datový inženýr, potřebuje ukládat a modelovat několik terabajtů dat v Prostředcích infrastruktury. Tým má kombinaci dovedností PySpark a T-SQL. Většina týmů, na kterých běží dotazy T-SQL, jsou příjemci, a proto nemusí psát příkazy INSERT, UPDATE nebo DELETE. Zbývající vývojáři dobře pracují v poznámkových blocích a protože jsou data uložená v Delta, můžou pracovat s podobnou syntaxí SQL.
Rob se rozhodne použít lakehouse, který týmu pro přípravu dat umožňuje využívat své různorodé dovednosti vůči datům a zároveň umožnit členům týmu, kteří jsou vysoce kvalifikovaní v T-SQL, aby data spotřebovával.
Scénář 3
Ash, občan, vývojář, je vývojář Power BI. Jsou obeznámeni s Excelem, Power BI a Office. Potřebují vytvořit datový produkt pro obchodní jednotku. Vědí, že nemají dost dovedností k vytvoření datového skladu nebo jezera, a ty se zdají být příliš moc pro své potřeby a objemy dat. Projdou si podrobnosti v předchozí tabulce a zjistí, že primární rozhodovací body jsou jejich vlastní dovednosti a že potřebují samoobslužnou službu, žádné schopnosti kódu a objem dat pod 100 GB.
Ash spolupracuje s obchodními analytiky, kteří jsou obeznámeni s Power BI a systém Microsoft Office, a ví, že už mají předplatné kapacity Premium. Vzhledem k tomu, že si myslí o svém větším týmu, si uvědomí, že primární spotřebitelé těchto dat jsou analytici, kteří znají bez kódu a analytické nástroje SQL. Ash se rozhodne použít datový diagram Power BI, který týmu umožňuje rychle vytvářet možnosti pomocí prostředí bez kódu. Dotazy je možné spouštět prostřednictvím Power BI a T-SQL a zároveň umožnit všem uživatelům Sparku v organizaci přístup k datům.
Scénář 4
Daisy je obchodní analytik zkušený s využitím Power BI k analýze kritických bodů dodavatelského řetězce pro rozsáhlý globální maloobchodní řetězec. Potřebují vytvořit škálovatelné datové řešení, které dokáže zpracovávat miliardy řádků dat a lze je použít k vytváření řídicích panelů a sestav, které je možné použít k obchodním rozhodnutím. Data pocházejí z rostlin, dodavatelů, odesílatelů a dalších zdrojů v různých strukturovaných, částečně strukturovaných a nestrukturovaných formátech.
Daisy se rozhodne používat eventhouse kvůli škálovatelnosti, rychlé době odezvy, pokročilým analytickým možnostem, včetně analýzy časových řad, geoprostorových funkcí a rychlého režimu přímých dotazů v Power BI. Dotazy je možné spouštět pomocí Power BI a KQL k porovnání mezi aktuálními a předchozími obdobími, rychle identifikovat vznikající problémy nebo poskytovat geoprostorovou analýzu vnitrozemí a námořních tras.
Scénář 5
Kirby je aplikační architekt zkušený při vývoji aplikací .NET pro provozní data. Potřebují databázi s vysokou souběžností s úplným dodržováním předpisů transakcí ACID a silně vynucenými cizími klíči pro relační integritu. Kirby chce výhodu automatického ladění výkonu zjednodušit každodenní správu databází.
Kirby se rozhodne pro databázi SQL v prostředcích infrastruktury se stejným databázovým strojem SQL jako Azure SQL Database. Databáze SQL v prostředcích infrastruktury se automaticky škálují tak, aby splňovaly poptávku po celý pracovní den. Mají plnou schopnost transakčních tabulek a flexibilitu úrovní izolace transakcí od serializovatelného až po čtení potvrzeného snímku. Databáze SQL v prostředcích infrastruktury automaticky vytváří a zahodí neclusterované indexy na základě silných signálů z plánů spouštění pozorovaných v průběhu času.
Ve scénáři Kirby musí být data z provozní aplikace spojená s dalšími daty v prostředcích infrastruktury: ve Sparku, ve skladu a z událostí v reálném čase v eventhouse. Každá databáze Fabric obsahuje koncový bod analýzy SQL, takže data, ke kterým se mají přistupovat v reálném čase ze Sparku nebo s dotazy Power BI pomocí režimu DirectLake. Tato řešení generování sestav šetří primární provozní databázi před režií analytických úloh a vyhněují se denormalizaci. Kirby má také existující provozní data v jiných databázích SQL a potřebuje je importovat bez transformace. Pokud chcete importovat existující provozní data bez převodu datového typu, Kirby navrhne datové kanály pomocí služby Fabric Data Factory pro import dat do databáze Fabric SQL.