Noll
När det kom till lagring, löften om Hadoop ljud som påminner om dem som är förknippade med de första dagarna av kärnkraft: varan lagring skulle vara för låga för att mätaren. Den ursprungliga designen förutsättningen var att om du kunde göra massively parallel computing linjärt skalbart och föra det nära till data, med hjälp av hårdvara skulle göra kostnaderna för lagring i efterhand. Det var antagandet bakom Hadoop ursprungliga strategi för att med hög tillgänglighet: med förvaring så billiga, att göra data tillgängliga (och lokala) med tre fulla kopior av data.
Men, naturligtvis, världen är knappast körs ut av data; de flesta förutsägelser har det växande geometriskt eller exponentiellt. Vid en viss punkt, big data lagring måste lyda de lagar som gravitation, om inte fysik; med för mycket av det kommer att visa sig kostsamma antingen på overhead eller dollar, och mer troligt, både och.
Hadoop 3.0 spec erkänner att han vid något tillfälle, för mycket billigt blir dyrt. Hadoop 3.0 är att låna några begrepp från den värld av enterprise storage. Med utplåning kodning, Hadoop 3.0 antar RAID tekniker för att reducera data utbredning. Med utplåning kodning, du kan grovt skär utbredning av lagring jämfört med tradition 3x replikering med ca 50%. Priset för detta är naturligtvis att medan replikerade data som är omedelbart tillgängliga, data hanteras via RAID metoder måste återställas, vilket innebär att du inte får failover få tillgång till direkt. Så, i praktiken, den nya radering kodning stöd av Hadoop 3.0 kommer sannolikt att användas som en data tiering strategi, där kallare (vilket är oftast äldre) data är lagrad på billigare, ofta långsammare medier.
För Hadoop, dessa metoder är inte nya. EMC har erbjudit sin egen stöd av HDFS emulering för sin Isilon scale-out lagring av filer för flera år. Skillnaden med 3.0 är att målen i denna strategi – att minska data utbredning – nu kan förverkligas genom open source-teknik. Men detta innebär att Hadoop användare måste omfamna information lifecycle management processer för avvärjande kallare data; vi förväntar oss att leverantörer av data arkiv och information lifecycle management verktyg kommer att fylla denna nyskapade vakuum som skapats av open source-världen.
Så nu när vi har kommit fram till ett sätt att innehålla lagring utbredning, vi ska höja brådskande för det genom att skala ut GARN. Hadoop 3.0 ger stöd för att förena flera GARN kluster. Inledande design antaganden för GARN pekade på att en uppåtgående gränsen för ungefär 10 000 noder, medan endast Yahoo överstiger det som räknas idag, förenade GARN gör det möjligt för en framtid där fler organisationer är benägna att bryta mot denna vägg.
Kör allt detta, naturligtvis, är flera faktorer. För det första, och mest uppenbara, generering av data ökar exponentiellt. Men för det andra, de organisationer som fick i Hadoop tidigare är nu sannolikt har flera kluster, antingen genom design eller tröghet. Och i många fall även att spridningen är stöd av det faktum att distributioner kan vara liggandes, inte bara på lokaler, men också i molnet. GARN federationen är inte nödvändigtvis-om styrning per se, men det skulle kunna öppna dörren i Hadoop 4.x generation till stöd för federationen över Hadoop data governance-projekt, som Atlas, Ranger, eller Vaktpost.
Men vänta, det finns mer.
Med 3.0, Hadoop är grunden för att hantera mer heterogent kluster. Det är inte så att man inte kunde blanda och matcha olika typer av hårdvara, period. Tills nu, de varianter som tenderade att kretsa lägga till nya generationer av noder som kan packa mer beräkna eller lagring jämfört med vad du skulle ha haft redan på plats; GARN som stöds. Men med framväxten av Grafikprocessorer och annan specialiserad hårdvara för nya typer av arbetsbelastning (tror djupt lärande), fanns det inget sätt för GARN för att explicit hantera dessa anslag. I version 3.0, grunden läggs för att hantera nya hårdvara typer. För Grafikprocessorer och Fpga: er, som kommer att förverkligas i 3.1 och 3.2 dot utgåvor respektive.
Hadoop 3,0 även tar nästa steg i att stärka NameNode tillförlitlighet. Medan Hadoop 2.0 stöder distribution av två noder (ett aktivt, ett standby), nu kan du ha så många standby NameNodes som du vill för mer robust hög tillgänglighet/failover. Eller som en av mina kollegor påpekade, handlar det om blodiga tid att Apache community lagt till denna viktiga funktion.
Med 3,0 nu i release, Hadoop gemenskapen är ute efter att öka takten i nya utgåvor. Och så två dot utsläpp (3.1 och 3.2) förväntas i kalendern för år 2018. Som nämnts ovan, kommer det att finnas mer avgränsning för specifik resurs typer förvaltas av GARN. Tillsammans med det, en ny GARN Services API kommer att förenkla förflyttning av externa arbetsbelastning genom att visa konfigurationer för säkerhet, schemaläggning och resurs ansökningar. Detta kommer att bidra till att göra GARN vänligare till långvariga arbetsbelastning, vilket har varit en svag punkt i det förflutna (GARN kom ut MapReduce, som var avsedd för batch-jobb).
Publicerad konton punkt till utökat stöd för Hamnarbetare behållare för att köra med GARN. Den manövreras motion är att göra Hadoop en snyggare distribution format för data analytics-relaterad kod. Dörren har redan knäckt öppna genom att MapR, med stöd för ihållande behållare. Medan GARN sattes upp för att separera olika arbetsbelastningar, behållare ger en större grad av isolering så att program skrivna i R eller Python, till exempel, kommer att arbeta på klustret det sätt de var avsedda för den bärbara datorn.
Som föranleder nästa fråga: när kommer Hadoop s kommande stöd för containertransporter arbetsbelastning ta den oundvikliga nästa steg i att formalisera stöd av Kubernetes. Som de facto konsensus standard för container orkestrering, Kubernetes stöd kunna expandera Hadoop från ett mål för BI och analytiska frågor till en plattform som körs applikationer. Ja, det finns informella sätt att koppla Kubernetes och GARN tillsammans, men att förenkla detta med tätare integration skulle kunna göra denna naturliga blandning mindre av en kluge.
Med cloud erbjuder en rad alternativ för att köra big data jobb med eller utan Hadoop, handsken har kastats ner till Apache gemenskapen. Aktivera Hadoop att mixa och matcha infrastrukturen så att den kan ge samma valfrihet och flexibilitet som cloud computing har redan gjort normen.
Relaterade Ämnen:
Hantering Av Data
Digital Omvandling
Robotteknik
Sakernas Internet
Innovation
Affärssystem
0