osvědčené postupy pro používání Azure Data Lake Storage Gen2

tento článek popisuje osvědčené postupy, které vám pomůžou optimalizovat výkon, snížit náklady a zabezpečit Azure Storage účet povolený v Data Lake Storage Gen2.

Najít dokumentaci

Azure Data Lake Storage Gen2 není vyhrazený typ služby nebo účtu. Jedná se o sadu funkcí, které podporují analytické úlohy s vysokou propustností. dokumentace k Data Lake Storage Gen2 poskytuje osvědčené postupy a pokyny pro použití těchto možností. V dokumentaci k úložišti objektů BLOB najdete všechny další aspekty správy účtů, jako je nastavení zabezpečení sítě, návrh pro vysokou dostupnost a zotavení po havárii.

Vyhodnotit podporu funkcí a známé problémy

Při nastavování účtu pro používání funkcí úložiště BLOB použijte následující vzor.

1. přečtěte si článek podpora funkcí Blob Storage v článku Azure Storage účty , abyste zjistili, jestli je funkce ve vašem účtu plně podporovaná. některé funkce ještě nejsou podporované nebo mají v Data Lake Storage Gen2 povolené účty částečnou podporu. Podpora funkcí se vždycky rozšiřuje, takže nezapomeňte pravidelně kontrolovat tento článek pro aktualizace.

2. přečtěte si o známých problémech s Azure Data Lake Storage Gen2 článkem a zjistěte, jestli existují nějaká omezení nebo zvláštní pokyny pro funkci, kterou chcete použít.

3. prohledejte články s funkcemi pro všechny doprovodné materiály, které jsou specifické pro Data Lake Storage Gen2 povolené účty.

Pochopení podmínek používaných v dokumentaci

Při přesunu mezi sadami obsahu si všimnete některých drobných rozdílů v terminologii. Například obsah, který je doporučený v dokumentaci k úložišti objektů BLOB, bude používat pojem BLOB místo souboru. Technicky, soubory, které ingestují do účtu úložiště, se stanou objekty blob ve vašem účtu. Proto je podmínka správná. To však může způsobit nejasnost, pokud používáte k souboru termínu. Zobrazí se také termín kontejneru , který se používá k odkazování na systém souborů. Tyto výrazy zvažte jako synonymum.

Zvážit Premium

Pokud vaše úlohy vyžadují nízkou latenci a/nebo vyžadují vysoký počet vstupních výstupních operací za sekundu (IOP), zvažte použití účtu úložiště blob bloku Premium. Tento typ účtu zpřístupňuje data prostřednictvím vysoce výkonného hardwaru. Data se ukládají na jednotky SSD (SSD), které jsou optimalizované pro nízkou latenci. SSD poskytují vyšší propustnost v porovnání s tradičními pevnými disky. Náklady na úložiště úrovně Premium jsou vyšší, ale náklady na transakce jsou nižší, takže pokud vaše úlohy spouštějí velký počet transakcí, může být účet objektu blob bloku Premium Premium ekonomický.

pokud se váš účet úložiště bude používat pro analýzy, důrazně doporučujeme použít Azure Data Lake Storage Gen2 společně s účtem úložiště objektů blob bloku premium. tato kombinace s účtem úložiště objektů blob bloku premium spolu s účtem s povoleným Data Lake Storage se označuje jako úroveň premium pro Azure Data Lake Storage.

Optimalizovat pro přijímání dat

Při ingestování dat ze zdrojového systému může být zdrojový hardware, zdrojový síťový hardware nebo síťové připojení k vašemu účtu úložiště kritickým bodem.

Zdrojový hardware

Bez ohledu na to, jestli používáte místní počítače nebo Virtual Machines (VM) v Azure, pečlivě vyberte příslušný hardware. V případě hardwarového disku zvažte použití jednotek SSD (Solid State Drive) a výběr diskového hardwaru s rychlejšími disky. V případě síťového hardwaru Používejte co možná nejrychlejší řadiče síťového rozhraní (NIC). V Azure doporučujeme virtuální počítače Azure s D14, které mají vhodně výkonný disk a síťový hardware.

Síťové připojení k účtu úložiště

Síťové připojení mezi zdrojovými daty a vaším účtem úložiště může někdy být kritickým bodem. Když jsou zdrojová data místní, zvažte použití vyhrazeného propojení s Azure ExpressRoute. pokud jsou zdrojová data v Azure, výkon je nejlepší, když jsou data ve stejné oblasti Azure jako účet s povoleným Data Lake Storage Gen2.

Konfigurace nástrojů pro přijímání dat pro maximální paralelismus

Abyste dosáhli nejlepšího výkonu, využijte veškerou dostupnou propustnost, která paralelně provede tolik operací čtení a zápisu.

Následující tabulka shrnuje nastavení klíče pro několik oblíbených nástrojů pro přijímání.

Váš účet se může škálovat, aby poskytoval potřebnou propustnost pro všechny scénáře analýzy. ve výchozím nastavení má účet s povoleným Data Lake Storage Gen2 dostatek propustnosti ve své výchozí konfiguraci, aby splňoval požadavky široké kategorie případů použití. Pokud narazíte na výchozí limit, může se účet nakonfigurovat tak, aby poskytoval větší propustnost, a to kontaktováním podpory Azure.

Sady dat struktury

Zvažte možnost předběžného plánování struktury dat. Formát souboru, velikost souboru a struktura adresářů mohou mít vliv na výkon a cenu.

Formáty souborů

Data je možné ingestovat v různých formátech. Data je možné zobrazit ve formátech pro lidské čtení, jako jsou JSON, CSV nebo XML, nebo jako komprimované binární formáty, jako je například .tar.gz . Data mohou pocházet i v různých velikostech. data se dají skládat z velkých souborů (několik terabajtů), jako jsou data z exportu SQL tabulky z místních systémů. Data mohou také pocházet ve formě velkého počtu drobných souborů (několik kilobajtů), jako jsou například data z událostí v reálném čase z řešení internetu věcí (IoT). Můžete optimalizovat efektivitu a náklady výběrem vhodného formátu souboru a velikosti souboru.

Hadoop podporuje sadu formátů souborů, které jsou optimalizované pro ukládání a zpracování strukturovaných dat. Mezi běžné formáty patří Avro, Parquet a optimalizovaný formát řádků (ORC). Všechny tyto formáty jsou strojově čitelné binární formáty souborů. Jsou komprimované, aby vám pomohly spravovat velikost souborů. Mají schéma vložené do každého souboru, který je usnadňuje. Rozdíl mezi těmito formáty je v tom, jak jsou data uložená. Avro ukládá data ve sloupcovém formátu a formáty Parquet a ORC ukládají data ve sloupcovém formátu.

Zvažte použití formátu souboru Avro v případech, kdy jsou vstupně-výstupní vzory složitější, nebo se vzory dotazů upřednostní načítání více řádků záznamů v celém rozsahu. Například formát Avro funguje dobře se sběrnicí zpráv, jako je centrum událostí nebo Kafka, které zapisují více událostí/zpráv po sobě.

Formáty souborů Parquet a ORC zvažte, když jsou vstupně-výstupní vzory mnohem čteny, nebo když jsou vzory dotazů zaměřené na podmnožinu sloupců v záznamech. Transakce čtení se dají optimalizovat tak, aby se místo čtení celého záznamu načítala konkrétní sloupce.

Apache Parquet je otevřený formát zdrojového souboru, který je optimalizovaný pro čtení analytických kanálů se silným přehledem. Sloupcová struktura úložiště Parquet umožňuje přeskočit nerelevantní data. Dotazy jsou mnohem efektivnější, protože mohou zúžit rozsah dat, která se mají odeslat z úložiště do analytického stroje. Vzhledem k tomu, že se podobné datové typy (pro sloupec) společně ukládají, Parquet podporuje efektivní komprimaci a kódování dat, které můžou snížit náklady na úložiště dat. Služby, jako je Azure synapse Analytics, Azure Databricks a Azure Data Factory mají nativní funkce, které využívají formáty souborů Parquet.

Velikost souboru

Větší soubory vedou k lepšímu výkonu a snížení nákladů.

Analytické stroje, jako je HDInsight, mají obvykle režijní náklady na jednotlivé soubory, které zahrnují úkoly, jako je například výpis, kontrola přístupu a provádění různých operací s metadaty. Pokud uložíte data jako mnoho malých souborů, může to negativně ovlivnit výkon. Obecně je vhodné uspořádat data do souborů s větší velikostí, aby se zajistil vyšší výkon (256 MB až 100 GB). Některé moduly a aplikace můžou mít problémy efektivně se zpracováním souborů, které mají velikost větší než 100 GB.

Zvýšení velikosti souboru může také snížit náklady transakce. Operace čtení a zápisu se účtují v přírůstcích po 4 megabajtech, takže se vám bude účtovat operace bez ohledu na to, jestli soubor obsahuje 4 megabajty nebo jenom pár kilobajtů. informace o cenách najdete v tématu Azure Data Lake Storage ceny.

V některých případech mají datové kanály omezenou kontrolu nad nezpracovanými daty, což má spoustu malých souborů. Obecně doporučujeme, aby váš systém měl nějaký proces pro agregaci malých souborů na větší počet pro použití v aplikacích pro příjem dat. Pokud zpracováváte data v reálném čase, můžete použít modul streamování v reálném čase (například Azure Stream Analytics nebo Spark streamování) společně s zprostředkovatelem zpráv (jako je například centrum událostí nebo Apache Kafka) k ukládání dat do větších souborů. Při agregaci malých souborů do větších je vhodné je Uložit do formátu optimalizovaného pro čtení, jako je Apache Parquet pro zpracování pro příjem dat.

Adresářová struktura

Každé zatížení má různé požadavky na způsob, jakým se data spotřebovávají, ale jedná se o některá běžná rozložení, která je potřeba vzít v úvahu při práci s Internet věcí (IoT), v dávkových scénářích nebo při optimalizaci pro data časových řad.

Struktura IoT

V úlohách IoT se může jednat o data, která se ingestují v různých produktech, zařízeních, organizacích a zákaznících. Je důležité předem naplánovat rozložení adresáře pro organizaci, zabezpečení a efektivní zpracování dat pro uživatele se vzdálení datovými proudy. Obecná šablona, kterou je třeba zvážit, může být následující rozložení:

*{Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/*

Například vykládka telemetrie pro stroj v letadle v rámci Velké Británie může vypadat jako tato struktura:

*UK/Planes/BA1293/Engine1/2017/08/11/12/*

V tomto příkladu tak, že umístíte datum na konci adresářové struktury, můžete použít seznamy ACL k jednoduššímu zabezpečení oblastí a předmětům věcí konkrétním uživatelům a skupinám. Pokud zadáte datovou strukturu na začátku, může být mnohem obtížnější zabezpečit tyto oblasti a záležitosti v předmětech. Pokud byste například chtěli poskytnout přístup pouze k datům Spojené království nebo určitým rovinám, je nutné použít samostatné oprávnění pro mnoho adresářů v každém adresáři s hodinami. Tato struktura by také exponenciálně zvýšila počet adresářů v době, kdy se čas stala.

Struktura úloh Batch

Běžně používaným přístupem při dávkovém zpracování je umístit data do adresáře "in". Až se data zpracují, vložte nová data do adresáře "out", aby bylo možné procesy pro příjem dat využívat. Tato struktura adresáře se někdy používá pro úlohy, které vyžadují zpracování na jednotlivých souborech, a nemusí vyžadovat výkonné paralelní zpracování v rámci velkých datových sad. Podobně jako u výše zmíněné struktury IoT obsahuje vhodná adresářová struktura pro věci, jako je například oblast a předmět (například organizace, produkt nebo producent). V rámci struktury zvažte datum a čas, které umožní lepší organizaci, filtrovaná hledání, zabezpečení a automatizaci ve zpracování. Úroveň členitosti struktury data Určuje interval, ve kterém jsou data nahraná nebo zpracovaná, například každou hodinu, každý den nebo dokonce měsíčně.

Občas se zpracování souborů nezdařilo z důvodu poškození dat nebo neočekávaných formátů. V takových případech může adresářová struktura těžit ze složky /Bad , aby přesunula soubory do pro další kontrolu. Úloha služby Batch může také zpracovávat zprávy a oznámení těchto neplatných souborů pro ruční zásah. Vezměte v úvahu následující strukturu šablon:

*{Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/*\ *{Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/*\ *{Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/*

Například marketingový firmu obdrží denní datové výtažky aktualizací zákazníků od jejich klientů v Severní Amerika. Může vypadat jako následující fragment kódu před a po zpracování:

*NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv*\ *NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv*

v běžném případě jsou data služby batch zpracovávána přímo do databází, jako je například podregistr nebo tradiční databáze SQL, není nutné mít adresář /in nebo /out , protože výstup již patří do samostatné složky pro tabulku podregistru nebo externí databázi. Například denní výpisy ze zákazníků by se měly nakládat do příslušných adresářů. Služba, jako je například Azure Data Factory, Apache Oozienebo Apache Flow , by mohla aktivovat denní podregistr nebo úlohu Spark pro zpracování a zápis dat do tabulky podregistru.

Datová struktura časové řady

V případě úloh podregistru může vytváření oddílů při vyřazování dat časových řad v některých dotazech pomáhat několik dotazů, které čtou pouze podmnožinu dat, což zvyšuje výkon.

Tyto kanály, které ingestují data časových řad, často umísťují své soubory se strukturovaným pojmenování pro soubory a složky. Níže je uveden běžný příklad, který se zobrazuje pro data strukturovaná podle data:

\DataSet\YYYY\MM\DD\ datafile_YYYY_MM_DD. TSV

Všimněte si, že informace o typu DateTime se zobrazí jak jako složky, tak i v názvu souboru.

Pro datum a čas je toto běžný vzor.

\DataSet\YYYY\MM\DD\HH\mm\ datafile_YYYY_MM_DD_HH_mm. TSV

Výběr, který provedete se složkou a organizací souborů, by se měl optimalizovat pro větší velikosti souborů a přiměřený počet souborů v každé složce.

Nastavení zabezpečení

Začněte tím, že si prohlédnete doporučení k zabezpečení služby Blob Storage v tématu doporučení zabezpečení . najdete pokyny k osvědčeným postupům, jak chránit vaše data před náhodným nebo škodlivým odstraněním, zabezpečením dat za bránou firewall a používáním Azure Active Directory (Azure AD) jako základu správy identit.

pak si přečtěte model řízení přístupu v Azure Data Lake Storage Gen2 článku, kde najdete pokyny, které jsou specifické pro Data Lake Storage Gen2 s povolenými účty. Tento článek vám pomůže pochopit, jak používat role řízení přístupu na základě role Azure (Azure RBAC) společně se seznamy řízení přístupu (ACL) k vymáhání oprávnění zabezpečení pro adresáře a soubory v hierarchickém systému souborů.

Ingestování, zpracování a analýza

existuje mnoho různých zdrojů dat a různými způsoby, jak lze tato data do účtu s povoleným Data Lake Storage Gen2 ingestovat.

Můžete například ingestovat velké sady dat z clusterů HDInsight a Hadoop nebo menší sady dat ad hoc pro vytváření prototypů aplikací. Můžete ingestovat streamovaná data generovaná různými zdroji, jako jsou aplikace, zařízení a senzory. Pro tento typ dat můžete pomocí nástrojů zachytit a zpracovat data na základě události v reálném čase a potom do svého účtu zapisovat události v dávkách. Můžete také ingestovat webový server, který obsahuje informace, jako je třeba historie požadavků na stránky. V případě dat protokolů zvažte možnost napsat si vlastní skripty a aplikace, abyste je nahráli, abyste měli flexibilitu jako součást vaší větší aplikace pro velké objemy dat.

jakmile jsou data ve vašem účtu dostupná, můžete spustit analýzu těchto dat, vytvořit vizualizace a dokonce i stáhnout data do místního počítače nebo do jiných úložišť, jako je například databáze Azure SQL nebo instance SQL Server.

Následující tabulka doporučuje nástroje, které můžete použít k ingestování, analýze, vizualizaci a stahování dat. Pomocí odkazů v této tabulce najdete pokyny ke konfiguraci a použití jednotlivých nástrojů.

Monitorovat telemetrii

Sledování využití a výkonu je důležitou součástí zprovozňování vaší služby. Mezi příklady patří časté operace, operace s vysokou latencí nebo operace, které způsobují omezování na straně služby.

veškerá telemetrie pro váš účet úložiště je k dispozici prostřednictvím Azure Storage protokoly v Azure Monitor. Tato funkce integruje váš účet úložiště s Log Analytics a Event Hubs a zároveň vám umožní archivovat protokoly do jiného účtu úložiště. úplný seznam protokolů metrik a prostředků a jejich přidružené schéma najdete v tématu Azure Storage referenční informace o monitorování dat.

Pokud se rozhodnete ukládat protokoly, záleží na tom, jak plánujete přístup k nim. Pokud například chcete mít přístup k protokolům prakticky v reálném čase a budete moci korelovat události v protokolech s jinými metrikami z Azure Monitor, můžete své protokoly ukládat do pracovního prostoru Log Analytics. To umožňuje dotazování protokolů pomocí KQL a vytváření dotazů, které vyčíslují StorageBlobLogs tabulku v pracovním prostoru.

Pokud chcete ukládat protokoly pro dotaz téměř v reálném čase i pro dlouhodobé uchovávání, můžete nakonfigurovat nastavení diagnostiky tak, aby odesílala protokoly do Log Analyticsho pracovního prostoru i účtu úložiště.

Pokud chcete získat přístup k protokolům prostřednictvím jiného dotazovacího stroje, jako je například Splunk, můžete nakonfigurovat nastavení diagnostiky tak, aby se protokoly odesílaly do centra událostí a protokoly ingestují z centra událostí do vybraného cíle.

protokoly Azure Storage v Azure Monitor můžete povolit prostřednictvím šablon Azure Portal, powershellu, Azure CLI a Azure Resource Manager. Pro nasazení ve velkém měřítku Azure Policy možné použít s plnou podporou pro úlohy nápravy. další informace najdete v tématu Azure/Community-policy a ciphertxt/AzureStoragePolicy.

Viz také

• model řízení přístupu v Azure Data Lake Storage Gen2
• Data Lake průvodce pro hitchhiker
• přehled Azure Data Lake Storage Gen2