Выделим пять важнейших аспектов работы администратора Селены: развертывание, моделирование данных, прием данных, выполнение запросов и мониторинг.
В серии статей подробно рассмотрим каждый из аспектов, и расскажем о том, как вы сможете полноценно использовать все возможности Селены.
Развертывание
Начнем с развертывания. Разделим этот процесс на два этапа: планирование и конфигурирование:
Планирование ресурсов ЦП
Если у вас достаточно оперативной памяти и места на диске, главным узким местом для аналитических запросов будут ресурсы ЦП. Поэтому сначала следует рассчитать количество кластеров в зависимости от требований к вычислительным ресурсам.
Общий объем ресурсов ЦП на кластер:
e_core = (scan_rows / cal_rows) / e_rt * e_qps
Имя переменной
Описание
Пример
e_core
Примерное количество ядер ЦП (vCPU)
540 ядер
scan_rows
Объем сканируемых данных в типичном сценарии
30 млн строк
e_qps
Ожидаемое число запросов в секунду
180 запросов в секунду
e_rt
Ожидаемое время ответа
300 мс
cal_rows
Вычислительная способность Селены: строк в секунду на ядро
30 млн строк в секунду
Рассмотрим пример.
Объем данных: таблица фактов — 360 млн строк в год, 1 млн строк в день.
Типичный запрос: соединение данных из таблицы фактов за месяц (30 млн строк) с небольшой таблицей измерений (десятки тысяч строк) и последующее агрегирование данных (например, GROUP BY и SUM).
Ожидания: время отклика до 300 мс, пиковая нагрузка — около 180 аналитических запросов в секунду.
Реализация примера в Селене
Согласно документации, Селена обрабатывает от 10 до 100 млн строк в секунду на ядро. Учитывая операции соединения таблиц и группировки данных, а также применения в выражениях относительно сложных функций, чтобы обрабатывать 30 млн строк в секунду, для этих задач может потребоваться 3 виртуальных ЦП (vCPU):
30 млн строк / (30 млн строк/с) / 300 мс = 3 ядра
При пиковой нагрузке в 180 запросов в секунду потребуется:
3 ядра * 180 = 540 ядер
Итак, получилось 540 vCPU. Если предположить, что у каждого физического сервера 48 vCPU, потребуется примерно 12 физических серверов.
При проверке концепции использовались 3 физических сервера по 16 виртуальных ядер каждый. Результаты нагрузочного тестирования показали время отклика 300–500 мс при 40 запросах в секунду. Кроме того, для рабочей среды было выбрано 7 физических серверов по 48 виртуальных ядер. Настоятельная рекомендация – сначала проводить подобные проверки концепции под конкретный сценарий.
Что показала проверка концепции? На основе результатов теста мы подготовили 3 фронтенд-узла по 16 ядер и 64 ГБ ОЗУ и 7 бэкенд-узлов по 48 ядер и 152 ГБ ОЗУ.
Дополнительные рекомендации:
Чем сложнее запрос и чем больше столбцов обрабатывается для каждой строки, тем меньше строк можно обработать в секунду при тех же аппаратных ресурсах.
С помощью эффективной фильтрации по условиям для отсеивания данных можно обрабатывать больше строк благодаря внутренним индексным структурам, которые ускоряют обработку.
Производительность во многом зависит от типа таблицы. Расчеты выше приведены для таблиц с дублирующимися ключами. Другие модели данных имеют свою специфику, что приводит к расхождениям между фактическим и расчетным количеством строк. Кроме того, на скорость выполнения запросов влияют партиционирование и бакетирование.
При сканировании больших объемов данных производительность диска также влияет на скорость обработки. В таких случаях рекомендуется использовать SSD.
Базовая конфигурация окружения
Обязательно: настройте окружение в соответствии с требованиями документации Селены по развертыванию системы. Отключите файл подкачки, укажите для избыточного выделения памяти (overcommit) значение 1 и настройте соответствующие лимиты ulimit.
Конфигурация оборудования
Фронтенд-узлы
o Рекомендуется: 8 vCPU, 32 ГБ ОЗУ
o Обязательно: не менее 200 ГБ на диске, рекомендуется SSD.
Бэкенд-узлы (без общих ресурсов)
Конфигурация бэкенд-узлов зависит от объема данных и типа рабочих нагрузок. Основные рекомендации:
o Рекомендуется: соотношение ЦП к ОЗУ: 1 vCPU на 4 ГБ. Минимальная конфигурация для рабочих сред — 8 ядер и 32 ГБ.
o Рекомендуется: дисковое пространство на одном узле — не менее 10 ТБ; емкость одного диска — не более 2 ТБ (предпочтительно SSD или NVMe). Для HDD требуется пропускная способность >150 МБ/с и IOPS >500.
o Рекомендуется: соотношение ЦП к томам не должно превышать 4:1. Например, для 16 vCPU — не более четырех томов.
o Рекомендуется: однородный кластер, то есть одинаковые аппаратные спецификации для всех узлов во избежание узких мест.
Вычислительные узлы (общий доступ к данным)
Конфигурация такая же, как у бэкенд-узлов, за исключением дисков: в архитектуре с общим доступом к данным данные хранятся в удаленном хранилище, а локальные диски вычислительных узлов используются как кэш для ускорения запросов. Объем локального кэша зависит от требований к производительности запросов.
Дополнительные требования к планированию развертывания
Обязательно: минимальный размер кластера в рабочем окружении — 3 фронтенд-узла + 3 бэкенд-узла. Рекомендуется разворачивать фронтенд и бэкенд отдельно. Если они разворачиваются на одних и тех же инстансах, настройте mem_limit в be.conf, чтобы оставить память для других сервисов. Например, если всего у вас 40 ГБ, а развернутый фронтенд занимает 8 ГБ, задайте mem_limit=30G (40-8-2), оставив 2 ГБ системе.
Обязательно: обеспечьте высокую доступность для фронтенда в рабочем окружении, 1 ведущий узел + 2 ведомых. Для увеличения числа параллельных потоков чтения добавьте узлы-наблюдатели.
Обязательно: используйте балансировщик нагрузки для чтения и записи в кластер. Например, Nginx, HAProxy или F5.