Základní prvky řízení dat

Správa dat je důležitá pro každou organizaci, která chce chránit svá data, a to zejména v regulovaných odvětvích, jako jsou finanční služby, zdravotnictví a farmacie, kde je to vyžadováno i zákony. Pokrývá to především oblast:

• Auditování – vedení podrobných a zabezpečených záznamů o každém přístupu a změně dat
• Určování závislostí – sledování původu dat a jejich využití v průběhu času
• Správa metadat – získávání informací o vlastních datech (rozlišujeme metadata technická – název tabulky, název souboru apod., nebo obchodní – klíčová slova apod.)
• Správa životního cyklu dat – správa dat od jejich vzniku až po jejich zánik včetně uchovávání, archivace, replikace, komprese a zálohování
• Datová kvalita a zásady přístupu – zajištění řádného katalogizování dat, jejich kvality a přístupnosti všem příslušným uživatelům

(Ne)řízený Hadoop

V big data oblasti se používá mnoho technologií, dominantní postavení patří ale Hadoop frameworku. Bohužel i přes jeho rozšířenost mu některé vlastnosti, na které jsme zvyklí z enterprise datových produktů, chybí, respektive nejsou v něm nativně k dispozici. Jednou z těchto vlastností jsou již zmíněné funkce pro správu data, respektive obtížná integrace se stávajícími řešeními pro správu dat zaměřenými především na svět relačních databází. Sledování změn v datech a kontrola přístupu k datům tak, jak ji známe ve světě datových skladů, v Hadoopu obecně neexistuje. Jedním z důvodů je široká škála typů dat – od strukturovaných (databázová tabulka) do semistrukturovaných (např. log soubor) a dokonce i nestrukturovaných (např. zvuk, obrázek). Je zřejmé, že citlivá data mohou být umístěna v kterémkoli z těchto souborů – je ovšem složité zjistit ve kterém. A už vůbec je problematické určit, zda neexistují úlohy, které tato data zpracovávají bez patřičných pravidel.

Dalším aspektem práce s daty v Hadoopu je, že vývojáři mají sklon svou práci dělit mezi různé nástroje v rámci Hadoop ekosystému jako například Apache Hive, Apache Spark či platformy s vyšší abstrakcí. Takže i když některé nástroje disponují potřebnými funkcemi, jednotná správa nad celým datovým tokem chybí.

To sebou nese nové výzvy a rizika, například:

• Získání přehledu, která data jsou používána a kým
• Zajištění, že výsledky jsou založeny na platných a kvalitních údajích
• Dodržení interních a externích regulatorních požadavků
• Mechanizmus pro zajištění přístupu uživatelů k datům, pro která mají oprávnění
• Udržování centralizované politiky (například ACL), která je prosazována napříč různými nástroji
• Zjištění, jak data protékají systémem a jak jsou transformována
• Určení, jak změny v datech a jejich zpracování budou mít vliv na další komponenty výpočtu

Pro úspěšný Hadoop projekt je nezbytně nutné pečlivě vybrat použité komponenty, a to nejen z hlediska funkčnosti, ale i s ohledem na zajištění správy dat.

Přehled řešení

Výše uvedené výzvy se většina komerčních distribucí či nadstaveb snaží více či méně úspěšně řešit. Ale i v rámci open source Hadoop ekosystému je snaha tuto problematiku postihnout. Stručné představení některých slibných projektů uvádím níže:

Apache Sentry

Apache Sentry poskytuje autorizaci přístupu k datům na bázi rolí. V současné době podporuje komponenty Apache Hive a Hive Metastore, Apache Solr, Impala a částečně HDFS. Sentry je navrženo jako autorizační zásuvný modul, dovolující definici pravidel přístupu uživatelů či aplikací k datům v rámci Hadoopu.

Obr. 1: Komponenty Apache Sentry

Koncepce Sentry je naznačena na obrázku 1:

• Sentry Server – RPC server spravující metadata. Poskytuje rozhraní pro jejich čtení a manipulaci
• Data Engine – aplikace pro zpracování dat (Hive, Imapala), která vyžaduje autorizaci přístupu k datům či zdrojům. Všechny požadavky klientů o přístup jsou směrovány na Sentry plugin, který zajistí jejich validaci
• Sentry Plugin – proces běžící na straně aplikace. Nabízí rozhraní pro manipulaci s autorizačními metadaty uloženými na Sentry serveru a na základě politik vyhodnocuje požadavky o přístup

Apache Ranger

Apache Ranger poskytuje komplexní přístup ke správě autorizačních politik. Jeho architektura je oproti Sentry obecnější a snadněji rozšiřitelná. Mimo Hive ho lze použít například s HDFS, HBase, Storm a Kafkou. Řešení také poskytuje možnost delegovat správu určitých dat jiným vlastníkům s cílem bezpečně decentralizovat vlastnictví dat. 

Obr. 2: Apache Ranger architektura

Jádrem Apache Ranger je centrální aplikace zajišťující administraci politik a auditování. Vynucení autorizačních politik mají na starosti Ranger zásuvné moduly, které jsou specifické pro každou aplikaci. Zásuvný modul je zahrnut v samotné aplikaci a je součástí stejného procesu – Namenode (HDFS), Hive Server (Hive), HBase serveru (HBase) apod., čímž zjednodušuje správu procesů na jednotlivých uzlech clusteru.

Apache Falcon

Apache Falcon je framework pro zjednodušení řízení životního cyklu dat v rámci Hadoopu. Umožňuje uživatelům konfigurovat, spravovat a řídit pohyb dat, jejich zpracování, obnovu po haváriích a uchovávání. Zjednodušení správy dat umožňuje vývojářům aplikací převést správu životního cyklu dat na Falcon namísto její implementace v aplikaci. Zároveň Falcon framework staví na osvědčených technologiích (Oozie, DistCP), a nezavádí tím tedy další komplexní aplikaci do prostředí Hadoopu.

Výše uvedené projekty řeší správu dat v prostředí Hadoopu prozatím bez přesahu do jiných technologií. V komplexním prostředí, kde je Hadoop pouze jednou z datových platforem, je vhodné metadata z těchto platforem integrovat například v podobě BI portálu, který zajistí jejich snadné vyhledávání a katalogizaci napříč celou společností.

Shrnutí

Schopnost poskytovat více dat více uživatelům je jednou z hlavních výhod Hadoopu. Nicméně odvrácenou stranou těchto výhod je, že je složitější sledovat, kdo přistupuje k jakým datům, a co s nimi dělá. Pro úspěšný Hadoop projekt je nezbytně nutné pečlivě vybrat použité komponenty, a to nejen z hlediska funkčnosti, ale i s ohledem na zajištění správy dat ve všech zmíněných ohledech. Je to jeden z důležitých bodů pro to, aby se big data technologie staly standardní součástí firemní datové infrastruktury.

Ondřej Dolák Autor článku je BI Architect společnosti Trask solutions, a. s.