Hlavní navigace

Zápisky z konference Apache: Big Data Europe 2015

5. 10. 2015
Doba čtení: 15 minut

Sdílet

Na konci září se v maďarské Budapešti konala konference Apache: Big Data Europe 2015, která na jedno místo přivedla odborníky, vědce a vývojáře open-source, kteří se zabývají zpracováním ohromného množství dat. Čím NASA zpracovává 4Tbps datový tok? Jak se ukládají ohromná data z LHC v CERN?

„State of the feather“ (Stav pírka)

Shane Curcuru, Apache vice president, brand manager

V úvodní přednášce celé konference zaznělo představení Apache foundation a osvětlení důvodů, proč tato nadace zastřešuje konferenci. Jako nejdůležitější součást nadace byli několikrát zmiňováni dobrovolníci, bez kterých by to nešlo. Nadace jako taková poskytuje pouze technické a administrativní zázemí pro projekty, samotné směřování je na komunitě kolem jednotlivých projektů. V současné době zastřešují 167 aktivních projektů a 45 je v procesu posuzování. Motto celé přednášky bylo: „Pokud máte komunitu, Apache bude rádo hostovat váš projekt, bez ohledu na použitou technologii.“Zajímavé bylo i představení rozpočtu nadace. Roční příjem tvoří přibližně milion dolarů, ale projekty, které zastřešují, mají hodnotu miliard a dle slov přednášejícího pomáhají šířit po světě dobro.

„Big Science and Big data at CERN“

Dirk Duelmann, deputy leader for data & storage service, CERN

Další v bloku keynotes následovala přednáška o využití Big Data technologií v CERNu. Sám autor popsal CERN jako pouhou infrastrukturu pro komunitu fyziků. Pro představu bylo přiblíženo i množství dat, generované v rámci projektu LHC. V době experimentu se odehraje kolem 40 milionů kolizí za sekundu a vzniklý datový tok se pohybuje v řádu PB/s, to je potřeba redukovat na přijatelnější hodnoty pro další práci. Vzhledem k množství dat existují v CERNu po provedení experimentu pouze v jedné kopii, ale jsou ihned replikovány na 12 TIER-1 lokací po světa. Pro samotné zálohy dat se stále používají pásky, protože mají vysokou efektivitu vzhledem ke spotřebované elektřině. Pravidelně také dochází k vylepšování páskového robota, kdy s příchodem nových technologií se kapacita jednotlivých pásek násobí. Momentálně mají přes 30 tisíc pásek, ale díky obměně a pravidelnému přehrávání na pásky o větší kapacitě stále mají dostatek volného místa. Na experimentech kolem CERNu se podílí přes 10 tisíc fyziků, což vede k velkému množství následně vygenerovaných dat, kdy různé týmy data čistí, agregují a dále zpracovávají. Zároveň hledají způsoby, jak si současné technologie přizpůsobit svým potřebám a výsledky těchto snah sdílejí s opensource komunitou, kde jsou velmi aktivní a jejíž nástroje ve velké míře používají právě díky možnostem přizpůsobení.

The destiny of data

Arun Murthy, Hortonworks

Přednášející ukazoval význam Big Data na příkladu vyhledávače, který má naindexovanou každou stránku na internetu, ale s konvenčními prostředky je problém z dat získat historii a komplexně je analyzovat. Jedním z důvodů je i fakt, že jeden MapReduce vygeneruje přes 3 TB surových dat. V této keynotes zazněla i tolik oblíbená prognóza do budoucna, tentokrát, vzhledem k zaměření konference na množství Big Data produkovaných za rok. Zatím co v letošním roce se očekává vygenerování kolem 4ZB dat, což je hlavně díky chytrým telefonům, v roce 2020 by měl objem BigData činit až 44ZB, neboť trend už není Internet of Things, ale Internet of AnyThing. No nezbývá než čekat, zda se prognóza vyplní a termín uchytí. Dobrou zprávou by mohlo být, že u Internet of AnyThing autor jako hlavní podmínku zmiňuje zabezpečenou obousměrnou komunikaci, která v prvé řadě umožní distribuci oprav při výskytu chyby. To by mohl být pozitivní trend do budoucna, ale stále je to hlavně na výrobcích, zda budou opravy vyrábět a vydávat. Už jen na okraj byl zmíněn odklon od plnotučných virtuálních strojů ke kontejnerům, hlavně k dockeru, z důvodů snižování režie.

Data science in the travel Industry

Paul Balm, Amadeus

Prezentace use case využití BigData ve firmě Amadeus. Firma začínala na konci 80. let s tvorbou systému pro sdílení rezervačních dat mezi aerolinkami, který uvedla na počátku 90. let. V tomto období se řešily rezervace letů hlavně po telefonu. Už od počátku se ukládala všechna dostupná data s ideou jejich možného budoucího využití. Problémem se však ukázala velká různorodost zdrojů a formátů poskytovaných dat. Nyní jsou tato data podkladem pro predikci budoucího vývoje při zavádění nových linek, kdy se na základě komplexního indexu zohledňujícího velké množství faktorů jako cena, doba letu, nabízené služby, nebo například i vývoj počasí v cílovém městě modeluje množství pasažérů. I přes snahu zpracovávat data v reálném čase stále vychází hlavně pro historická data výhodněji dávkové zpracování. Jeden z dotazů směřoval i na opakovanou použitelnost těchto reportů, které se dělají na přání zákazníků a z následné diskuze vyplynulo, že i když je snaha mít co nejvíce univerzální řešení, každý zákazník chce trochu jiná data a příprava reportů stále obsahuje značné množství ruční práce.

One click hadoop clusters – anywhere

Janos Matyas, Hortonworks

Lidé z firmy Hortonworks se při své práci nástroji pro BigData potýkali s problémy při vývoji nových aplikaci a jejich uvádění do produkce. Šlo hlavně o neustálé nasazování nových serverů pro různá oddělení a různorodé projekty. Přes několik stupňů automatizace se dopracovali až k systému, který umožňuje automatické nasazovaní serverů bez nutnosti externího zásahu pro všechny fáze životního cyklu systému. Díky této automatizaci je možno kontrolovat plnění například SLA a podle potřeby nasazovat další stoje. Celý systém je založen na kombinaci nástrojů Docker, Swarm, Consul a Apache Ambari. Swarm například umožňuje spravovat docker cluster pomocí stejného API, jako samotný docker. Jako vedlejší produkt celého projektu vznikly docker image pro celý hadoop stack, které jsou volně k dispozici. Bohužel už jen na okraj bylo zmíněno, že zvětšování clusteru je velmi snadné, ale jeho zmenšování je více komplikované, nejspíše v souvislosti s přesouváním zdrojů na zbývající běžící uzly

High throughput Kafka for science

Jane Wyngaard, NASA JPL

Přednáška lidí z NASA slibovala zajímavé technické povídání bez marketingových vsuvek. Na začátku jsme byli seznámeni s problémy, které se aktuální řeší, jedná se hlavně o zpracování velkého množství dat ze soustavy radioteleskopů, kde souhrnný datový tok je kolem 4 Tbps a k předávání zpráv by chtěli použít Apache Kafka. Samotné testování bylo označeno jako líný benchmark, kdy se jen vezme cluster 96 strojů, ze kterých se sestaví lab. Stroje však neměly úplně mainstreamové parametry, krom zapojení do 40Gbps sítě například zaujaly i 0,5 PB NAND úložištěm. I přes tuto sestavu se podařilo dostat jen k rychlosti cca 1 Gbps pro samotné zprávy do velikosti 5 MB na zprávu. U hodnoty 5 MB byl významnýnárůst na rychlost 6 Gbps a pak opět propad k 1 Gbps. Vysvětlení tohoto nárůstu však během měření nenašli. Bohužel v prezentaci chyběla informace o režii systému Kafka i TCP. Z následující debaty vyplynulo, že tyto hodnoty ani nebyly měřeny. Tuto přednášku ale osobně považuji za hozenou rukavici ke komplexnějšímu měření propustnosti tohoto systému.

IPython Notebook as a Unified Data Science Interface for Hadoop

Casey Stella

Představení nástroje pro snadnou práci s velkými daty. Nástroj, nebo spíše dobře zabalená sada nástrojů, poskytují možnost připojit se ke zdrojovým datům a provádět nad těmito daty rychlou analýzu pomocí jazyku python. Dle přednášejícího nejsou nástroje pro data science „naštěstí“ kompatibilní s JVM a použití pythonu umožňuje využití silného zázemí knihoven a snadné propojení mnoha zdrojů dat, stejně jako vizualizaci výsledků. Jako příklad užití byla uvedena Open Payment Data, která v USA obsahují souhrn plateb od firem pro lékaře. Z velké části se jedná o platby farmaceutických firem a i když samotná data jsou částečně agregovaná a neobsahují konkrétní jména lékařů, mohou dobře posloužit pro náhled do problematiky. Při pohledu na výdaje dle lékařských oborů se ukázalo, že 20 % všech příjmů jde do ortopedie a například lékaři zabývající se diabetem, kterým trpí 20 % obyvatel, inkasují pouze 3% z celkového koláče. Nejvíce peněz směřuje na kapitolu jídlo a pití, ale díky analýze jsou zde i velmi podezřelé až chybné údaje, kdy například jeden lékař v rámci jedné platby inkasoval 60 000 USD v kategorii občerstvení, kde se průměr pohyboval kolem 150 USD. Autor došel na základě tohoto a dalších údajů k přesvědčení, že data jsou sice dostupná, ale nikdo je moc nekontroluje, protože jejich zpracování bez vhodných nástrojů vyžaduje celkem mnoho úsilí.

R as a language for big data analytics

Andrie de Vries, Microsoft

Jazyk R je zaměřen především na statistiku a díky tomu je využíván i pro datovou analytiku. Ačkoliv není žádným nováčkem na poli jazyků, do popředí se dostává hlavně nyní v souvislosti s fenoménem BigData. Naučili se ho využívat například novináři, kdy NY Times s jeho pomocí vytvářejí předpovědi volebních výsledků nebo predikci výběru nováčků v jejich lize amerického fotbalu NFL. Přednášející zmínil i využití jazyku R ve firmě Microsoft, kdy jim například pomáhá optimalizovat in-game prodeje na platformě Xbox a nebo plánování zdrojů potřebných pro cloudovou platformu Azure. V plánu je i poskytování data science „as a service“.

How Apache Drives music recommendations at Spotify

Josh Baer

Úterní keynotes otvírá příběh o počátku služby Spotify, kdy se její budoucí spoluautorseznámí s obsluhou hudebního obchodu, začne s nimi probírat hudbu, která se mu líbí a obsluha mu začne doporučovat další muziku, která by ho mohla zaujmout a většinou se trefí. Ve Spotify se rozhodli pro stejnou službu pravidelných doporučení, ale bylo potřeba ji škálovat na miliony uživatelů. Momentálně mají přes 75 milionů uživatelů, více jak 30 milionů songů a denně se přehraje přes miliardu skladeb. Jednou z hlavních součástí je Discover weekly, který doporučuje uživatelům novou hudbu, která by je mohla zajímat. Někteří uživatelé dle reakcí považují až za děsivé, že je služba dobře zná a doporučená hudba se většinou velmi dobře trefí do jejich vkusu. Na pozadí znamená vytvoření tohoto doporučení zpracování 30TB logu ze serverů každý den. Vyhodnocují se písničky, doba poslechu, posloupnost přehrávání a mnoho dalšího. Dříve používali jako backend PostgreSQL, ale nyní niž lépe vychází hadoop, který mají nasazený. Celková úložná kapacita činí přes 60 PB dat a stroje mají celkem 70 TB RAM. Pro řízení clusteru používají Apache Casandra a svých 1155 strojů mají rozděleno do více jak 100 clusterů, kdy největší má 60 strojů. Nyní si pro lepší workflow tvoří nástroj Luigi, do kterého hledají přispěvatele.

Keeping the Elephant in the room

Gary Richardson, UK Head of Data Engineering KPMG

Velmi netechnická keynote, o některých problémech práce s Big Data vzhledem k následné monetizaci. Samotné hraní si s daty je sice zajímavé, ale hlavně velké korporace se potřebují pohybovat v mantinelech, kterým rozumění, jako je například návratnost investice. Mnoho zajímavých projektů skončí na tom, že vytvoří proof of concept, ale v té době nemají vůbec vymyšleno, co s ním dál. Chybí jim hlavně směřování v obchodních věcech a i když technicky jsou dokonalí, nejsou schopni se uchytit. Doporučením je, jít na trh včas, aby projekty musely mezi sebou soutěžit a získávat tak zpětnou vazbu. Z pohledu konzultantské firmy tady sice jsou nová data a nové technologie, ale problémy začínajících firem jsou vesměs stále ty samé jako dříve.

Úterní blok keynotes uzavírala panelová diskuze, kde krom deklarace zájmu velkých hráčů v oboru rozvíjet tento trh zazněla jedna důležitá myšlenka. Velmi podstatná je standardizace a interoperabilita. Všechny firmy se chtějí podílet na budování standardů a definic rozhraní, aby se dalo snadno rozšiřovat a případně migrovat existující řešení.

Syntetic Data Generation for Realistic analytics examples and testing

Ronald J. Nowling, Red Hat

Problémem vývoje BigData aplikaci jsou občas i samotná data, která můžou být svázána různými licencemi, NDA a dalšími omezeními, proto se objevuje i poptávka po vygenerovaných datech, která by ovšem připomínala data reálná. Další konkrétní problém při vývoji v Red Hatu byla zpracovávaná data, jednalo se CSV s daty oddělenými tabulátorem a bez uvozovek v textu. Samotné soubory měly stovky GB po kompresi a gzip bohužel podporuje pouze sekvenční přístup, takže bylo potřeba tato data vždy celá rozbalit. Postupně vznikl předpis s názvem BigPetStore pro Bigtop, který umožní vytvořit fiktivní zverimex s generátorem transakci s využitím technologií hadoop a spark. Zde však při testování narazili na další problém a tím bylo nedostatek IPv4 adres pro testovací cluster. Bohužel (z mého pohledu) byl problém vyřešen NATem a na IPv6 se zatím nedostalo.

Spark and machine learning, to the aid of the Data scientist

Frank Ketelaars Big Data Leader, IBM

Spark je open source projekt, nikoliv finální produkt. Je však možné na jeho základě vytvořit velmi zajímavé produkty. Pro ukázky dvou řešení je použit nástroj IPython notebook, představovaný na jedné ze včerejších přednášek. Prvním je analýza kupónů v nákupní akci. Přes popis této akce pořádané v Japonsku, přes některá data jsme se dostali až k závěrečným statistikám, které měly pro některé BigData projekty typické rozuzlení. „Našli jsme ve zpracovávaných datech nějaký pattern, ale nevíme, co znamená.“ Jako další byl nastíněn koncept propojených vozidel, a zpracování dostupných dat z pokusných strojů, opět ale chyběl nějaký dále využitelný závěr a celkově prezentace připomínala neduhy zmiňované v dnešní druhé keynote. Nakonec následoval krátký blok o data science jako oboru, kdy jsme si opět vyslechli varování o chybějících lidech a doporučení, vybudovat data science tým a ne jednotlivce, snažící se obsáhnout celý tento obor.

Being ready for Apache Kafka: today's ecosystem and future roadmap

Michale G. Noll, Confluent

Náhled do vývoje systému Apache Kafka. Firma Confluent poskytuje messaging platformu na systému Kafka a je i aktivním přispěvatelem do projektu. Kafka je připodobňován k linuxovým rourám. Jako příklad uvádí použití v sociální síti LinkedIn, kde obslouží přes jeden bilion (angl. 1 trilion – pozn. autora) zpráv denně což dělá kolem 175 TB dat. Krom jiného tyto zprávy obsluhují analýzu kliků na jednotlivé prvky, nebo jsou využity pro ochranu před DDoS. Verze 0.9.0 plánovaná na listopad tohoto roku přidá jako hlavní vylepšení SSL šifrování. Momentálně existují knihovny pro mnoho jazyků, ale oficiálně jsou podporovány jen Java knihovny. Ideou je do budoucna jako referenční použít knihovnu pro jazyk C a nad touto knihovnou vystavět API pro další jazyky. Za problematický je považován i import a export dat. Momentálně vládne status quo a systém samotný to nijak neřeší, existují externí nástroje, jako například copycat, které jsou schopny více či méně tyto operace řešit.

Open Source in memory platforms

Dr. Konstantin Boudnik, WANdisco

Začít open source projekt je velmi snadné, vyberete si místo, kde budete mít kód, programovací jazyk a začnete psát a commitovat. Složitá část ovšem začíná u vybudování otevřené komunity. Tomu odpovídá i pohled na svět v Apache foundation. Komunita je důležitější než kód. Open source je vývojový model, ale 90% velkých FOSS projektu je spravováno nadací nebo podobným sdružením. Podobné je to i s Apache Bigtop, který si klade za cíl velmi zjednodušit instalaci nástrojů pro BigData. Rozbalování tarballů je již překonané. Zároveň je možno pozorovat přesun od BigData k FastData. Dokazují to i projekty jako Spark, který se z malého projektu na githubu stal jedním z Apache top-level projektů. Podobné je to i s nástrojem Ignite, který zdvojnásobil komunitu přispěvatelů za 5 měsíců a za stejnou dobu narostla komunita uživatelů na čtyřnásobek. Proč vlastně řešit zpracování v paměti? Je totiž přibližně 5000× rychlejší než klasický disk, 1500–2000× než SSD a jen 10× pomalejší než cache procesoru. Přitom oproti cache je řádově levnější. Momentálně je cílem, aby data neopouštěla paměť při zpracováním celým stackem a ne pouze jednou konkrétní aplikací.

Big data for human beings

Mark Shuttleworth, Canonical

Na počátku třetího dne jsme se dověděli, že balíčkovací systém je pro dnešní potřeby nedostačující.

Instalace je reaktivní, kdy při instalaci jednoho balíčku systém pouze řeší závislosti a ty pak nainstaluje. Pro uživatele je však mnohem důležitější služba než balíček, který ji poskytuje. Tato služba by měla být nezávislá na operačním systému. Jako nástroj pro dosažení tohoto cíle je uváděn Juju. Jedná se o řešení, kde si namodelujete vaší službu, což je možno v GUI nebo v příkazové řádce a pak si tuto službu spustíte v privátním, nebo veřejném cloudu. Dle autora je motivací pro tento nástroj snaha vytvořit mechanizmus, jak dostat dobro k lidem tak rychle, jak je to jen možné.

How to deploy a secure. HA hadoop platform

Olaf Flebbe

Díky LXC a puppetu jste schopni velmi rychle vytvořit kompletní stack pro BigData. Z pohledu administrátorů se však spíše jedná o BigComputing. Je potřeba spravovat velké množství strojů, což bez automatizace nejde. Jako scénář posloužila implementace v německém ekvivalentu americké NSA. Jako základ pro řízení přístupu byl použit Kerberos s openLDAPem, neboť jedním z požadavků byla schopnost auditovat zdrojové kódy a následně to z těchto kódů sestavit. Za operační systém byl zvolen Debian Jessie. Velmi příjemná byla informace, že veškeré změny prováděné v kódu se autoři snažili poslat do upstreamu daných nástrojů. Na problémy narazili hlavně při automatizaci, kdy moduly pro správu Kerbera v puppetu měly přímo v sobě zadrátovaná hesla, což nebylo pro dané nasazení přijatelné. Dalším problémem byl například nástroj zookeeper pro centralizovanou správu, který sice podporuje ACL, ale neposkytuje nástroj pro jejich správu. Navíc i přes nasazení ACL se tato pravidla nevztahují na root adresář tohoto nástroje.

Profiting from Apache brands without losing your soul

Shane Curcuru, Apache vice president, brand manager

Apache foundation definuje politiku ochranných známek pro všech více jak 200 projektů sdružených pod hlavičkou Apache. Každý projekt má svou vlastní komisi, která si projekt řídí, samotná nadace poskytuje pouze zastřešení a podporu. Cílem nadace je poskytovat software pro veřejné dobro. Všechny ochranné známky jsou majetkem nadace a „Apache“ je umístěno před samotným názvem produktu. Cílem je nalákat lidi k nadaci a k dalším jejím projektům. Důležité je, mít vlastní značku pro produkt, který je založen na software od Apache, například je v pořádku použít „powered by“, ale ne přímo bez povolení vložit název produktu do Apache do názvu svého produktu. Podpora nadace je velmi snadná, stačí používat její software a dát světu vědět, že ho používáte. V lepším případě můžou organizace dodat své zaměstnance. 30% přispěvatelů jsou zaměstnanci, kteří mají přispívání v náplni práce. V tomto případě by ale veškerá komunikace měla probíhat na veřejných mailing listech, ne ve vnitrofiremní konferenci, nebo třeba na slacku. Pokud někdo poruší známku k Apache produktům, následuje nejprve soukromé oznámení, poté mediální tlak, vyřazení zaměstnanců dané společnosti z projektu a v posledním kroku i právní kroky. Ideální je alespoň odpovědět, stačí napsat: „ok, bereme na vědomí, zjednáme nápravu, bude to chvíli trvat“.

UX DAy - tip 2

Linaro big Data

Martin Stadler

Přednáška o platformě ARM64 a její vazbě na BigData. V současné době pracuje přes 200 inženýrů na arm serverech. V rámci Open data platform initiative se podílejí zároveň na standardizaci hadoop infrastruktury. Cílem je hlavně na korporátní sféru a softwarově definovanou infrastrukturu. Hlavním cílem je optimalizovat komponenty, na reálnou zátěž na platformě ARM64. Ve spolupráci s RedHatem například probíhá optimalizace openJDK. Zároveň se pracuje na zrychlování kryptografických funkcí v jádře a openSSL, kdy došlo až k šestnáctinásobnému zrychlení. Samotné sestavení hadoopu a sparku je velmi dobrým zátěžovým testem. Jedním z cílů je udělat balíčky, nebo vymyslet jiný způsob distribuce na úrovni. Zároveň se vymýšlejí benchmarky a simulují reálné problémy pro otestování výkonu a propustnosti. Momentálně se stává limitujícím faktorem externí I/O operace, ale přesto se stále pokračuje v optimalizacích, na kterých se podílí například i CERN. 

Byl pro vás článek přínosný?

Autor článku

Petr Černohouz pracuje jako programátor pro výzkum a vývoj v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény – sdružení CZ.NIC.