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 | Lakehouse | sklad | Eventhouse |
|---|---|---|---|
| objem dat | Neomezený | Neomezený | Neomezený |
| Druh dat | Nestrukturovaný částečně strukturovaná, strukturovaný |
Strukturovaný částečně strukturovaná (JSON) |
Nestrukturovaný částečně strukturovaná, strukturovaný |
| primární persona 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í programátorské dovednosti | 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 | Ne | Ano | Ano, pro vkládání více tabulek |
| primárního vývojového 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 | na úrovni objektu , RLS, CLS, DDL/DML, dynamické maskování dat | RLS |
| Přístupujte k datům prostřednictvím klávesových zkratek | Ano | Ano, prostřednictvím koncového bodu SQL Analytics | Ano |
| může být zdrojem pro klávesové zkratky | Ano (soubory a tabulky) | Ano (tabulky) | Ano |
| Dotaz napříč položkami | Ano | Ano | Ano |
| pokročilá analytika | 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ě a streamovaný příjem dat mají zpoždění několik sekund. |
* 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 | Fabric SQL databáze | Power BI Datamart |
|---|---|---|
| objem dat | 4 TB | Až 100 GB |
| Typ datového | Strukturovaný částečně strukturovaná, nestrukturovaný |
Strukturovaný |
| Primární persona 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 vývojáře | 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 | Datové toky, T-SQL |
| transakce s více tabulkami | Ano, plná shoda s ACID | Ne |
| primárního vývojového rozhraní | Skripty SQL | Power BI |
| zabezpečení | Úroveň objektů, RLS, CLS, DDL/DML, dynamické maskování dat | Integrovaný editor RLS |
| Přístup k datům prostřednictvím klávesových zkratek | Ano | Ne |
| může být zdrojem pro klávesové zkratky | Ano (tabulky) | Ne |
| Dotaz napříč položkami | Ano | Ne |
| pokročilá analytika | Analytické možnosti T-SQL, data replikovaná do formátu delta parquet v OneLake pro analýzu | 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, vektor, graf, XML, prostorové, klíč-hodnota | 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
Prohlédněte si tyto scénáře pro pomoc při výběru úložiště dat ve Fabric.
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. Při zvažování většího týmu jsou primárními spotřebiteli těchto dat také ti, kteří mají zkušenosti s SQL a analytickými nástroji SQL. Susan se rozhodne použít sklad Fabric, který týmu umožňuje především pracovat s T-SQL, a zároveň umožňuje 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 Fabric. 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, což týmu pro přípravu dat umožňuje využívat své různorodé dovednosti při práci s daty, a zároveň umožňuje členům týmu, kteří jsou vysoce zkušení v T-SQL, pracovat s daty.
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 lakehouse, a že tyto možnosti se zdají být příliš složité pro jejich 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 Microsoft Office, a ví, že už mají předplatné kapacity Premium. Když přemýšlejí o svém širším týmu, uvědomují si, že primární uživatelé těchto dat jsou analytici, kteří se orientují v no-code a SQL analytických nástrojích. Ash se rozhodne použít datamart Power BI , který týmu umožňuje rychle rozvíjet schopnosti pomocí bezkódového prostředí. 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ází ze závodů, od 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ého dotazu 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 úplným dodržováním vlastností ACID, vysokou souběžností a silně vynucenými cizími klíči pro relační integritu. Kirby chce využít výhody automatického ladění výkonu ke zjednodušení každodenní správy databází.
Kirby se rozhodne pro databázi SQL ve Fabricuse stejným SQL databázovým strojem jako Azure SQL Database. Databáze SQL v systému Fabric se automaticky škálují tak, aby splňovaly poptávku po celý pracovní den. Mají plnou funkčnost transakčních tabulek a flexibilitu úrovní izolace transakcí od serializovatelného až po potvrzené snímkové čtení. Databáze SQL ve Fabricu automaticky vytváří a zahodí neclusterované indexy na základě silných signálů z prováděcích plánů pozorovaných v průběhu času.
Ve scénáři Kirbyho musí být data z provozní aplikace spojena s dalšími daty ve Fabric: 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, což umožňuje přístup k datům v reálném čase ze Sparku nebo prostřednictvím dotazů Power BI s použitím režimu DirectLake. Tato řešení pro sestavy chrání primární provozní databázi před zátěží způsobenou analytickými úlohami a vyhýbají 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.