Comparative Analysis of HDFS and Apache Ozone Data Storage Systems

Full Text

1. ВВЕДЕНИЕ

Термин «большие данные» появился в конце 2000-х гг., когда из-за лавинообразного роста количества цифровых данных, генерируемых в сети Интернет, потребовались принципиально новые системы для эффективной работы с ними. Важными свойствами, характеризирующими большие данные, являются так называемые 3V: volume – объем данных, velocity – скорость накопления и variety – разнообразность источников и структур данных [7]. Именно наличие этих свойств требуют разработки и использования принципиально новых решений для обработки и хранения данных. Важно отметить, что около 80% цифровых данных на сегодняшний день являются неструктурированными или полуструктурированными (веб-страницы, телеметрия и др.)¹. Данный факт не позволяет использовать традиционные локальные и распределенные реляционные СУБД для эффективного анализа подобного контента.

Прежде всего, понятие «большие данные» ассоциируется с экосистемой Hadoop – первой разработкой с открытым исходным кодом, позволяющей распределенно хранить и обрабатывать петабайты данных и решать огромное количество прикладных задач: от машинного обучения до полнотекстового поиска.

1.1. Архитектура Hadoop

Актуальная версия Hadoop 3 включает в себя 4 базовых компонента [7]:

• Hadoop Common: утилиты и программные библиотеки, позволяющие клиентам взаимодействовать с Hadoop;
• HDFS (Hadoop Distributed File System): распределенная файловая система, обеспечивающая высокоскоростной доступ к данным приложений;
• Hadoop YARN: платформа для планирования заданий и управления ресурсами кластера;
• Hadoop MapReduce: система на основе YARN для параллельной обработки больших наборов данных, один из вычислительных движков для Hadoop.

Рассмотрим взаимодействие основных модулей HDFS.

Пользователь HDFS взаимодействует только с HDFS Client-сервисом, который принимает запросы от пользователя и отображает результаты, скрывая процессы на основных узлах системы.

HDFS состоит из двух основных типов узлов:

• DataNode – сервера, на которых хранятся сами данные. Являются самым распространенным типом узлов в HDFS;
• NameNode – хранит дерево пространства имен HDFS и связанные с ним метаданные.

Файлы для хранения в HDFS разбиваются на блоки, хранятся и реплицируются в локальных файловых системах DataNode по всему кластеру; хранятся как объекты в памяти NameNode (и реплицируются на диск), каждый из которых обычно занимает около 200 байт [6].

1.2. Проблемы Hadoop и HDFS

Одной из ключевых проблем Hadoop является частый дисбаланс ресурсов хранения и вычислений. Данное ограничение возникает из-за использования подхода «перемещение кода к данным». В классическом Hadoop вычисления над данными проводятся на тех же серверах, где они и хранятся. Это заставляет клиентов покупать оборудование, имеющее как вместительный жесткий диск, так и мощные вычислительные ресурсы. Если потребность в объеме хранилища данных растет быстрее, чем потребности в количестве ядер для вычислений, то клиенту приходится платить также и за дополнительные вычислительные ресурсы.

Также важным недостатком HDFS является ограничение масштабирования системы. Согласно [7], максимальное количество файлов в HDFS не должно превышать 500 миллионов. Данное ограничение связано с особенностью хранения метаданных на HDFS NameNode: вне зависимости от размера блока данных размер метаданных, хранящихся для него, всегда остается фиксированным.

Хранение небольших файлов в HDFS приводит к неэффективному использованию памяти NameNode [1]. «Маленькие файлы» в терминологии Hadoop – это файлы, размер которых значительно меньше размера блока в HDFS (128 МБ по умолчанию). Причем наличие подобных файлов в HDFS естественно и неизбежно. Это могут быть временные файлы, скрипты для запуска кода, файлы конфигураций и т.д.

Если маленьких файлов слишком много, Name Node может исчерпать пространство метаданных в памяти раньше, чем узлы DataNode исчерпают пространство данных на диске. DataNode’ы также сообщает об изменениях в состоянии блоков в NameNode по сети, что тормозит процесс совершения операций.

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

Еще одной проблемой HDFS является отказоустойчивость. Высокая доступность (High Availability, HA) конфигурация использует архитектуру Active-StandBy для NameNode [7].

При портере всего двух узлов в кластере (обоих NameNode) становятся недоступными все метаданные HDFS, а значит и информация о расположении данных на кластере. В итоге все данные, хранящиеся на кластере, являются практически потерянными.

Ввиду рассмотренных выше ограничений HDFS, во многих организациях встает вопрос о миграции своих платформ хранения и обработки данных на более современные решения [2; 4].

2. APACHE OZONE

В 2020 г. было представлено распределенное объектное хранилище Apache Ozone. Основным драйвером для разработки Apache Ozone стало желание преодолеть архитектурные ограничения, которыми обладает HDFS [3].

Немаловажным преимуществом нового хранилища было максимальная совместимость с HDFS API, что позволяет применять код прикладных программ экосистемы Hadoop (Hive, Spark и т.д.) с новым типом хранилища данных с минимальными изменениями.

Разработчики Apache Ozone также учли современные тенденции в мире обработки больших данных – миграция продуктов в облачную среду и распространение протокола S3 [5], поэтому Apache Ozone изначально создавался как объектное хранилище.

2.1. Архитектура Apache Ozone

Основными компонентами Apache Ozone являются²:

• Ozone Manager – менеджер пространства имен, который хранит информацию о volume, bucket и ключах;
• Storage Container Manager – сервис, управляющий контейнерами для хранения данных;
• Recon Server – сервис мониторинга для кластера Ozone;
• Datanode – узлы для хранения данных;
• S3 Gateway – сервис, имплементирующий протокол S3 для работы с Ozone.

Схема взаимодействия основных компонентов Apache Ozone представлена на рис. 1.

 

Рис. 1. Схема взаимодействия компонентов Apache Ozone

Fig. 1. Apache Ozone Component Interaction scheme

 

Ozone использует сразу два вида Master-сервисов для хранения метаинформации: Ozone Manager и Storage Container Manager. Каждый volume является корневым элементом пространства имен в Ozone Manager. Это значительно отличается от HDFS, который предоставляет корневую файловую систему как единую сущность.

Storage Container Manager (SCM) – основной узел управления пространством блоков. Основная обязанность SCM – создавать контейнеры и управлять ими. Контейнер, объем которого равен 5 ГБ, является основной единицей репликации в Ozone.

Узлы Datanode регулярно отправляют отчеты о контейнерах подобно отчетам о блоках в HDFS. Количество отчетов по контейнерам Ozone гораздо ниже количества отчетов по блокам в HDFS. Например, кластер Ozone с узлами данных емкостью 196 ТБ будет иметь около 40 тысяч контейнеров. При использовании HDFS количество блоков хранения данных будет составлять порядка полутора миллионов.

Управляющие сервисы Apache Ozone, в отличие от HDFS, могут эффективно управлять метаданными не только в оперативной памяти, но и на дисках. Желательно хранить метаданных на быстрых дисках (NVME, SSD).

2.2. Организация хранения данных в Apache Ozone

Основные сущности хранения данных в Ozone – это namespace (пространство имен), volume (том), bucket (корзина) и key (ключ). Namespace Ozone состоит из множества томов. Volume можно сравнить с домашним каталогом пользователя. Они используются для хранения корзин (пользователи могут создавать любое необходимое количество). Ozone хранит данные в виде ключей, которые, в свою очередь находятся внутри корзин. На рис. 2 изображена иерархическая схема организации хранения объектов в Ozone.

 

Рис. 2. Организация хранения объектов в Apache Ozone

Fig. 2. Organization of object storage in Apache Ozone

 

2.3. Пользовательские интерфейсы Ozone

Ozone предоставляет два интерфейса для взаимодействия с данными, которые позволяют любому приложению, которое ожидает интерфейс типа HDFS, работать с Ozone без каких-либо изменений: это o3fs и ofs.

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

Также Ozone предоставляет совместимый с S3 интерфейс REST для использования данных хранилища объектов с любыми совместимыми с S3 инструментами. S3-контейнеры хранятся в томе /s3v. Для доступа к записи-чтении данных по этому интерфейсу используется S3G (S3 Gateway).

2.4. Преимущества архитектуры Ozone

При обращении к HDFS клиент должен получить актуальную информацию о расположении файлов. NameNode в HDFS является единственным Master-сервисом системы, где хранится вся метаинформация о расположении данных в DataNode. Ее можно разделить на два логических картежа:

• файл разбивается на группу блоков;
• каждый блок реплицируется на DataNode (по умолчанию трижды).

Таким образом для хранения одного файла в 128 MB необходимы по крайней мере четыре записи метаинформации в памяти NameNode для успешного поиска данных при обращении клиента.

Ozone же разделяет управление пространством имен и управление пространством блоков, что помогает системе масштабироваться намного лучше. Пространство имен управляется компонентом Ozone Manager, а пространство блоков управляется компонентом Storage Container Manager.

Реализация данной архитектуры позволяет хранить в Ozone огромное количество объектов. Технологическим ограничением в данном случае является исключительно размер дисков, выделенных под хранение метаданных Ozone в OM и SCM.

Другая проблема, которую решает Ozone – обеспечение улучшенной доступности и отказоустойчивости кластера: в HDFS при отказе обоих NameNode кластер становится недоступен. Чтобы избежать подобной ситуации необходимо иметь возможность увеличить количество реплик мастер серверов OM и SCM до необходимого. Для репликации метаданных между несколькими OM используется Apache Ratis (реализация Raft-протокола). С помощью данного протокола в кластере Ozone может быть любое нечетное количество Master-серверов, начиная с 3.

3. ERASURE CODING

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

Чтобы уменьшить выделение ресурсов на случай аварийной потери серверов можно использовать другие методы внесения избыточности. Один из них – ErasureCoding (EC), который поддерживается как в HDFS³, так и в Ozone⁴.

EC преобразует сообщение из k символов в более длинное сообщение (кодовое слово) из n символов так, что исходное сообщение может быть восстановлено по k′ любым символам.

В табл. 1 можно видеть сравнение классической тройной репликации с различными конфигурациями ErasureCoding. Data durability описывает число копий, которые могут быть утрачены без риска потери файла.

 

Таблица 1. Сравнение ErasureCoding и тройной репликации блоков

Table 1. Comparison of ErasureCoding and triple block replication

	Data blocks	Parity blocks	Data durability	Storage efficiency, %
Single replica	1	0	0	100
Three-way replica	3	0	2	33
RS(6,3)	6	3	3	66
RS(10,4)	10	4	4	71

 

Для того, чтобы использовать Erasure Coding-конфигурацию, на кластере должно D + P узлов данных, где D – количество серверов с данными; P – заданная четность (Parity blocks).

Размер всех D + P блоков должен быть одинаковым. Блоки меньшего размера дополняются пустыми данными.

Ozone поддерживает ограниченный набор конфигураций. Они задаются группой параметров (кодек)–(данные)–(четность)–(размер):

• кодек может быть только RS (Reed-Solomon) или XOR;
• данные и четность по умолчанию могут быть 3-2, 6-3 или 10-4;
• размер чанка может быть как числом, так и числом с суффиксом k. Если суффикс есть, это число умножается на 1024.

Доступные значения: 512, 1024, 2048 или 4096.

Примеры валидных конфигураций EC Ozone: RS-3-2-1024k, RS-6-3-1024k, XOR-2-1-1024;

В HDFS в настоящее время поддерживаются пять встроенных политик: RS-3-2-1024k, RS-6-3-1024k, RS-10-4-1024k, RS-LEGACY-6-3-1024k, XOR-2-1-1024k [16].

Так как описанный подход к хранению данных является достаточно популярным было принято решение включить в тестирование конфигурацию HDFS и Ozone с использованием подхода Erasure Coding на ряду со стандартным подходом троекратной репликации блоков.

4. ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ APACHE OZONE И HDFS

Объектом тестирования является объектное хранилище Apache Ozone доступ к которому осуществляется либо по протоколу s3:// (S3-совместимым клиентом), либо через Hadoop-совместимого клиента по схеме ofs:// и сравнение результатов с записью/чтением данных в HDFS.

В качестве эталонной системы был взят обычный Data Locality Hadoop кластер размером в 7 серверов со следующими характеристиками (табл. 2).

 

Таблица 2. Аппаратные характеристики серверов для проведения тестирования

Table 2. Hardware characteristics of servers for testing

CPU	2 Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz, 72 vCPU
RAM	525GB
SSD	4
Network	2x25Gbps

 

Архитектура кластера Ozone, использовавшаяся при проведении тестирования, представляет собой:

• три мастер-сервера с установленными в режиме High Availability OM и SCM;
• пять DataNode с установленными на них S3G.
• Архитектура кластера HDFS, использованная при проведении тестирования, представляет собой:
• два Name Node в режиме High Availability;
• пять DataNode.

В качестве конфигураций для тестирования были выбраны следующие варианты настройки кластера.

1. HDFS replication=3. Тестирование скорости чтения и записи данных на стандартном Hadoop кластере с фактором репликации блоков данных Х3.
2. HDFS EC RS-3-2-1024k. Тестирование скорости чтения и записи данных на Hadoop-кластере с HDFS, работающим в режиме Erasure Coding.
3. ofs RATIS/THREE. Тестирование скорости чтения и записи данных на кластере с Ozone в качестве хранилища данных. Используется стандартный подход хранения данных с использованием протокола Ratis для синхронизации метаинформации и троекратной репликацией контейнеров.
4. ofs EC RS-3-2-1024k, доступ к бакетам озона через s3g. Тестирование скорости чтения и записи данных на кластере с Ozone в качестве хранилища данных.

Был создан единый клиент для создания заданных параметров нагрузки для HDFS, ofs и нативный s3. Данный клиент позволяет задать произвольную нагрузку на HDFS, ofs или s3 и получить thread dumps любых подсистем и самого клиента и вывести метрики клиента в prometheus.

На момент написания статьи наиболее свежими версиями Apache Ozone являются 1.4.2 и 1.4.3. Чтобы исследовать темпы развития программного продукта обе версии сервиса сравнивались с HDFS версии 3.3.6.

4.1. Сценарий тестирования

Было принято решение тестировать операции чтения и записи файлов двух размеров: 20 Мб и 1 Кб.

Размер файлов в 20 Мб позволяет дать ощутимую нагрузку на файловые операции (CreateFile, Look UpFile, createKey, GetInfoKey и так далее) и в то же время оценить скорость работы подсистемы хранения данных (DataNode).

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

4.1.1. Тест с файлами 20 Мб

1. Создаем три директории/бакета с заданным типом репликации на HDFS и Ozone.
2. Создаем 300 000 файлов среднего размера 20 Мб, по 100 000 файлов на бакет посредством 250 клиентов (по 50 на клиентскую ноду) по схеме HDFS, по схеме ofs, через s3g (стандартный s3 клиент Apache, s3g выбирается случайно для загрузки каждого файла).
3. Запускаем чтение 300 000 файлов среднего размера 20 Мб, по 100 тыс. файлов на бакет посредством 250 клиентов (по 50 на клиентскую ноду) по схеме HDFS, по схеме ofs и через s3g.
4. Сравниваем результаты.

4.1.2. Тест с файлами 1 Кб

1. Создаем три директории/бакета с заданным типом репликации на HDFS и Ozone.
2. Создаем 3 000 000 файлов размером 1 Kб, посредством 250 клиентов (по 50 на клиентскую ноду) по схеме HDFS, ofs и через s3g.
3. Запускаем чтение 3 000 000 файлов размером 1 Kб, посредством 250 клиентов (по 50 на клиентскую ноду) по схеме HDFS, ofs и через s3g.
4. Сравниваем результаты.

4.2. Результаты тестирования

4.2.1. Тестирование записи и чтения файлов размером 1 Кб

По результатам тестирования можно сделать вывод, что скорость записи данных Ozone в версии 1.4.3 улучшилась в 1,5 раза, но, тем не менее, через схему ofs результат все еще как минимум в два раза меньше, по сравнению с HDFS на том же оборудовании. Скорость записи через схему s3:// увеличилась почти в 2 раза, но также значительно ниже, чем HDFS и на 13% медленнее ofs (табл. 3, рис. 3).

 

Таблица 3. Результат тестирования скорости записи файлов размером 1 Кб (файлов/с)

Table 3. Results of file writing speed tests for 1 KB files (files/sec)

	HDFS	OZONE 1.4.2	OZONE 1.4.3
HDFS/ofs(EC)	3000	1000	1500
s3(EC)		720	1300
HDFS/ofs(R)	4000	1000	1500
s3(R)		700	1300

 

Рис. 3. Результат тестирования скорости записи файлов размером 1 Кб (файлов/с)

Fig. 3. Results of file writing speed tests for 1 KB files (files/sec)

 

Тестирование чтения данных показало результат гораздо лучше: если производительность Ozone версии 1.4.2 на операциях чтения была почти на 30% ниже, чем HDFS, то Ozone 1.4.3 теперь на 60% обгоняет HDFS (табл. 4, рис. 4).

 

Таблица 4. Результат тестирования скорости чтения файлов размером 1 Кб (файлов/с)

Table 4. Results of file reading speed tests for 1 KB files (files/sec)

	HDFS	OZONE 1.4.2	OZONE 1.4.3
HDFS/ofs(EC)	33 000	24 000	53 000
s3(EC)		20 000	44 000
HDFS/ofs(R)	33 000	22 000	55 000
s3(R)		20 000	43 000

 

Рис. 4. Результат тестирования скорости чтения файлов размером 1 Кб (файлов/с)

Fig. 4. Results of file reading speed tests for 1 KB files (files/sec)

 

4.2.2. Тестирование чтения и записи файлов размером 20 Mб

Скорость записи файлов размером 20 Мб в HDFS и Ozone 1.4.2 примерно одинаковы. Ozone версии 1.4.3 показал рост на 18% при использовании схемы ofs с ErasureCoding и порядка 50% при использовании стандартной трехкратной репликации. Скорость записи через схему s3:// увеличилась более, чем в 2 раза. В версии Ozone 1.4.3 запись данных во всех конфигурациях оказалась значительно быстрее HDFS (табл. 5, рис. 5).

 

Таблица 5. Результат тестирования скорости записи файлов размером 20 Mб (файлов/с)

Table 5. Results of file writing speed tests for 20M files (files/sec)

	HDFS	OZONE 1.4.2	OZONE 1.4.3
HDFS/ofs(EC)	450	460	531
s3(EC)		280	600
HDFS/ofs(R)	216	190	320
s3(R)		150	280

 

Рис. 5. Результат тестирования скорости записи файлов размером 20 Мб (файлов/с)

Fig. 5. Results of file writing speed tests for 20M files (files/sec)

 

Тест показал более, чем двукратное преимущество HDFS над Ozone при чтении относительно больших файлов (табл. 6, рис. 6).

 

Таблица 6. Результат тестирования скорости чтения файлов размером 20 Мб (файлов/с)

Table 6. Results of file reading speed tests for 20M (files/sec)

	HDFS	OZONE 1.4.2	OZONE 1.4.3
HDFS/ofs(EC)	1350	600	765
s3(EC)		456	742
HDFS/ofs(R)	1380	736	875
s3(R)		715	794

 

Рис. 6. Результат тестирования скорости чтения файлов размером 20 Мб (файлов/с)

Fig. 6. Results of file reading speed tests for 20M (files/sec)

 

ЗАКЛЮЧЕНИЕ

В статье рассмотрены системы хранения данных HDFS 3.3.6, Ozone 1.4.0.2.0 и Ozone 1.4.0.3.0 на кластерах похожей конфигурации. Проведено тестирование базовых операций чтения и записи фалов различного размера и различных конфигураций хранилищ. Результаты тестирования оказались достаточно противоречивы. Ozone новейшей версии показал отличные результаты при чтении маленьких файлов и записи файлов размером 20 Мб. Но, в то же время, запись больших файлов и чтение файлов размером 1 Кб оказалась значительно медленнее результатов HDFS.

На основе полученных результатов можно утверждать, что если нагрузка на файловую систему как таковую достаточно велика, то предельная скорость записи на Ozone в два и более раз меньше, чем на HDFS.

Удалось установить, что замедление записи большого количества данных размером 1Кб связана с особенностями работы Ozone Manager: при большом количестве запросов на запись данных быстро заполняется очередь CallQueue.

Важно отметить, что Apache Ozone еще достаточно молодой проект, и на момент написания статьи в Jira Apache Ozone было открыто более 300 багов⁵. Но в то же время разработка, благодаря интересу сообщества, идет быстрыми темпами, что подтверждают результаты сравнения двух новейших версий сервиса.

¹ Structured vs unstructured data // IBM URL: https://www.ibm.com/think/topics/structured-vs-unstructured-data.

² Ozone architecture. Cloudera. URL: https://docs.cloudera.com/cdpprivate-cloud-base/7.1.9/ozone-overview/topics/ozone-architecture.html.

³ HDFS Erasure Coding. URL: https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html.

⁴ Ozone Erasure Coding. URL: https://ozone.apache.org/docs/edge/feature/erasurecoding.html.

⁵ Apache Ozone – ASF JIRA. URL: https://issues.apache.org/jira/projects/HDDS/summary.

About the authors

Kirill O. Ievlev

Moscow Technical University of Communications and Informatics

Author for correspondence.
Email: ievlev.k.o@yandex.ru
ORCID iD: 0009-0003-2723-3154
SPIN-code: 1380-5720
ResearcherId: IAN-1730-2023

Postgraduate Student, Assistant of the Department of Mathematical Cybernetics and Information Technologies

Russian Federation, Moscow

Mikhail G. Gorodnichev

Moscow Technical University of Communications and Informatics

Email: m.g.gorodnichev@mtuci.ru
ORCID iD: 0000-0003-1739-9831
SPIN-code: 4576-9642
Scopus Author ID: 55836031600
ResearcherId: D-3256-2019

Cand. Sci. (Eng.), Associate Professor, Head of the Department of Mathematical Cybernetics and Information Technologies, Dean of the Faculty of Information Technologies

Russian Federation, Moscow

References

Supplementary files