Повышение эффективности аналитических баз данных: кейс «Комус» и Arenadata17.03.2025 13:16

Хабр, привет! Современные высоконагруженные системы требуют точной настройки и регулярного мониторинга, чтобы обеспечить стабильную производительность в условиях постоянно растущих объёмов данных. Когда речь идёт о крупной аналитической базе данных, развёрнутой в облачной среде, оптимизация её работы становится критически важной задачей. В прошлой статье мы уже рассказывали о типичных ошибках при работе с Arenadata DB (ADB), о том, как их избежать и значительно повысить производительность кластера. Сегодня же поделимся реальным опытом на примере компании «Комус» — лидера в области B2B-ритейла, которая обратилась к Arenadata за проведением комплексного аудита своего кластера ADB.

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

Обзор инфраструктуры

Текущие параметры кластера

Кластер ADB компании «Комус» был развёрнут в облачной инфраструктуре VK Cloud, что предоставило гибкость и масштабируемость системы. Однако, как показал аудит, специфика виртуализированной среды требует особого внимания к настройкам сети, дисков и ресурсного управления. Ниже представлены ключевые параметры инфраструктуры:

• Сегментные хосты: 8 хостов с 192 ГБ оперативной памяти и 32 ядрами Intel Xeon Platinum 3,8 ГГц на каждый.

• Мастер-хосты:

  • Основной: 128 ГБ памяти и 16 ядер.

  • Резервный: аналогичная конфигурация.

• Сетевые интерфейсы: 1×10 Гбит/с, MTU=1500.

• Дисковая подсистема:

  • Каждый хост имеет два раздела размером 1,7 ТБ с файловой системой XFS.

  • Общий объём кластера под данные составляет 13,6 ТБ, из которых 7,2 ТБ уже используются.

Сильные стороны конфигурации

1. Баланс нагрузки между хостами.

   • Следование лучшим практикам: на каждом сегментном хосте размещено по 6 логических сегментов, что позволяет эффективно использовать ресурсы.

   • Равномерное распределение данных между сегментами.

2. Запас по оперативной памяти.

   • Средняя загрузка памяти не превышает 30%, что оставляет возможности для роста нагрузки.

3. Использование SSD/NVMe дисков.

   • Высокая производительность подсистемы ввода-вывода даже при пиковых нагрузках.

Обнаруженные проблемы

Несмотря на сбалансированную архитектуру, мы выявили несколько ключевых проблем.

Сетевые ограничения

В текущей конфигурации используется MTU=1500, так как изначально это был единственный доступный вариант. Однако для эффективной работы распределённых систем, таких как ADB, оптимальный размер MTU составляет 8800–9000 байт (Jumbo Frames). При меньшем значении пакеты, передаваемые по сети, фрагментируются, что увеличивает нагрузку на сетевое оборудование и снижает пропускную способность канала.

Действия «Комуса»: на основе рекомендаций Arenadata компания «Комус» начала работу с облачным провайдером VK Cloud для внесения изменений в сетевые настройки. Был выполнен переход на Jumbo Frames (MTU=9000), который позволил значительно улучшить пропускную способность сети и снизить фрагментацию пакетов.

Потенциальная нехватка места для роста

В данный момент кластер использует около 7,2 ТБ данных из доступных 13,6 ТБ, что оставляет около 30% свободного пространства. Однако для эффективной работы системы и предотвращения переполнения хранилища важно запланировать расширение, особенно с учётом роста объёмов данных и нагрузки. Рекомендуется не допускать использования более 70% доступного пространства для данных, чтобы избежать проблемы с производительностью и обеспечить оперативное масштабирование системы в будущем. При нынешнем темпе роста данных возможные проблемы с нехваткой места могут возникнуть быстрее, чем это предполагалось изначально.

Действия «Комуса»: на основании анализа трендов компания «Комус» приняла решение о плановом расширении объёма хранилища. На данный момент ресурсы для хранения многократно увеличены, чтобы обеспечить устойчивую работу системы даже при значительном преумножении нагрузки.

Рекомендации по инфраструктуре

• Оптимизация сетевых настроек.

  • Если провайдер поддерживает MTU=8800–9000, необходимо внести изменения для использования Jumbo Frames.

  • В противном случае установить параметр gp_max_packet_size=1450, чтобы уменьшить фрагментацию пакетов.

• Планирование расширения хранилища.

  • Оценить прогнозы роста данных и заранее проработать план масштабирования.

Анализ использования ресурсов

Загрузка CPU

• Мастер-хосты:

  • Нагрузка минимальна (в среднем 3–5%).

  • Пики нагрузки не превышают 30%, что говорит о хорошем запасе производительности.

• Сегментные хосты:

  • Утилизация CPU равномерна, пики составляют 80–90% в рабочее время.

  • Ночью и в выходные процессоры загружены менее чем на 10%.

 Использование памяти

На сегментных хостах используется от 40 до 60 ГБ оперативной памяти из доступных 192 ГБ.

• В пиковых случаях загрузка достигает 75 ГБ, что свидетельствует о высоких потребностях отдельных запросов.

Подсистема ввода-вывода

• Средняя нагрузка на запись и чтение остаётся низкой, однако в пиковые моменты фиксировалось до 25 тыс. операций в секунду.

• При чтении и записи на диски наблюдались пики до 2000 МБ/с и 800 МБ/с соответственно, что соответствует возможностям SSD/NVMe.

Сеть

• Утилизация сетевых интерфейсов составляет от 100 до 300 МБ/с в среднем.

• Симметричный сетевой трафик подтверждает равномерное распределение данных между сегментами.

• Ошибок и потерь пакетов не зафиксировано.

Рекомендации:

1. Поддерживать равномерное распределение нагрузки на сегментных хостах.

2. Перенести интенсивные запросы на время с низкой загрузкой (ночь, выходные).

Работа с ресурсными группами

Роль ресурсных групп в управлении нагрузкой

Ресурсные группы в ADB обеспечивают гибкое распределение памяти и вычислительных мощностей между запросами. Это особенно важно для кластеров, работающих с разнообразной нагрузкой, такой как аналитические запросы, ETL-процессы и пользовательские операции. Однако аудит выявил несколько проблем в текущих настройках, которые ограничивают эффективность использования ресурсов.

Проблемы и выявленные узкие места

Переподписка на память

1. Установленный параметр gp_resource_group_enable_recalculate_query_mem=off приводит к завышению значений памяти, выделяемой запросам. Например, для групп bi_group и etl_group уровень переподписки достигает четырёхкратного значения, что повышает вероятность ошибок нехватки памяти (OOM).

2. Некоторые запросы потребляют весь доступный объём памяти, что приводит к генерации большого количества спилл-файлов.

Высокая конкуренция запросов

В etl_group и bi_group одновременно может работать до 20 и 15 запросов соответственно. При этом конкуренция за ресурсы приводит к снижению производительности, особенно в часы пиковой нагрузки.

Нехватка памяти для малых групп

В группе monitoring_group наблюдается частая генерация спиллов из-за низкого значения statement_mem=125MB, что не соответствует её текущему профилю нагрузки.

Рекомендации по оптимизации

Перераспределение конкуренции:

1. Уменьшить максимальное количество одновременных запросов в группах etl_group (до 15) и bi_group (до 10).

2. Это позволит увеличить объём памяти, выделяемой каждому запросу, снизив количество спилл-файлов.

Корректировка параметра gp_resource_group_enable_recalculate_query_mem:

1. Рассмотреть возможность включения этого параметра. Это обеспечит более точный расчёт памяти, исходя из характеристик сегментных хостов, а не мастер-хоста.

2. Если параметр оставить выключенным, необходимо снизить значение MEMORY_SPILL_RATIO для bi_group и etl_group.

Увеличение выделяемой памяти для малых групп.

Поднять значение statement_mem в monitoring_group до 300–500MB, чтобы минимизировать спиллы.

Динамическая настройка ресурсных групп.

Изменять параметры групп в зависимости от времени суток. Ночью приоритет отдавать etl_group, днём — пользовательским группам.

Реализация рекомендаций

В таблице представлены примерные настройки для дневного и ночного времени:

Анализ данных и схем хранения

Типы таблиц и их распределение

Кластер «Комус» использует преимущественно колоночные таблицы (Append-Optimized Column-Oriented), что соответствует лучшим практикам для аналитических систем. Однако аудит выявил ряд проблем.

Большое количество файлов

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

Избыточное партиционирование

Некоторые таблицы, такие как hybris.ordcustomertracking_add и src_hybris.cartcustomertracking, содержат тысячи партиций, из которых значительная часть пустая. Это создаёт ненужную нагрузку на словарь данных.

Рекомендации

• Сокращение количества файлов. Рассмотреть возможность перевода некоторых таблиц на формат AO Row-Oriented для уменьшения числа файлов.

• Оптимизация партиционирования. Удалить пустые партиции или объединить их для снижения нагрузки на метаданные.

• Анализ использования индексов. Провести аудит индексов на крупных таблицах и определить, какие из них можно оптимизировать или удалить.

Результаты аудита и дальнейшие шаги

Ключевые выводы аудита

Эффективность текущей конфигурации:

1. Инфраструктура в целом соответствует потребностям текущей нагрузки. Равномерное распределение данных и хорошая балансировка процессорных и сетевых ресурсов обеспечивают стабильную работу системы.

2. Использование SSD/NVMe-дисков позволяет справляться с пиковыми нагрузками на чтение и запись.

Выявленные узкие места:

1. Сетевые ограничения: низкое значение MTU (1500) увеличивает фрагментацию пакетов, снижая пропускную способность.

2. Переподписка на память: текущее отключение параметра gp_resource_group_enable_recalculate_query_mem создаёт риски превышения лимитов памяти для отдельных запросов.

3. Высокое количество файлов: AO-таблицы с избыточным партиционированием перегружают файловую систему.

Запас производительности:

1. Кластер обладает значительным резервом по памяти и CPU. Средняя загрузка CPU в рабочее время не превышает 30–40%, что позволяет обрабатывать больше данных при корректной настройке ресурсных групп. В VK Cloud используются современные процессоры Intel Platinum с тактовой частотой 3.8 ГГц.

Рекомендации по улучшению

Оптимизация настроек кластера:

1. Увеличить значение MTU или адаптировать gp_max_packet_size для предотвращения потери производительности в сети.

2. Перераспределить нагрузку между группами, снизив степень конкуренции и оптимизировав параметры памяти.

3. Рассмотреть возможность перехода на динамическую настройку ресурсных групп в зависимости от времени суток.

Работа с данными:

1. Уменьшить количество пустых партиций и оптимизировать структуру таблиц с высокой файловой нагрузкой.

2. Провести аудит индексов для крупных таблиц и пересмотреть их целесообразность.

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

Реализация рекомендаций

Некоторые изменения могут быть реализованы без значительных затрат времени:

• Настройка параметра gp_max_packet_size и перераспределение конкуренции групп возможны в течение одного планового окна.

• Оптимизация пустых партиций и индексов требует более детального анализа, но может быть выполнена постепенно.

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

Заключение от Arenadata

Оптимизация работы высоконагруженных систем всегда требует баланса между удовлетворением текущих потребностей и планированием будущего роста. Проведённый аудит кластера ADB компании «Комус» позволил выявить узкие места в конфигурации, предложить практические рекомендации по повышению производительности и сформировать стратегию для долгосрочного развития инфраструктуры. В ходе работы было показано, что даже незначительные изменения — такие как корректировка сетевых параметров или перераспределение памяти — способны существенно повысить эффективность системы. Внедрение предложенных решений не только обеспечит стабильную работу в настоящий момент, но и подготовит кластер к будущим вызовам.

Мы благодарим компанию «Комус» за сотрудничество и надеемся, что наш опыт будет полезен читателям, которые сталкивающимся с подобными задачами на своих проектах.

Резюмируем

Коллеги из «Комус» высоко оценили результаты проведённого аудита, отметив его практическую ценность и объём предоставленных рекомендаций. Благодаря оперативной реализации ключевых изменений, таких как пересмотр сетевых настроек и оптимизация использования ресурсов, удалось быстро добиться улучшения производительности системы.

Особое внимание было уделено рекомендациям, требующим долгосрочных усилий, например оптимизации партиционирования таблиц. Хотя это трудоёмкий процесс, он уже включён в планы компании, поскольку его выполнение обеспечит устойчивость системы к будущим нагрузкам. Кроме того, аудит стал для компании не просто инструментом диагностики, но и поводом пересмотреть подходы к работе с аналитической базой данных. Были внесены изменения в процессы управления и использования ADB, что повысило эффективность взаимодействия между командами и помогло улучшить внутренние практики.

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