Problém velkých dat
Velké objemy dat exponenciálně rostou. K tomuto jevu dochází již léta, ale jeho tempo se od roku 2012 dramaticky zrychlilo. Podívejte se na tento blog s názvem Big Data Just Beginning to Explode od CSC, kde najdete podobný pohled na vznik velkých dat a problémy s tím související.
IRI si je tohoto trendu vědoma již od založení společnosti na konci 70. let. Jeho vlajková loď CoSort je navržena tak, aby zvládla rostoucí objemy dat prostřednictvím efektivnosti softwarových algoritmů a designu, „přenosných“ technik využití hardwaru a konsolidace úloh (např. sort-join-aggregate-encrypt-report). Otázka, kterou tento článek pokládá, je otázkou přístupu vzhledem k „vzestupu strojů.“
Hardwarové omezení při jeho řešení
Výkon počítače se po desetiletí jistě zrychluje ve většině ohledů. A pro mnohé je házení hardwaru na problém velkých dat pouze druhou přirozeností. Problém však může být větší. Zvažte Moorův zákon, podle kterého se výkon CPU pouze zdvojnásobí v nejlepším případě každých 18 měsíců a inherentní zastaralost, problémy s údržbou a čisté náklady strategie zaměřené na hardware.
Něco nového, co je třeba zvážit, je také očekávání, že toto výkonové paradigma pro velká data se možná chýlí ke konci. Podle Geryho Menegaze je jeho předpokladem, že konec Moorova zákona je blízko. Časopis Time zveřejnil podobný článek v květnu 2012 s názvem Kolaps Moorova zákona: Fyzik říká, že se to už děje. Podle článku Time
Vzhledem k tomu Kaku říká, že až se Moorův zákon do konce příští dekády konečně zhroutí, „prostě [to] trochu upravíme pomocí počítačů podobných čipům ve třech rozměrech. Kromě toho říká „možná budeme muset přejít na molekulární počítače a možná koncem 21. století kvantové počítače.“
Pro většinu uživatelů je však jejich hardware kupován tak, aby zvládal a do jisté míry škáloval, aby čelil velkým výzvám zpracování dat, kterým čelí nebo které předvídají. Ale čím méně efektivně software na něm běží, tím více hardwarových prostředků musí být vynaloženo na překonání neefektivity. Příkladem v našem světě může být nákup IBM p595 pro běh /bin/sort, když by počítač o třetinové velikosti a nákladech s CoSort místo toho přinesl stejný výsledek.
Mezitím DB a ELT zařízení jako Exadata a Netezza postavená na hardwaru již vyžadují 6-7 ciferné investice. A i když mohou škálovat, aby přebírali větší zatížení, obvykle existuje limit toho, jak moc mohou škálovat (určitě ne exponenciálně), kolik peněz lze utratit za pokus o škálování a jak jsou lidé ochotni spoléhat se na jediného dodavatele pro každý kritický aspekt jejich pracovní zátěže. A je dobrý nápad místo toho uložit režii transformace velkých dat v databázích, které byly navrženy pro optimalizaci ukládání a načítání (dotazů)?
I kdyby všechny tyto otázky měly snadné odpovědi, jak se vyřeší výpočetní problémy (i jen s lineárním škálováním růstu velkých dat), které vyžadují exponenciálně větší spotřebu zdrojů (jako je třídění)? Zdá se, že odpověď nespočívá v pouhém čekání na dostupné kvantové výpočty…
Role softwaru
Jak architekti Hadoopu a datových skladů vědí, třídění – a operace spojení, agregace a načítání v ETL, které se spoléhají na třídění – jsou jádrem velkého problému zpracování dat a exponenciálním spotřebitelem výpočetní prostředky. Jak se velká data zdvojnásobují, požadavky na zdroje pro jejich třídění se mohou ztrojnásobit. Klíčem ke zvládnutí tohoto problému škálovatelnými, dostupnými a účinnými způsoby jsou proto algoritmy, techniky využití hardwaru a schémata zpracování spojená s multiplatformním, vícejádrovým třídicím softwarem.
Příspěvek CoSort
Výkon CoSort se lineárně mění v objemu, více v souladu s Amdahlovým zákonem. Zatímco CoSort dokáže transformovat stovky gigabajtů velkých dat během několika minut pomocí několika desítek jader, jiné nástroje mohou trvat více než dvakrát tak dlouho, neškálují se zdaleka tak dobře a/nebo spotřebovávají více paměti a I/O v procesu. Ještě důležitější je možná to, že CoSort integruje třídění přímo do souvisejících aplikací a veškerou svou těžkou práci dělá mimo vrstvy DB a BI, kde by byla příprava dat méně efektivní.
Co-rutinní architektura CoSort přesouvá záznamy mezi třídičem a programy jako SortCL (nástroj CoSort pro transformaci, filtrování, vyhledávání, hlášení, migraci a ochranu) interaktivně prostřednictvím paměti. Jakmile je tedy k dispozici další seřazený záznam, může se přesunout do aplikace, načíst atd. Aplikace vypadá, že čte vstupní soubor, ale ve skutečnosti ještě nebyl vytvořen zadní konec zdroje. A ne, nedostanete se před třídičem.
Na konci roku 2015 se CoSort stal také motorem v moderní platformě IRI pro správu a manipulaci s velkými daty, Voracity. Voracity bezproblémově využívá oba motory CoSort nebo Hadoop.
Závěr
Samotnými fyzickými výpočetními zdroji nelze počítat s řešením problému zpracování velkých dat. Softwarové prostředí CoSort je prostředí, ve kterém požadovaná transformace velkých dat a související úlohy neběží jako samostatné procesy, ale paralelně během stejného I/O průchodu.
Pokud tedy potřebujete rychlé třídění pro nějaký jiný účel než jen pro čas na třídění, měli byste přemýšlet o tom, co se stane po třídění, a o nejlepších způsobech, jak takové procesy propojit. A jakmile určíte nejlepší běhové paradigma, můžete pak kombinovat vysoce výkonný hardware s takovým softwarem pro optimalizaci výkonu? Můžete umístit data DW pomocí CoSort například na straně databázového serveru Exadata? Nebo by dávalo větší smysl ponechat si IBM p595 a přidat CoSort na trojnásobnou propustnost? Nebo pokud máte v úmyslu používat Hadoop, zvažte použití stejných jednoduchých 4GL CoSort nebo intuitivních mapování ETL Voracity k řízení úloh MapReduce 2, Spark, Storm nebo Tez.
Nechte svůj rozpočet a představivost, aby se staly vašimi průvodci při řešení růstu dat.