Nul
Als het ging om de opslag, de beloften van Hadoop geluid denken aan die in verband met de vroege dagen van kernenergie: commodity-opslag zou te goedkoop meter. Het oorspronkelijke ontwerp uitgangspunt was dat als je zou kunnen maken massively parallel computing lineair schaalbaar en brengen deze in de buurt van de gegevens, met behulp van hardware zou de kosten van opslag van een nabeschouwing. Dat was de achterliggende gedachte van Hadoop is een originele benadering van de high-availability: met opslag zo goedkoop, data beschikbaar (en lokale) met drie volledige replica ‘ s van de gegevens.
Maar het is natuurlijk de wereld is nauwelijks uitgevoerd van gegevens; de meeste voorspellingen hebben het steeds geometrisch of exponentieel. Op een bepaald punt, big data opslag moet gehoorzamen aan de wetten van de zwaartekracht, zo niet de natuurkunde; dat te veel van het zal blijken kostbaar hetzij in overhead-of dollars, en meer waarschijnlijk, beide.
De Hadoop 3.0 specificatie erkent dat, op een bepaald moment te veel goedkoper wordt het duur. Hadoop 3.0 is het lenen van een aantal concepten uit de wereld van enterprise storage. Met uitwissing codering, Hadoop 3.0 neemt RAID-technieken voor het verminderen van de gegevens uit te dijen. Met uitwissing codering, kunt u ongeveer snijd de uitbreiding van de opslagcapaciteit dan bij de traditie 3x replicatie met ongeveer 50%. De prijs van dat, natuurlijk, is dat terwijl de gerepliceerde data is direct beschikbaar, gegevens beheerd door middel van RAID benaderingen moeten hersteld worden – wat betekent dat je niet voor failover direct toegang krijgen tot. Dus, in de praktijk, de nieuwe wissen codering ondersteuning van Hadoop 3.0 zal waarschijnlijk gebruikt worden als een data-tiering strategie, waar het kouder is (dat is meestal oudere) gegevens die zijn opgeslagen op de goedkopere, vaak langzamer media.
Voor Hadoop, deze benaderingen zijn niet nieuw. EMC heeft zijn eigen ondersteuning van HDFS emulatie voor de Isilon scale-out opslag van bestanden voor meerdere jaren. Het verschil met 3.0 is dat de doelstellingen van deze benadering – het verminderen van de gegevens wildgroei – kan nu worden gerealiseerd door middel van open source technologie. Maar dit betekent dat Hadoop adopters moeten omarmen information lifecycle management processen voor deprecating kouder gegevens; we verwachten dat de aanbieders van data-archivering en informatie lifecycle management tooling vult deze nieuw gecreëerde vacuüm gecreëerd door de open source wereld.
Dus nu dat we komen voor een manier om te bevatten opslag wildgroei, we verhogen de urgentie voor het door de schalen uit GAREN. Hadoop 3.0 voegt ondersteuning voor het samenwerken van meerdere GAREN clusters. Het oorspronkelijke ontwerp van de aannames voor GAREN wees naar een opwaartse grens van ruwweg 10.000 knooppunten; terwijl alleen Yahoo overschrijdt, gelden vandaag de dag, samenwerken GAREN zorgt voor een toekomst waarin steeds meer organisaties zijn waarschijnlijk de schending van die muur.
Het besturen van dit alles, natuurlijk, is een aantal factoren. Eerste, en meest voor de hand liggende, het genereren van data groeit exponentieel. Maar ten tweede organisaties die kreeg in Hadoop eerder zijn door nu waarschijnlijk in meerdere clusters, door ontwerp of inertie. En in veel gevallen, dat de verspreiding wordt gesteund door het feit dat implementaties kunnen worden languit, niet alleen op gebouwen, maar ook in de cloud. GAREN federatie is niet per se over het bestuur per se, maar het kan de deur openen in de Hadoop-4.x-generatie te ondersteunen voor de federatie over Hadoop data governance projecten, zoals de Atlas, Ranger, of Wachtpost.
Maar wacht, er is meer.
Met 3.0, Hadoop is het leggen van de basis voor het beheren van meer heterogene clusters. Het is niet dat je niet kon mix en match verschillende soorten hardware, periode. Tot nu, de varianten de neiging om te draaien het toevoegen van nieuwe generaties van knooppunten die kunnen pack meer berekenen of opslag in vergelijking met wat je zou al op zijn plaats; GAREN ondersteund. Maar met de opkomst van de Gpu ‘ s en andere gespecialiseerde hardware voor nieuwe vormen van werkbelasting (denk diep leren), was er geen manier om GAREN te expliciet het beheer van deze toewijzingen. In versie 3.0, de basis is gelegd voor het beheren van nieuwe typen hardware. Voor Gpu ‘s en fpga’ s, die komt tot uiting in de 3.1 en 3.2 punt van afgifte, respectievelijk.
Hadoop 3.0 neemt ook de volgende stap in de versterking van NameNode betrouwbaarheid. Terwijl Hadoop 2.0 ondersteund implementatie van twee knooppunten (één actief is, een stand-by), nu kun je zo veel stand-by NameNodes als u wilt voor meer robuuste hoge beschikbaarheid/failover. Of, zoals één van mijn collega ‘ s merkte op, het is over verdomme tijd dat de Apache community toegevoegd aan deze belangrijke functie.
Met de 3.0 nu in release, de Hadoop community is op zoek naar stap het tempo van nieuwe releases. En dus, twee dot releases (3.1 en 3.2) zijn naar verwachting in het kalenderjaar 2018. Zoals hierboven is opgemerkt, zal er meer afbakening voor specifieke types van middelen beheerd door GAREN. Samen met een nieuw GAREN Services API zal vereenvoudigen de beweging van externe workloads door het inkapselen van de configuraties voor de veiligheid, planning en resource-aanvragen. Dit zal helpen GAREN vriendelijker langdurige workloads, dat is zijn zwakke plek in het verleden (GAREN kwam uit MapReduce, die ontworpen was voor de batch jobs).
Gepubliceerd accounts punt aan uitgebreide ondersteuning voor het Koppelvenster containers te lopen met GAREN. De bedienbaar beweging is het maken van Hadoop een nettere implementatie formaat voor de data-analyse-gerelateerde code. De deur is al gekraakt door MapR, met ondersteuning voor blijvende containers. Tijdens het GAREN is opgezet om verschillende workloads, containers biedt een grotere mate van isolatie, zodat programma ‘ s geschreven in R of Python, bijvoorbeeld, zal werken op het cluster van de manier waarop ze zijn ontworpen op de laptop.
Dat vraagt de volgende vraag: wanneer zal Hadoop aangekondigde ondersteuning voor container-workloads nemen de onvermijdelijke volgende stap in het formaliseren van de ondersteuning van Kubernetes. Als de de facto consensus standaard container voor orchestration, Kubernetes ondersteuning zou kunnen uitbreiden Hadoop van een doel voor BI en analyse van query ‘ s aan een platform dat draait toepassingen. Ja, er zijn informele manieren om de draad Kubernetes en GAREN samen, maar de vereenvoudiging van deze met nauwere integratie zouden kunnen maken van deze natuurlijke combinatie minder van een kluge.
Met de cloud biedt een waaier van opties voor het uitvoeren van big data banen met of zonder Hadoop, de gauntlet, is neergeworpen op de Apache community. Het inschakelen van Hadoop om te mixen en matchen-infrastructuur, zodat het kan dezelfde vrijheid van keuze en de flexibiliteit die cloud computing heeft al de norm.
Verwante Onderwerpen:
Data Management
Digitale Transformatie
Robotica
Het Internet van Dingen
Innovatie
Enterprise Software
0