Аналитика, которая помещается в память: до 1,5 ТБ

Распределённые системы платят за каждую границу между узлами сетевым shuffle, координацией и сложностью эксплуатации. Когда в одном сервере до 1,5 ТБ RAM и 192 ядра, многие аналитические нагрузки, которым понадобился бы кластер из машин поменьше, помещаются на один-два крупных узла.

• ClickHouse хорошо масштабируется вертикально: отдайте ему все ядра и достаточно RAM для горячих кусков данных и кэшей.
• DuckDB работает внутри процесса на одном узле и напрямую выигрывает от большого объёма RAM и быстрых NVMe.
• Spark в локальном режиме на одном большом узле полностью обходится без сетевого shuffle; в небольшом кластере запускайте по нескольку экзекьюторов на хост.

На двухсокетном Max 192 память по умолчанию разделена на два NUMA-узла, по одному на процессор. Движки, интенсивно работающие с памятью, показывают лучшие результаты, когда каждый процесс остаётся в пределах одного сокета: привязывайте экземпляры через numactl, запускайте по одному экземпляру на сокет или включайте поддержку NUMA в самом движке, если она есть. Односокетный Max 96 с 96 ядрами и 1 152 ГБ RAM полностью снимает этот вопрос.

В серверах Max — четыре накопителя NVMe Gen5 по 7,68 ТБ (30,72 ТБ сырой ёмкости), в Pro 64 — четыре накопителя по 3,84 ТБ. Схему выбирайте в зависимости от того, на каком уровне обеспечивается избыточность:

• Репликация на уровне данных (ClickHouse ReplicatedMergeTree, репликация Kafka, реплики OpenSearch): используйте диски по отдельности в политике хранения JBOD или в страйпе, а отказы дисков пусть покрывают реплики на других серверах.
• Один узел без реплик: RAID 10 — около 15 ТБ полезного объёма на сервере Max, резервные копии — в другом месте.

Разделяйте данные по уровням хранения. Свежие партиции держите на NVMe, а старые переносите на более дешёвую ёмкость: политики хранения ClickHouse умеют перемещать куски данных в S3-совместимое хранилище, которое можно развернуть самостоятельно, например на Ceph RGW или SeaweedFS на Storage 264 (264 ТБ сырой ёмкости) в Ашберне, Лос-Анджелесе, Амстердаме или Франкфурте.

Сжатие меняет расчёты: колоночные движки часто хранят данные в несколько раз компактнее исходного объёма, поэтому оценивайте потребность в дисках по выборке собственных данных, а не по размеру исходников.

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

• ClickHouse: шардируйте данные по узлам Pro 64 или Max с двумя репликами на шард, а для координации запустите ClickHouse Keeper на трёх узлах. Keeper нетребователен к ресурсам, поэтому хватит небольших серверов, например Core 16.
• Spark: выделяйте экзекьюторам примерно по 4–8 ядер с соответствующим объёмом памяти, а каталоги shuffle и spill размещайте на NVMe.
• Kafka: минимум три брокера с фактором репликации 3, логи — на NVMe.
• OpenSearch или Elasticsearch: держите heap каждой JVM ниже примерно 30 ГБ, чтобы сжатые указатели на объекты (compressed oops) оставались включены, отдавайте не меньше половины RAM под кэш файловой системы, а на больших серверах запускайте несколько узлов на хост.

У Max 192 — порты 2 × 100 Гбит/с для кластеров с интенсивным shuffle, у Pro 64 и Max 96 — 2 × 25 Гбит/с. Аналитика часто упирается в перемещение данных, поэтому измеряйте пропускную способность между узлами как можно раньше.