Архитектура

Selena имеет простую архитектуру. Вся система состоит только из двух типов компонентов: frontend и backend. Узлы frontend называются FE. Существует два типа backend узлов: BE и CN (Compute Nodes). BE развертываются при использовании локального хранилища данных, а CN развертываются при хранении данных в объектном хранилище или HDFS. Selena не зависит от внешних компонентов, что упрощает развертывание и обслуживание. Узлы могут масштабироваться горизонтально без простоя сервиса. Кроме того, Selena имеет механизм репликации для метаданных и служебных данных, что повышает надежность данных и эффективно предотвращает единые точки отказа (SPOF).

Selena совместима с протоколами MySQL и поддерживает стандартный SQL. Пользователи могут легко подключаться к Selena из клиентов MySQL для получения мгновенных и ценных аналитических данных.

Варианты архитектуры

Selena поддерживает shared-nothing (каждый BE имеет часть данных в своем локальном хранилище) и shared-data (все данные в объектном хранилище или HDFS, а каждый CN имеет только кэш в локальном хранилище). Вы можете решить, где хранить данные, исходя из ваших потребностей.

Shared-nothing

Локальное хранилище обеспечивает улучшенную задержку запросов для запросов в реальном времени.

Как типичная база данных с массивно-параллельной обработкой (MPP), Selena поддерживает архитектуру shared-nothing. В этой архитектуре BE отвечают как за хранение данных, так и за вычисления. Прямой доступ к локальным данным в режиме BE позволяет выполнять локальные вычисления, избегая передачи и копирования данных, и обеспечивает сверхбыструю производительность запросов и аналитики. Эта архитектура поддерживает многореплицированное хранение данных, повышая способность кластера обрабатывать высококонкурентные запросы и обеспечивая надежность данных. Она хорошо подходит для сценариев, требующих оптимальной производительности запросов.

Узлы

В архитектуре storage-nothing Selena состоит из двух типов узлов: FE и BE.

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

FE

FE отвечают за управление метаданными, управление клиентскими соединениями, планирование запросов и диспетчеризацию запросов. Каждый FE использует BDB JE (Berkeley DB Java Edition) для хранения и поддержания полной копии метаданных в своей памяти, обеспечивая согласованные сервисы во всех FE. FE могут работать как лидер, последователи и наблюдатели. Если лидер-узел выходит из строя, последователи выбирают лидера на основе протокола Raft.

Роль FE	Управление метаданными	Выборы лидера
Leader	Leader FE читает и записывает метаданные. Follower FE и Observer FE могут только читать метаданные. Они направляют запросы на запись метаданных к Leader FE. Leader FE обновляет метаданные, а затем использует протокол Raft для синхронизации изменений метаданных с Follower FE и Observer FE. Записи данных считаются успешными только после синхронизации изменений метаданных с более чем половиной Follower FE.	Leader FE, технически говоря, также является follower узлом и избирается из Follower FE. Для проведения выборов лидера более половины Follower FE в кластере должны быть активными. Когда Leader FE выходит из строя, Follower FE начинают новый раунд выборов лидера.
Follower	Followers могут только читать метаданные. Они синхронизируют и воспроизводят логи от Leader FE для обновления метаданных.	Followers участвуют в выборах лидера, что требует активности более половины followers в кластере.
Observer	Observers синхронизируют и воспроизводят логи от Leader FE для обновления метаданных.	Observers в основном используются для увеличения конкурентности запросов кластера. Observers не участвуют в выборах лидера и поэтому не добавляют давления на выбор лидера в кластере.

BE

BE отвечают за хранение данных и выполнение SQL.

• Хранение данных: BE имеют эквивалентные возможности хранения данных. FE распределяют данные по BE на основе предопределенных правил. BE преобразуют поступающие данные, записывают данные в требуемом формате и генерируют индексы для данных.

• Выполнение SQL: FE разбирают каждый SQL-запрос в логический план выполнения в соответствии с семантикой запроса, а затем преобразуют логический план в физические планы выполнения, которые могут быть выполнены на BE. BE, которые хранят целевые данные, выполняют запрос. Это исключает необходимость в передаче и копировании данных, достигая высокой производительности запросов.

Shared-data

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

В архитектуре shared-data BE заменяются "вычислительными узлами (CN)", которые отвечают только за задачи вычисления данных и кэширование горячих данных. Данные хранятся в недорогих и надежных удаленных системах хранения, таких как Amazon S3, GCP, Azure Blob Storage, MinIO и т.д. При попадании в кэш производительность запросов сопоставима с архитектурой shared-nothing. CN узлы могут добавляться или удаляться по требованию в течение секунд. Эта архитектура снижает стоимость хранения, обеспечивает лучшую изоляцию ресурсов, высокую эластичность и масштабируемость.

Архитектура shared-data поддерживает такую же простую архитектуру, как и ее аналог shared-nothing. Она состоит только из двух типов узлов: FE и CN. Единственное отличие заключается в том, что пользователи должны предоставить backend объектное хранилище.

Узлы

FE в архитектуре shared-data предоставляют те же функции, что и в архитектуре shared-nothing.

BE заменяются CN (Compute Nodes), а функция хранения передается объектному хранилищу или HDFS. CN являются stateless вычислительными узлами, которые выполняют все функции BE, за исключением хранения данных.

Хранилище

Кластеры Selena shared-data поддерживают два решения хранения: объектное хранилище (например, AWS S3, Google GCS, Azure Blob Storage или MinIO) и HDFS.

В кластере shared-data формат файлов данных остается согласованным с кластером shared-nothing (с связанным хранилищем и вычислениями). Данные организованы в файлы сегментов, и различные технологии индексирования повторно используются в cloud-native таблицах, которые являются таблицами, используемыми специально в кластерах shared-data.

Кэш

Кластеры Selena shared-data разделяют хранение данных и вычисления, позволяя каждому масштабироваться независимо, тем самым снижая затраты и повышая эластичность. Однако эта архитектура может влиять на производительность запросов.

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

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

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

Изучение на практике

Попробуйте Быстрые старты, чтобы получить обзор использования Selena в реалистичных сценариях.