Последние полгода — вал проектов по BigData и Data Lake. Софтовую часть трогать не будем, там каждый выбирает своё. А вот по железу, фазированию и сайзингу видим один и тот же набор граблей, на которые наступают с завидной регулярностью. Поэтому решили разобрать отдельно.
Началось всё, как обычно, с конкретного запроса. Приходит заказчик: «нам нужна СХД на 150 терабайт под аналитическую платформу». Откуда 150? Открываем схему фермы, а там сложены диски всех виртуалок — вот и получилось круглое число.
Само по себе это число не значит ничего. За ним прячутся три вопроса, и пока на них нет ответов, любая спецификация — это гадание. Причём гадание дорогое: ошибка обнаруживается не на этапе закупки, а через полгода, когда место кончилось, а бюджет уже освоен.
Природа данных
Вопрос первый: что вообще сожмётся
Массив работает с тем, что до него дошло. Всё, что сжато или зашифровано внутри виртуальной машины, приходит готовым потоком.
Начнём с конца, потому что это самая дорогая ошибка из трёх.
Логика простая до банальности. Массив работает с тем, что до него дошло. Если данные сжаты или зашифрованы внутри виртуальной машины, до массива долетает готовый высокоэнтропийный поток — сжимать там нечего. Ни компрессия, ни компакция не помогут, потому что работа уже сделана этажом выше.
Разберём подробнее, потому что тут много нюансов.
Что не сожмётся никогда. Всё зашифрованное на уровне приложения или ОС — TDE в СУБД, LUKS и BitLocker внутри ВМ, SSE в объектных хранилищах. Ровно 1:1, без вариантов. Хороший шифр на выходе даёт поток, статистически неотличимый от случайного.
Важная оговорка, которую путают постоянно: SED-диски и шифрование томов средствами самой СХД на коэффициент не влияют вообще. Они работают после компрессии. Проблема только в шифровании выше уровня массива.
Дальше — уже сжатые форматы. Архивы, медиа, дедуплицированные бэкапы. Тут 1,0–1,05:1, и рассчитывать на них при сайзинге просто нельзя.
Взвешенный коэффициент по такой платформе выходит 1,1–1,2 к 1. А в расчёте ёмкости при этом стоит 2 к 1.
Что не сожмётся, хотя выглядит невинно. Вот здесь и живут основные сюрпризы.
ClickHouse. MergeTree сжимает данные собственными кодеками, LZ4 по умолчанию, часто ZSTD. На массив ложится готовое. Кто-то ставит в расчёт 2:1 «потому что это же база данных» — и промахивается вдвое.
Kafka. Зависит от compression.type у продюсеров. При snappy, lz4 или zstd — сжато на клиенте, массиву достаётся 1,05–1,15:1. При none — сегменты логов жмутся отлично, 3–5:1. Это единственный из тяжёлых компонентов, где ответ может оказаться в вашу пользу. Идите и спрашивайте.
Parquet и ORC со snappy или zstd. Классика даталейка, и классика же несжимаемая. Если под словом «объектное хранилище» у вас лежит именно это — забудьте про дедупликацию как про фактор сайзинга.
Базы с внутренней компрессией страниц — Oracle Advanced Compression, HCC, SQL Server page compression. Отдельная развилка: иногда выгоднее отключить компрессию в СУБД и отдать её массиву, снимается нагрузка с CPU серверов. Но это решение с обязательным тестом производительности, а не «давайте попробуем в проде».
Что сожмётся отлично. Текстовые логи, метабазы Airflow и Superset, конфигурации, исходники — 3–10:1. Несжатые CSV, JSON, XML, дампы. PostgreSQL без компрессии таблиц. Образы ОС однотипных виртуалок.
Дедупликация — это отдельная механика, и про неё забывают. Она работает независимо от сжимаемости. Двести одинаковых виртуальных машин из одного шаблона: каждый блок несжимаемый, но блоки повторяются, и дедуп даёт прекрасный результат. И наоборот — уникальный несжимаемый датасет не возьмёт ни компрессия, ни дедуп. Там честные 1:1, и никакие вендорские гарантии этого не изменят.
Теперь арифметика, ради которой всё считалось. Возьмите типовой стек: ноды ClickHouse, объектное хранилище, брокеры Kafka. В нормальном проекте это порядка 90% всего выделенного объёма. И все три сжимают данные сами. Хорошо сжимаемая часть — метабазы, логи, конфиги — это единицы процентов, на общий коэффициент не влияет никак.
Взвешенный коэффициент по такой платформе выходит 1,1–1,2:1. А в расчёте ёмкости при этом стоит 2:1, потому что так написано в типовом сайзере под виртуализацию. Разница между этими двумя цифрами и есть та самая дельта, которую кто-то обнаружит через полгода. Обычно не тот, кто подписывал спецификацию.
Архитектура размещения
Вопрос второй: где эти данные должны физически лежать
Движки с собственной репликацией живут на локальных дисках. Массив нужен там, где важно быстрое переключение при отказе.
ClickHouse, Kafka, Greenplum, HDFS, Elasticsearch проектировались под локальные диски. У них своя репликация, своё представление о размещении данных, свои механизмы восстановления после отказа узла. Это архитектура shared-nothing, и она не про массив.
Если положить такое на общую СХД, вы получаете двойную защиту: RAID на массиве плюс реплики движка. Ёмкость расходуется дважды. А узкое место переезжает в фабрику, где все узлы кластера начинают конкурировать за одни и те же порты. Вместо распределённой системы получается распределённая система с одной общей точкой отказа и одной общей очередью.
Обратное забывают чаще, и это тоже ошибка. Мастер-ноды, каталоги, реестры схем, метабазы, образы виртуалок — им не нужна пропускная способность. Им нужно быстрое переключение при отказе хоста, снапшоты и предсказуемое восстановление. Это ровно то, ради чего массив покупается. Держать их на локальных дисках — значит добровольно отказаться от HA там, где он достаётся почти бесплатно.
Отдельно про объектный слой, который в наших краях рассматривают почему-то последним. И ClickHouse, и Kafka, и Greenplum, и Spark сегодня умеют выносить холодные данные в S3. ClickHouse — через S3 disk и политики хранения. Kafka — через tiered storage. Обычно это самый дешёвый способ закрыть рост объёма, и почти всегда он оказывается за рамками первоначального обсуждения. А потом выясняется, что 60% данных не трогали полгода, и они спокойно могли лежать на QLC-ёмкости втрое дешевле.
Виртуализация
Вопрос третий: что виртуализировать
Граница проходит не по названию продукта, а по требуемой пропускной способности и допустимому разбросу задержки.
Здесь редко бывает честный ответ «да» или «нет». Граница проходит не по названию продукта, а по требуемой пропускной способности и по тому, насколько критичен разброс задержки.
Метабазы, коннекторы, оркестрация, реестры, Karaf с его бандлами, мониторинг — виртуализируются без раздумий. Нагрузка на ввод-вывод низкая, а выигрыш от живой миграции, снапшотов и быстрого восстановления перевешивает всё остальное. Спорить тут не о чем.
Сегменты Greenplum, DataNode, Kafka под серьёзным потоком записи, data-ноды Elasticsearch — обычно остаются на физике. Не потому, что «не заработает», заработает прекрасно. Но движок рассчитывает на прямой доступ к NVMe, а гипервизор возвращает ему предсказуемость с оговорками. На тестах разницу не видно, на проде под нагрузкой — видно.
Мониторинг показывает, что всё хорошо, а работать невозможно.
Между этими краями — самая большая и самая интересная зона, где всё решают настройки. И вот тут наблюдение из практики: проблемы в средней зоне почти никогда не от нехватки ресурсов. Они от переподписки vCPU и от того, что виртуалку размазало между сокетами.
Симптом узнаваемый до боли: растёт время ожидания планировщика, при этом утилизация процессора выглядит скромно, все графики зелёные, а пользователи жалуются на рывки. Мониторинг показывает, что всё хорошо, а работать невозможно. Ready time и co-stop — первое, куда надо смотреть, а не последнее.
Второй классический источник — общий datastore. Аналитическая ВМ выедает очередь, а рядом на том же LUN живёт что-то чувствительное. Разносить надо на этапе проектирования, а не когда начнёт болеть.
Конвейеры данных
Обвязка: про неё вспоминают в последнюю очередь
Сайзинг «в среднем по палате» ломается именно на обвязке: у каждого компонента свой профиль требований.
Про ClickHouse и Kafka все помнят. Про конвейеры — почти никогда, а это десяток компонентов, у каждого свой характер.
Kafka Connect и Debezium. CDC-поток из транзакционных баз. Диску почти ничего не нужно, зато нужна память под буферы и стабильная сеть. Больно бьёт по задержке, если оказывается на переподписанном хосте.
NiFi. Вот кого недооценивают систематически. У него три репозитория — flowfile, content, provenance — и все три пишут активно. Content repository под потоком уверенно даёт нагрузку по IOPS выше, чем от него ждут. Провенанс растёт незаметно и однажды забивает диск целиком. Локальные NVMe, отдельные тома под каждый репозиторий, мониторинг заполнения — не роскошь.
Apache Karaf и вообще OSGi-контейнеры. Скромный по ресурсам, живёт на виртуалке прекрасно. Что действительно нужно — быстрый рестарт и снапшот перед деплоем бандлов, потому что откат по горячим следам случается чаще, чем хотелось бы. Это как раз аргумент за виртуализацию, а не против.
Airflow. Метабаза, логи задач, DAG-и. Ресурсов ест мало, но логи растут линейно и бесконечно, если не настроена ротация. Видели, как метабаза Airflow на 200 гигабайт кладёт планировщик просто потому, что никто не чистил историю запусков.
Schema Registry, ZooKeeper, etcd. Объёмы копеечные, но ZooKeeper и etcd крайне чувствительны к задержке fsync. Медленный диск под etcd — и кластер начинает переизбирать лидера на ровном месте. Их нельзя ставить «куда осталось место».
Trino и Presto. Координатор виртуализируется спокойно. Воркеры хотят память и сеть, а под spill — локальный быстрый диск. Если spill улетает на сетевой том, тяжёлые джойны превращаются в тыкву.
Superset и Metabase. BI-слой, метабазы небольшие, но кэши запросов растут. Ставятся на виртуалку, живут на массиве, вопросов не вызывают.
Смысл всего перечисления простой: сайзинг «в среднем по палате» ломается именно на обвязке. Нельзя взять суммарный объём фермы и разделить на количество серверов. Одному компоненту нужна память, другому — IOPS, третьему — низкая задержка fsync при мизерном объёме. Считать надо по профилям.
Карта оборудования
Теперь про железо: что подо что подходит
Платформа почти всегда собирается из нескольких типов железа. Попытка обойтись одним — источник большинства проблем.
Перейдём к конкретике, потому что абстракции хороши до момента подписания спецификации.
Сразу оговоримся: платформа почти всегда собирается из нескольких типов оборудования. Попытка обойтись одним — это и есть источник большинства проблем, которые мы описали выше.
Lenovo ThinkAgile HX (Nutanix) — под обвязку и платформенный слой.
Это то место, где HCI играет в свою силу. Метабазы, Airflow, NiFi небольших конвейеров, Karaf, CDC-коннекторы, реестры, BI-слой, мастер-ноды, dev- и test-контуры. Всё то, где ценность в управляемости, снапшотах и быстром восстановлении, а не в выжимании последних микросекунд.
Отдельно стоит посмотреть на Nutanix Unified Storage. Там есть S3-совместимый объектный слой, который закрывает холодный тир для аналитики прямо на том же кластере, без отдельного железа. Плюс Files для общих датасетов и Volumes для блочного доступа. Для средних платформ это часто снимает вопрос отдельной СХД целиком.
Из актуального: ThinkAgile HX650 V4 на Intel Xeon 6 — рабочая лошадка под этот слой. HX650a V4 — если в тот же кластер нужны GPU под инференс.
Lenovo ThinkSystem bare metal — под данные движков.
Всё, что shared-nothing и требовательно к диску: ноды ClickHouse, брокеры Kafka под потоком, сегменты Greenplum, DataNode, воркеры Spark и Trino, data-ноды Elasticsearch, узлы обучения моделей.
SR650 V4 в 2U даёт до 36 NVMe и до 10 слотов PCIe Gen5 — под аналитический узел этого хватает с запасом. Xeon 6 с P-ядрами, до 86 ядер на сокет, поддержка MRDIMM и CXL. Для ClickHouse и Greenplum, где всё упирается в память и её пропускную способность, это ощутимо.
Важный момент, который часто пропускают: под аналитику нужен не самый быстрый процессор, а правильный баланс ядер, памяти и NVMe-каналов. Топовый CPU при недостатке дисковых каналов будет ждать данные. Это тот случай, когда экономия на дисках делает бессмысленной переплату за процессор.
Lenovo DG Series (QLC, ёмкость) — под холодный слой, архив и бэкапы.
QLC-флеш на ONTAP. Ёмкость дёшево, при этом всё ещё флеш. Идеальное место для холодного тира, общих датасетов по NFS, целевого хранилища резервных копий. Есть S3 прямо на массиве, что снимает вопрос отдельного объектного хранилища для холодных данных.
Один нюанс из практики: полезная ёмкость на этих массивах ниже сырой примерно на треть — right-sizing, ADP-партиционирование, двойная чётность RAID-DP, резерв WAFL. Это нормально для all-flash корпоративного класса, но это надо закладывать в расчёт с самого начала, а не обнаруживать при пусконаладке. И считать надо в тех же единицах, что и требование: сайзеры считают в base-2, а подписывают base-10, разница около 10%.
Lenovo DM Series (NVMe, производительность) — под то, что требует скорости и HA.
Мастер-ноды, каталоги, метабазы, датасторы под виртуализацию, общие датасеты, где важна задержка. Unified — то есть и блок, и файл. Когда нужен быстрый NFS под общие данные для обучения, это сюда.
Lenovo DE и DS Series (блочные SAN) — под датасторы и служебные СУБД.
Классический блочный доступ. DE — мидрейндж с гибридом и all-flash, DS — блочный all-flash. Датасторы под виртуализацию, служебные базы, там где не нужен файловый доступ и не нужны фичи ONTAP.
Чего делать не надо. Не надо ставить сегменты Greenplum и ноды ClickHouse на блочную СХД, какая бы быстрая она ни была. Не надо держать метабазы и мастер-ноды на локальных дисках без HA. Не надо покупать один массив «на всё» и потом объяснять, почему аналитика тормозит, а бэкап не укладывается в окно.
Фазирование закупок
Про фазирование, раз уж начали
Платформа данных строится итерациями, а закупка почему-то планируется как одна большая поставка на три года вперёд.
Отдельная беда, не про железо, но про те же деньги.
Платформа данных строится итерациями. Сначала стенд и пилот на паре узлов, потом продуктив, потом расширение под реальный поток. Проблема в том, что закупка почему-то планируется как одна большая поставка «на три года вперёд».
Результат предсказуемый: половина мощности стоит и греет воздух первый год, а к третьему году выясняется, что профиль нагрузки изменился и нужно было совсем другое. Плюс железо стареет, а гарантия тикает с момента поставки, а не с момента ввода в эксплуатацию.
Разумнее закладывать расширяемость и брать под текущую фазу плюс понятный горизонт. Благо и HX, и ThinkSystem, и DG нормально расширяются узлами и дисками без остановки сервиса.
Правда, тут есть встречный аргумент, который в 2026 звучит громче обычного: рост спроса из-за ИИ сделал сроки поставок непредсказуемыми. Долгие размышления стали дорогими. Так что баланс между «не переплатить сейчас» и «не ждать полгода потом» каждый ищет сам. Но искать его надо осознанно, а не по принципу «взяли с запасом, авось пригодится».
Чек-лист
Что спросить до того, как считать спецификацию
Шесть вопросов, которые превращают круглое число в расчёт, который можно защищать.
Короткий список, который экономит недели переписки:
- Кодеки. Что стоит в ClickHouse MergeTree, какой compression.type у продюсеров Kafka, чем сжаты parquet в объектном слое.
- Шифрование. Есть ли TDE, LUKS, SSE — что угодно выше уровня массива.
- Реальное заполнение. Сколько записано на дисках сегодня, а не сколько выделено. Разница обычно кратная.
- Прогноз роста. На горизонте планирования, с разбивкой по компонентам. Kafka с retention 7 дней и ClickHouse с историей за три года растут совершенно по-разному.
- Профиль доступа. Какая доля данных реально читается за месяц. Это ответ на вопрос, нужен ли холодный тир.
- Требования к восстановлению. RPO и RTO по каждому слою. У метабазы Airflow и у сырых данных Kafka они разные, и защищать их одинаково — переплата.
Проверить оценки по сжимаемости несложно: у большинства вендоров есть утилиты, которые прогоняются по каталогу с реальными данными и дают прогноз ещё до переноса. Полдня работы против месяцев объяснений, почему место кончилось.
Итог
Вместо вывода
Круглое число в запросе — это не требование, это симптом. Оно означает, что кто-то сложил диски виртуалок и не задал ни одного из шести вопросов выше.
Хорошая новость: все шесть закрываются за пару встреч с командой платформы. Плохая: без них любая спецификация — это ставка, а не расчёт. И проверяется она не на бумаге, а на проде, через полгода, когда менять что-то уже дорого.
Планируете платформу данных — пишите, разберём конкретную конфигурацию. Заодно посчитаем, сколько у вас реально сожмётся.