Как Facebook хранит 300 петабайт и развивает инфраструктуру

Источник: computerra

В социальные сети попадает всё больше людей, которые стремительно наполняют их контентом. Хранилище данных Facebook выросло втрое за последний год, достигнув объёма в 300 ПБ. Основная проблема компании в том, что эти триста петабайт должны оставаться легкодоступными миллиарду пользователей. Как же крупнейшая социальная сеть справляется с этой задачей?

Для сотрудников Facebook "большие данные" - ежедневная действительность, бросающая всё новые вызовы. Целый отдел специалистов из разных областей постоянно разрабатывает перспективные методы хранения данных. Любую новую систему сначала тестируют на реальных массивах, после чего принимают решение: внедрять её, отправить на доработку или полностью изменить предлагаемый подход.

На аппаратном уровне в Facebook используются такие традиционные технологии, как дисковые системы хранения данных и RAID-массивы. Особенность в том, что они могут быть легко масштабированы "на лету" за счёт кластерной платформы.

Для упрощения процессов репликации и синхронизации в дата-центрах Facebook применяется иерархическая распределённая файловая система HDFS. Однако это не совсем типовое решение на основе платформы Hadoop.

Основу инфраструктуры Facebook составляет программная надстройка Hive, которая с целью ускорения обработки использует систему индексов и обеспечивает SQL-подобный язык запросов HiveQL. Хранение метаданных в СУБД значительно ускоряет выполнение семантической проверки при выполнении запросов.

Перед записью файлов в HDFS они предварительно сжимаются, причём алгоритм и настройки компрессии выбираются эвристически для каждого блока данных. Реализация системы обработки запросов Map-Reduce под названием Corona также имеет свои отличия. Она оптимизирована для работы с большими таблицами. 

В большинстве реляционных баз данные организованы в виде двумерных таблиц, анализ которых осуществляется построчно. В Hive используется гибридный многоколонный формат записей (RCFile), адаптированный для хранения реляционных таблиц на кластерах.

Структура формата RCFile (изображение: facebook.com).

Структура формата RCFile (изображение: facebook.com).

Структура размещения данных RCFile представляет собой систематическое сочетание нескольких компонентов, включающих формат хранения данных, подходы к их сжатию и методы оптимизации чтения. Он обеспечивает четыре ключевых преимущества: быструю загрузку данных, высокую скорость обработки запросов, эффективное использование дискового пространства и хорошую адаптивность динамических шаблонов доступа к данным.

В общем случае перевод табличных данных в битовую последовательность выполняется сначала по строкам, а затем по колонкам, но в RCFile сделана важная оптимизация: столбцы таблиц записываются друг за другом смежными блоками и сжимаются индивидуально с помощью кодека Zlib / LZO, снабжаясь описанием в виде метаданных. 

Благодаря такому подходу при операции чтения можно ограничиться выполнением выборочной распаковки данных. Поэтому при выполнении запроса пропускаются долгие этапы декомпрессии и десериализации ненужных столбцов. Специалисты Facebook указывают, что применение структуры RCFile позволяет им сжимать исходные данные примерно в пять раз. Без неё компании потребовалось бы сегодня хранилище на полтора эксабайта, а в ожидании загрузки ленты новостей пользователи успевали бы вздремнуть.

С дальнейшим распространением Facebook в развивающихся регионах размеры пользовательских профилей стали расти быстрее, а связка Hive + RCFile перестала быть достаточно эффективным решением.

Выход был найден при сотрудничестве с командой инженеров Hortonworks. Они разработали формат ORCFile, в котором оптимизация распределённого хранения данных в экосистеме Hadoop получила дальнейшее развитие.

Структура формата ORCFile (изображение: facebook.com).

Структура формата ORCFile (изображение: facebook.com).

 

Когда Hive записывает с помощью ORCFile табличные данные, они индивидуально сжимаются и разбиваются на блоки по 256 МБ, называемые полосами. Такой алгоритм был создан после многочисленных экспериментов с реальными базами. Размер полос в 256 МБ оказался оптимальным, а итогом проделанной работы стал вывод о неэффективности применения одинаковых настроек сжатия и постоянного использования словаря. 

Программисты Facebook изменили код ORCFile так, чтобы целесообразность использования разных методов компрессии определялась для каждого блока данных заранее и без ухудшения производительности. Объём памяти, занимаемый словарём, сократился на 30%, а скорость записи возросла в 1,4 раза.

Сравнение формата ORCFile в модификации Facebook с его исходным  вариантом и RCFile (изображение: facebook.com).

Сравнение формата ORCFile в модификации Facebook с его исходным вариантом и RCFile (изображение: facebook.com).

Другим важным преимуществом нового формата стала возможность индексировать столбцы и строки с указанием их смещения, устраняя необходимость в частом использовании разделительных знаков.

Применив все эти улучшения, команда Facebook обеспечила значительную экономию дискового пространства. Степень сжатия данных последовательно довели сначала до пятикратной, а теперь и до восьмикратной. Причём, скорость их обработки также увеличилась.  

Сегодня ORCFile уже успешно используется для хранения десятков петабайт данных. Модификация ORCFile, выполненная Facebook, демонстрирует в среднем втрое более высокую производительность, чем её изначальный вариант с открытым исходным кодом. Все наработки по оптимизации были переданы в проект Apache Hive.


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=36681