Узел кластера Greenplum ревет кулерами и уходит в kernel panic. Дата-саентисты запустили выгрузку миллиона эмбеддингов для обучения рекомендательной системы, а аналитики одновременно обновили дашборд. Дисковый I/O бьется в 100%, интерконнект задыхается, база встает колом. Так умирает классический MPP под смешанной AI-нагрузкой. В MoranaLabs мы разворачиваем индустриальный ИИ, computer vision на периферии и reinforcement learning на железе клиента. Мы видим это постоянно: компания хочет внедрять тяжелые ML-модели, но их слой данных — это монолитная реляционная СУБД, созданная для BI, а не для машинного обучения. Когда облачные вендоры отвалились, а лицензии превратились в тыкву, строить Lakehouse на open-стеке вместо Snowflake и Databricks: Iceberg + Trino + S3 on-prem под ИИ и 152-ФЗ — не дань моде. Это единственный способ масштабировать данные без риска обрушить всю инфраструктуру.
Почему классическое хранилище больше не работает? Потому что машинное обучение требует форматов, которые MPP-базы ненавидят. Фичи, сырые логи, изображения, стримы данных — все это не ложится в жесткую реляционную схему без катастрофического оверхеда. В Greenplum или Vertica вычислительные мощности намертво спаяны с дисками. Растут объемы исторической выборки? Покупайте новые серверы целиком, даже если вам нужно только место под холодные партиции. Lakehouse решает это физическим разделением storage и compute. Вы складываете петабайты на дешевые жесткие диски в S3-совместимое хранилище. MinIO даст вам феноменальную скорость на NVMe-массивах, но потребует идентичного железа. Ceph сложнее в тюнинге, но переварит гетерогенный зоопарк серверов, что критично в условиях нехватки оборудования. Вычислительный движок — Trino или отечественная CedrusData — масштабируется независимо и поднимается только в момент выполнения запроса. В условиях дефицита железа и безумных цен на GPU это архитектурный спасательный круг. Подготовка фичей перекладывается на дешевые CPU-узлы Trino, а дорогостоящие GPU занимаются исключительно инференсом и обучением, забирая готовые паркеты напрямую из объектного хранилища.
Центром этой конструкции становится Apache Iceberg. Не Delta Lake, жестко завязанный на экосистему Spark, и не Hudi, а открытый стандарт табличного формата. Iceberg ведет транзакционный журнал на уровне метаданных, позволяя Trino выполнять SQL-запросы на скоростях, сопоставимых с нативным чтением из базы, не сканируя директории в S3 впустую. Как перевезти enterprise с легаси-МРР на этот стек без даунтайма? Только не через big bang. Разовые масштабные миграции всегда заканчиваются параличом бизнеса. Спасает механизм федерации запросов. Вы ставите Trino поверх существующего Greenplum и нового S3-бакета одновременно. Данные мигрируют по доменам, от холодных к горячим. Аналитик пишет запрос к единой точке входа, а где физически лежат данные — в старой базе или уже в Iceberg-таблице — определяет маршрутизатор. Приложения не замечают подмены слоя хранения.
Закон 152-ФЗ и требования ФСТЭК к КИИ диктуют жесткие правила игры. Вы не можете просто насыпать файлов в бакет и отдать к нему ключи. Вам нужен ролевой доступ, аудит-трейл и маскирование чувствительной информации. В open-стеке это собирается из Apache Ranger или встроенных политик CedrusData поверх каталога таблиц вроде Hive Metastore, Nessie или Gravitino. Вы фильтруете строки для разных отделов, маскируете колонки с персданными регулярками и логируете каждый SELECT на уровне пользователя и сессии. Это не облако, данные не покидают периметр дата-центра, регулятор счастлив.
CREATE TABLE lakehouse.ai_features.user_embeddings (
user_id BIGINT,
feature_vector ARRAY(REAL),
updated_at TIMESTAMP(6) WITH TIME ZONE
) WITH (
format = 'PARQUET',
partitioning = ARRAY['day(updated_at)'],
sorted_by = ARRAY['user_id']
);
-- Лекарство от смерти оптимизатора из-за мелких файлов
ALTER TABLE lakehouse.ai_features.user_embeddings
EXECUTE OPTIMIZE (file_size_threshold => '256MB');Идеально ли это работает из коробки? Нет. Там, где вендор вроде Databricks сглаживает углы за ваши деньги, open-source бьет по лицу. Главная проблема — DML-операции и мелкие файлы. Каждое обновление или удаление в Iceberg порождает новый снапшот и россыпь дельта-файлов. Спустя неделю интенсивных апдейтов листинг S3 начинает тормозить, p99 улетает в космос, а оптимизатор Trino слепнет от огромного количества метаданных. То, что в Snowflake работает как невидимая магия автокомпактизации, здесь придется писать руками. Вы ставите в Airflow расписание через EXECUTE OPTIMIZE. Метаданные нужно пылесосить регулярными процедурами expire_snapshots и remove_orphan_files. Если этого не сделать, озеро данных за месяц превратится в непроходимое болото.
Когда дым рассеивается и инфраструктура отлажена, бенчмарки показывают реальность. Пропускная способность на чтение последовательных паркетов для PyTorch-загрузчиков бьет рекорды. ТСО на горизонте трех лет оказывается кратно ниже стоимости облачного хранилища, потому что вы не платите вендору налог за каждый просканированный гигабайт. Вы покупаете железо один раз и утилизируете его полностью. Но чтобы это взлетело, нужна бескомпромиссная готовность на всех уровнях. Мы используем чек-лист из десяти пунктов для оценки инфраструктуры. Развернут ли отказоустойчивый S3-кластер on-prem с предсказуемым временем отклика? Обеспечена ли сеть минимум в 100 гигабит между вычислительными узлами и хранилищем, чтобы транспорт не стал бутылочным горлышком? Размечены ли домены данных для поэтапного переноса через федерацию? Интегрирован ли слой RBAC с корпоративным Active Directory? Написаны ли скрипты регулярной компактизации и очистки снепшотов для каждой Iceberg-таблицы? Обучена ли команда специфике работы с форматами данных на S3? Настроен ли мониторинг задержек S3 API и нагрузки на дисковую подсистему? Адаптированы ли пайплайны машинного обучения к потоковому чтению из бакетов вместо неэффективного поллинга по JDBC? Работает ли система непрерывного аудита под требования ФСТЭК? Согласованы ли с бизнесом обновленные SLA по доступности и свежести данных? Если больше двух ответов отрицательные, система рухнет при первой серьезной нагрузке. Проектирование платформы данных под ИИ в MoranaLabs начинается именно с этих вопросов. Технологии работают только тогда, когда холодная инженерия преобладает над слепой верой в новые фреймворки.