За разлика от всяка I/O подсистема, Hadoop също идва с набор от примитиви. Тези примитивни съображения, макар и общи по своята същност, вървят и със системата Hadoop IO, разбира се, с някаква специална конотация към нея. Hadoop се занимава с множество терабайти набори от данни; специално разглеждане на тези примитиви ще даде представа как Hadoop се справя с въвеждането и изхода на данни. Тази статия бързо преглежда тези примитиви, за да даде перспектива за входната изходна система на Hadoop.
Интегритет на данните
Интегритет на данните означава, че данните трябва да останат точни и последователни при всички операции по съхранение, обработка и извличане. За да гарантира, че никакви данни не се губят или повреждат по време на постоянството и обработката, Hadoop поддържа строги ограничения за целостта на данните. Всяка операция за четене/запис се извършва на дискове, още повече, че през мрежата е податлива на грешки. А обемът данни, които Hadoop обработва, само влошава ситуацията. Обичайният начин за откриване на повредени данни е чрез контролни суми. контролна сума се изчислява, когато данните за първи път влизат в системата и се изпращат по канала по време на процеса на извличане. Извличащият край изчислява отново контролната сума и съвпада с получените. Ако съвпада точно, тогава данните се считат за без грешки, иначе съдържат грешка. Но проблемът е – какво ще стане, ако изпратената контролна сума е повредена? Това е много малко вероятно, защото това е малка информация, но не е неоспорима възможност. Използването на правилния вид хардуер като ECC памет може да се използва за облекчаване на ситуацията.
Това е просто откриване. Следователно, за да се коригира грешката, се използва друга техника, наречена CRC (Cyclic Redundancy Check).
Hadoop го прави по-далеч и създава отделна контролна сума за всеки 512 (по подразбиране) байта данни. Тъй като CRC-32 е само 4 байта, режийните разходи за съхранение не са проблем. Всички данни, които влизат в системата, се проверяват от възлите за данни, преди да бъдат препратени за съхранение или по-нататъшна обработка. Данните, изпратени до конвейера на възела на данни, се проверяват чрез контролни суми и всяка намерена повреда незабавно се уведомява до клиента с ChecksumException . Клиентът, прочетен от datanode, също преминава през същата тренировка. Възлите на данни поддържат дневник на проверката на контролната сума, за да следят проверения блок. Регистраторът се актуализира от възела за данни при получаване на сигнал за успех за проверка на блок от клиента. Този тип статистика помага за поддържане на лошите дискове.
Отделно от това се извършва периодична проверка на магазина за блокове с помощта на DataBlockScanner работи заедно с нишката на datanode във фонов режим. Това предпазва данните от повреда във физическия носител за съхранение.
Hadoop поддържа копие или копия на данни. Това се използва специално за възстановяване на данни от масивна корупция. След като клиентът открие грешка, докато чете блок, той незабавно докладва на възела за данни за лошия блок от възела на име, преди да изхвърли ChecksumException . След това namenode го маркира като лош блок и планира всяка по-нататъшна препратка към блока към неговите реплики. По този начин репликата се поддържа с други реплики и маркираният лош блок се премахва от системата.
За всеки файл, създаден в LocalFileSystem на Hadoop , скрит файл със същото име в същата директория с разширение .
Компресия
Имайки предвид обема данни, с които се занимава Hadoop, компресирането не е лукс, а изискване. Има много очевидни предимства от компресирането на файлове, използвано правилно от Hadoop. Той спестява изискванията за съхранение и е задължителна способност за ускоряване на предаването на данни през мрежата и дисковете. Има много инструменти, техники и алгоритми, които обикновено се използват от Hadoop. Много от тях са доста популярни и са били използвани за компресиране на файлове през вековете. Например, често се използват gzip, bzip2, LZO, zip и т.н.
Сериализиране
Процесът, който превръща структурираните обекти в поток от байтове, се нарича сериализация . Това е специално необходимо за предаване на данни през мрежата или за запазване на необработени данни на дискове. Десериализация е просто обратният процес, при който поток от байтове се трансформира в структуриран обект. Това е особено необходимо за обектна реализация на необработените байтове. Следователно не е изненадващо, че разпределените изчисления използват това в няколко различни области:комуникация между процеси и постоянство на данните.
Hadoop използва RPC (Remote Procedure Call) за осъществяване на комуникация между процесите между възлите. Следователно, протоколът RPC използва процеса на сериализация и десериализация, за да изобрази съобщение в потока от байтове и обратно и да го изпрати през мрежата. Процесът обаче трябва да бъде достатъчно компактен, за да се използва най-добре мрежовата честотна лента, както и бърз, оперативно съвместим и гъвкав, за да се приспособят актуализациите на протокола във времето.
Hadoop има свой собствен компактен и бърз формат за сериализация, Writables , които програмите MapReduce използват за генериране на ключове и типове стойности.
Структура от данни на файловете
Има няколко контейнера на високо ниво, които разработват специализираната структура от данни в Hadoop, за да съхраняват специални типове данни. Например, за да поддържате двоичен дневник, SequenceFile контейнерът предоставя структурата на данните за запазване на двоични двойки ключ-стойност. След това можем да използваме ключа, като клеймо за време, представено от LongWritable и стойност от Записване , което се отнася до регистрирано количество.
Има друг контейнер, сортирано извличане на SequenceFile , наречен MapFile . Той предоставя индекс за удобно търсене по ключ.
Тези два контейнера са оперативно съвместими и могат да се преобразуват един от друг.
Заключение
Това е само бърз преглед на входно/изходната система на Hadoop. Ще се задълбочим в много сложни подробности в следващите статии. Не е много трудно да се разбере входно/изходната система на Hadoop, ако човек има основно разбиране за I/O системите като цяло. Hadoop просто вложи малко допълнителен сок, за да бъде в крак с неговата разпределена природа, която работи в огромен мащаб от данни. Това е всичко.
Справка
Уайт, Том. Hadoop, Окончателното ръководство, 2009 . O’Reilly Publications.
