Меню

Hadoop HDFS - Разпределена файлова система на Hadoop

hadoop hdfs hadoop distributed file system

Този урок обяснява Hadoop HDFS - разпределена файлова система, компоненти и клъстерна архитектура на Hadoop. Също така ще научите за алгоритъма за осведоменост на стойката:

Както научихме в предишния урок, най-големият проблем с големите данни е да ги съхраняваме в съществуваща система. И дори ако някак си съхранихме част от него в съществуваща система, обработката на BigData отнема години.

Резултатите, които искахте за минути, отнемаха седмици или може би месеци и поради това стойността на този резултат беше загубена.

=> Внимавайте тук за простият сериал за обучение на BigData.

Компоненти на Hadoop - HDFS

Какво ще научите:

Разпределена файлова система Hadoop

За да разрешим този проблем или да се справим с него, сега имаме HADOOP. Hadoop реши този проблем с големи данни, използвайки Hadoop HDFS.

съхраняване на големи данни

Hadoop HDFS реши проблема със съхранението на големи данни и Намаляване на картата на Hadoop разреши проблемите, свързани с обработката на част от Големите данни.

Компоненти на Hadoop

Сега знаем, че Hadoop по същество има разпределена файлова система ... НО ЗАЩО?

Защо Hadoop е разпределена файлова система?

java j2ee интервю въпроси и отговори

Нека се опитаме да разберем какво е разпределена файлова система и да разберем предимствата на разпределената файлова система.

Разпределена файлова система

Да вземем пример за четене на 1TB данни. Имаме сървър, който е добър сървър от висок клас, който има 4 I / O (Input Output) канала и всеки канал има честотна лента от 100MB / s, като използвате тази машина, ще можете да прочетете тези 1TB данни в 43 Минути.

Сега, ако въведем 10 броя машини точно като това, какво ще се случи?

Разпределена файлова система

Времето е намалено до точно 4,3 минути. Това е така, защото цялото усилие е разделено на 10 машини и затова времето, необходимо за обработка на 1TB данни, намалява до 1/10тит.е. 4,3 минути.

По същия начин, когато разглеждаме BigData, тези данни се разделят на множество части от данни и ние всъщност ги обработваме поотделно и затова Hadoop е избрал разпределена файлова система пред централизирана файлова система.

Компоненти на Hadoop

Hadoop HDFS има 2 основни компонента за решаване на проблемите с BigData.

  • Първият компонент е Hadoop HDFS за съхранение на големи данни.
  • Вторият компонент е Hadoop Map Reduce за обработка на големи данни.

Основни компоненти на Hadoop

Сега, когато виждаме архитектурата на Hadoop (изображението е дадено по-долу), тя има две крила, където е лявото крило „Съхранение“ а дясното е „Обработка“ . Това означава, че лявото е HDFS, т.е. Hadoop Distribution File System, а дясното е YARN и Map Reduce, т.е. е обработващата част.

Използвайки HDFS, Hadoop ни позволява да съхраняваме големи данни и използвайки YARN & Map Reduce, Hadoop ни позволява да обработваме същите големи данни, които съхраняваме в HDFS.

Основни компоненти на Hadoop

Както можете да видите на изображението по-горе, HDFS има два основни демона или можете да ги извикате като процеси или нишки, които не са нищо друго освен JAVA процеси, т.е. изпълняващи се в JVM - NameNode и DataNode.

NameNode е главен демон, който работи на Master Machine, т.е. машина от висок клас по същество и DataNode е Slave машина, която работи на стоков хардуер. Може да има повече DataNode, тъй като Slave Machines са повече от Master Machine.

Така че винаги имаме един NameNode и множество DataNode, работещи на подчинени машини.

По същия начин имаме YARN от другата страна, която отново има два демона, единият е Resource Manager, който работи на Master Machine и Node Manager, който работи на Slave Machine, точно както DataNode. Така че всяка подчинена машина има два демона - единият е DataNode, а другият е Node Manager.

Главната машина работи с NameNode и работи с Resource Manager. NameNode е отговорен за управлението на данните в разпределената файлова система Hadoop, а Resource Manager е отговорен за изпълнението на задачите за обработка на тези съхранени данни.

NameNode и DataNode

Ще навлезем дълбоко в HDFS архитектурата и затова е важно да разберем какво е NameNode и DataNode, тъй като това са двата основни демона, които всъщност изпълняват изцяло HDFS.

NameNode

  • Това е Master Daemon.
  • Управление и поддържане на DataNodes.
  • Записва метаданни.
  • Получава сърдечен ритъм и блокира отчети от всички DataNodes.

DataNode

  • Това е Slave Daemon.
  • Тук се съхраняват реални данни.
  • Обслужва заявки за четене и писане от клиентите.

NameNode DataNode

Просто се съсредоточете върху диаграмата, както можете да видите, има централизиран машинен възел, който контролира различни DataNode, които са там, т.е. стоков хардуер. Така че Name Node не е нищо друго освен Master Daemon, който поддържа всички DataNode.

Тези NameNode имат цялата информация за данните, които се съхраняват в DataNode. DataNode, както подсказва самото име, съхранява данните, които се намират в клъстера Hadoop.

NameNode има само информацията за това какви данни се съхраняват на кой DataNode. И така, това, което можем да кажем, е, че NameNode съхранява метаданните на данните, които се съхраняват в DataNodes.

DataNode също прави друга задача, т.е.редовно изпраща сърдечния ритъм обратно към NameNode. Сърдечните удари всъщност казват на NameNode, че този DataNode е все още жив.

Например, DataNodes изпраща сърдечен ритъм обратно към NameNode и по този начин NameNode има картината, че тези DataNodes са живи, така че NameNode може да използва тези DataNode, за да съхранява повече данни или да чете данните от тези DataNodes.

Сега стигаме до DataNode, DataNode не е нищо друго освен Slave Daemons, който всъщност съхранява данните, изпратени до клъстера Hadoop. Тези DataNodes са тези, които всъщност обслужват заявката за четене и запис, направена от клиентите.

Ако някой иска да прочете данните от клъстера Hadoop, тогава тези заявки всъщност се обработват от DataNodes, където данните се намират.

Клъстерна архитектура на Hadoop

В предишната тема, свързана с NameNode и DataNode, използвахме термина „Hadoop Cluster“. Нека да разгледаме набързо какво точно е това?

Клъстерна архитектура на Hadoop

Горното изображение показва общия преглед на архитектурата на клъстери на Hadoop. Hadoop Cluster не е нищо друго освен Master-Slave Topology, в която има Master Machine, както можете да видите в горната част, т.е. Hadoop Cluster. В тази главна машина има NameNode и изпълняващият се диспечер на ресурси, т.е. Master Daemons.

Главната машина е свързана с цялата подчинена машина с помощта на ключови ключове, защото тези DataNodes всъщност се съхраняват в различни стелажи, така че, както можете да видите Компютър 1, Компютър 2, Компютър 3 до Компютър N. Машини или DataNodes и всички те присъстват в една стойка.

„Стойката всъщност е група от машини, които се намират физически на едно определено място и са свързани помежду си.“

По този начин мрежовата честотна лента между всяка машина е възможно най-малка. По същия начин има повече стелажи, но те не присъстват на едно и също място, следователно можем да имаме „n“ брой стелажи и също така да имаме „n“ брой DataNodes или компютри или Slave Machines в тези стелажи.

По този начин подчинените машини всъщност се разпределят по клъстера, но в същото време те са свързани помежду си.

Как се съхраняват данни в HDFS?

Сега бавно навлизаме в детайлите как HDFS работи изобщо. Тук ще изследваме архитектурата на HDFS.

Когато казваме, че съхраняваме файл в HDFS, данните се съхраняват като блокове в HDFS. Целият файл не се съхранява в HDFS, защото, както знаете, Hadoop е разпределена файлова система.

Така че, ако имате размер на файла може би 1 PB (Peta Byte), тогава този вид хранилище не присъства в една машина, тъй като клъстерът Hadoop е направен с помощта на стоковия хардуер. Хардуерът в една машина би бил около 1 TB или 2 TB.

По този начин целият файл трябва да бъде разделен на части от данни, които се наричат ​​HDFS блокове.

  • Всеки файл се съхранява на HDFS като блокове.
  • Размерът по подразбиране на всеки блок е около 128 MB в Apache Hadoop 2.x (и 64mb в предишната версия, т.е. Apache Hadoop 1.x).
  • Има възможност за увеличаване или намаляване на размера на файла на блоковете, използвайки конфигурационния файл, т.е. hdfssite.xml, който се доставя с пакета Hadoop.

Нека вземем пример, за да разберем този механизъм и да видим как се създават тези блокове.

Нека разгледаме файл от 248 MB тук, сега, ако го счупим или преместим този файл в Hadoop Cluster, т.е. 2.x, тогава този файл ще бъде разбит на един блок, т.е. Блок A от 128 MB и друг Б от 120 MB.

Както можете да видите, първият блок е от 128 MB, т.е. първата първа плоча се изрязва там и затова другият блок е от 120 MB, а не 128 MB, т.е. няма да губи място, ако оставащият размер на файла е по-малък от размера на блока по подразбиране.

Примерна диаграма на клъстер Hadoop

Сега имаме друг проблем пред нас, т.е. безопасно ли е да имаме по едно копие на всеки блок?

Отговорът е НЕ, защото има шанс системата да се провали и това не е нищо друго освен стоков хардуер, поради който може да имаме големи проблеми. За да преодолее този проблем, Hadoop HDFS има добро решение, т.е. „Репликацията на блок“.

недефинирана препратка към c ++

Репликация на архитектурен блок на Hadoop

Hadoop създава реплики на всеки блок, който се съхранява в разпределената файлова система на Hadoop и по този начин Hadoop е система с толерантност към неизправности, т.е. въпреки че системата ви се провали или вашият DataNode се провали или копието е загубено, ще имате множество други копия присъстват в другите DataNodes или в другите сървъри, така че винаги можете да изберете тези копия от там.

Репликация на блокове

Както се вижда в горната диаграма, която представлява репликация на блокове, има пет различни блока на файл, т.е. блок 1, 2,3,4,5. Нека първо проверим с блок 1 и ще намерите копия на блок 1 в възел 1, възел 2 и възел 4.

По същия начин Блок 2 също има три копия, т.е. Node 2, Node 3 и Node 4 и така същото за Block 3, 4 и 5 в съответните възли.

Така че освен създадените реплики, всеки блок е репликиран три пъти, т.е. Hadoop следва фактор на репликация по подразбиране от три, което означава, че всеки файл, който копирате в Hadoop Distribution File System, се репликира три пъти.

С други думи, ако копирате 1 GB файл в Hadoop Distribution File System, той всъщност съхранява 3 GB файл в HDFS. Добрата част е, че коефициентът на репликация по подразбиране е променлив чрез промяна в конфигурационните файлове на Hadoop.

Как Hadoop решава къде да съхранява репликите?

Hadoop всъщност следва концепцията за Rack Awareness, за да реши къде да съхранява коя реплика на блок.

По-долу е дадена диаграмата, изобразяваща алгоритъма за информираност на стойката.

Алгоритъм за осведоменост на багажника

Има три различни стойки, т.е. Rack-1, Rack-2 и Rack-3.

Rack-1 има четири DataNodes, както и Rack-2 & Rack-3, като по този начин целият клъстер Hadoop ще се състои от всичките три стелажа и ще има 12 DataNodes.

Да предположим, че блок A се копира в DataNode 1 в Rack-1, тъй като според концепцията за Rack Awareness репликата на Block A не може да бъде създадена в същия шкаф и трябва да бъде създадена във всеки друг шкаф, освен в Rack-1 като основният файл вече съществува в Rack-1.

Ако създадем репликите на блок A в същия Rack-1 и в случай, че целият Rack-1 се провали, ние със сигурност ще загубим данните, поради което репликите трябва да се съхраняват във всеки друг шкаф, но не и в Rack-1.

Така че репликата ще бъде създадена в DataNode 6 и 8 на Rack-2. По същия начин, за блок Б и блок С, репликите ще бъдат създадени в различни стелажи, както е показано в горната диаграма.

Заключение

Научихме със следните насоки от този урок-

  • Hadoop HDFS решава проблема със съхранението на BigData.
  • Hadoop Map Reduce решава проблемите, свързани с обработката на BigData.
  • NameNode е Master Daemon и се използва за управление и поддръжка на DataNodes.
  • DataNode е Slave Daemon и реалните данни се съхраняват тук. Той служи за четене и писане на заявки от клиентите.
  • В Hadoop Cluster стелажът всъщност е група от машини, които присъстват физически на едно определено място и са свързани помежду си.
  • Всеки файл се съхранява на HDFS като блокове.
  • Размерът по подразбиране на всеки блок е около 128 MB в Apache Hadoop 2.x (64 MB в предишната версия, т.е. Apache Hadoop 1.x)
  • Има възможност за увеличаване или намаляване на размера на файла на блоковете, използвайки конфигурационния файл, т.е. hdfssite.xml, който се доставя с пакета Hadoop.

В следващия урок за HDFS ще научим за HDFS архитектурата и механизмите за четене и запис.

=> Посетете тук, за да видите поредицата за обучение на BigData за всички.

Препоръчително четене

^