Эта статья выбрана из серии статей «Практика инфраструктуры Byte Beat».

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

Как распределенная система хранения данных с самой большой внутренней емкостью хранения и масштабируемостью кластера в ByteDance, HDFS быстро развивается вместе с быстрым расширением ключевых направлений бизнеса ByteDance. Эта статья начнется с процесса разработки HDFS и представит основные проблемы и решения на пути разработки.

Введение в HDFS

Поскольку такая система, как HDFS, существует уже очень давно, а сценарии приложений очень зрелы, мы кратко представим эту часть.

Полное название HDFS — распределенная файловая система Hadoop, которая является наиболее широко используемой в отрасли распределенной файловой системой с открытым исходным кодом. Принцип и архитектура в основном такие же, как у Google GFS. Его основные особенности заключаются в следующем:

То же представление дерева каталогов, что и локальная файловая система
Добавлять только записи (случайные записи не поддерживаются)
Последовательное и случайное чтение
Очень большой масштаб данных
Простое расширение и высокая отказоустойчивость

ByteDance с поддержкой HDFS

ByteDance уже давно использует HDFS и за 7 лет разработки напрямую поддержала более десяти платформ данных и косвенно поддержала сотни бизнес-разработок. С точки зрения размера кластера и объема данных платформа HDFS превратилась в крупную платформу с десятками тысяч серверов в компании, поддерживающую объем данных уровня EB.

Прежде чем углубляться в соответствующие технические детали, давайте взглянем на архитектуру ByteDance HDFS.

Введение в архитектуру

уровень доступа

Уровень доступа — это самый большой уровень, отличающийся от версии сообщества, который не определен в версии сообщества. При реализации ByteDance из-за того, что узлы в кластере слишком велики, нам нужно много узлов имен для реализации механизма федерации для доступа к службам данных различных предприятий верхнего уровня. Однако, когда количество NameNodes становится очень большим, унифицированный доступ, запрашиваемый пользователями, и управление унифицированными представлениями также будут иметь большие проблемы. Чтобы решить проблему слишком разбросанного доступа пользователей, нам нужен независимый уровень доступа для поддержки унифицированного доступа, запрошенного пользователями, и прямой маршрутизации, в то же время он также может предоставлять права пользователей и возможности управления потоком в сочетании со службами; кроме того, уровень доступа также должен обеспечивать унифицированное представление внешнего дерева каталогов.

Что касается формы развертывания, уровень доступа зависит от некоторых внешних компонентов, таких как Redis, MySQL и т. д., и будет состоять из группы NNProxy без сохранения состояния, которые обеспечивают маршрутизацию запросов, ограничение квоты, возможность отслеживания и ограничение скорости трафика.

слой метаданных

Основными модулями этого уровня являются Name Node, ZKFC и BookKeeper (в отличие от QJM, BookKeeper более стабилен и надежен с точки зрения крупномасштабной многоузловой синхронизации данных).

Name Node отвечает за хранение метаданных всего кластера HDFS и является мозгом всей системы. В случае сбоя весь кластер становится недоступным. Таким образом, Name Node имеет набор решений высокой доступности master-slave на основе ZKFC с горячим резервированием.

Name Node также сталкивается с проблемами масштабируемости, а пропускная способность одной машины всегда ограничена. Итак, HDFS представила механизм федерации. В кластере можно развернуть несколько групп узлов имен, которые независимо поддерживают свои собственные метаданные и совместно используют ресурсы хранения узла данных. Таким образом, кластер HDFS можно масштабировать бесконечно. Однако в рамках этого механизма федерации деревья каталогов каждой группы узлов имен отделены друг от друга. Таким образом, есть некоторые решения, которые позволяют всему кластеру федерации предоставлять внешнему миру полное представление о дереве каталогов.

слой данных

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

Узел данных будет периодически сообщать пульс узлу имени и периодически сообщать информацию о своей сохраненной копии узлу имени. Этот процесс выполняется независимо для каждого кластера в Федерации. Возвращаемый результат отчета пульса будет содержать инструкции, выданные узлом имени узлу данных.Например, необходимо скопировать копию на другой узел данных или удалить копию.

Основной бизнес

Давайте посмотрим на основные сервисы, которые в настоящее время предоставляет ByteDance HDFS:

Hive, HBase, служба журналов, хранилище данных Kafka
Yarn, данные платформы вычислительной платформы Flink
Spark, MapReduce для хранения данных, связанных с вычислениями

стадия разработки

В ByteDance, с быстрым развитием бизнеса, объем данных и масштаб кластера HDFS быстро увеличились.Первоначальный кластер HDFS быстро превысил масштаб тысяч и десятков тысяч. В середине я наступил на бесчисленное количество ям, а на большой сцене есть несколько этапов.

Первый этап

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

Федерация также создает проблему унифицированного пространства имен, поэтому унифицированное пространство просмотра необходимо, чтобы помочь предприятиям создать унифицированный доступ. Чтобы решить эту проблему, мы представили компонент Name Node Proxy для реализации таких функций, как унифицированное представление и управление несколькими арендаторами, которые будут представлены в главе NNProxy ниже.

вторая стадия

Объем данных продолжает увеличиваться, а также есть узкие места в управлении деревом каталогов в режиме федерации, в основном это выражается в том, что после увеличения объема данных GC версии Java становится более частым, стоимость миграция узлов по поддеревьям слишком велика, время запуска узлов слишком велико и т. д. Проблема. Поэтому мы решили проблемы GC, оптимизации блокировок, ускорения запуска и т. д. посредством рефакторинга, а также дополнительно улучшили сервисные возможности оригинального Name Node. Содержит больше метаданных. Чтобы решить эту проблему, мы также внедрили компонент DanceNN, представленный ByteDance, который совместим со всеми функциями оригинальной Java-версии NameNode, что значительно повышает стабильность и производительность. Подробности описаны в главе DanceNN ниже.

Третий этап

Когда объем данных превышает EB, а масштаб кластера расширяется до десятков тысяч, проблема медленных узлов, более точной классификации услуг, проблемы стоимости и узких мест метаданных становятся более заметными. С точки зрения архитектуры мы продолжаем развиваться в направлении улучшения построения многопользовательской системы, реконструкции узлов данных и слоев метаданных. Эта часть в данный момент в процессе, так как будет много точек оптимизации, в этой статье будет дана практика реализации оптимизации медленных узлов.

ключевые улучшения

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

NNProxy (имя узла прокси)

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

Давайте сначала представим восходящую и нисходящую системы, в которых находится NNProxy.

Давайте сначала посмотрим, что делает NNProxy.

управление маршрутом

Как упоминалось во введении к федерации выше, каждый кластер поддерживает свое собственное независимое дерево каталогов и не может предоставить внешнему миру полное представление дерева каталогов. Управление маршрутизацией в NNProxy решает эту проблему. Управление маршрутизацией хранит таблицу монтирования, в которой записаны отношения сопоставления между несколькими путями и кластером.

Например/user -> hdfs://namenodeB, значение этого отношения отображения состоит в том, что /user и его подкаталоги находятся вnamenodeBВ этом кластере весь доступ к /user и его подкаталогам будет перенаправляться NNProxy наnamenodeB, получить результат, а затем вернуть его клиенту.

Принцип сопоставления — самое длинное совпадение, например, у нас есть другое сопоставление/user/tiger/dump -> hdfs://namenodeC, то /user/tiger/dump и все его подкаталоги находятся на namenodeC, а другие подкаталоги в каталоге /user — на namenodeB. Как показано ниже:

Ограничение квоты

Учащиеся, которые использовали HDFS, будут знакомы с концепцией квоты. Мы выделяем определенный объем пространства для каждой коллекции каталогов, и как только использование превышает этот порог, запись отключается. Эту работу выполняет NNProxy. NNProxy будет получать последнюю информацию об использовании квоты через систему мониторинга квоты в режиме реального времени.Когда пользователь выполняет операции с метаданными, NNProxy выносит суждение на основе ситуации с квотой пользователя и принимает решение о прохождении или отклонении.

Отследить поддержку

ByteTrace — это система трассировки, которая записывает и отслеживает поведение вызовов между пользователями и системой, а также системой в целях анализа, эксплуатации и обслуживания. Трассировочная информация в нем будет прикреплена к запросу RPC к NNProxy. После того, как NNProxy получит ByteTrace, он может узнать восходящий модуль, ПОЛЬЗОВАТЕЛЯ и идентификатор приложения текущего запроса. С одной стороны, NNProxy отправляет эту информацию в Kafka для некоторого автономного анализа, а с другой стороны, она агрегирует и управляет в режиме реального времени, чтобы отслеживать онлайн-трафик.

Ограничения движения

Несмотря на то, что NNProxy очень легкий и может выдерживать большое количество запросов в секунду, пропускная способность серверного узла имен ограничена. Таким образом, когда запросы на чтение и запись с высоким QPS полностью перенаправляются на узел имен из-за внезапных больших заданий, узел имен будет перегружен, задержка увеличится и даже возникнет OOM, затрагивающий всех пользователей в кластере. Поэтому еще одной очень важной задачей NNProxy является ограничение тока для защиты бэкэнда Name Node. В настоящее время текущее ограничение основано на параметрах путь+RPC и пользователь+RPC.Например, мы можем ограничить запрос на создание пути /user/tiger/warhouse до 100 запросов в секунду или запрос на удаление пользователя до 5 запросов в секунду. . Как только трафик пользователя превысит этот порог, NNProxy вернет повторное исключение, и Клиент повторит попытку после получения этого исключения. Таким образом, дросселированный путь или пользователь почувствуют, что доступ к HDFS происходит медленнее, но это не приведет к сбою.

Dance NN (узел названия танца)

решенная проблема

Как упоминалось выше, после того, как объем данных достигает уровня EB, в исходной Java-версии Name Node возникает множество онлайн-проблем, которые необходимо решить. Ниже приводится краткое изложение некоторых проблем, с которыми мы столкнулись в процессе практики:

Java-версия Name Node разработана на языке Java, когда масштаб INode составляет сотни миллионов, это неизбежно приведет к серьезным проблемам GC;
Узел имени версии Java полностью размещает метаинформацию INode в памяти, а 1 миллиард INode занимают около 800ГБ памяти (включая часть нативной памяти, занимаемой самой JVM), что еще больше усугубляет GC;
В нашем текущем масштабе кластера для перезапуска Name Node от перезапуска до восстановления службы требуется 6 часов.В случае одновременного сбоя основного и резервного, бизнес верхнего уровня серьезно страдает;
Узел имени версии Java имеет глобальную блокировку чтения-записи, любая операция модификации дерева каталогов блокирует другие операции чтения-записи, а параллелизм низкий;

Из вышеизложенного видно, что в сценарии с большим объемом данных нам срочно нужна новая версия архитектуры Name Node для переноса наших массивных метаданных. В дополнение к переписыванию языка C++, чтобы избежать проблем со сборщиком мусора, вызванных Java, мы также провели специальные оптимизации в некоторых сценариях.

Дизайн блокировки дерева каталогов

HDFS представляет собой распределенный кластер внутри и обеспечивает единую файловую систему извне, поэтому операции с файлами и каталогами должны быть такими же, как операции в локальной файловой системе Linux. Это требует, чтобы HDFS соответствовала тем же характеристикам атомарности, согласованности, изоляции и надежности, что и характеристики ACID в системах баз данных. Поэтому, когда DanceNN сталкивается с несколькими пользователями, работающими с одним и тем же файлом или одним и тем же каталогом одновременно, необходимо убедиться, что атрибут ACID не будет уничтожен, и операция должна быть заблокирована.

В отличие от традиционного хранилища KV и структуры таблиц базы данных, DanceNN поддерживает древовидную структуру данных, поэтому простая блокировка клавиш или блокировка строк неприменима в DanceNN. В случае блокировки таблицы базы данных или нативной NN добавление одной блокировки ко всему дереву каталогов серьезно повлияет на общую пропускную способность и задержку.Поэтому DanceNN переработал древовидную структуру блокировки для обеспечения ACID.Пропускная способность чтения может достигать 8 Вт, а пропускная способность записи может достигать 2 Вт, что более чем в 10 раз превышает производительность нативной NN.

Здесь мы переклассифицируем RPC, напримерcreateFile,getFileInfo,setXAttrЭтот тип RPC по-прежнему является простой операцией CURD на определенном INode; напримерdeleteRPC можно удалить файл или каталог, последнее повлияет на все файлы во всем поддереве; напримерrenameRPC, с другой стороны, является более сложным типом операции, которая может включать в себя несколько INode или даже все INode в нескольких поддеревьях.

Оптимизация запуска DanceNN

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

Многопоточное сканирование и заполнение BlockMap

В процессе запуска системы первым шагом является чтение информации, сохраненной в дереве каталогов, и заполнение BlockMap, что аналогично операции чтения FSImage с помощью NN в Java. В конкретном процессе реализации запускается несколько потоков для параллельного сканирования статической древовидной структуры каталогов. Поместите результат сканирования в заблокированный буфер. Когда количество элементов в буфере достигает заданного числа, новый буфер регенерируется для получения запроса, и в старом буфере запускается поток для заполнения данными в BlockMap.

Получение оптимизации отчетов по блокам

После запуска DanceNN сначала перейдет в безопасный режим, получит отчеты о блоках со всех узлов даты и улучшит информацию, сохраненную в BlockMap. Когда сообщаемый узел даты достигает определенного процента, режим безопасности будет отключен, и запрос клиента может быть официально получен в это время. Следовательно, скорость получения отчетов о блоках также повлияет на время запуска Date Node. DanceNN сделал здесь оптимизацию, назначив разные запросы разным потокам для обработки по BlockID, каждый поток отвечает за фиксированный слайс, и нет конкуренции между потоками, что значительно ускоряет скорость получения отчетов по блокам. Как показано ниже:

Оптимизация медленных узлов

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

Вообще говоря, оптимизация проблемы медленного узла тесно связана с бизнес-требованиями верхнего уровня и объемом базовых ресурсов.В крайних случаях запрос верхнего уровня очень мал, а ресурсы нижнего уровня достаточно богаты. , проблемы с медленными узлами будет очень мало, и наоборот, они станут очень серьезными. В кластере ByteDance HDFS проблема медленных узлов когда-то была очень серьезной, особенно после того, как процент использования диска стал очень высоким, одна за другой возникали различные проблемы с медленными узлами. Фундаментальная причина в том, что баланс ресурсов отстает.Использование диска многих машин достигло красной черты, что приводит к деградации записи.Новые горячие ресурсы будут сосредоточены на небольшом количестве машин.В этом случае, когда количество запросов в секунду для бизнеса верхнего уровня увеличивается. Для некоторых служб анализа больших данных и запросов с высокими требованиями к задержке P999 большое количество обращений к данным (> 10 000 запросов), вероятно, застревает в обработке медленного запроса.

Направление нашей оптимизации будет разделено на два аспекта: чтение медленных узлов и запись медленных узлов.

Читать оптимизацию медленных узлов

Мы прошли несколько этапов:

Самое раннее, используя версию сообщества, его Switch Read использует время для чтения пакета как статистическую единицу.Когда время для чтения пакета превышает пороговое значение, считается, что время чтения текущего пакета истекло. Если в течение определенного временного окна слишком много пакетов тайм-аута, текущий узел считается медленным узлом. Но проблема в том, что использование пакетов в качестве статистической единицы делает алгоритм недостаточно чувствительным, так что каждый раз, когда считывается медленный узел, для небольших сценариев ввода-вывода (некоторые компании, занимающиеся перебором байтов, используют большое количество случайных небольших операций ввода-вывода в качестве типичных сценарии использования), эти накопившиеся пакеты вызвали проблемы.
Впоследствии мы разработали оптимизацию чтения для Hedged Read. Hedged Read устанавливает тайм-аут для каждого чтения. Если время чтения истекло, другой поток будет открыт, чтобы инициировать запрос на чтение ко второй реплике в новом потоке, и, наконец, ответ, возвращенный предпочтительно на первой и второй репликах, будет принят в качестве результата чтения. Однако в этом случае, когда происходит концентрация медленных узлов, это приведет к усилению трафика чтения. В тяжелых случаях даже небольшой диапазон пропускной способности недоступен в течение короткого времени.
Основываясь на предыдущем опыте, мы дополнительно оптимизировали и включили оптимизацию Fast Switch Read.Этот метод оптимизации использует пропускную способность в качестве критерия для оценки медленных узлов.Когда пропускная способность в течение периода времени меньше порогового значения, считается текущий узел быть медленным узлом. И порог динамически регулируется в соответствии с текущим состоянием чтения, а длина временного окна и размер порога пропускной способности динамически изменяются. В следующей таблице представлена стоимость онлайн-бизнес-теста на тот момент:

Host:X.X.X.X	3 Копировать Переключатель Чтение	2 копии Хеджированное чтение	3 копии Хеджированное чтение	3 Copy Fast Switch Read (оптимизированный алгоритм)
Время чтения p999	977 ms	549 ms	192 ms	128 ms
Максимальное время чтения	300 s	125 s	60 s	15.5 s
Количество вхождений длинного хвоста (более 500 мс)	238 раз/день	75 раз/день	15 раз/день	3 раза/день
Количество вхождений длинного хвоста (более 1000 мс)	196 раз/день	64 раза/день	6 раз/день	3 раза/день

Дополнительные соответствующие данные испытаний:

Напишите оптимизацию медленного узла

Применимые сценарии для оптимизации узла медленной записи относительно просты. Основное решение — замедлить промежуточные узлы конвейера в процессе записи. Для решения этой проблемы мы также разработали алгоритмы Fast Failover и Fast Failover+.

Fast Failover

Fast Failover будет поддерживать количество пакетов, время ACK которых слишком велико в течение определенного периода времени.Когда количество ACK тайм-аута превышает пороговое значение, он завершит текущий блок и подаст заявку на новый блок на namenode для продолжения записи.

Проблема с Fast Failover заключается в том, что произвольное завершение текущего блока увеличит количество небольших блоков в системе, что негативно скажется на последующей скорости чтения и обслуживании метаданных namenode. Поэтому Fast Failover поддерживает порог переключения, и если объем записываемых данных (размер блока) больше этого порога, будет выполнено переключение блоков.

Однако для достижения порогового размера данных для записи это вызовет задержку, которую трудно воспринять пользователям, поэтому, когда объем данных меньше порогового, требуется дополнительная оптимизация.

Fast Failover+

Для решения вышеуказанных проблем, когда количество записываемых данных (размер блока) меньше порогового, мы вводим новый метод оптимизации - Fast Failover+. Алгоритм сначала отфильтровывает более медленные узлы данных из конвейера, удаляет медленные узлы из текущего конвейера и переходит к этапу восстановления конвейера. Pipeline Recovery подаст заявку на новый узел данных в namenode, сформирует новый конвейер с оставшимися узлами данных и синхронизирует записанные данные с новым узлом данных (этот шаг называется блоком передачи). Из-за небольшого объема записанных данных время передачи блока невелико. По статистике среднее время p999 всего 150мс. Дополнительные расходы, связанные с восстановлением конвейера, приемлемы.

В следующей таблице представлена стоимость онлайн-бизнес-теста на тот момент:

Host:X.X.X.X	Fast Failover p99	Fast Failover+ p99 (оптимизированный алгоритм)	Fast Failover p95	Fast Failover+ p95 (оптимизированный алгоритм)
Средняя продолжительность промывки	1.49 s	1.23 s	182 ms	147 ms
Максимальное время промывки	80 s	66 s	9.7 s	6.5 s
Количество вхождений длинного хвоста (p99 > 10 с, p95 > 1 с)	63 раза/день	38 раз/день	94 раза/день	55 раз/день
Количество вхождений длинного хвоста (p99 > 5 с, p95 > 0,5 с)	133 раза/день	101 раз/день	173 раза/день	156 раз/день

Некоторые дальнейшие сравнения практических эффектов:

конец

Разработка HDFS в ByteDance длилась очень долго. За 7 лет мы прошли путь от первоначального масштаба кластера в несколько сотен единиц, поддерживающих объем данных уровня PB, до десятков тысяч многокластерных платформ, поддерживающих объем данных уровня EB. С быстрым увеличением объема бизнеса наша команда также пережила стадию жестокого взрыва, крупномасштабного развития и работы на платформе. В этом процессе мы наступили на множество ям и накопили достаточно богатый опыт. Конечно, самое главное, что компания по-прежнему развивается с высокой скоростью, и мы по-прежнему сохраняем свое первоначальное намерение, придерживаемся «ДНЯ ПЕРВОГО» и продолжаем путь.

Команда инфраструктуры ByteDance

Команда инфраструктуры ByteDance — важная команда, которая поддерживает бесперебойную работу множества пользовательских продуктов ByteDance, включая Douyin, Today's Toutiao, Xigua Video и Volcano Small Video, Стабильная разработка обеспечивает гарантии и импульс.

В компании команда инфраструктуры в основном отвечает за создание частного облака ByteDance, управление десятками тысяч кластеров серверного масштаба, отвечает за десятки тысяч гибридных развертываний вычислений/хранилищ и гибридных развертываний онлайн/офлайн, а также за поддержку стабильного хранилища. нескольких массивных данных ЭП.

В культурном плане команда активно использует открытый исходный код и инновационные аппаратные и программные архитектуры. Мы давно набираем студентов по направлению инфраструктура, подробнее см.job.bytedance.com, заинтересованные могут обращаться по электронной почте guoxinyu.0372@bytedance.com .

Добро пожаловать в "Техническую команду ByteDance"