sql >> Database teknologi >  >> NoSQL >> HBase

Begrænsninger af Hadoop, måder at løse Hadoop-ulemper på

Vi har diskuteret Hadoop-funktioner i vores tidligere Hadoop-tutorial. Nu skal vi dække Hadoops begrænsninger. Der er forskellige ulemper ved Apache Hadoop-frameworks.

For eksempel problem med små filer, langsom behandling, kun batchbehandling, forsinkelse, sikkerhedsproblem, sårbarhed, ingen cachelagring osv.

Alle disse begrænsninger af Hadoop vil vi diskutere detaljeret i denne Hadoop-tutorial.

Hvad er Hadoop?

Apache Hadoop er en open source softwareramme til distribueret lagring og behandling af enorme mængder datasæt. Open source betyder, at den er frit tilgængelig, og selv vi kan ændre dens kildekode i henhold til kravene.

Apache Hadoop gør det også muligt at køre applikationer på et system med tusindvis af noder. Dets distribuerede filsystem har mulighed for hurtige dataoverførselshastigheder mellem noder.

Det giver også systemet mulighed for at fortsætte driften i tilfælde af knudefejl. De vigtigste funktioner i Hadoop er som følger:

  • I Apache Hadoop er data tilgængelige på trods af maskinfejl på grund af mange kopier af data. Så hvis en maskine går ned, så kan man få adgang til dataene fra en anden sti.
  • Apache Hadoop er skalerbar, da det er nemt at tilføje ny hardware til noden.
  • Hadoop er meget fejltolerant, da der som standard er gemt 3 replikaer af hver blok på tværs af klyngen. Så hvis en node i klyngen går ned, kan data på den node nemt gendannes fra den anden node.
  • Apache Hadoop kører på en klynge af råvarehardware, som ikke er særlig dyrt.
  • I Apache Hadoop lagres data pålideligt på klyngen på trods af hardwarefejl på grund af replikering af data på klyngen.

Selvom Hadoop er det mest kraftfulde værktøj til Big Data, er der forskellige begrænsninger for det. På grund af Hadoops begrænsninger opstod Apache Spark og Apache Flink.

Begrænsninger af Hadoop

Forskellige begrænsninger af Apache Hadoop er angivet nedenfor sammen med deres løsning-

a. Problemer med små filer

Det største problem med Hadoop er, at det ikke er egnet til små data. HDFS mangler evnen til at understøtte den tilfældige læsning af small på grund af dets højkapacitetsdesign.

Små filer er mindre end HDFS-blokstørrelsen (standard 128MB). Hvis du gemmer disse enorme antal små filer, kan HDFS ikke håndtere disse mange små filer.

Som HDFS blev designet til at arbejde med et lille antal store filer til lagring af store datasæt i stedet for et stort antal små filer. Hvis der er mange små filer, vil NameNode blive overbelastet, da den gemmer navneområdet for HDFS.

Løsning: 

Du skal blot flette de små filer for at skabe større filer og derefter kopiere større til HDFS.

Hadoop-arkiver (HAR-filer) omhandler problemet med mange små filer. Hadoop Archives fungerer ved at bygge et lagdelt filsystem på toppen af ​​HDFS.

Med hjælp Hadoop-arkivkommandoen oprettes HAR-filer; dette kører et MapReduce job for at pakke filerne, der arkiveres, i et lille antal HDFS-filer. At læse filer gennem HAR er ikke mere effektivt end at læse gennem HDFS.

Da hver HAR-filadgang kræver to indeksfiler læst samt datafilen for at læse, vil dette gøre det langsommere.

Sekvensfiler overvinder også problemet med små filer. I hvilken vi bruger filnavnet som nøglen og filindholdet som værdien.

Ved at skrive et program til filer (100 KB), kan vi lægge dem ind i en enkelt Sequence-fil, og så kan vi behandle dem på en streaming-måde, der opererer på Sequence-filen.

MapReduce i Hadoop kan opdele Sequence-filen i bidder og operere på hver chunk uafhængigt, fordi Sequence-filen kan opdeles.

Ved at gemme filer i Hbase kan vi overvinde problemet med små filer. Vi gemmer faktisk ikke millioner af små filer i HBase, men tilføjer det binære indhold af filen til en celle.

b. Langsom behandlingshastighed

MapReduce behandler en enorm mængde data. I Hadoop fungerer MapReduce ved at opdele behandlingen i faser:Kort og Reducer . Så MapReduce kræver meget tid til at udføre disse opgaver, hvilket øger latensen. Reducerer derfor behandlingshastigheden.

Løsning:

Ved at behandle data i hukommelsen overvinder Apache Spark dette problem. Ligesom i In-memory-behandling, bliver der ikke brugt tid på at flytte data/processer ind og ud af disken, hvilket gør det hurtigere.

Apache Spark er 100 gange hurtigere sammenlignet med MapReduce, fordi den behandler alt i hukommelsen.

Flink kan også overvinde dette problem. Flink behandler hurtigere end Spark på grund af dens streaming-arkitektur.

c. Understøttelse kun til batchbehandling

Hadoop understøtter kun batchbehandling, den er ikke egnet til streaming af data. Derfor er den samlede ydeevne langsommere. MapReduce-rammeværket udnytter ikke Hadoop-klyngens hukommelse maksimalt.

Løsning

Apache Spark løser dette problem, da det understøtter streambehandling. Men Spark-stream-behandling er ikke så meget effektiv som Flink, da den bruger mikro-batch-behandling. Apache Flink forbedrer den overordnede ydeevne, da den giver en enkelt kørselstid for streaming såvel som batchbehandling.

d. Ingen realtidsbehandling

Apache Hadoop er en batchbehandlingsramme. Det betyder, at det tager en enorm mængde data i input, behandler det og producerer resultatet.

Batchbehandling er meget effektiv til at behandle en stor mængde data, men afhænger af størrelsen af ​​de data, der behandles, og systemets regnekraft; et output kan blive betydeligt forsinket. Apache Hadoop er ikke egnet til realtidsbehandling.

Løsning:

Spark er velegnet til strømbehandling. Dampbehandling giver kontinuerlige input/outputdata. Den behandler data inden for den korte tid.

Flink giver en enkelt kørselstid for både streaming og batchbehandling.

e. Iterativ behandling

Apache Hadoop er ikke meget effektiv til iterativ behandling. Da Hadoop ikke understøttes cyklisk dataflow (dvs. en kæde af trin, hvor hvert output fra det forrige trin er input til det næste trin).

Løsning:

Spark overvinder dette problem. Som Apache Spark får adgang til data fra RAM i stedet for disken. Dette forbedrer dramatisk ydeevnen af ​​en iterativ algoritme, der får adgang til det samme datasæt gentagne gange.

I Apache Spark, for iterativ behandling, skal hver iteration planlægges og udføres separat.

f. Latency

MapReduce i Hadoop er langsommere, fordi det understøtter forskellige formater, strukturerede og enorme mængder data. I MapReduce tager Map et sæt data og konverterer det til et andet datasæt, hvor et individuelt element opdeles i et nøgleværdi-par.

Reduce tager outputtet fra kortet som og Reduce tager outputtet fra kortet som input og proces videre. MapReduce kræver meget tid at udføre disse opgaver og øger derved forsinkelsen.

Løsning:

Apache Spark kan reducere dette problem. Selvom Spark er batchsystemet, er det relativt hurtigere, fordi det cacher meget af inputdataene i hukommelsen ved hjælp af RDD. Apache Flink datastreaming opnår lav latenstid og høj gennemstrømning.

g. Ingen brugervenlighed

MapReduce-udvikleren i Hadoop skal udlevere kode for hver eneste operation, hvilket gør det meget vanskeligt at arbejde. I Hadoop har MapReduce ingen interaktiv tilstand, men tilføjelse af hive og gris gør arbejdet med MapReduce lidt lettere.

Løsning:

Spark har overvundet dette problem, da Spark har en interaktiv tilstand. Så både udviklere og brugere kan få mellemliggende feedback til forespørgsler og andre aktiviteter.

Da spark har tonsvis af operatører på højt niveau, er det nemt at programmere Spark. Man kan også bruge Apache Flink, da den også har operatører på højt niveau.

h. Sikkerhedsproblem

Apache Hadoop er udfordrende med at vedligeholde de komplekse applikationer. Hadoop mangler kryptering på lager- og netværksniveau, hvilket er et stort problem. Apache Hadoop understøtter Kerberos-godkendelse, som er svær at administrere.

Løsning:

Apache Spark giver sikkerhedsbonus. Hvis du kører Apache Spark i HDFS, kan den bruge HDFS ACL'er og tilladelser på filniveau.

i. Sårbar af natur

Apache Hadoop er skrevet i Java. Java, er et mest populært sprog, og derfor er java mest udnyttet af cyberkriminelle.

j. Ingen cachelagring

Apache Hadoop er ikke effektiv til caching. MapReduce kan ikke cache de mellemliggende data i hukommelsen til det yderligere krav, og dette forringer Hadoops ydeevne.

Løsning:

Spark og Flink overvinder dette problem. Spark and Flink cache-data i hukommelsen for yderligere iterationer, som forbedrer den overordnede ydeevne.

k. Lang kode

Apache Hadoop har 1.20.000 kodelinjer. Antallet af linjer producerer antallet af fejl. Derfor vil det tage længere tid at udføre programmerne.

Løsning:

Spark og Flink er skrevet i Scala og Java. Men implementeringen er i Scala, så antallet af kodelinjer er mindre end Hadoop. Det tager således mindre tid at udføre programmerne.

Konklusion

Som et resultat af Hadoops begrænsning opstod behovet for Spark og Flink. Gør således systemet mere venligt at spille med en enorm mængde data.

Apache Spark giver databehandling i hukommelsen og forbedrer dermed behandlingshastigheden. Flink forbedrer ydeevnen, da den giver en enkelt kørselstid til streaming såvel som batchbehandling.

Spark giver sikkerhedsbonus. Derfor kan man løse alle disse Hadoop-begrænsninger ved at bruge andre big data-teknologier som Apache Spark og Flink.

Hvis du finder andre begrænsninger af Hadoop, så lad os det vide ved at efterlade en kommentar i et afsnit nedenfor.


  1. Sådan henter du detaljerne fra mongo db og sender eller gemmer i objekt i nodejs Fork-metoden

  2. mongodb tekstsøgning ved hjælp af flere sprog

  3. Mongoose Unikt indeks virker ikke!

  4. Hvordan opretter man Mongoose-skema med en række objekt-id'er?