Dok je Hadoop dizajniran oko robne infrastrukture, Hadoop 3.x suočava se s realnošću da previše jeftine pohrane može biti skupo.
Kad je riječ o pohrani, obećanja Hadoopa zvuče mirisno na ona povezana s ranim danima nuklearne energije: pohrana robe bila bi presjeftina za mjerenje. Izvorna premisa dizajna bila je da ako masivno paralelno računalstvo možete učiniti linearno skalabilnim i približiti ga podacima, korištenje standardnog hardvera učinilo bi troškove pohrane naknadnim razmišljanjem. To je bila pretpostavka iza Hadoopovog izvornog pristupa visokoj dostupnosti: uz tako jeftinu pohranu, učinite podatke dostupnima (i lokalnim) s tri pune replike podataka.
Ali, naravno, svijetu teško da ponestaje podataka; većina predviđanja ima da raste geometrijski ili eksponencijalno. U jednom trenutku pohrana velikih podataka mora poštovati zakone gravitacije, ako ne i fizike; imati previše toga pokazat će se skupim bilo u režijskim troškovima ili u dolarima, a što je vjerojatnije, oboje.
The Hadoop 3.0
Spec priznaje da u nekom trenutku previše jeftino postaje skupo. Hadoop 3.0 posuđuje neke koncepte iz svijeta poslovne pohrane. S kodiranjem za brisanje, Hadoop 3.0 usvaja RAID tehnike za smanjenje rasprostranjenosti podataka. Kodiranjem za brisanje možete grubo smanjiti rasprostranjenost pohrane u usporedbi s tradicionalnom 3x replikacijom za oko 50%. Cijena toga je, naravno, da dok su replicirani podaci odmah dostupni, podaci kojima se upravlja kroz RAID pristupe moraju biti vraćeni - što znači da nećete odmah dobiti failover pristup. Dakle, u praksi će se nova podrška kodiranja za brisanje Hadoopa 3.0 vjerojatno koristiti kao strategija razvrstavanja podataka, gdje se hladniji (koji su obično stariji) podaci pohranjuju na jeftinije, često sporije medije.Za Hadoop ovi pristupi nisu novi. EMC je ponudio vlastitu podršku HDFS emulacija za svoj Isilon skalirano pohranjivanje datoteka na nekoliko godina. Razlika u odnosu na 3.0 je u tome što se ciljevi ovog pristupa - smanjenje širenja podataka - sada mogu ostvariti kroz tehnologiju otvorenog koda. Ali to znači da oni koji usvajaju Hadoop moraju prihvatiti procese upravljanja životnim ciklusom informacija za odbacivanje hladnijih podataka; očekujemo da će pružatelji alata za arhiviranje podataka i upravljanje životnim ciklusom informacija ispuniti ovaj novostvoreni vakuum koji je stvorio svijet otvorenog koda.
Dakle, sada kada smo smislili način za obuzdavanje širenja skladišta, povećat ćemo hitnost za to smanjivanjem YARN-a. Hadoop 3.0 dodaje podršku za udruživanje više YARN klastera. Početne pretpostavke dizajna za YARN upućivale su na gornju granicu od otprilike 10 000 čvorova; dok samo Yahoo premašuje taj broj danas, udruživanje YARN-a omogućuje budućnost u kojoj će više organizacija vjerojatno probiti taj zid.
Pokretač svega toga je, naravno, nekoliko čimbenika. Prvo, i najočitije, generiranje podataka eksponencijalno raste. Ali drugo, one organizacije koje su ranije ušle u Hadoop vjerojatno će do sada imati više klastera, bilo prema dizajnu ili inercijom. A u mnogim slučajevima, to širenje je potaknuto činjenicom da se implementacije mogu proširiti, ne samo u prostorijama, već iu oblaku. YARN federacija nije nužno o upravljanju samom po sebi, ali bi mogla otvoriti vrata u generaciji Hadoop 4.x podršci za federaciju kroz Hadoopove projekte upravljanja podacima, kao što je Atlas, Ranger, ili Stražar.
Ali čekaj, ima još.
S 3.0, Hadoop postavlja temelje za upravljanje više heterogenih klastera. Nije da ne možete kombinirati različite vrste hardvera, točka. Do sada su se varijante vrtjele dodajući nove generacije čvorova koji bi mogli imati više računala ili pohrane u usporedbi s onim što biste već imali; YARN je to podržao. Ali s pojavom GPU-a i drugog specijaliziranog hardvera za nove vrste radnih opterećenja (razmislite o dubokom učenju), nije bilo načina da YARN eksplicitno upravlja tim dodjelama. U verziji 3.0 postavljaju se temelji za upravljanje novim vrstama hardvera. Za GPU i FPGA, to će se ostvariti u izdanjima od 3.1 odnosno 3.2 točke.
Hadoop 3.0 također poduzima sljedeći korak u jačanju NameNode pouzdanost. Dok je Hadoop 2.0 podržavao implementaciju dvaju čvorova (jedan aktivan, jedan u stanju pripravnosti), sada možete imati koliko god želite čvorova NameNodes u pripravnosti za robusniju visoku dostupnost/nadilaženje u slučaju greške. Ili kao što je jedan od mojih kolega primijetio, bilo je krajnje vrijeme da Apache zajednica doda ovu važnu značajku.
Uz 3.0 koji je sada u izdanju, Hadoop zajednica nastoji ubrzati tempo novih izdanja. I tako, dva dot izdanja (3.1 i 3.2) očekuju se u kalendarskoj 2018. godini. Kao što je gore navedeno, bit će više razgraničenja za specifične vrste resursa kojima upravlja YARN. Uz to, novi YARN Services API pojednostavit će kretanje vanjskih radnih opterećenja enkapsulacijom konfiguracija za sigurnost, raspoređivanje i zahtjeve za resursima. To će pomoći da YARN postane lakši za dugotrajna radna opterećenja, što je bila njegova slaba točka u prošlosti (YARN je proizašao iz MapReducea, koji je dizajniran za grupne poslove).
Objavljeni računi ukazuju na proširenu podršku za Docker spremnike za rad s YARN-om. Operabilno kretanje čini Hadoop urednijim formatom za implementaciju koda koji se odnosi na analitiku podataka. Vrata je već razbijen po MapR, uz podršku za trajni spremnici. Dok je YARN postavljen za odvajanje različitih radnih opterećenja, spremnici pružaju veći stupanj izolacije da će programi napisani u R-u ili Pythonu, na primjer, raditi na klasteru onako kako su dizajnirani na laptop.
To potiče sljedeće pitanje: kada će Hadoopova nadolazeća podrška za radna opterećenja u kontejnerima poduzeti neizbježan sljedeći korak u formaliziranju podrške za Kubernetes. Kao de facto konsenzusni standard za orkestraciju spremnika, podrška za Kubernetes mogla bi proširiti Hadoop s cilja za BI i analitičke upite na platformu koja pokreće aplikacije. Da, postoje neformalne načine spojiti Kubernetes i YARN zajedno, ali pojednostavljenje ovoga s čvršćom integracijom moglo bi ovu prirodnu kombinaciju učiniti manje klugeom.
Uz oblak koji nudi niz opcija za pokretanje velikih podatkovnih poslova sa ili bez Hadoopa, rukavica je bačena Apache zajednici. Omogućite Hadoopu da kombinira i usklađuje infrastrukturu kako bi mogao pružiti istu slobodu izbora i fleksibilnost koju je računalstvo u oblaku već učinilo normom.