Преглед на федерацията за клъстерна архитектура Hadoop 2.0

Федерация за клъстерна архитектура на Hadoop 2.0

Въведение:

В този блог ще се задълбоча във Федерацията на клъстерната архитектура на Hadoop 2.0. Apache Hadoop се е развил много след пускането на Apache Hadoop 1.x. Както знаете от предишния ми блог, че следва главна / подчинена топология, където NameNode действа като главен демон и е отговорен за управлението на други подчинени възли, наречени DataNodes. В тази екосистема този Master Daemon или NameNode се превръща в пречка и напротив, компаниите трябва да имат NameNode, който е силно достъпен. Именно тази причина се превърна в основата на HDFS Federation Architecture и HA (Архитектура с висока наличност) .

Темите, които разгледах в този блог, са както следва:

• Настоящата HDFS архитектура
• Ограничения на текущата HDFS архитектура
• HDFS Федерация Архитектура

Преглед на текущата архитектура на HDFS:

Както можете да видите на фигурата по-горе, текущият HDFS има два слоя:

• HDFS пространство от имена (NS): Този слой отговаря за управлението на директориите, файловете и блоковете. Той осигурява цялата операция с файловата система, свързана с пространство от имена, като създаване, изтриване или модифициране на файлове или файлови директории.
• Слой за съхранение: Състои се от два основни компонента.
  1. Управление на блокове : Изпълнява следните операции:
     • Проверява периодично сърдечните удари на DataNodes и управлява членството в DataNode в клъстера.
     • Управлява блоковите отчети и поддържа местоположението на блока.
     • Поддържа блокови операции като създаване, модификация, изтриване и разпределение на местоположението на блока.
     • Поддържа фактор на репликация, последователен в целия клъстер.

2. Физическо съхранение : Управлява се от DataNodes, които са отговорни за съхраняването на данни и по този начин осигурява достъп за четене / запис до данните, съхранявани в HDFS.

И така, текущата архитектура HDFS ви позволява да имате едно пространство от имена за клъстер. В тази архитектура един NameNode е отговорен за управлението на пространството от имена. Тази архитектура е много удобна и лесна за изпълнение. Също така, той осигурява достатъчна възможност да отговори на нуждите на малкия производствен клъстер.

Ограничения на настоящия HDFS:

Както беше обсъдено по-рано, настоящият HDFS е достатъчен за нуждите и случаите на използване на малък производствен клъстер. Но големи организации като Yahoo, Facebook откриха някои ограничения, тъй като клъстерът HDFS нарасна експоненциално. Нека да разгледаме набързо някои от ограниченията:

как да използвам

1. Пространството от имена е не е мащабируемо като DataNodes. Следователно можем да имаме само този брой DataNodes в клъстера, който един NameNode може да обработва.
2. Двата слоя, т.е. слой на пространство от имена и слой за съхранение са плътно свързани което прави алтернативното изпълнение на NameNode много трудно.
3. Ефективността на цялата система Hadoop зависи от пропускателна способност на NameNode. Следователно, цялостното изпълнение на всички HDFS операции зависи от това колко задачи NameNode може да обработва в определен момент.
4. NameNode съхранява цялото пространство от имена в RAM за бърз достъп. Това води до ограничения по отношение на размер на паметта т.е. броят на обектите на пространството от имена (файлове и блокове), с които може да се справи един сървър за пространство на имена.
5. Много от организациите (доставчик), разполагащи с HDFS, позволяват на множество организации (наематели) да използват своето пространство от имена на клъстера. Така че, няма разделяне на пространството от имена и следователно има без изолация сред организациите наематели, които използват клъстера.

HDFS Федерация Архитектура:

• В HDFS Federation Architecture имаме хоризонтална мащабируемост на услугата за имена. Следователно имаме множество NameNodes, които са обединени, т.е.независими един от друг.
• DataNodes са налични в дъното, т.е.подлежащ слой за съхранение.
• Всеки DataNode се регистрира с всички NameNodes в клъстера.
• DataNodes предават периодични сърдечни удари, блокират отчети и обработват команди от NameNodes.

Изобразителното представяне на HDFS Federation Architecture е дадено по-долу:

Преди да продължа напред, нека накратко да поговоря за горния архитектурен образ:

• Има множество пространства от имена (NS1, NS2,…, NSn) и всяко от тях се управлява от съответния NameNode.
• Всяко пространство от имена има свой собствен блоков пул (NS1 има Pool 1, NSk има Pool k и така нататък).
• Както е показано на изображението, блоковете от пул 1 (небесносини) се съхраняват в DataNode 1, DataNode 2 и т.н. По същия начин всички блокове от всеки блок блокове ще се намират във всички DataNodes.

Сега нека разберем подробно компонентите на HDFS Federation Architecture:

Блок басейн:

Блокът блокове не е нищо друго освен набор от блокове, принадлежащи към определено пространство от имена. И така, имаме колекция от блокови пулове, където всеки блоков пул се управлява независимо от другия. Тази независимост, при която всеки блок блокове се управлява независимо, позволява на пространството от имена да създава идентификатори на блокове за нови блокове без координация с други пространства от имена. Блоковете с данни, присъстващи във всички блокове, се съхраняват във всички DataNodes. По принцип блоковият пул осигурява абстракция, така че блоковете данни, пребиваващи в DataNodes (както е в Архитектурата на единичното пространство от имена), могат да бъдат групирани, съответстващи на определено пространство от имена.

Обем на пространството от имена:

Обемът на пространството от имена не е нищо друго освен пространство от имена заедно с неговия блоков пул. Следователно, в HDFS Федерацията имаме множество обеми на пространство от имена. Това е самостоятелна единица за управление, т.е.Всеки том на пространството от имена може да функционира независимо. Ако NameNode или пространство от имена бъдат изтрити, съответният блоков пул, който се намира в DataNodes, също ще бъде изтрит.

Демо на федерацията за клъстерна архитектура на Hadoop 2.0 | Едурека

Предполагам, че имате доста добра идея за HDFS Federation Architecture. Това е по-скоро теоретична концепция и хората обикновено не я използват в практическа производствена система. Има някои проблеми с внедряването на HDFS Federation, което затруднява внедряването. Следователно, HA (Архитектура с висока наличност) се предпочита за решаване на проблема с единичната точка на отказ. Покрих HDFS HA ​​архитектура в следващия ми блог.

След като разбрахте Hadoop HDFS Federation Architecture, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение по сертифициране на големи данни Hadoop на Edureka помага на обучаемите да станат експерти в HDFS, прежди, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, като използват случаи в реално време за търговия на дребно, социални медии, авиация, туризъм, финанси.

Имате въпрос към нас? Моля, споменете го в раздела за коментари и ние ще се свържем с вас.

как да използвам пакета в java -