Повторяющийся разбор записей
Одним из факторов, способствующих не слишком высокой производительности Hadoop, является то, что в конфигурации, которая применяется по умолчанию, данные сохраняются в распределенной файловой системе (HDFS) в том же текстовом формате, в котором они были образованы. Поэтому при использовании этого метода хранения обязанность разбора полей каждой записи ложится на код пользователя. Hadoop обеспечивает возможность хранения данных в файлах (SequenceFile) в виде пар "ключ/значение", но, несмотря на эту возможность, в коде пользователя требуется разбор "значения" каждой записи, если оно состоит из нескольких атрибутов. Мы обнаружили, что использование для хранения данных механизма SequenceFile без сжатия в наших испытаниях приводило к уменьшению производительности. Заметим, что именно тактика использования этого механизма без сжатия предлагалась сообществом MR для повышения производительности Hadoop.
В отличие от повторяющегося разбора записей в MR, в СУБД записи разбираются при начальной загрузке данных. Этот шаг разбора позволяет менеджеру хранения данных СУБД аккуратно разместить данные в области хранения, чтобы во время выполнения можно было непосредственно обращаться к наиболее эффективному представлению значений атрибутов. Во время выполнения никакой интерпретации кортежей параллельные СУБД не производят.
В модели MR нет ничего такого, что запрещало бы разбирать записи заранее и сохранять их в оптимизированных структурах (т.е. пойти на некоторое увеличение времени загрузки ради повышения производительности во время выполнения). Например, данные можно было бы хранить в файловой системе с использованием платформенно-независимого и расширяемого механизма компании Google Protocol Buffer, обеспечивающего сериализацию структурированных данных (эта опция не поддерживается в Hadoop). Или же можно было бы в каждом узле переместить данные из среды MR в реляционную СУБД, заменяя, тем самым, уровень хранения HGFS оптимизаированным хранилищем структурированных данных в стиле СУБД .
На основе подобных идей можно найти способы повышения производительности системы Hadoop. Накладные расходы на разбор данных являются проблемой, и механизм SequenceFile не обеспечивает ее эффективного решения. Эту проблему следует считать ориентиром при выборе направления будущих разработок.
