Данные: что стоит за «озером» и «хранилищем»

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

Три слова, которые путают все

Хранилище (data warehouse). Данные приводят к единой структуре заранее, при загрузке. Долго на входе, быстро и надёжно на выходе. Классический сценарий: отчётность, финансы, всё, где цифра должна сходиться.

Озеро (data lake). Данные складывают как есть, структуру придумывают в момент чтения. Быстро на входе, дорого и медленно на выходе — потому что каждый аналитик разбирается заново. Сценарий: разведка, машинное обучение, данные, формат которых заранее неизвестен.

Гибрид (lakehouse). Попытка совместить: хранить дёшево и как есть, но поверх держать каталог и структуру. Работает, но требует дисциплины, а дисциплина — это люди, а не лицензия.

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

Проверочный вопрос на встрече: «Назовите три вопроса, на которые вы хотите получать ответ, и кто сегодня отвечает на них вручную». Если ответа нет — проект ещё не готов, и продавать сейчас значит продавать себе проблему на этапе внедрения.

Где на самом деле уходят деньги и время

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

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

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

Качество. Пропуски, дубли, поля, которые сотрудники годами использовали не по назначению. Это вскрывается на второй неделе и всегда неожиданно для заказчика.

Люди. Данные без аналитика — это счёт за хранение. Если у клиента нет того, кто будет задавать вопросы, покупка платформы не создаст такого человека.

Как об этом говорить с клиентом

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

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

Не «основа для искусственного интеллекта», а «без порядка в данных любая модель будет обучаться на мусоре». Это честная и понятная формулировка, которая ставит проект по данным на своё место — до, а не вместо ИИ.

Где вендоры преувеличивают

«Подключается к любым источникам». Список коннекторов длинный, но реальные системы клиента часто самописные или старых версий. Всегда уточняйте, что именно у клиента и есть ли этот коннектор в рабочем состоянии.

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

«Единый источник правды». Красивая фраза, за которой стоит организационное решение: кто-то должен объявить, какая система главная по каждому объекту. Технология этого не решает и не может.

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

Что спросить у своего инженера перед встречей

1. Какие из источников клиента мы подключаем штатно, а какие потребуют разработки?
2. Как считается стоимость эксплуатации при росте объёма и числа запросов — где точки роста счёта?
3. Что мы делаем с историческими изменениями: если клиент переименовал филиал, что будет с прошлогодними отчётами?
4. Кто на стороне клиента должен быть выделен и на сколько часов в неделю?
5. Какой минимальный полезный результат мы можем показать за месяц и что для него нужно?

Красные флаги на стороне клиента

• «Сначала соберём, потом придумаем». Самый частый способ похоронить проект. Без первого вопроса не будет и первого результата, а без результата не будет второго этапа.
• Нет владельца данных. Если никто не отвечает за то, какая запись о клиенте правильная, разногласия будут вечными, а виноватым назначат систему.
• Отчёты живут в таблицах у трёх человек. Это не проблема, а актив: там уже есть логика расчётов. Плохо, если эти люди не участвуют в проекте — тогда логику восстановят неправильно.
• Инициатива только сверху. Если те, кто вводит данные, не понимают зачем, качество не улучшится, а именно от него зависит результат.

Вопросы, которые задаст технический директор

«Где физически лежат данные?» — вопрос про размещение и требования к персональным данным. Ответ нужен точный, с названием площадки, а не «в облаке».

«Как мы заберём свои данные, если решим уйти?» — проверка на замкнутость. Готовность спокойно ответить резко повышает доверие.

«Что с нагрузкой на боевые системы?» — выгрузка данных не должна класть учётную систему в рабочее время. Нужен ответ про режим и окна.

«Кто видит какие данные?» — разграничение доступа внутри озера. Зарплаты и себестоимость не должны быть доступны всем аналитикам по умолчанию.

Материал обновлён 30 сентября 2026