задний план
статус кво
Полное название HDFS — распределенная файловая система Hadoop, которая сама по себе является модулем проекта Apache Hadoop.Являясь краеугольным камнем хранения больших данных, она обеспечивает возможности хранения больших объемов данных с высокой пропускной способностью. С момента своего выпуска в апреле 2006 года HDFS по-прежнему имеет очень широкий спектр приложений.Взяв в качестве примера ByteDance, с быстрым развитием бизнеса компании текущий масштаб услуг HDFS достиг уровня «Double 10»:
- Один узел кластера уровня 100 000
- Объем данных одного кластера достигает уровня 10EB
К основным сценариям использования относятся
- не в сети
- База хранилища механизма запросов OLAP, включая такие сценарии, как Hive/ClickHouse/Presto
- Данные автономного обучения машинного обучения
- ближняя линия
- ByteMQ
- Контрольная точка потоковой передачи
При обслуживании сервисов HDFS многие компании в отрасли используют режим малого кластера, то есть развертывание нескольких изолированных и независимых кластеров HDFS в производстве для удовлетворения различных потребностей бизнеса. ByteDance использует федеральную модель развертывания с большим кластером, которая охватывает несколько компьютерных залов, то есть HDFS имеет только один кластер, и этот кластер имеет несколько служб имен, но базовое DN охватывает 3 компьютерных зала A/B/C, потому что сообщество HDFS не имеет поддержки, связанной с восприятием компьютерного зала, поэтому команда ByteDance HDFS специально разработала и реализовала эту функцию.Эта статья познакомит с работой этой части.
мотивация
Быстрое развитие бизнеса и разнообразие бизнес-сценариев поставили перед HDFS большие проблемы. Вот несколько типичных проблем:
- Как удовлетворить потребности развития бизнеса с точки зрения мощностей
- Как удовлетворить спрос на низкую задержку в сценариях ближней линии
- Как выполнить требования аварийного восстановления на уровне компьютерного зала для критически важных предприятий
- Как эффективно управлять и поддерживать такой масштабный кластер
Чтобы ответить на эти вопросы, HDFS необходимо итеративно оптимизировать по нескольким направлениям, таким как запуск DanceNN, создание платформы для эксплуатации и обслуживания и т. д. В этой статье не будут представлены все схемы эволюции ByteDance HDFS, но основное внимание будет уделено стратегия развития многокомнатной архитектуры HDFS, которая напрямую отвечает на два упомянутых выше вопроса, а именно:
- Как удовлетворить потребности бизнеса в развитии с точки зрения емкости: как разумно хранить данные в нескольких компьютерных залах, чтобы емкость можно было быстро увеличить за счет ресурсов других компьютерных залов?
- Как выполнить требования аварийного восстановления для ключевого бизнеса: Как система соответствует требованиям аварийного восстановления на уровне компьютерного зала основного бизнеса?
Архитектура версии сообщества
Технология ByteDance HDFS родилась из HDFS сообщества Apache.Чтобы облегчить вам понимание процесса технической разработки внутренней версии, в этом разделе мы сначала разберемся с архитектурой сообщества HDFS.
Рисунок (1) Архитектура HDFS сообщества Apache
Как видно из рисунка (1), сообщество HDFS можно разделить на три части с точки зрения архитектуры:
- Клиент: клиент, который обращается к HDFS, в основном взаимодействует с HDFS через SDK HDFS.Реализация SDK HDFS относительно сложна, и многие логические схемы обработки ввода-вывода реализованы в SDK, поэтому он указан как часть архитектуры отдельно.
- Управление метаданными: NameNode, отвечающий за управление метаданными кластера, включая информацию о расположении дерева каталогов и блоков данных. Чтобы решить проблему расширения метаданных, сообщество предоставляет функцию федерации и вводит концепцию NameService. Проще говоря, каждый NameService предоставляет пространство имен. Чтобы обеспечить высокую доступность NameNode, NameService содержит несколько узлов NameNode ( обычно 2), эти узлы NameNode работают в режиме одного мастера и нескольких резервных копий. Функция федерации не обязательно связана с архитектурой многокомпьютерного зала, поэтому в следующем обсуждении мы не будем обсуждать такие понятия, как федерация/служба имен.
- Управление данными: DataNode, который отвечает за хранение фактических данных пользователей. Как упоминалось ранее, одной из функций NameNode является управление информацией о местоположении блоков данных. С точки зрения конкретной реализации, NameNode не будет сохранять информацию об этих блоки, но полагайтесь на DataNode, чтобы активно отчитываться, чтобы поддерживать его.
На данный момент решения, связанные с архитектурой кластеров HDFS с несколькими компьютерами, в основном дополняются уровнем метаданных, поэтому следующее обсуждение будет сосредоточено на части метаданных. В остальной части этой статьи, если не указано иное, соответствующие термины относятся к версии HDFS ByteDance.
Архитектура байтовой версии
Рисунок (2) Архитектура Byte Beat HDFS
Примечание: Из-за собственной архитектуры BookKeeper NameNode (DanceNN) фактически должен найти информацию о конечной точке BookKeeper через ZooKeeper.Для удобства понимания эта часть коммуникационных отношений не показана.
Сравнивая рисунок (1) и рисунок (2), мы можем обнаружить, что HDFS ByteDance по-прежнему сохраняет базовую архитектуру HDFS сообщества, а также добавляет некоторые уникальные функции, в том числе:
- DanceNN, NameNode, повторно реализованный ByteDance на C++, в основном совместим с версией NameNode сообщества в протоколе. Если не указано иное, DanceNN и NameNode, появляющиеся позже, относятся к DanceNN.
- NNProxy, NameNode Proxy, обеспечивает единое пространство имен для функции федерации.Поскольку он не имеет прямого отношения к архитектуре многокомпьютерного зала, он не будет здесь подробно описываться.
- BookKeeper, Apache BookKeeper, такой же, как JournaNode в сообществе, предоставляя совместное решение для хранения журнала редактирования для Active и Standby NameNode, которое является основой для реализации метода HA NameNode.
Стоит отметить, что сам BookKeeper предоставляет стратегию конфигурации хранилища на уровне комнаты, которая является основой решения аварийного восстановления нескольких комнат HDFS.Эта функция гарантирует, что HDFS NameNode обеспечивает возможности аварийного восстановления нескольких машинных комнат.Мы продолжим подробно обсудим позже.
эволюция
Двойная комната
Как упоминалось ранее, текущий большой кластер HDFS представляет собой модель с несколькими машинными залами, охватывающую A / B / C. Конкретная последовательность эволюции: A -> A, B -> A, B, C. Теперь он также поддерживает прямое расширение к большему количеству компьютерных залов Способность. В этом разделе основное внимание будет уделено процессу эволюции двухкомпьютерной комнаты от A -> A, B. Идея дизайна архитектуры многокомпьютерной комнаты в следующем в основном является расширением архитектуры двухкомпьютерной комнаты. .
размещение данных
Рисунок (3) Структура двухкомнатного DataNode Byte Beat HDFS
Схему двухконвертного размещения данных HDFS можно описать следующим образом:
- DN компьютерных залов A/B напрямую образуют кластер из двух компьютерных залов, расположенных в компьютерных залах, и подчиняются одному и тому же NameNode.
- Когда каждый файл записывается, гарантируется, что по крайней мере одна копия существует в каждой компьютерной комнате, и данные записываются в две компьютерные комнаты в режиме реального времени.
- Когда каждый клиент читает файл, он предпочтительно читает копию в машинном зале, чтобы избежать создания большого объема пропускной способности для чтения в компьютерном зале.
Преимущество такой схемы в том, что уровень хранения скрывает детали кластера от приложений верхнего уровня, а вычислительные ресурсы можно распределять напрямую и без смысла. Дизайн сочетает в себе характеристики автономных данных с однократной записью и многократным чтением и полностью учитывает рациональное использование полосы пропускания в компьютерных залах.
- Поскольку полоса пропускания для записи, как правило, не является скачкообразной, автономная полоса пропускания компьютерного зала может поддерживать требование синхронной записи, поэтому данные могут быть синхронно размещены по крайней мере в одной копии в двух компьютерных залах.
- Автономные запросы склонны к большим пакетным запросам, поэтому необходимо убедиться, что в компьютерном зале нет пропускной способности для пакетного чтения в нормальных условиях.
Ключом к реализации является то, что DanceNN добавил способность восприятия компьютерного зала.DanceNN добавляет распознавание топологии компьютерного зала, когда клиент выполняет операции с данными.Поскольку внешний протокол DanceNN не изменился, верхний уровень приложению не нужно вносить изменения в восприятие.
Дизайн аварийного восстановления
Дизайн размещения данных в архитектуре двухкомпьютерного зала был представлен ранее.Он решил проблему расширения мощностей, но не решил проблему аварийного восстановления на уровне машинного зала.Хотя NameNode добивается высокой доступности в виде одного мастера и несколько резервных копий, все NameNodes по-прежнему хранятся.В машинном зале, в системе аварийного восстановления инфраструктуры ByteDance, необходимо добиться аварийного восстановления на уровне компьютерного зала. Поскольку данные HDFS реализуют синхронную запись копий данных в нескольких компьютерных залах, для достижения цели аварийного восстановления необходимо только преобразовать метаданные в архитектуру с двумя компьютерами для обеспечения аварийного восстановления на компьютере. уровень комнаты. Компонент метаданных HDFS, о котором мы упоминали ранее, на самом деле состоит из двух частей, а именно NameNode и NameNode Proxy (NNProxy).Поскольку NNProxy является службой пересылки без сохранения состояния, нам нужно сосредоточиться только на дизайне NameNode для многокомнатной архитектуры метаданных.
Рисунок (4) Система ByteDance HDFS NameNode
Из рисунка (4) видно, что NameNode содержит 3 ключевых модуля:
- Apache ZooKeeper, предоставляющий службы метаданных для Apache BookKeeper.
- Apache BookKeeper, который предоставляет решение общего хранилища EditLog для решения высокой доступности NameNode.
- DanceNN — высокопроизводительная реализация NameNode, разработанная ByteDance.
Эти три элемента составляют иерархическую одностороннюю цепочку зависимостей, DanceNN -> BookKeeper -> ZooKeeper, так что эти три могут независимо завершить план аварийного восстановления двухкомпьютерной комнаты и, наконец, представить метаданные аварийного восстановления NameNode двухкомпьютерной комнаты в виде целом в целом служить.
| компоненты | Многокомнатное решение |
|---|---|
| ZooKeeper | Ансамбль ZK состоит из 5 серверов, эти 5 серверов распределены по 3 машинным залам, а коэффициент распределения A:B:C = 2:2:1. |
| BookKeeper | Кластер BK обычно состоит из 14 серверов, распределенных по 2 машинным залам, с коэффициентом распределения 1:1. |
| DanceNN | Служба имен содержит 5 DanceNN, эти 5 DanceNN распределены по 2 компьютерным залам, коэффициент распределения 3:2, рабочий режим 1 активный + 4 резервных. |
С точки зрения реализации, ключом здесь является стратегия записи журнала редактирования в компьютерной комнате DanceNN, потому что, когда DanceNN переключается между ведущим и резервным, если журнал редактирования не может быть синхронизирован, тогда услуга недоступна благодаря размещению данных в компьютерной комнате BookKeeper. function , DanceNN может использовать эти стратегии для выполнения плана аварийного восстановления двух компьютерных залов.
- Обычно журнал редактирования будет храниться в BookKeeper с 4 копиями, и соотношение распределения этих 4 копий составляет 1:1.
- В сценариях аварийного восстановления DanceNN может быстро переключиться в однокомнатный режим, журналы редактирования по-прежнему хранятся в 4 копиях, но стратегия хранения изменена на хранение в одной комнате, и исторические журналы редактирования также могут использоваться в обычном режиме.
Байпасная система
Основной дизайн решения двухкомпьютерного зала HDFS был представлен ранее, но на самом деле, в дополнение к итеративной эволюции архитектуры, реализация решения требует наличия ряда обходных систем для его поддержки, в том числе:
- Балансировщик: нужно определить расположение компьютерного зала.
- Mover: Необходимо убедиться, что фактическое размещение данных соответствует мультирумной стратегии.
- Система эксплуатации и обслуживания
- В архитектуре федерации несколько служб имен должны обеспечивать эффективность главного переключения.
- План операций по эксплуатации и техническому обслуживанию: заранее прогнозируйте связанные с этим возможные сбои и выполняйте их в системе эксплуатации и технического обслуживания.
- План плавного перехода для бизнеса с минимальным нарушением работы бизнеса
Из-за ограничений по объему в данной статье не будут подробно описываться эти разработки, а желающие студенты могут пообщаться друг с другом.
Мультирум
Архитектура многокомпьютерного зала HDFS является расширением архитектуры двухкомпьютерного зала.Прямым мотивом для ее исследований и разработок является нехватка ресурсов в машинном зале.Например, в 2020 году в Компьютерный зал B, но новый главный машинный зал компании C имеет больше ресурсов. Вначале мы пытались использовать компьютерный зал C в качестве независимого кластера для предоставления услуг, но обнаружили, что кровные связи бизнеса слишком сложны, а стоимость миграции слишком высока, поэтому мы выбрали метод расширения компьютерного зала. на основе двух компьютерных залов на несколько компьютерных залов.Решение должно соответствовать этим требованиям.
- Разумное использование полосы пропускания в компьютерных залах
- Совместимость с существующими двухкомнатными решениями
- Минимальные затраты на миграцию
- Соответствует стандартам аварийного восстановления компьютерного зала ByteDance.
Окончательная схема конструкции такая:
- Стратегия размещения данных поддерживает несколько компьютерных залов и совместима с существующей стратегией размещения двухкомпьютерных залов.
- Стратегия аварийного восстановления NameNode остается неизменной, поскольку в многокомпьютерной архитектуре HDFS по-прежнему гарантирует восстановление после сбоя только в одном компьютерном зале.
Соответствующая система обхода также корректируется соответствующим образом.Хотя нижний уровень HDFS обеспечивает стратегию размещения данных в нескольких компьютерных залах, в автономных сценариях пользователи могут выбрать для хранения только два компьютерных зала, например A/B, B/C, A / B, эта операционная стратегия определяется после всестороннего рассмотрения стабильности, рациональности использования полосы пропускания и рационального использования ресурсов.Основная цель - обеспечить стабильное развитие бизнеса.С точки зрения последующей практики эта стратегия является очень правильный выбор.
Эпилог
Согласно нашим неполным исследованиям, архитектура многокомпьютерного зала ByteDance HDFS имеет свой уникальный путь в отрасли.Главной причиной этого является быстрое развитие бизнеса компании, а направление строительства компьютерного зала также является уникальным в отрасли. .Эти факторы побуждают HDFS к развитиюУ него есть своя уникальная итеративная эволюция, и ожидается, что результаты оправдают ожидания.Например, в 2020 году полное использование компьютерного зала C обеспечит стабильность бизнеса даже при отсутствии поставка ресурсов в компьютерный зал B; Гала-мероприятие Весеннего фестиваля 2021 года предназначено для ближних сервисов, таких как ByteMQ, потоковая передача CheckPoint и т. д., и обеспечивает стратегию аварийного восстановления в нескольких комнатах.
Наконец, архитектура многокомпьютерного зала HDFS все еще постоянно итерируется.В среднесрочной и долгосрочной перспективе не исключено, что будет больше новых компьютерных залов, что создаст больше проблем для архитектуры многокомпьютерного зала HDFS. Базовые условия оригинального решения для многокомпьютерного зала больше недоступны, поэтому команда HDFS начала итерацию сопутствующих функций, так что следите за обновлениями!
Присоединяйтесь к нам
Команда по хранению больших данных ByteDance является лидером отрасли в области хранения больших данных, ответственным за построение всей глобальной инфраструктуры хранения больших данных ByteDance, поддерживающей Toutiao, Douyin, Xigua Video, Tomato Novels, электронную коммерцию, игры, образование. и т. д. Многочисленные линейки продуктов, управляющие десятками эксабайт данных. Мы давно стремимся к технологической эволюции сверхкрупномасштабных систем хранения, включая ускорение доступа, поток данных, оптимизацию затрат, эффективную эксплуатацию и обслуживание, а также доступность услуг.Мы приглашаем новых студентов присоединиться к нам и построить систему следующего поколения Система хранения уровня 10EB вместе.Это Шанхай, если вы заинтересованы, вы можете связатьсяfandi.3@bytedance.comИ указать направление хранения больших данных.