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

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

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

Готового мониторинга для SSRS и Power BI Report Server в сети нет - одни обзоры «SQL Server» с CPU и памятью. Собрал свой на Grafana: трейс упавших рассылок, тяжёлые отчёты, ночная нагрузка pbix и грабли с часовым поясом. Сборку отдаю целиком.

Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что-то делать: все вокруг внедряют, конкуренты вон что-то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.

Это был, кажется, пятый такой звонок за месяц.

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

Так вот, если коротко - не надо бежать.

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

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

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

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

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