Спор о формате таблиц для lakehouse, похоже, закончился, Iceberg сегодня поддерживают Trino, Spark, ClickHouse, Snowflake и дальше по списку, так что следующим приходится выбирать каталог. Каталог хранит указатель на актуальную версию таблицы, проводит commit и решает, кому эту таблицу читать, поэтому по весу я бы поставил этот выбор рядом с выбором СУБД.

В статье разбираю Lakekeeper, это один бинарник на Rust и обычный Postgres для метаданных, права на OpenFGA до отдельной таблицы и механизм ContractVerification, который может отклонить commit, если тот ломает контракт данных. Для сравнения рядом Apache Polaris, проект фонда Apache на Java с RBAC в два уровня и федерацией внешних каталогов.

В конце описан стек из банковского проекта (RustFS, Lakekeeper с Postgres, SeaTunnel, NiFi, Trino и ClickHouse), который развернули на своём железе за три дня и через три недели вывели в тестовую эксплуатацию.

К этой статье меня подтолкнула причина донельзя прозаическая. Сижу недавно на брифинге, и прилетает жалоба: сервер отчётов работает из рук вон плохо. Сервер при этом не мой, в орбиту обслуживания он не входил, а тут пришлось вспомнить, как оно всё устроено у SQL Server Reporting Services (SSRS), вспомнить молодость, так сказать. Вспомнил. Заодно собрал то, чего мне самому когда-то не хватало, — и решил, что пора всё это выложить в одну статью.

Сервер отчётов — сервис незаметный, пока кто-нибудь из бизнеса не напишет: «а почему мне со вчерашнего дня не приходит утренняя рассылка». Сидишь, открываешь портал, видишь, что подписка вроде есть, вроде активна, а письма не уходят. Ну и как оно всегда было? Лезешь в логи, а логов нормальных нет, есть только таблица где-то внутри базы, в которую редко кто, кроме DBA, и заглядывал.

Знакомо? Если вы держите SSRS или его старшего брата Power BI Report Server, наверняка знакомо.

Вопросы, на которые SSRS обязан отвечать сам, звучат просто.

Какие рассылки упали этой ночью и по какой причине?

Какие отчёты открывают чаще всего, а какие не открывали полгода? Это обычная статистика использования отчётов, которой в портале нет.

Где сервер реально упирается в ресурсы?

Кто владелец подписки, которая ломается третью неделю подряд?

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

В феврале этого года проект с красивым именем Polaris незаметно стал полноценным проектом фонда Apache. Новость прошла как-то мимо, ну стал и стал, мало ли. Между тем это одна из тех новостей, которые лет через пять, возможно, будут называть поворотной точкой. Потому что Polaris — это каталог. А каталог в мире Iceberg — то самое место, где на самом деле лежит власть над вашими данными.

Звучит громко, понимаю. Поясню, откуда такая уверенность.

Последние несколько лет хранилища данных строят по новой схеме: файлы лежат в объектном хранилище, поверх них открытый формат в виде метаданных, движки обработки живут отдельно в виде федеративного обработчика и ходят за данными. Схему назвали лейкхаусом (Data LakeHouse), а формат в ней почти везде один и тот же — Apache Iceberg. Вендоры за него отвоевались, открыли и согласовали, и все выдохнули. Данные наконец-то ничьи (формат parquet): лежат у вас, читаются чем угодно, никакой платформы-хозяина.

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

Начнём даже не с каталогов, а на шаг раньше — с того, что такое вообще Iceberg, вокруг которого последний год прыгают все вендоры.

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

Напомню и про два профиля настроек для СУБД из первой части: первый — тяжёлая ERP с одной большой базой, второй — стопка из сотни бухгалтерских баз на одном инстансе. Настройки, о которых пойдёт речь ниже, зависят от профиля использования так же, как зависела схема размещения данных из предыдущей части. К концу статьи станет видно, из чего складывается ответ на вопрос «почему тормозит», и что железо в этом ответе часто ни при чём.

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

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

Вопрос, который витает немым подтекстом, звучит просто. С чем именно он не справляется?

Вариантов проблем четыре, и справляться с ними надо по‑разному. Блокировки, неоптимальный код, дисковая подсистема, нехватка памяти или процессорных ядер. Новое железо помогает в последних двух случаях, да и то не всегда. Блокировки и медленный код переезжают на новый сервер в полном составе, и через следующие полгода история повторяется, уже с потраченным бюджетом.

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

Возьмите Oracle Exadata. Никому не придёт в голову привезти стойку, включить питание и пройти установку кнопкой «Далее». Конфигурацию считают под профиль нагрузки. Схему размещения данных согласовывают заранее. Приёмку и ввод в эксплуатацию закладывают отдельным этапом работ, с отдельными сроками и бюджетом, и зовут людей, которые это уже проходили. Никто при этом не спрашивает, к чему такие сложности, всем понятно, какого класса машина приехала.

«Отдельные базы больше не нужны», «конец пайплайнов» - каждую неделю кто-то крупный со сцены хоронит то, что ты вчера поставил в прод. ClickHouse поступил ровно наоборот, и поэтому его анонсы стоит прочитать внимательно. Что реально показали на Open House 2026 и что из этого доедет до прода - разбор практика без вендорского глянца.

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

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

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

Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто-то задыхается на боевой OLTP-базе под аналитической нагрузкой. Кто-то впервые строит BI и не понимает, с какого края подходить. У кого-то накопились данные из десятка систем-источников, и существующих средств уже не хватает.

У всех «хранилище». А правильный технический ответ зависит от условий задачи.

За годы работы в банках, ритейле и системной интеграции мы пришли к простой картине: для среднего и крупного бизнеса большинство DWH-проектов сводится к четырёхзонной архитектуре поверх двух специализированных движков. Не Inmon, не Kimball-star-schema, не Data Vault 2.0 - и при этом не «modern data stack как у Databricks один-в-один».

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