Выделенный сервер для аналитики больших данных: конфигурация и цена

MAATRIX

Выделенный сервер для аналитики больших данных — это не просто «мощный компьютер в стойке», а сбалансированная машина, где каждый компонент подобран под характер нагрузки. Аналитика данных упирается то в память, то в диск, то в процессор, и стоит промахнуться с одним из этих узлов, как остальные простаивают, а деньги за них платятся исправно. Ниже разберём, из чего реально складывается конфигурация под ClickHouse, Spark, PostgreSQL и Hadoop, сколько это стоит и на чём можно сэкономить без ущерба для скорости отчётов.

Почему для аналитики берут выделенный сервер, а не облако

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

Выделенный сервер отдаёт вам всю физическую машину целиком. Никаких соседей, никакого оверселлинга, вся память и все ядра ваши двадцать четыре часа в сутки. Для колоночных СУБД вроде ClickHouse это критично: движок рассчитывает на прямой доступ к памяти и диску и раскрывается только на честном железе. Плюс дедик почти всегда выходит дешевле в пересчёте на гигабайт RAM и терабайт NVMe, чем облачная виртуалка эквивалентной мощности, — а для big data этих гигабайтов и терабайтов нужно много.

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

Оперативная память: главный ресурс аналитики

Для аналитики больших данных память — ресурс номер один. Колоночные и in-memory движки держат в RAM рабочие наборы, промежуточные результаты агрегаций, хеш-таблицы для JOIN и кэш словарей. Чем больше данных помещается в память, тем реже система лезет на диск, а значит, тем быстрее отвечают дашборды. Практическое правило простое: горячий, часто запрашиваемый срез данных в идеале должен целиком помещаться в оперативную память.

Отправная точка для серьёзной работы — 128 ГБ. Этого хватает для ClickHouse на десятках миллиардов строк, если данные хорошо сжаты и запросы бьют по индексу. Для Spark и связки с Hadoop, где каждый executor хочет свой кусок heap, комфортный диапазон — 256–512 ГБ, а под крупные in-memory витрины и тяжёлый ETL берут и целый терабайт. Экономить на памяти опаснее всего: нехватка RAM выливается в своп и спиллинг на диск, и вместо ускорения вы получаете многократное замедление на ровном месте.

Отдельно стоит смотреть на тип и частоту памяти. Серверные платформы на DDR4 ECC остаются рабочей лошадкой и стоят заметно дешевле, DDR5 даёт выигрыш в пропускной способности на память-интенсивных сценариях. ECC-коррекция обязательна: при работе с терабайтами через RAM единичные битовые ошибки статистически неизбежны, и без коррекции они тихо испортят результат агрегации, о чём вы даже не узнаете.

Процессор: ядра важнее гигагерц

Аналитические движки почти всегда распараллеливают запрос на все доступные потоки. ClickHouse дробит скан таблицы по ядрам, Spark раскидывает задачи по executor'ам, PostgreSQL с параллельными планами тоже задействует несколько воркеров. Поэтому для big data число ядер важнее тактовой частоты: сервер на 32–64 ядрах обгонит на аналитике быстрый настольный процессор с восемью ядрами в разы, даже если у последнего выше гигагерцы.

На практике выбор идёт между двумя семействами. AMD EPYC даёт максимум ядер и линий памяти на сокет и обычно выигрывает по цене за ядро — это дефолт для колоночных СУБД и параллельного ETL. Intel Xeon хорош там, где важны отдельные ускорители инструкций и предсказуемая производительность на смешанной нагрузке. Для большинства аналитических задач EPYC — прагматичный выбор: больше потоков за те же деньги напрямую превращаются в более быстрые запросы.

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

Диски: NVMe, RAID и объём под данные

Big data — это в первую очередь большие объёмы, которые надо где-то хранить и быстро читать. Здесь правит NVMe: скорость случайного чтения на порядок выше SATA SSD, а для колоночных сканов и шафла в Spark именно диск часто становится узким местом. Обычные HDD в аналитике сегодня оправданы только под холодный архив, к которому обращаются раз в месяц; под рабочие данные — только твердотельные накопители на NVMe.

Массив собирают с оглядкой на задачу. RAID 10 из NVMe даёт и скорость, и отказоустойчивость, но платите вы половиной ёмкости. RAID 0 максимизирует пропускную способность и объём, но не прощает выхода диска из строя — допустим только там, где данные легко перелить заново из источника. Для аналитической реплики, которую в любой момент можно пересобрать из первичного хранилища, RAID 0 экономит деньги; для единственной копии витрин — только RAID 10 или регулярные бэкапы на отдельный узел.

Объём считайте с запасом на рост и на служебные нужды. Колоночное сжатие в ClickHouse ужимает данные в разы, но промежуточные результаты, индексы, логи и место под слияния съедают дополнительные проценты. Практика показывает: закладывайте под данные не больше 70–75 процентов ёмкости массива, оставляя остальное дыхательным зазором, иначе в самый неподходящий момент диск заполнится посреди тяжёлого ETL.

Сеть: почему для кластеров нужен 10G

Пока аналитика живёт на одной машине, гигабитной сети хватает с головой. Но как только вы разносите Hadoop, Spark или шардированный ClickHouse на несколько узлов, между ними начинает гулять большой объём трафика: шафл, репликация, распределённые JOIN. На гигабите узлы упираются в сеть и простаивают в ожидании данных, и весь смысл распределённой обработки теряется. Здесь нужен минимум 10G, а для плотных кластеров и больше.

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

Для одиночного аналитического сервера ситуация проще: достаточно надёжного канала и адекватной защиты от DDoS. Скорость выгрузки отчётов клиентам определяется внешним аплинком, а он у нормального провайдера с запасом. Так что 10G-обвязку берите осознанно — под кластер она обязательна, под одиночный дедик чаще избыточна и лишь удорожает конфигурацию.

Из чего складывается цена и где реально сэкономить

Цена выделенного сервера под аналитику складывается из четырёх основных статей: процессор, объём и тип памяти, дисковая подсистема и сеть с трафиком. Память и NVMe обычно дают наибольший вклад именно на big data — их нужно много, и именно они определяют, поместится ли горячий набор в RAM и как быстро читаются сканы. Ориентировочно стартовая аналитическая машина на 24–32 ядрах, 128 ГБ ECC и паре NVMe в массиве обходится в несколько десятков тысяч рублей в месяц; конфигурации на 256–512 ГБ и терабайтах NVMe стоят кратно дороже.

Экономят грамотно, а не отрезая нужное. Первый честный ход — брать прошлое поколение EPYC или Xeon: разница в реальной производительности на аналитике невелика, а цена ниже заметно. Второй — не переплачивать за DDR5, если сценарий не память-интенсивный до предела. Третий — точно рассчитать объём диска под сжатые данные вместо покупки терабайтов «на всякий случай». А вот на ECC-памяти, отказоустойчивости хранилища единственной копии данных и на резервном копировании экономить нельзя — эти статьи защищают сами ваши данные.

Отдельно про модель оплаты. У MAATRIX выделенные серверы доступны с оплатой картой российского банка, через СБП, криптовалютой и токеном MAAT, а конфигурацию можно собрать под конкретный профиль нагрузки, а не выбирать из трёх жёстких коробок. Если вы не уверены в требованиях, разумнее начать с умеренной машины, снять метрики на своих реальных запросах и точечно нарастить тот компонент, который окажется узким местом. Мы поможем подобрать баланс ядер, памяти и NVMe под вашу конкретную аналитику.

Локации: где разместить аналитический сервер

Выбор страны размещения — это не про мощность, а про закон, задержки и доступ к источникам данных. Если вы работаете с персональными данными российских пользователей, размещение в России закрывает требования 152-ФЗ о хранении таких данных внутри страны и даёт минимальный пинг до отечественной аудитории и внутренних систем. Это дефолт для бизнеса, чья аналитика завязана на российских клиентов и локальные интеграции.

Сервер в США оправдан, когда аналитика тянет данные из мировых облаков и открытых датасетов, а также когда нужен чистый, ничем не запятнанный IP для работы с глобальными API. Американские дата-центры близки к основным облачным регионам, откуда часто и приходят сырые данные, поэтому ETL из зарубежных источников идёт быстрее. Британская локация — это Европа, соответствие GDPR при работе с данными европейцев и низкий пинг до европейских клиентов и партнёров.

У MAATRIX доступны все три локации — Россия, США и Великобритания, — поэтому аналитический контур можно поставить именно там, где живут ваши данные и ваши требования. Если аудитория и источники распределены, рабочая схема — держать сырьё и первичный ETL ближе к источнику, а витрины для отчётности — ближе к тем, кто эти отчёты смотрит. Такой подход снижает и задержки, и объём трансграничного трафика.

Частые вопросы