Выделим пять важнейших аспектов работы администратора Селены: развертывание, моделирование данных, прием данных, выполнение запросов и мониторинг.
В серии статей подробно рассмотрим каждый из аспектов, и расскажем о том, как вы сможете полноценно использовать все возможности Селены.
Развертывание
Начнем с развертывания. Разделим этот процесс на два этапа: планирование и конфигурирование:
Планирование ресурсов ЦП
Если у вас достаточно оперативной памяти и места на диске, главным узким местом для аналитических запросов будут ресурсы ЦП. Поэтому сначала следует рассчитать количество кластеров в зависимости от требований к вычислительным ресурсам.
Общий объем ресурсов ЦП на кластер:
В серии статей подробно рассмотрим каждый из аспектов, и расскажем о том, как вы сможете полноценно использовать все возможности Селены.
Развертывание
Начнем с развертывания. Разделим этот процесс на два этапа: планирование и конфигурирование:
Планирование ресурсов ЦП
Если у вас достаточно оперативной памяти и места на диске, главным узким местом для аналитических запросов будут ресурсы ЦП. Поэтому сначала следует рассчитать количество кластеров в зависимости от требований к вычислительным ресурсам.
Общий объем ресурсов ЦП на кластер:
e_core = (scan_rows / cal_rows) / e_rt * e_qpsРассмотрим пример.
- Объем данных: таблица фактов — 360 млн строк в год, 1 млн строк в день.
- Типичный запрос: соединение данных из таблицы фактов за месяц (30 млн строк) с небольшой таблицей измерений (десятки тысяч строк) и последующее агрегирование данных (например, GROUP BY и SUM).
- Ожидания: время отклика до 300 мс, пиковая нагрузка — около 180 аналитических запросов в секунду.
Реализация примера в Селене
Согласно документации, Селена обрабатывает от 10 до 100 млн строк в секунду на ядро. Учитывая операции соединения таблиц и группировки данных, а также применения в выражениях относительно сложных функций, чтобы обрабатывать 30 млн строк в секунду, для этих задач может потребоваться 3 виртуальных ЦП (vCPU):
Согласно документации, Селена обрабатывает от 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 виртуальных ядер каждый. Результаты нагрузочного тестирования показали время отклика 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 Рекомендуется: однородный кластер, то есть одинаковые аппаратные спецификации для всех узлов во избежание узких мест.
Конфигурация такая же, как у бэкенд-узлов, за исключением дисков: в архитектуре с общим доступом к данным данные хранятся в удаленном хранилище, а локальные диски вычислительных узлов используются как кэш для ускорения запросов. Объем локального кэша зависит от требований к производительности запросов.
- Фронтенд-узлы
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.
