Пост 13. Структуры NameNode. Block reporting

Доброго времени суток!
Сегодня хотел освятить вопрос какие же структуры данных ханятся на главном сервере HDFS - NameNode. Но перед этим замечу, что у NN есть 2 очень важных "продукта жизнидеятельности". Файл checkpoint (fsimage) и файл изенений (editlog)

[root@namenode current]# ll|tail -8
-rw-r--r--. 1 hdfs hdfs      30 Mar  6 11:43 edits_0000000000000023545-0000000000000023546
-rw-r--r--. 1 hdfs hdfs 1048576 Mar  6 11:44 edits_inprogress_0000000000000023547
-rw-r--r--. 1 hdfs hdfs   30901 Apr  1 14:24 fsimage_0000000000000057057
-rw-r--r--. 1 hdfs hdfs      62 Apr  1 14:24 fsimage_0000000000000057057.md5
-rw-r--r--. 1 hdfs hdfs   32231 Apr  1 15:24 fsimage_0000000000000057268
-rw-r--r--. 1 hdfs hdfs      62 Apr  1 15:24 fsimage_0000000000000057268.md5
-rw-r--r--. 1 hdfs hdfs       6 Mar  6 11:43 seen_txid
-rw-r--r--. 1 hdfs hdfs     174 Apr  1 15:24 VERSION

Важный момент - что пишется в эти файлы. 

NameNode имеет несколько структур:

1) Файл - блоки (например: /tmp/file1 - block66, block91). Пишется в журнал изменений.

2) Файл - права доступа (например: /tmp/file1 hdfs:hadoop 777). Пишется в журнал.

3) Блоки - datanode. (block66 - datanode1, datanode8, datanode14). Не пишется в журнал изменений.

При каждой перезагрузке DN - передает namenode список блоков, которые она содержит (так называемый block reporting). Если презагружалась NN список блоков ей передают все ноды кластера.

Пост 12. Плоский файл со смещением.

Доброго времени суток!

Иногда хочется обрабатывать всеми прелестями, которые предоставляет hadoop,  файлы не меняя их начальный формат (хочется его сохранить для других приложений, например).

Бывает такое, что исходным файлом будет плоский файл со смещением  (каждая колонка имеет фиксированное смещение относительно начала строки).

Например, есть файл, в котором имеются 4 колонки: первая это символы с 1 по 4, вторая с 5 по 10, третья с 11по 16, четвертая с 17 по 24.Как то так:

col1fieldfield2field#3

а хочется получить структуру вида:

col1       field      field2    field#3

Нет проблем – описываем следующую структуру:

create external table fixed_offset (a string,b string, c string,d string)

ROW FORMAT SERDE 'org.apache.hadoop.hive.contrib.serde2.RegexSerDe'

 WITH SERDEPROPERTIES

 (

 "input.regex" = "(.{4})(.{5})(.{6})(.{7}).*",

 "output.format.string" = "%1$s %2$s %3$s %4$s"

 )

 STORED AS TEXTFILE; 

И обращаемся через обычный select:

Select * from fixed_offset

Пост 11. Запись файлов в HDFS.

Доброго времени суток. Подумалось мне, что о самом главном я еще и не рассказывал. А точнее о том как файлы записываются в HDFS. Иллюстрирует это действо картинка ниже.

Клиент, инициируя запись файла обращается к NameNode (NN) и сообщает в какую директорию HDFS и он хочет записать файл. NN проверяет наличие прав у клиента, факт существования файла и.т.п. Если все хорошо – передает список DN на которые надо записать файл. Клиент  «пилит» файл на своей стороне и по блокам начинает передавать его в кластер, где внутри кластера по интерконнекту происходит репликация. Затем это действо повторяется со следующим блоком и так далее пока не будут записаны все блоки. Рядом с каждым блоком пишется файл контрольной суммы, который каждый раз сверяется с расчетной при чтении блока.

Запись блоков происходит последовательно. Как говорил Сталин Черчилю на ялтинской конференции: “доверяй, но проверяй” – давайте проверим. 

Файл из прошлого поста (он у меня около 4.2 Мб) загружаем с разными размерами блока.

Сначала 1 Мб (это 5 блоков).

hadoop fs -D dfs.blocksize=1048576 -put /tmp/alpha.txt /tmp/

загрузка произошла практически моментально.

Теперь попробуем записать с блоком 1 Кб (я не сошел с ума – просто экспериментирую).

hadoop fs -D dfs.blocksize=1024 -put /tmp/alpha.txt /tmp/

Время загрузки значительно увеличилось (идет запись 4400 блоков вместо 5), что позволило нам не спеша открыть рядышком вторую консольку и командой

netstat -na|grep 50010|grep EST

Воочию убедиться что открыто не 4400 сессий с DataNodes (порт 50010), а периодически открываются разные сессии. Кстати, эта особенность framework - еще одно объяснение почему Hadoop любит большие блоки.