De standaard datablokgrootte van HDFS/Hadoop is 64 MB. De blokgrootte op de schijf is over het algemeen 4KB.
Wat betekent een blokgrootte van 64 MB? ->Betekent dit dat de kleinste eenheid voor het lezen van schijf 64 MB is?
Zo ja, wat is het voordeel hiervan?-> gemakkelijk voor continue toegang tot grote bestanden in HDFS?
Kunnen we hetzelfde doen door de originele blokgrootte van 4 KB te gebruiken?
Antwoord 1, autoriteit 100%
Wat betekent een blokgrootte van 64 MB?
De blokgrootte is de kleinste gegevenseenheid die een bestandssysteem kan opslaan. Als je een bestand van 1k of 60Mb opslaat, neemt het één blok in beslag. Zodra u de grens van 64 MB overschrijdt, heeft u een tweede blok nodig.
Zo ja, wat is het voordeel hiervan?
HDFS is bedoeld om grote bestanden te verwerken. Laten we zeggen dat je een bestand van 1000 MB hebt. Met een blokgrootte van 4k zou je 256.000 verzoeken moeten doen om dat bestand te krijgen (1 verzoek per blok). In HDFS gaan die verzoeken over een netwerk en brengen ze veel overhead met zich mee. Elk verzoek moet worden verwerkt door de Name Node om te bepalen waar dat blok kan worden gevonden. Dat is veel verkeer! Als u blokken van 64 MB gebruikt, daalt het aantal verzoeken tot 16, waardoor de kosten van overhead en belasting van de Name Node aanzienlijk worden verminderd.
Antwoord 2, autoriteit 29%
Het ontwerp van HDFS is oorspronkelijk geïnspireerd op het ontwerp van het Google File System (GFS). Hier zijn de twee redenen voor grote blokgroottes zoals vermeld in het originele GFS-artikel (noot 1 over GFS-terminologie versus HDFS-terminologie: chunk = block, chunkserver = datanode, master = namenode; opmerking 2: vetgedrukte opmaak is van mij):
Een grote brok biedt verschillende belangrijke voordelen. Ten eerste, het vermindert de behoefte van klanten om met de master te communiceren, omdat voor lezen en schrijven op dezelfde chunk slechts één eerste verzoek aan de master nodig is om informatie over de locatie van de chunk te krijgen. De vermindering is vooral belangrijk voor onze workloads, omdat applicaties grote bestanden meestal achter elkaar lezen en schrijven. […] Ten tweede, aangezien een client op een groot stuk waarschijnlijk veel bewerkingen op een bepaald stuk zal uitvoeren, kan het de netwerkoverhead verminderen door een aanhoudende TCP-verbinding met de chunkserver te houden over een langere tijdsperiode. Ten derde verkleint het de omvang van de metadata die op de master zijn opgeslagen. Hierdoor kunnen we de metadata bewaren
in het geheugen, wat op zijn beurt andere voordelen met zich meebrengt die we in paragraaf 2.6.1 zullen bespreken.
Tot slot wil ik erop wijzen dat de huidige standaardgrootte in Apache Hadoopis 128 MB (zie dfs.blocksize).
Antwoord 3, autoriteit 5%
In HDFS bepaalt de blokgrootte het niveau van replicatiedeclustering. Hoe kleiner de blokgrootte, uw blokken worden gelijkmatiger verdeeld over de DataNodes. Hoe hoger de blokgrootte, uw gegevens zijn mogelijk minder gelijkmatig verdeeld in uw cluster.
Dus wat heeft het voor zin om een hogere blokgrootte te kiezen in plaats van een lage waarde? Hoewel in theorie een gelijke verdeling van gegevens een goede zaak is, heeft het hebben van een te lage blokkering een aantal belangrijke nadelen. De capaciteit van NameNode is beperkt, dus een blokgrootte van 4 KB in plaats van 128 MB betekent ook dat er 32768 keer meer informatie moet worden opgeslagen. MapReduce zou ook kunnen profiteren van gelijk verdeelde gegevens door meer kaarttaken op meer NodeManager en meer CPU-kernen te starten, maar in de praktijk gaan theoretische voordelen verloren door het niet kunnen uitvoeren van sequentiële, gebufferde leesbewerkingen en vanwege de latentie van elke kaarttaak.
Antwoord 4, autoriteit 4%
In het normale besturingssysteem is de blokgrootte 4K en in hadoop 64 Mb.
Omdat voor het eenvoudig onderhouden van de metadata in Namenode.
Stel dat we slechts 4K blokgrootte hebben in hadoop en we proberen 100 MB aan gegevens in deze 4K te laden, dan hebben we hier steeds meer 4K-blokken nodig. En namenode moet al deze 4K-blokken met metadata onderhouden.
Als we een blokgrootte van 64 MB gebruiken, worden de gegevens in slechts twee blokken geladen (64 MB en 36 MB). Daarom wordt de grootte van de metadata verkleind.
Conclusie:
Om de last voor namenode HDFS te verminderen, geeft u de voorkeur aan 64 MB of 128 MB aan blokgrootte. De standaardgrootte van het blok is 64 MB in Hadoop 1.0 en het is 128 MB in Hadoop 2.0.
Antwoord 5
Het heeft meer te maken met het zoeken naar schijven van de HDD (Hard Disk Drives). In de loop van de tijd was de zoektijd van de schijf niet veel vooruitgegaan in vergelijking met de schijfdoorvoer. Dus als de blokgrootte klein is (wat tot te veel blokken leidt), zullen er te veel schijfzoekopdrachten zijn, wat niet erg efficiënt is. Terwijl we vooruitgang boeken van HDD naar SDD, heeft de zoektijd van de schijf niet veel zin, omdat het bewegende delen in SSD zijn.
Ook als er te veel blokken zijn, zal dit de Name Node belasten. Merk op dat de Name Node de volledige metadata (data over blokken) in het geheugen moet opslaan. In de Apache Hadoop is de standaard blokgrootte 64 MB en in de Cloudera Hadoop is de standaard 128 MB.
Antwoord 6
- Als de blokgrootte was ingesteld op minder dan 64, zou er een enorm aantal blokken in het cluster zijn, waardoor NameNode een enorme hoeveelheid metadata moet beheren.
- Omdat we voor elk blok een Mapper nodig hebben, zouden er veel Mappers zijn, die elk een stukje gegevens verwerken, wat niet efficiënt is.
Antwoord 7
De reden waarom Hadoop 64 MB koos, was omdat Google 64 MB koos. De reden waarom Google 64 MB koos, was vanwege een Goudlokje-argument.
Als je een veel kleinere blokgrootte hebt, zou de zoekoverhead toenemen.
Door een iets kleinere blokgrootte worden kaarttaken snel genoeg uitgevoerd zodat de kosten voor het plannen ervan vergelijkbaar worden met de kosten om ze uit te voeren.
Het hebben van een aanzienlijk grotere blokgrootte begint het beschikbare leesparallellisme te verminderen en kan het uiteindelijk moeilijk maken om taken lokaal voor de taken te plannen.
Zie Google Research-publicatie: MapReduce
http://research.google.com/archive/mapreduce.html
Antwoord 8
Hieronder staat wat het boek “Hadoop: The Definitive Guide”, 3e editie uitlegt (p45).
Waarom is een blok in HDFS zo groot?
HDFS-blokken zijn groot in vergelijking met schijfblokken, en de reden is om:
de kosten van het zoeken te minimaliseren. Door een blok groot genoeg te maken, wordt de tijd
om de gegevens van de schijf over te zetten kan aanzienlijk langer zijn dan
de tijd om te zoeken naar het begin van het blok. Dus de tijd om over te stappen
een groot bestand gemaakt van meerdere blokken werkt bij de schijfoverdracht
tarief.Een snelle berekening laat zien dat als de zoektijd ongeveer 10 ms is en
de overdrachtssnelheid is 100 MB/s, om de zoektijd 1% van de
overdrachtstijd, moeten we de blokgrootte rond de 100 MB maken. De
standaard is 64 MB, hoewel veel HDFS-installaties 128 MB gebruiken
blokken. Dit cijfer zal verder naar boven worden herzien als overdracht
snelheden groeien met nieuwe generaties schijfstations.Dit argument moet echter niet te ver worden doorgevoerd. Kaart taken in
MapReduce werkt normaal gesproken op één blok tegelijk, dus als u dat ook hebt gedaan
weinig taken (minder dan knooppunten in het cluster), zullen uw taken langzamer worden uitgevoerd
dan ze anders zouden kunnen.