Vi har diskuterat Hadoop-funktioner i vår tidigare Hadoop-handledning. Nu ska vi täcka begränsningarna för Hadoop. Det finns olika nackdelar med Apache Hadoop-ramverk.
Till exempel problem med små filer, långsam bearbetning, enbart batchbearbetning, fördröjning, säkerhetsproblem, sårbarhet, ingen cachelagring etc.
Alla dessa begränsningar av Hadoop kommer vi att diskutera i detalj i denna Hadoop-handledning.
Vad är Hadoop?
Apache Hadoop är ett ramverk för öppen källkod för distribuerad lagring och bearbetning av enorma mängder datamängder. Öppen källkod betyder att den är fritt tillgänglig och även vi kan ändra dess källkod enligt kraven.
Apache Hadoop gör det också möjligt att köra applikationer på ett system med tusentals noder. Dess distribuerade filsystem erbjuder snabba dataöverföringshastigheter mellan noder.
Det låter också systemet fortsätta att fungera i händelse av nodfel. Huvuddragen i Hadoop är följande:
- I Apache Hadoop är data tillgänglig trots maskinfel på grund av många kopior av data. Så om någon maskin kraschar kan man komma åt data från en annan väg.
- Apache Hadoop är skalbar, eftersom det är lätt att lägga till ny hårdvara till noden.
- Hadoop är mycket feltolerant, eftersom 3 repliker av varje block som standard lagras över klustret. Så om någon nod i klustret går ner kan data på den noden enkelt återställas från den andra noden.
- Apache Hadoop körs på ett kluster av råvaruhårdvara som inte är särskilt dyrt.
- I Apache Hadoop lagras data på ett tillförlitligt sätt i klustret trots maskinvarufel på grund av replikering av data i klustret.
Även om Hadoop är det mest kraftfulla verktyget för Big Data, finns det olika begränsningar för det. På grund av Hadoops begränsningar kom Apache Spark och Apache Flink till.
Begränsningar för Hadoop
Olika begränsningar för Apache Hadoop ges nedan tillsammans med deras lösning-
a. Problem med små filer
Det största problemet med Hadoop är att det inte är lämpligt för små data. HDFS saknar förmågan att stödja slumpmässig avläsning av små på grund av dess design med hög kapacitet.
Små filer är mindre än HDFS-blockstorleken (standard 128MB). Om du lagrar dessa stora mängder små filer kan HDFS inte hantera dessa många små filer.
Eftersom HDFS designades för att fungera med ett litet antal stora filer för att lagra stora datamängder snarare än ett stort antal små filer. Om det finns många små filer, kommer NameNode att överbelastas eftersom den lagrar namnutrymmet för HDFS.
Lösning:
Slå helt enkelt ihop de små filerna för att skapa större filer och kopiera sedan större till HDFS.
Hadoop-arkiv (HAR-filer) hanterar problemet med många små filer. Hadoop Archives fungerar genom att bygga ett lager filsystem på toppen av HDFS.
Med hjälp av Hadoop-arkivkommandot skapas HAR-filer; detta kör ett MapReduce jobb för att packa filerna som arkiveras i ett litet antal HDFS-filer. Att läsa filer via HAR är inte effektivare än att läsa genom HDFS.
Eftersom varje HAR-filåtkomst kräver att två indexfiler läses samt att datafilen ska läsas, kommer detta att göra det långsammare.
Sekvensfiler övervinner också problemet med små filer. I vilken vi använder filnamnet som nyckel och filinnehållet som värde.
Genom att skriva ett program för filer (100 kB) kan vi lägga in dem i en enda sekvensfil och sedan kan vi bearbeta dem på ett strömmande sätt som använder sekvensfilen.
MapReduce i Hadoop kan dela upp Sequence-filen i bitar och arbeta på varje bit oberoende eftersom Sequence-filen är delbar.
Genom att lagra filer i Hbase kan vi lösa problemet med små filer. Vi lagrar faktiskt inte miljontals små filer i HBase utan lägger till det binära innehållet i filen i en cell.
b. Långsam bearbetningshastighet
MapReduce bearbetar en enorm mängd data. I Hadoop fungerar MapReduce genom att dela upp bearbetningen i faser:Karta och Minska . Så MapReduce kräver mycket tid för att utföra dessa uppgifter, vilket ökar latensen. Därför minskar bearbetningshastigheten.
Lösning:
Genom att bearbeta data i minnet löser Apache Spark detta problem. Liksom i minnesbehandling läggs ingen tid på att flytta data/processer in och ut ur disken, vilket gör det snabbare.
Apache Spark är 100 gånger snabbare jämfört med MapReduce eftersom den bearbetar allt i minnet.
Flink kan också övervinna detta problem. Flink bearbetar snabbare än Spark på grund av dess strömmande arkitektur.
c. Stöd endast för batchbearbetning
Hadoop stöder endast batch-bearbetning, det är inte lämpligt för streaming av data. Därför är den övergripande prestandan långsammare. MapReduce-ramverket utnyttjar inte minnet i Hadoop-klustret maximalt.
Lösning
Apache Spark löser detta problem eftersom det stöder strömbehandling. Men Spark-strömbehandling är inte lika effektiv som Flink eftersom den använder mikrobatch-bearbetning. Apache Flink förbättrar den övergripande prestandan eftersom den ger en enda körtid för såväl streaming som batchbearbetning.
d. Ingen realtidsbearbetning
Apache Hadoop är ett ramverk för batchbearbetning. Det betyder att det tar en enorm mängd data i input, bearbetar den och producerar resultatet.
Batchbearbetning är mycket effektiv för att bearbeta en stor mängd data, men beror på storleken på data som bearbetas och systemets beräkningskraft; en utgång kan försenas avsevärt. Apache Hadoop är inte lämplig för realtidsbehandling.
Lösning:
Spark är lämplig för strömbehandling. Ångbehandling ger kontinuerliga in-/utdata. Den bearbetar data inom kort tid.
Flink ger enkel körtid för både streaming och batch-bearbetning.
e. Iterativ bearbetning
Apache Hadoop är inte mycket effektiv för iterativ bearbetning. Eftersom Hadoop inte stöds cykliskt dataflöde (dvs. en kedja av steg där varje utgång från föregående steg är indata till nästa steg).
Lösning:
Spark övervinner detta problem. Eftersom Apache Spark kommer åt data från RAM istället för disken. Detta förbättrar dramatiskt prestandan för en iterativ algoritm som får åtkomst till samma datauppsättning upprepade gånger.
I Apache Spark, för iterativ bearbetning, måste varje iteration schemaläggas och exekveras separat.
f. Latens
MapReduce i Hadoop är långsammare eftersom det stöder olika format, strukturerade och enorma mängder data. I MapReduce tar Map en uppsättning data och omvandlar den till en annan uppsättning data, där ett enskilt element bryts ner i ett nyckel-värdepar.
Reduce tar utdata från kartan som och Reduce tar utdata från kartan som input och process vidare. MapReduce kräver mycket tid för att utföra dessa uppgifter och ökar därmed latensen.
Lösning:
Apache Spark kan minska detta problem. Även om Spark är batchsystemet är det relativt snabbare, eftersom det cachar mycket av indata i minnet med RDD. Apache Flink-dataströmning uppnår låg latens och hög genomströmning.
g. Ingen användarvänlighet
MapReduce-utvecklaren i Hadoop behöver lämna kod för varje operation vilket gör det mycket svårt att arbeta. I Hadoop har MapReduce inget interaktivt läge, men att lägga till kupa och gris gör det lite lättare att arbeta med MapReduce.
Lösning:
Spark har övervunnit detta problem, eftersom Spark har ett interaktivt läge. Så att både utvecklare och användare kan få mellanliggande feedback för frågor och andra aktiviteter.
Eftersom spark har massor av högnivåoperatörer så är det lätt att programmera Spark. Man kan också använda Apache Flink eftersom den också har högnivåoperatorer.
h. Säkerhetsproblem
Apache Hadoop är utmanande när det gäller att underhålla de komplexa applikationerna. Hadoop saknar kryptering på lagrings- och nätverksnivå, vilket är ett stort problem. Apache Hadoop stöder Kerberos-autentisering, vilket är svårt att hantera.
Lösning:
Apache Spark ger en säkerhetsbonus. Om du kör Apache Spark i HDFS kan den använda HDFS ACL:er och filnivåbehörigheter.
i. Sårbar av naturen
Apache Hadoop är skrivet i Java. Java är ett mest populärt språk, och därför utnyttjas java mest av cyberbrottslingar.
j. Ingen cachning
Apache Hadoop är inte effektivt för cachning. MapReduce kan inte cachelagra mellanliggande data i minnet för ytterligare krav och detta minskar prestandan för Hadoop.
Lösning:
Spark och Flink övervinner detta problem. Spark and Flink cachedata i minnet för ytterligare iterationer som förbättrar den övergripande prestandan.
k. Lång kod
Apache Hadoop har 1 20 000 rader kod. Antalet rader ger antalet buggar. Därför kommer det att ta längre tid att köra programmen.
Lösning:
Spark och Flink är skrivna i Scala och Java. Men implementeringen är i Scala, så antalet kodrader är mindre än Hadoop. Det tar alltså mindre tid att köra programmen.
Slutsats
Som ett resultat av Hadoops begränsning uppstod behovet av Spark och Flink. Gör alltså systemet vänligare att spela med en enorm mängd data.
Apache Spark tillhandahåller bearbetning i minnet av data, vilket förbättrar bearbetningshastigheten. Flink förbättrar prestandan eftersom det ger en gångtid för både streaming och batchbearbetning.
Spark ger säkerhetsbonus. Därför kan man lösa alla dessa Hadoop-begränsningar genom att använda andra stora datateknologier som Apache Spark och Flink.
Om du hittar andra begränsningar för Hadoop, så vänligen meddela oss genom att lämna en kommentar i ett avsnitt nedan.