s3.get_object(Bucket='corporate-lake', Key='raw_logs/2023/data.json')
Эту или подобную строку я стабильно вижу на каждом втором аудите корпоративной инфраструктуры. И это приговор вашему кластеру. Наивная вера в то, что можно свалить терабайты сырой телеметрии в один бакет, натравить на них скрипты на Python, и дата-саентисты чудесным образом начнут поставлять модели в прод, обходится бизнесу в миллионы рублей на простаивающем железе.
В Morana Labs мы делаем индустриальный ИИ: хардкорный reinforcement learning, компьютерное зрение на edge-устройствах и high-load инференс прямо на железе заказчика. Данные не покидают защищенный периметр, никаких облаков. И когда мы заходим на проект, вопрос физического хранения данных становится ребром в первый же день. Потому что красивые архитектурные паттерны из интернета рассыпаются в пыль, когда p99 latency чтения батча для обучения упирается в лимиты I/O или кривой формат.
Где хранить данные для AI: озеро, хранилище или lakehouse — выбор под нагрузку и 152-ФЗ
Популярный миф гласит: просто купите S3-хранилище, назовите его Data Lake, и проблемы с ML-пайплайнами исчезнут. Это ложь, щедро оплаченная вендорами облачных сервисов. Классическое хранилище данных (DWH) вроде Greenplum или ClickHouse строилось под абсолютно другие профили нагрузки. DWH идеально подходит для BI-аналитики. Вы получаете строгую схему, транзакционную целостность и возможность строить дашборды, где агрегаты отдаются за миллисекунды. Но попробуйте засунуть в реляционную базу пятьдесят терабайт сырых тензоров, изображений или неструктурированных логов для обучения нейросети. DWH задохнется. Он требует жесткой трансформации данных до записи (ETL), а ML-инженерам нужны сырые распределения, не искаженные предварительными фильтрами.
Озеро данных (Data Lake) предлагает обратный подход: пишем все подряд, разбираемся при чтении (ELT). Это дешево с точки зрения хранения, но катастрофически дорого в момент обучения. Если вы храните данные в JSON или сырых CSV, парсинг текста убьет CPU серверов еще до того, как видеокарты получат хотя бы один тензор. GPU простаивают, пока процессоры пытаются разобрать запятые. И здесь на сцену выходит Lakehouse.
Иллюзия гибкости: когда Lakehouse на on-prem железе превращается в тыкву
Lakehouse — это попытка натянуть транзакционную семантику на объектное хранилище. Берем дешевый S3, кладем туда данные и сверху накрываем открытыми табличными форматами вроде Apache Iceberg, Hudi или Delta Lake. Идея отличная: мы получаем версионирование, time travel (возможность откатиться к состоянию датасета недельной давности для воспроизводимости экспериментов) и ACID-транзакции.
Но когда вы поднимаете Iceberg на on-prem железе без управляемых облачных сервисов, вы остаетесь один на один с компакцией мелких файлов. Если ваш микросервис стримит логи по 10 килобайт, через месяц S3 захлебнется от количества объектов, а метаданные Lakehouse станут весить больше, чем сами полезные логи. MLOps-инженеру придется настраивать асинхронные джобы для перепаковки этого мусора в крупные блоки, иначе любая попытка собрать датасет для обучения положит сеть из-за overhead'а на установку соединений. Честный трейд-офф заключается в том, что Lakehouse гибок, спасает ML-нагрузки от хаоса, но мучительно сложен в эксплуатации. Классический DWH прост в поддержке, но душит ML-нагрузки.
Архитектура без западных облаков и смерть дата-болота
Как только в проекте появляются персональные данные, коммерческая тайна или требования 152-ФЗ, про AWS, Snowflake и Databricks можно забыть. Суверенитет диктует полный физический контроль над инфраструктурой, вплоть до изолированных стоек (air-gapped) на производстве. Типичный рабочий стек в таких условиях собирается из open-source компонентов на голом железе. Базовым слоем выступает S3-совместимое объектное хранилище, чаще всего кластер MinIO. Для быстрых аналитических срезов и BI рядом ставится ClickHouse, а для работы с метаданными — обычный PostgreSQL.
| Тип хранилища | Основная задача | Схема данных | Влияние на ML-инфраструктуру |
|---|---|---|---|
| DWH (ClickHouse, Greenplum) | BI, дашборды, аналитика | Строгая при записи (Schema-on-write) | Душит ML. Дорогая трансформация, не тянет сырые тензоры и медиа. |
| Data Lake (MinIO, HDFS) | Сырые архивы, логи | Определяется при чтении (Schema-on-read) | Простой старт, но высокий риск получить болото без каталогизации. |
| Lakehouse (Iceberg + S3) | Единый доступ для ML и BI | Версионируемая транзакционная | Идеально для MLOps, требует суровой инженерии для компакции файлов. |
Самое критичное в этой схеме — формат хранения. Масштабируемое машинное обучение требует колоночных форматов: Parquet или ORC. Обучение моделей редко использует все доступные поля в логах. Алгоритму нужны конкретные фичи. Колоночное хранение позволяет вычитывать с диска только те байты, которые относятся к нужным колонкам. Добавьте сюда грамотное партиционирование по датам или логическим сегментам, и I/O нагрузка падает на порядки. Скорость чтения критична: грамотно нарезанный Parquet на NVMe-массиве с MinIO способен отдавать данные со скоростью 10–15 ГБ/с, насыщая шину PCIe и загружая видеокарты напрямую.
Стоимость хранения в таком on-prem контуре составляет примерно 1500–2000 рублей за терабайт в месяц. Это сущие копейки по сравнению с облачным egress-трафиком, который разорит вас на этапе регулярного переобучения тяжелых моделей. Но у дешевизны есть темная сторона. Если вы просто складываете файлы в корзины без описания, хранилище за месяц превращается в зловонное Data Swamp — болото данных.
Болото возникает там, где исчезает ответственность. Инженер залил датасет, обучил модель и уволился. Схема логов поменялась на бэкенде, пайплайн упал, а новая команда третьи сутки пытается понять, откуда бралась колонка с температурой датчика. Чтобы этого не произошло, хранилище мертво без Data Catalog — каталога данных уровня DataHub или Amundsen. Каждый датасет обязан иметь физического владельца. Никакой production ML невозможен без контракта: кто отвечает за партицию, где описана ее схема, и как оркестратор понимает, что данные готовы к поглощению. Индустриальный ИИ — это жесткая дисциплина, где успех определяется тем, насколько быстро и безопасно вы можете прокачать терабайт с диска в VRAM.
Архитектура данных — это компромисс между скоростью разработки и стоимостью поддержки. Выбирать стек нужно не по красивым презентациям на конференциях, а исходя из того, на чем вы будете терять больше денег: на простое дорогих GPU из-за медленного чтения или на зарплатах инженеров, поднимающих упавший кластер Iceberg посреди ночи.