01

Природа данныхПрирода данихThe nature of the data

Вопрос первый: что вообще сожмётся

Питання перше: що взагалі стиснеться

Question one: what will actually compress

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

Масив працює з тим, що до нього дійшло. Усе, що стиснуте або зашифроване всередині віртуальної машини, приходить готовим потоком.

The array works with whatever reaches it. Anything compressed or encrypted inside the VM arrives as a finished stream.

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

Почну з кінця, бо це найдорожча помилка з трьох. Логіка проста до банальності. Якщо дані стиснуті або зашифровані всередині віртуальної машини, до масиву долітає готовий високоентропійний потік — стискати там нічого. Ні компресія, ні компакція не допоможуть, бо роботу вже зроблено поверхом вище.

I will start from the end, because this is the most expensive of the three mistakes. The logic is banal. If the data is compressed or encrypted inside the VM, what reaches the array is a finished high-entropy stream — there is nothing left to squeeze. Neither compression nor compaction helps, because the work was already done one floor up.

Что не сожмётся никогда. Всё зашифрованное на уровне приложения или ОС — TDE в СУБД, LUKS и BitLocker внутри ВМ, SSE в объектных хранилищах. Ровно 1:1, без вариантов. Хороший шифр на выходе даёт поток, статистически неотличимый от случайного.

Що не стиснеться ніколи. Усе зашифроване на рівні застосунку або ОС — TDE в СУБД, LUKS і BitLocker усередині ВМ, SSE в об’єктних сховищах. Рівно 1:1, без варіантів. Добрий шифр на виході дає потік, статистично невідрізнюваний від випадкового.

What never compresses. Anything encrypted at the application or OS level — TDE in the database, LUKS and BitLocker inside the VM, SSE in object storage. Exactly 1:1, no exceptions. A good cipher outputs a stream statistically indistinguishable from random.

Важная оговорка, которую путают постоянно: SED-диски и шифрование томов средствами самой СХД на коэффициент не влияют вообще. Они работают после компрессии. Проблема только в шифровании выше уровня массива.

Важливе застереження, яке плутають постійно: SED-диски й шифрування томів засобами самої СХД на коефіцієнт не впливають узагалі. Вони працюють після компресії. Проблема лише в шифруванні вище рівня масиву.

One caveat people get wrong constantly: self-encrypting drives and volume encryption done by the array itself have no effect on the ratio at all. They run after compression. The problem is only encryption above the array level.

Дальше — уже сжатые форматы. Архивы, медиа, дедуплицированные бэкапы. Тут 1,0–1,05:1, и рассчитывать на них при сайзинге просто нельзя.

Далі — уже стиснуті формати. Архіви, медіа, дедупліковані бекапи. Тут 1,0–1,05:1, і розраховувати на них під час сайзингу просто не можна.

Then come the already-compressed formats. Archives, media, deduplicated backups. That is 1.0–1.05:1, and you cannot build a sizing on it.

Что не сожмётся, хотя выглядит невинно

Що не стиснеться, хоча виглядає невинно

What will not compress although it looks innocent

ClickHouse. MergeTree сжимает данные собственными кодеками, LZ4 по умолчанию, часто ZSTD. На массив ложится готовое. Кто-то ставит в расчёт 2:1 «потому что это же база данных» — и промахивается вдвое.

ClickHouse. MergeTree стискає дані власними кодеками, LZ4 за замовчуванням, часто ZSTD. На масив лягає готове. Хтось ставить у розрахунок 2:1 «бо це ж база даних» — і промахується вдвічі.

ClickHouse. MergeTree compresses with its own codecs, LZ4 by default and often ZSTD. What lands on the array is already packed. Someone budgets 2:1 “because it is a database” — and misses by half.

Kafka. Зависит от compression.type у продюсеров. При snappy, lz4 или zstd — сжато на клиенте, массиву достаётся 1,05–1,15:1. При none сегменты логов жмутся отлично, 3–5:1. Это единственный из тяжёлых компонентов, где ответ может оказаться в вашу пользу. Идите и спрашивайте.

Kafka. Залежить від compression.type у продюсерів. За snappy, lz4 або zstd — стиснуто на клієнті, масиву дістається 1,05–1,15:1. За none сегменти логів тиснуться чудово, 3–5:1. Це єдиний із важких компонентів, де відповідь може виявитися на вашу користь. Ідіть і питайте.

Kafka. Depends on the producers’ compression.type. With snappy, lz4 or zstd the client already compressed it and the array gets 1.05–1.15:1. With none, log segments compress beautifully, 3–5:1. This is the one heavy component where the answer may go your way. Go and ask.

Parquet и ORC со snappy или zstd. Классика даталейка, и классика же несжимаемая. Если под словом «объектное хранилище» у вас лежит именно это — забудьте про дедупликацию как про фактор сайзинга.

Parquet і ORC зі snappy або zstd. Класика дата-лейку, і класика ж нестислива. Якщо під словом «об’єктне сховище» у вас лежить саме це — забудьте про дедуплікацію як про чинник сайзингу.

Parquet and ORC with snappy or zstd. A data-lake classic, and classically incompressible. If “object storage” in your project means this, forget deduplication as a sizing factor.

Базы с внутренней компрессией страниц — Oracle Advanced Compression, HCC, SQL Server page compression. Отдельная развилка: иногда выгоднее отключить компрессию в СУБД и отдать её массиву, снимается нагрузка с CPU серверов. Но это решение с обязательным тестом производительности, а не «давайте попробуем в проде».

Бази з внутрішньою компресією сторінок — Oracle Advanced Compression, HCC, SQL Server page compression. Окрема розвилка: іноді вигідніше вимкнути компресію в СУБД і віддати її масиву, знімається навантаження з CPU серверів. Але це рішення з обов’язковим тестом продуктивності, а не «давайте спробуємо в проді».

Databases with page-level compression — Oracle Advanced Compression, HCC, SQL Server page compression. A separate fork: sometimes it pays to switch compression off in the database and hand it to the array, taking load off server CPUs. But that decision requires a performance test, not a “let us try it in production”.

Что сожмётся отлично. Текстовые логи, метабазы Airflow и Superset, конфигурации, исходники — 3–10:1. Несжатые CSV, JSON, XML, дампы. PostgreSQL без компрессии таблиц. Образы ОС однотипных виртуалок.

Що стиснеться чудово. Текстові логи, метабази Airflow і Superset, конфігурації, вихідники — 3–10:1. Нестиснуті CSV, JSON, XML, дампи. PostgreSQL без компресії таблиць. Образи ОС однотипних віртуалок.

What compresses beautifully. Text logs, Airflow and Superset metadata databases, configs, source code — 3–10:1. Uncompressed CSV, JSON, XML, dumps. PostgreSQL without table compression. OS images of identical VMs.

Дедупликация — это отдельная механика, и про неё забывают. Она работает независимо от сжимаемости. Двести одинаковых виртуальных машин из одного шаблона: каждый блок несжимаемый, но блоки повторяются, и дедуп даёт прекрасный результат. И наоборот — уникальный несжимаемый датасет не возьмёт ни компрессия, ни дедуп. Там честные 1:1, и никакие вендорские гарантии этого не изменят.

Дедуплікація — це окрема механіка, і про неї забувають. Вона працює незалежно від стисливості. Двісті однакових віртуальних машин з одного шаблону: кожен блок нестисливий, але блоки повторюються, і дедуп дає чудовий результат. І навпаки — унікальний нестисливий датасет не візьме ні компресія, ні дедуп. Там чесні 1:1, і жодні вендорські гарантії цього не змінять.

Deduplication is a separate mechanism, and it gets forgotten. It works independently of compressibility. Two hundred identical VMs from one template: every block is incompressible, but the blocks repeat, and dedup does wonderfully. And the reverse — a unique incompressible dataset yields to neither compression nor dedup. An honest 1:1, and no vendor guarantee changes that.

Теперь арифметика, ради которой всё считалось. Возьмите типовой стек: ноды ClickHouse, объектное хранилище, брокеры Kafka. В нормальном проекте это порядка 90% всего выделенного объёма. И все три сжимают данные сами. Хорошо сжимаемая часть — метабазы, логи, конфиги — это единицы процентов, на общий коэффициент не влияет никак.

Тепер арифметика, заради якої все рахувалося. Візьміть типовий стек: ноди ClickHouse, об’єктне сховище, брокери Kafka. У нормальному проєкті це близько 90% усього виділеного обсягу. І всі три стискають дані самі. Добре стислива частина — метабази, логи, конфіги — це одиниці відсотків, на загальний коефіцієнт не впливає ніяк.

Now the arithmetic all of this was for. Take a typical stack: ClickHouse nodes, object storage, Kafka brokers. In a normal project that is around 90% of the whole allocated volume. All three compress their data themselves. The nicely compressible part — metadata databases, logs, configs — is a few per cent and moves the overall ratio not at all.

Взвешенный коэффициент по такой платформе выходит 1,1–1,2 к 1. А в расчёте ёмкости при этом стоит 2 к 1.

Зважений коефіцієнт по такій платформі виходить 1,1–1,2 до 1. А в розрахунку ємності при цьому стоїть 2 до 1.

The weighted ratio for such a platform comes out at 1.1–1.2 to 1. And the capacity calculation says 2 to 1.

В расчёте стоит 2:1, потому что так написано в типовом сайзере под виртуализацию. Разница между этими двумя цифрами и есть та самая дельта, которую кто-то обнаружит через полгода. Обычно не тот, кто подписывал спецификацию.

У розрахунку стоїть 2:1, бо так написано в типовому сайзері під віртуалізацію. Різниця між цими двома цифрами і є та сама дельта, яку хтось виявить через пів року. Зазвичай не той, хто підписував специфікацію.

The calculation says 2:1 because that is what a standard virtualisation sizer prints. The gap between those two numbers is the delta someone discovers six months later. Usually not the person who signed the specification.

02

Архитектура размещенияАрхітектура розміщенняPlacement architecture

Вопрос второй: где эти данные должны физически лежать

Питання друге: де ці дані мають фізично лежати

Question two: where the data should physically live

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

Рушії з власною реплікацією живуть на локальних дисках. Масив потрібен там, де важливе швидке перемикання при відмові.

Engines with their own replication live on local disks. The array is needed where fast failover matters.

ClickHouse, Kafka, Greenplum, HDFS, Elasticsearch проектировались под локальные диски. У них своя репликация, своё представление о размещении данных, свои механизмы восстановления после отказа узла. Это архитектура shared-nothing, и она не про массив.

ClickHouse, Kafka, Greenplum, HDFS, Elasticsearch проєктувалися під локальні диски. У них своя реплікація, своє уявлення про розміщення даних, свої механізми відновлення після відмови вузла. Це архітектура shared-nothing, і вона не про масив.

ClickHouse, Kafka, Greenplum, HDFS and Elasticsearch were designed for local disks. They have their own replication, their own view of data placement, their own node-failure recovery. That is shared-nothing architecture, and it is not about an array.

Если положить такое на общую СХД, вы получаете двойную защиту: RAID на массиве плюс реплики движка. Ёмкость расходуется дважды. А узкое место переезжает в фабрику, где все узлы кластера начинают конкурировать за одни и те же порты. Вместо распределённой системы получается распределённая система с одной общей точкой отказа и одной общей очередью.

Якщо покласти таке на спільну СХД, ви отримуєте подвійний захист: RAID на масиві плюс репліки рушія. Ємність витрачається двічі. А вузьке місце переїжджає у фабрику, де всі вузли кластера починають конкурувати за ті самі порти. Замість розподіленої системи виходить розподілена система з однією спільною точкою відмови та однією спільною чергою.

Put that on shared storage and you get double protection: RAID on the array plus engine replicas. Capacity is spent twice. And the bottleneck moves into the fabric, where every cluster node competes for the same ports. Instead of a distributed system you get a distributed system with one shared point of failure and one shared queue.

Обратное забывают чаще, и это тоже ошибка. Мастер-ноды, каталоги, реестры схем, метабазы, образы виртуалок — им не нужна пропускная способность. Им нужно быстрое переключение при отказе хоста, снапшоты и предсказуемое восстановление. Это ровно то, ради чего массив покупается. Держать их на локальных дисках — значит добровольно отказаться от HA там, где он достаётся почти бесплатно.

Зворотне забувають частіше, і це теж помилка. Майстер-ноди, каталоги, реєстри схем, метабази, образи віртуалок — їм не потрібна пропускна здатність. Їм потрібне швидке перемикання при відмові хоста, знімки та передбачуване відновлення. Це рівно те, заради чого масив купується. Тримати їх на локальних дисках — означає добровільно відмовитися від HA там, де він дістається майже безкоштовно.

The reverse is forgotten more often, and it is also a mistake. Master nodes, catalogs, schema registries, metadata databases, VM images — they do not need throughput. They need fast failover when a host dies, snapshots and predictable recovery. That is exactly what an array is bought for. Keeping them on local disks means giving up HA where it comes almost free.

Отдельно про объектный слой, который в наших краях рассматривают почему-то последним. И ClickHouse, и Kafka, и Greenplum, и Spark сегодня умеют выносить холодные данные в S3. ClickHouse — через S3 disk и политики хранения. Kafka — через tiered storage. Обычно это самый дешёвый способ закрыть рост объёма, и почти всегда он оказывается за рамками первоначального обсуждения. А потом выясняется, что 60% данных не трогали полгода, и они спокойно могли лежать на QLC-ёмкости втрое дешевле.

Окремо про об’єктний шар, який у наших краях розглядають чомусь останнім. І ClickHouse, і Kafka, і Greenplum, і Spark сьогодні вміють виносити холодні дані в S3. ClickHouse — через S3 disk і політики зберігання. Kafka — через tiered storage. Зазвичай це найдешевший спосіб закрити зростання обсягу, і майже завжди він опиняється поза межами первинного обговорення. А потім з’ясовується, що 60% даних не чіпали пів року, і вони спокійно могли лежати на QLC-ємності втричі дешевше.

A word on the object tier, which around here is somehow considered last. ClickHouse, Kafka, Greenplum and Spark can all move cold data to S3 today. ClickHouse through S3 disks and storage policies, Kafka through tiered storage. It is usually the cheapest way to absorb growth, and it almost always falls outside the initial discussion. Then it turns out 60% of the data has not been touched in six months and could happily have lived on QLC capacity at a third of the price.

03

ВиртуализацияВіртуалізаціяVirtualisation

Вопрос третий: что виртуализировать

Питання третє: що віртуалізувати

Question three: what to virtualise

Граница проходит не по названию продукта, а по требуемой пропускной способности и допустимому разбросу задержки.

Межа проходить не за назвою продукту, а за потрібною пропускною здатністю та припустимим розкидом затримки.

The line follows required throughput and tolerable latency jitter, not the product name.

Здесь редко бывает честный ответ «да» или «нет». Граница проходит не по названию продукта, а по требуемой пропускной способности и по тому, насколько критичен разброс задержки.

Тут рідко буває чесна відповідь «так» або «ні». Межа проходить не за назвою продукту, а за потрібною пропускною здатністю і за тим, наскільки критичний розкид затримки.

An honest yes or no is rare here. The line follows required throughput and how critical latency jitter is, not the product name.

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

Метабази, конектори, оркестрація, реєстри, Karaf з його бандлами, моніторинг — віртуалізуються без роздумів. Навантаження на введення-виведення низьке, а виграш від живої міграції, знімків і швидкого відновлення переважує все інше. Сперечатися тут немає про що.

Metadata databases, connectors, orchestration, registries, Karaf with its bundles, monitoring — virtualise them without a second thought. I/O load is low, and the gain from live migration, snapshots and fast recovery outweighs everything else.

Сегменты Greenplum, DataNode, Kafka под серьёзным потоком записи, data-ноды Elasticsearch — обычно остаются на физике. Не потому, что «не заработает», заработает прекрасно. Но движок рассчитывает на прямой доступ к NVMe, а гипервизор возвращает ему предсказуемость с оговорками. На тестах разницу не видно, на проде под нагрузкой — видно.

Сегменти Greenplum, DataNode, Kafka під серйозним потоком запису, data-ноди Elasticsearch — зазвичай залишаються на фізиці. Не тому, що «не запрацює», запрацює чудово. Але рушій розраховує на прямий доступ до NVMe, а гіпервізор повертає йому передбачуваність із застереженнями. На тестах різниці не видно, у проді під навантаженням — видно.

Greenplum segments, DataNodes, Kafka under a serious write stream, Elasticsearch data nodes — these usually stay on bare metal. Not because it “will not work”: it works fine. But the engine expects direct NVMe access, and the hypervisor gives predictability back with conditions. In a test you do not see the difference; in production under load you do.

Мониторинг показывает, что всё хорошо, а работать невозможно.

Моніторинг показує, що все добре, а працювати неможливо.

Monitoring says everything is fine, and the system is unusable.

Между этими краями — самая большая и самая интересная зона, где всё решают настройки. И вот тут наблюдение из практики: проблемы в средней зоне почти никогда не от нехватки ресурсов. Они от переподписки vCPU и от того, что виртуалку размазало между сокетами.

Між цими краями — найбільша і найцікавіша зона, де все вирішують налаштування. І ось тут спостереження з практики: проблеми в середній зоні майже ніколи не від браку ресурсів. Вони від перепідписки vCPU і від того, що віртуалку розмазало між сокетами.

Between those edges lies the largest and most interesting zone, where configuration decides everything. And here is an observation from practice: problems in the middle zone almost never come from a lack of resources. They come from vCPU oversubscription and from a VM smeared across sockets.

Симптом узнаваемый до боли: растёт время ожидания планировщика, при этом утилизация процессора выглядит скромно, все графики зелёные, а пользователи жалуются на рывки. Ready time и co-stop — первое, куда надо смотреть, а не последнее.

Симптом упізнаваний до болю: зростає час очікування планувальника, при цьому утилізація процесора виглядає скромно, усі графіки зелені, а користувачі скаржаться на ривки. Ready time і co-stop — перше, куди треба дивитися, а не останнє.

The symptom is painfully recognisable: scheduler wait time grows, CPU utilisation looks modest, every graph is green, and users complain about stutter. Ready time and co-stop are the first place to look, not the last.

Второй классический источник — общий datastore. Аналитическая ВМ выедает очередь, а рядом на том же LUN живёт что-то чувствительное. Разносить надо на этапе проектирования, а не когда начнёт болеть.

Друге класичне джерело — спільний datastore. Аналітична ВМ виїдає чергу, а поруч на тому самому LUN живе щось чутливе. Розносити треба на етапі проєктування, а не коли почне боліти.

The second classic source is a shared datastore. The analytics VM eats the queue while something latency-sensitive lives on the same LUN. Separate them at design time, not when it starts to hurt.

04

Конвейеры данныхКонвеєри данихData pipelines

Обвязка: про неё вспоминают в последнюю очередь

Обв'язка: про неї згадують в останню чергу

The plumbing is remembered last

Сайзинг «в среднем по палате» ломается именно на обвязке: у каждого компонента свой профиль требований.

Сайзинг «у середньому по палаті» ламається саме на обв'язці: у кожного компонента свій профіль вимог.

Averaged-out sizing breaks on the plumbing: every component has its own requirement profile.

Про ClickHouse и Kafka все помнят. Про конвейеры — почти никогда, а это десяток компонентов, у каждого свой характер.

Про ClickHouse і Kafka всі пам’ятають. Про конвеєри — майже ніколи, а це десяток компонентів, у кожного свій характер.

Everyone remembers ClickHouse and Kafka. Almost nobody remembers the pipelines — and that is a dozen components, each with its own temperament.

Kafka Connect и Debezium. CDC-поток из транзакционных баз. Диску почти ничего не нужно, зато нужна память под буферы и стабильная сеть. Больно бьёт по задержке, если оказывается на переподписанном хосте.

Kafka Connect і Debezium. CDC-потік із транзакційних баз. Диску майже нічого не потрібно, зате потрібна пам’ять під буфери і стабільна мережа. Боляче б’є по затримці, якщо опиняється на перепідписаному хості.

Kafka Connect and Debezium. A CDC stream out of transactional databases. It needs almost nothing from disk but wants memory for buffers and a stable network. It suffers badly on an oversubscribed host.

NiFi. Вот кого недооценивают систематически. У него три репозитория — flowfile, content, provenance — и все три пишут активно. Content repository под потоком уверенно даёт нагрузку по IOPS выше, чем от него ждут. Провенанс растёт незаметно и однажды забивает диск целиком. Локальные NVMe, отдельные тома под каждый репозиторий, мониторинг заполнения — не роскошь.

NiFi. Ось кого недооцінюють систематично. У нього три репозиторії — flowfile, content, provenance — і всі три пишуть активно. Content repository під потоком упевнено дає навантаження по IOPS вище, ніж від нього чекають. Провенанс зростає непомітно й одного дня забиває диск цілком. Локальні NVMe, окремі томи під кожен репозиторій, моніторинг заповнення — не розкіш.

NiFi. This one is systematically underestimated. It has three repositories — flowfile, content, provenance — and all three write actively. Under load the content repository reliably produces more IOPS than anyone expects. Provenance grows quietly and one day fills the disk completely. Local NVMe, separate volumes per repository and fill monitoring are not luxuries.

Apache Karaf и вообще OSGi-контейнеры. Скромный по ресурсам, живёт на виртуалке прекрасно. Что действительно нужно — быстрый рестарт и снапшот перед деплоем бандлов, потому что откат по горячим следам случается чаще, чем хотелось бы. Это как раз аргумент за виртуализацию, а не против.

Apache Karaf і взагалі OSGi-контейнери. Скромний за ресурсами, живе на віртуалці чудово. Що справді потрібно — швидкий рестарт і знімок перед деплоєм бандлів, бо відкат по гарячих слідах трапляється частіше, ніж хотілося б. Це якраз аргумент за віртуалізацію, а не проти.

Apache Karaf and OSGi containers in general. Modest on resources, perfectly happy on a VM. What it really needs is a fast restart and a snapshot before deploying bundles, because rollbacks happen more often than one would like. That is an argument for virtualisation, not against it.

Airflow. Метабаза, логи задач, DAG-и. Ресурсов ест мало, но логи растут линейно и бесконечно, если не настроена ротация. Видел, как метабаза Airflow на 200 гигабайт кладёт планировщик просто потому, что никто не чистил историю запусков.

Airflow. Метабаза, логи задач, DAG-и. Ресурсів їсть мало, але логи зростають лінійно й нескінченно, якщо не налаштована ротація. Бачив, як метабаза Airflow на 200 гігабайт кладе планувальник просто тому, що ніхто не чистив історію запусків.

Airflow. Metadata database, task logs, DAGs. It eats few resources, but logs grow linearly and endlessly without rotation. I have seen a 200-gigabyte Airflow metadata database take the scheduler down simply because nobody purged the run history.

Schema Registry, ZooKeeper, etcd. Объёмы копеечные, но ZooKeeper и etcd крайне чувствительны к задержке fsync. Медленный диск под etcd — и кластер начинает переизбирать лидера на ровном месте. Их нельзя ставить «куда осталось место».

Schema Registry, ZooKeeper, etcd. Обсяги копійчані, але ZooKeeper і etcd вкрай чутливі до затримки fsync. Повільний диск під etcd — і кластер починає переобирати лідера на рівному місці. Їх не можна ставити «куди лишилося місце».

Schema Registry, ZooKeeper, etcd. Trivial volumes, but ZooKeeper and etcd are extremely sensitive to fsync latency. A slow disk under etcd and the cluster starts re-electing a leader out of nowhere. You cannot put them “wherever there is room left”.

Trino и Presto. Координатор виртуализируется спокойно. Воркеры хотят память и сеть, а под spill — локальный быстрый диск. Если spill улетает на сетевой том, тяжёлые джойны превращаются в тыкву.

Trino і Presto. Координатор віртуалізується спокійно. Воркери хочуть пам’ять і мережу, а під spill — локальний швидкий диск. Якщо spill відлітає на мережевий том, важкі джойни перетворюються на гарбуз.

Trino and Presto. The coordinator virtualises calmly. Workers want memory and network, and a fast local disk for spill. If spill goes to a network volume, heavy joins turn into a pumpkin.

Superset и Metabase. BI-слой, метабазы небольшие, но кэши запросов растут. Ставятся на виртуалку, живут на массиве, вопросов не вызывают.

Superset і Metabase. BI-шар, метабази невеликі, але кеші запитів зростають. Ставляться на віртуалку, живуть на масиві, питань не викликають.

Superset and Metabase. The BI tier: small metadata databases, but query caches grow. They go on a VM, live on the array and raise no questions.

Смысл всего перечисления простой: сайзинг «в среднем по палате» ломается именно на обвязке. Нельзя взять суммарный объём фермы и разделить на количество серверов. Одному компоненту нужна память, другому — IOPS, третьему — низкая задержка fsync при мизерном объёме. Считать надо по профилям.

Сенс усього переліку простий: сайзинг «у середньому по палаті» ламається саме на обв’язці. Не можна взяти сумарний обсяг ферми й поділити на кількість серверів. Одному компоненту потрібна пам’ять, іншому — IOPS, третьому — низька затримка fsync за мізерного обсягу. Рахувати треба за профілями.

The point of the whole list is simple: averaged-out sizing breaks on the plumbing. You cannot take the total farm volume and divide it by the number of servers. One component wants memory, another IOPS, a third low fsync latency at a negligible volume. Size by profile.

05

Карта оборудованияКарта обладнанняHardware map

Теперь про железо: что подо что подходит

Тепер про залізо: що під що підходить

Now the hardware: what fits what

Платформа почти всегда собирается из нескольких типов железа. Попытка обойтись одним — источник большинства проблем.

Платформа майже завжди збирається з кількох типів заліза. Спроба обійтися одним — джерело більшості проблем.

A platform is almost always built from several hardware types. Trying to make do with one causes most of the problems.

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

Перейду до конкретики, бо абстракції гарні до моменту підписання специфікації. Одразу зауважу: платформа майже завжди збирається з кількох типів обладнання. Спроба обійтися одним — це і є джерело більшості проблем, які я описав вище.

To the specifics, because abstractions are fine right up until the specification is signed. One caveat first: a platform is almost always built from several hardware types. Trying to make do with one is the source of most of the problems described above.

Гиперконвергентный кластер — под обвязку и платформенный слой

Гіперконвергентний кластер — під обв’язку і платформний шар

The HCI cluster — for plumbing and the platform tier

Это то место, где HCI играет в свою силу. Метабазы, Airflow, NiFi небольших конвейеров, Karaf, CDC-коннекторы, реестры, BI-слой, мастер-ноды, dev- и test-контуры. Всё то, где ценность в управляемости, снапшотах и быстром восстановлении, а не в выжимании последних микросекунд.

Це те місце, де HCI грає у свою силу. Метабази, Airflow, NiFi невеликих конвеєрів, Karaf, CDC-конектори, реєстри, BI-шар, майстер-ноди, dev- і test-контури. Усе те, де цінність в керованості, знімках і швидкому відновленні, а не у вичавлюванні останніх мікросекунд.

This is where HCI plays to its strengths. Metadata databases, Airflow, NiFi for small pipelines, Karaf, CDC connectors, registries, the BI tier, master nodes, dev and test environments. Everything whose value is manageability, snapshots and fast recovery rather than squeezing out the last microsecond.

Отдельно стоит посмотреть на объектный слой прямо на самой платформе виртуализации. S3-совместимый доступ закрывает холодный тир для аналитики на том же кластере, без отдельного железа, плюс файловые шары под общие датасеты и блочный доступ. Для средних платформ это часто снимает вопрос отдельной СХД целиком.

Окремо варто подивитися на об’єктний шар прямо на самій платформі віртуалізації. S3-сумісний доступ закриває холодний тир для аналітики на тому самому кластері, без окремого заліза, плюс файлові шари під спільні датасети і блоковий доступ. Для середніх платформ це часто знімає питання окремої СХД цілком.

It is worth a separate look at the object tier provided by the virtualisation platform itself. S3-compatible access covers the cold tier for analytics on the same cluster with no extra hardware, plus file shares for shared datasets and block access. For mid-sized platforms that often removes the question of a separate array entirely.

Bare metal — под данные движков

Bare metal — під дані рушіїв

Bare metal — for engine data

Всё, что shared-nothing и требовательно к диску: ноды ClickHouse, брокеры Kafka под потоком, сегменты Greenplum, DataNode, воркеры Spark и Trino, data-ноды Elasticsearch, узлы обучения моделей.

Усе, що shared-nothing і вимогливе до диска: ноди ClickHouse, брокери Kafka під потоком, сегменти Greenplum, DataNode, воркери Spark і Trino, data-ноди Elasticsearch, вузли навчання моделей.

Everything shared-nothing and disk-hungry: ClickHouse nodes, Kafka brokers under load, Greenplum segments, DataNodes, Spark and Trino workers, Elasticsearch data nodes, model-training nodes.

Современный двухюнитовый сервер даёт до 36 NVMe и порядка десяти слотов PCIe Gen5 — под аналитический узел этого хватает с запасом. Актуальные процессоры дают под сотню ядер на сокет, поддержку MRDIMM и CXL. Для ClickHouse и Greenplum, где всё упирается в память и её пропускную способность, это ощутимо.

Сучасний двоюнітовий сервер дає до 36 NVMe і близько десяти слотів PCIe Gen5 — під аналітичний вузол цього вистачає із запасом. Актуальні процесори дають під сотню ядер на сокет, підтримку MRDIMM і CXL. Для ClickHouse і Greenplum, де все впирається в пам’ять та її пропускну здатність, це відчутно.

A modern 2U server takes up to 36 NVMe drives and around ten PCIe Gen5 slots — plenty for an analytics node. Current CPUs offer close to a hundred cores per socket plus MRDIMM and CXL support. For ClickHouse and Greenplum, where everything hinges on memory and its bandwidth, that is noticeable.

Важный момент, который часто пропускают: под аналитику нужен не самый быстрый процессор, а правильный баланс ядер, памяти и NVMe-каналов. Топовый CPU при недостатке дисковых каналов будет ждать данные. Это тот случай, когда экономия на дисках делает бессмысленной переплату за процессор.

Важливий момент, який часто пропускають: під аналітику потрібен не найшвидший процесор, а правильний баланс ядер, пам’яті та NVMe-каналів. Топовий CPU за браку дискових каналів чекатиме на дані. Це той випадок, коли економія на дисках робить безглуздою переплату за процесор.

A point often missed: analytics needs not the fastest CPU but the right balance of cores, memory and NVMe lanes. A top-end CPU starved of disk channels will simply wait for data. This is the case where saving on disks makes the CPU premium pointless.

QLC-ёмкость — под холодный слой, архив и бэкапы

QLC-ємність — під холодний шар, архів і бекапи

QLC capacity — for the cold tier, archive and backups

Ёмкость дёшево, при этом всё ещё флеш. Идеальное место для холодного тира, общих датасетов по NFS, целевого хранилища резервных копий. Объектный доступ прямо на массиве снимает вопрос отдельного хранилища для холодных данных.

Ємність дешево, при цьому все ще флеш. Ідеальне місце для холодного тиру, спільних датасетів по NFS, цільового сховища резервних копій. Об’єктний доступ прямо на масиві знімає питання окремого сховища для холодних даних.

Cheap capacity that is still flash. The ideal home for a cold tier, shared datasets over NFS and a backup target. Object access on the array itself removes the question of separate storage for cold data.

Один нюанс из практики: полезная ёмкость на таких массивах ниже сырой примерно на треть — right-sizing, партиционирование под системные нужды, двойная чётность, служебные резервы файловой системы. Это нормально для all-flash корпоративного класса, но это надо закладывать в расчёт с самого начала, а не обнаруживать при пусконаладке. И считать надо в тех же единицах, что и требование: сайзеры считают в base-2, а подписывают base-10, разница около 10%.

Один нюанс із практики: корисна ємність на таких масивах нижча за сиру приблизно на третину — right-sizing, партиціонування під системні потреби, подвійна парність, службові резерви файлової системи. Це нормально для all-flash корпоративного класу, але це треба закладати в розрахунок від самого початку, а не виявляти під час пусконалагодження. І рахувати треба в тих самих одиницях, що й вимога: сайзери рахують у base-2, а підписують base-10, різниця близько 10%.

One practical nuance: usable capacity on such arrays is about a third below raw — right-sizing, partitioning for system needs, double parity, filesystem reserves. That is normal for enterprise all-flash, but it has to be in the calculation from the start rather than discovered at commissioning. And count in the same units as the requirement: sizers work in base-2 while contracts are signed in base-10, a difference of about 10%.

NVMe-массив — под то, что требует скорости и HA

NVMe-масив — під те, що потребує швидкості та HA

The NVMe array — for what needs speed and HA

Мастер-ноды, каталоги, метабазы, датасторы под виртуализацию, общие датасеты, где важна задержка. Unified — то есть и блок, и файл. Когда нужен быстрый NFS под общие данные для обучения, это сюда. А классический блочный SAN остаётся под датасторы и служебные СУБД — там, где не нужен файловый доступ.

Майстер-ноди, каталоги, метабази, датастори під віртуалізацію, спільні датасети, де важлива затримка. Unified — тобто і блок, і файл. Коли потрібен швидкий NFS під спільні дані для навчання, це сюди. А класичний блоковий SAN лишається під датастори і службові СУБД — там, де не потрібен файловий доступ.

Master nodes, catalogs, metadata databases, virtualisation datastores, shared datasets where latency matters. Unified — both block and file. When you need fast NFS for shared training data, this is the place. Classic block SAN stays under datastores and utility databases, where file access is not needed.

Чего делать не надо. Не надо ставить сегменты Greenplum и ноды ClickHouse на блочную СХД, какая бы быстрая она ни была. Не надо держать метабазы и мастер-ноды на локальных дисках без HA. Не надо покупать один массив «на всё» и потом объяснять, почему аналитика тормозит, а бэкап не укладывается в окно.

Чого робити не треба. Не треба ставити сегменти Greenplum і ноди ClickHouse на блокову СХД, хоч би якою швидкою вона була. Не треба тримати метабази і майстер-ноди на локальних дисках без HA. Не треба купувати один масив «на все» і потім пояснювати, чому аналітика гальмує, а бекап не вкладається у вікно.

What not to do. Do not put Greenplum segments and ClickHouse nodes on block storage, however fast it is. Do not keep metadata databases and master nodes on local disks without HA. Do not buy one array “for everything” and then explain why analytics is slow and backup does not fit its window.

06

Фазирование закупокФазування закупівельPhasing the purchase

Про фазирование, раз уж начал

Про фазування, раз уже почав

On phasing, while we are here

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

Платформа даних будується ітераціями, а закупівля чомусь планується як одна велика поставка на три роки вперед.

A data platform is built in iterations, yet the purchase is somehow planned as one big delivery three years ahead.

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

Окрема біда, не про залізо, але про ті самі гроші. Платформа даних будується ітераціями. Спочатку стенд і пілот на парі вузлів, потім продуктив, потім розширення під реальний потік. Проблема в тому, що закупівля чомусь планується як одна велика поставка «на три роки вперед».

A separate trouble, not about hardware but about the same money. A data platform is built in iterations: first a lab and a pilot on a couple of nodes, then production, then expansion for the real stream. The problem is that procurement is somehow planned as one big delivery “three years ahead”.

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

Результат передбачуваний: половина потужності стоїть і гріє повітря перший рік, а до третього року з’ясовується, що профіль навантаження змінився і потрібно було зовсім інше. Плюс залізо старіє, а гарантія цокає з моменту поставки, а не з моменту введення в експлуатацію.

The result is predictable: half the capacity heats the air for the first year, and by year three the load profile has changed and something else was needed. On top of that the hardware ages, and the warranty ticks from delivery, not from commissioning.

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

Розумніше закладати розширюваність і брати під поточну фазу плюс зрозумілий горизонт. Благо і гіперконвергенція, і сервери, і масиви нормально розширюються вузлами й дисками без зупинки сервісу.

It is smarter to design for expansion and buy for the current phase plus a horizon you can see. HCI, servers and arrays all expand with nodes and disks without stopping the service.

Правда, тут есть встречный аргумент, который в 2026 звучит громче обычного: рост спроса из-за ИИ сделал сроки поставок непредсказуемыми. Долгие размышления стали дорогими. Так что баланс между «не переплатить сейчас» и «не ждать полгода потом» каждый ищет сам. Но искать его надо осознанно, а не по принципу «взяли с запасом, авось пригодится».

Щоправда, тут є зустрічний аргумент, який у 2026 звучить гучніше за звичайне: зростання попиту через ШІ зробило терміни поставок непередбачуваними. Довгі роздуми стали дорогими. Тож баланс між «не переплатити зараз» і «не чекати пів року потім» кожен шукає сам. Але шукати його треба свідомо, а не за принципом «взяли із запасом, раптом знадобиться».

There is a counter-argument, and in 2026 it is louder than usual: AI-driven demand has made lead times unpredictable. Long deliberation became expensive. So everyone finds their own balance between “do not overpay now” and “do not wait six months later”. But find it deliberately, not by the principle of “we took extra, it might come in handy”.

07

Чек-листЧек-листChecklist

Что спросить до того, как считать спецификацию

Що спитати до того, як рахувати специфікацію

What to ask before you price a specification

Шесть вопросов, которые превращают круглое число в расчёт, который можно защищать.

Шість питань, які перетворюють кругле число на розрахунок, який можна захищати.

Six questions that turn a round number into a calculation you can defend.

1. Кодеки. Что стоит в ClickHouse MergeTree, какой compression.type у продюсеров Kafka, чем сжаты parquet в объектном слое.
2. Шифрование. Есть ли TDE, LUKS, SSE — что угодно выше уровня массива.
3. Реальное заполнение. Сколько записано на дисках сегодня, а не сколько выделено. Разница обычно кратная.
4. Прогноз роста. На горизонте планирования, с разбивкой по компонентам. Kafka с retention 7 дней и ClickHouse с историей за три года растут совершенно по-разному.
5. Профиль доступа. Какая доля данных реально читается за месяц. Это ответ на вопрос, нужен ли холодный тир.
6. Требования к восстановлению. RPO и RTO по каждому слою. У метабазы Airflow и у сырых данных Kafka они разные, и защищать их одинаково — переплата.

1. Кодеки. Що стоїть у ClickHouse MergeTree, який compression.type у продюсерів Kafka, чим стиснуті parquet в об’єктному шарі.
2. Шифрування. Чи є TDE, LUKS, SSE — будь-що вище рівня масиву.
3. Реальне заповнення. Скільки записано на дисках сьогодні, а не скільки виділено. Різниця зазвичай кратна.
4. Прогноз зростання. На горизонті планування, з розбивкою за компонентами. Kafka з retention 7 днів і ClickHouse з історією за три роки зростають зовсім по-різному.
5. Профіль доступу. Яка частка даних реально читається за місяць. Це відповідь на питання, чи потрібен холодний тир.
6. Вимоги до відновлення. RPO і RTO за кожним шаром. У метабази Airflow і в сирих даних Kafka вони різні, і захищати їх однаково — переплата.

1. Codecs. What ClickHouse MergeTree uses, what compression.type the Kafka producers set, how the parquet in the object tier is compressed.
2. Encryption. Is there TDE, LUKS, SSE — anything above the array level.
3. Actual fill. How much is written on disk today, not how much is allocated. The difference is usually a multiple.
4. Growth forecast. Over the planning horizon, broken down by component. Kafka with 7-day retention and ClickHouse with three years of history grow in completely different ways.
5. Access profile. What share of the data is actually read in a month. That answers whether you need a cold tier.
6. Recovery requirements. RPO and RTO per tier. The Airflow metadata database and raw Kafka data have different ones, and protecting them identically means overpaying.

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

Перевірити оцінки щодо стисливості нескладно: у більшості вендорів є утиліти, які проганяються по каталогу з реальними даними і дають прогноз ще до перенесення. Пів дня роботи проти місяців пояснень, чому місце скінчилося.

Checking compressibility estimates is not hard: most vendors ship a utility that runs over a directory of real data and returns a forecast before anything is migrated. Half a day of work against months of explaining why the space ran out.

08

ИтогПідсумокBottom line

Вместо вывода

Замість висновку

Instead of a conclusion

Круглое число в запросе — это не требование, это симптом. Оно означает, что кто-то сложил диски виртуалок и не задал ни одного из шести вопросов выше.

Кругле число в запиті — це не вимога, це симптом. Воно означає, що хтось склав диски віртуалок і не поставив жодного з шести питань вище.

A round number in a request is not a requirement, it is a symptom. It means someone added up the VM disks and asked none of the six questions above.

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

Хороша новина: усі шість закриваються за пару зустрічей із командою платформи. Погана: без них будь-яка специфікація — це ставка, а не розрахунок. І перевіряється вона не на папері, а в проді, через пів року, коли міняти щось уже дорого.

The good news: all six are closed in a couple of meetings with the platform team. The bad news: without them any specification is a bet, not a calculation. And it is settled not on paper but in production, six months later, when changing anything is already expensive.