Архитектура метаданных

В этом документе описаны общая архитектура, структура хранения и поток данных метаданных FE в Apache Doris, а также подробности реализации, порядок запуска и механизм восстановления после сбоев.

Терминология

Термин	Описание
FE	Frontend, узел фронтенда Doris. Принимает запросы клиентов и возвращает ответы, управляет метаданными и кластером, а также формирует планы выполнения запросов.
BE	Backend, узел бэкенда Doris. Хранит данные, управляет ими и выполняет планы запросов.
bdbje	Oracle Berkeley DB Java Edition. В Doris bdbje обеспечивает постоянное хранение журналов операций с метаданными и высокую доступность FE.

Общая архитектура

Как показано выше, Doris имеет двухуровневую архитектуру. Первый уровень состоит из нескольких узлов FE и обеспечивает горизонтальное масштабирование и высокую доступность FE. Второй уровень состоит из нескольких узлов BE, отвечающих за хранение данных и управление ими. Этот документ посвящён архитектуре и реализации метаданных на уровне FE.

1. Узлы FE делятся на два типа: follower и observer. Для выборов leader, синхронизации данных и связанных с этим задач узлы FE используют bdbje (BerkeleyDB Java Edition).

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

3. Узлы observer только синхронизируют метаданные с leader и не участвуют в выборах. Их можно масштабировать горизонтально, чтобы расширить возможности сервиса чтения метаданных.

Примечание: понятия follower и observer в Doris соответствуют понятиям replica и observer в bdbje. Далее в тексте могут встречаться оба варианта названий.

Структура метаданных

Метаданные Doris полностью хранятся в памяти. Каждый узел FE поддерживает в памяти полный образ метаданных. Во внутреннем развёртывании Baidu кластер с 2,500 таблицами и 1 миллионом tablets (3 миллионами реплик) использует для метаданных всего около 2 GB памяти. (Расход памяти на промежуточные объекты запросов, сведения о различных заданиях и прочее необходимо оценивать отдельно, но общий объём потребляемой памяти остаётся небольшим.)

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

На рисунке ниже показано содержимое метаданных Doris.

Как показано выше, метаданные Doris содержат четыре категории данных:

1. Сведения о пользовательских данных, включая базы данных, схемы таблиц и сведения о tablets.
2. Сведения о различных заданиях, например заданиях загрузки, клонирования и изменения схемы.
3. Сведения о пользователях и правах доступа.
4. Сведения о кластере и узлах.

Поток данных

Поток данных метаданных устроен следующим образом:

1. Записывать метаданные может только узел FE с ролью leader. После того как операция записи изменяет данные в памяти leader, она сериализуется в запись журнала и записывается в bdbje в виде пары ключ-значение. Ключ представляет собой целое число из непрерывной последовательности и служит идентификатором записи журнала, а значение содержит сериализованный журнал операции.

2. После записи журнала в bdbje он реплицируется на остальные узлы FE, не являющиеся leader, согласно политике bdbje (write-majority или write-all). Эти узлы FE воспроизводят журнал, обновляя собственный образ метаданных в памяти и тем самым завершая синхронизацию метаданных с leader.

3. Когда количество записей журнала на leader достигает порогового значения (по умолчанию 10w записей) и наступает время очередного запуска потока создания контрольных точек (по умолчанию каждые 60 секунд), этот поток считывает существующий файл образа и последующие записи журнала, воспроизводит их для создания новой копии образа метаданных в памяти и записывает эту копию на диск, формируя новый образ. Новая копия образа создаётся путём воспроизведения журнала, поскольку запись существующего образа напрямую требует блокировки чтения, которая препятствовала бы операциям записи. В результате при каждом создании контрольной точки используется вдвое больше памяти.

4. После создания файла образа leader уведомляет остальные узлы, не являющиеся leader, о доступности нового образа. Эти узлы сами загружают последний файл образа по HTTP и заменяют старый локальный файл.

5. После создания образа старые записи журнала в bdbje периодически удаляются.

Подробности реализации

Каталог метаданных

1. Каталог метаданных задаётся параметром конфигурации FE meta_dir.
2. Каталог bdb/ содержит данные bdbje.
3. Каталог image/ содержит файлы образов.

Основные файлы в каталоге image/:

Файл	Описание
image.[logid]	Последний файл образа. Суффикс logid указывает идентификатор последней записи журнала, включённой в образ.
image.ckpt	Файл образа, запись которого выполняется в данный момент. После успешного завершения записи он переименовывается в image.[logid] и заменяет старый файл образа.
VERSION	Содержит cluster_id, который однозначно идентифицирует кластер Doris. cluster_id представляет собой случайное 32-битное целое число, создаваемое при первом запуске leader; его также можно задать параметром конфигурации FE cluster_id.
ROLE	Содержит собственную роль узла FE, которая может быть только FOLLOWER или OBSERVER. Значение FOLLOWER означает, что узел FE может участвовать в выборах. (Примечание: даже узел leader имеет роль FOLLOWER.)

Порядок запуска

1. При первом запуске FE, если скрипт запуска выполняется без параметров, узел FE пытается запуститься в роли leader. В итоге в журнале запуска FE появляется сообщение transfer from UNKNOWN to MASTER.

2. При первом запуске FE, если в скрипте запуска указан параметр --helper, указывающий на корректный узел FE с ролью leader, узел FE сначала запрашивает у leader по HTTP свою роль (ROLE) и cluster_id, а затем загружает последний файл образа. Прочитав файл образа и сформировав образ метаданных, узел FE запускает bdbje для синхронизации журналов. После завершения синхронизации он воспроизводит из bdbje записи журнала, следующие за файлом образа, чтобы получить окончательный образ метаданных.

   Примечание 1: при запуске с параметром --helper необходимо сначала добавить узел FE на leader с помощью команды mysql, иначе запуск завершится с ошибкой.

   Примечание 2: --helper может указывать на любой узел follower, не обязательно на leader.

   Примечание 3: во время синхронизации журналов bdbje в журнале FE отображается сообщение xxx detached. Это ожидаемое поведение, указывающее на то, что выполняется загрузка журналов.

3. При повторном запуске FE, если скрипт запуска выполняется без параметров, узел FE определяет свою роль по локально сохранённым данным ROLE. Он также считывает сведения о leader из информации о кластере, хранящейся в локальной bdbje, а затем читает локальный файл образа и журналы в bdbje для формирования образа метаданных. (Если роль, записанная в локальном ROLE, не совпадает с ролью, записанной в bdbje, выдаётся ошибка.)

4. При повторном запуске FE, если в скрипте запуска указан параметр --helper, процедура аналогична первому запуску: узел FE сначала запрашивает роль у leader, но затем сравнивает полученный результат с локально сохранённым ROLE и выдаёт ошибку при несовпадении.

Чтение, запись и синхронизация метаданных

1. Для чтения и записи метаданных можно подключиться с помощью mysql к любому узлу FE. Если подключённый узел не является leader, он перенаправляет операцию записи на leader. После успешной записи leader возвращает идентификатор последней записи журнала. Затем узел, не являющийся leader, ждёт, пока идентификатор воспроизведённой им записи журнала не станет больше возвращённого идентификатора, и только после этого возвращает клиенту сообщение об успешном выполнении. Этот механизм обеспечивает семантику Read-Your-Write на любом узле FE.

   Примечание: некоторые операции, не связанные с записью, также перенаправляются на leader, например SHOW LOAD. Обычно этим командам требуется прочитать промежуточное состояние некоторых заданий, которое не записывается в bdbje и потому отсутствует в памяти узлов, не являющихся leader. (Синхронизация метаданных между узлами FE полностью основана на воспроизведении журнала bdbje. Если операция изменения метаданных не записана в журнал bdbje, её результат не будет виден на других узлах, не являющихся leader.)

2. Узел leader запускает поток TimePrinter, который периодически записывает в bdbje пару ключ-значение с текущим временем. Остальные узлы, не являющиеся leader, воспроизводят эту запись журнала, считывают указанное в ней время и сравнивают его со своим локальным временем. Если отставание по времени превышает заданный порог (параметр конфигурации meta_delay_toleration_second, интервал записи равен половине этого значения), узел переходит в состояние недоступности для чтения. Этот механизм не позволяет узлу, не являющемуся leader, продолжать выдавать устаревшие метаданные после длительной потери связи с leader.

3. Метаданные разных узлов FE обладают лишь согласованностью в конечном счёте. В нормальных условиях период рассогласования составляет порядка миллисекунд. В рамках одного сеанса гарантируется монотонная согласованность доступа к метаданным, однако при подключении одного и того же клиента к разным узлам FE может наблюдаться откат метаданных. (Для систем с пакетным обновлением влияние этой проблемы невелико.)

Восстановление после сбоя

Сценарий	Поведение
Сбой узла leader	Оставшиеся узлы follower немедленно выбирают нового leader для обслуживания запросов.
Сбой большинства узлов follower	Запись метаданных становится невозможной. Если в этот момент поступает запрос на запись, текущее поведение таково: процесс FE немедленно завершается. В дальнейшем планируется оптимизация, которая позволит продолжать обслуживание операций чтения при недоступности записи.
Сбой узла observer	Не влияет на состояние других узлов, а также на чтение и запись метаданных на них.