Медиацентр
Где лежат ваши данные: как выбрать архитектуру, которую не придется перестраивать через два года
15.10.2026В ночь на 8 октября беспилотники атаковали центр обработки данных (ЦОД) «Яндекса» в Сасове, 9 октября – в Калуге, 11 октября – во Владимире. По данным «Ведомостей», работа владимирской площадки была полностью остановлена, компания перевела платформы в аварийный режим и призвала клиентов использовать альтернативные сценарии. Сбои затронули не только сервисы самого «Яндекса», но и сторонние платформы, зависящие от его инфраструктуры. По оценке Strategy Partners, большая доля пострадавших приходится на корпоративных клиентов, которые размещали в облаке внутренние сервисы.
Для ИТ-директора в этой истории важна инженерная сторона. CNews опубликовал результаты опроса 93 представителей крупных компаний: хотя бы частично спланированные сценарии аварийного восстановления (Disaster Recovery) есть у 86,9% участников, а для 41,5% целевое время восстановления не превышает часа. При этом регулярные учения чаще двух раз в год проводят 34,4%, а для 68,1% основным способом восстановления остается резервное копирование с ручным возвратом виртуальных машин в строй. Весенний опрос Linx Cloud и Global CIO дал более жесткую картину: формализованную и регулярно проверяемую стратегию аварийного восстановления имеют 20% компаний, а 42% плана не имеют вовсе.Почему выбор архитектуры данных дороже, чем кажетсяРоссийский рынок решений для управления данными, по прогнозам экспертов, растет более чем на 20% в год до 2030 года. По оценке «К2Тех», пилоты 2024–2025 годов показали: эффективность ИИ-решений определяют не выбор модели, а качество, структура и управляемость данных (эту связку мы разбирали в статье «ИИ, автоматизация или разработка: как не промахнуться с выбором»). Архитектура данных задает стоимость и скорость каждой следующей инициативы, а перестройка через два года означает повторную миграцию, переписанные загрузки и месяцы, когда команда занята переездом вместо развития.К привычным критериям выбора, то есть объему данных, скорости запросов и стоимости, добавляется еще один: где физически лежат данные и за какое время их можно поднять на другой площадке. Ни одна из трех архитектур сама по себе не защищает от потери площадки. Устойчивость проектируется отдельно: репликацией на вторую площадку и регулярной проверкой восстановления. Различается цена переезда. Открытые форматы и раздельное хранение и вычисления делают его проще, зависимость от закрытых форматов поставщика делает дороже. Ограничивает выбор и закон: первичные базы персональных данных граждан России по части 5 статьи 18 152-ФЗ должны находиться на территории страны, поэтому запасную площадку для таких данных, как правило, приходится искать у российских провайдеров.Три архитектуры – три разные задачи1. Классическое хранилищеКорпоративное хранилище данных (КХД, англ. DWH) остается правильным выбором, когда данные в основном структурированы и приходят из ограниченного числа учетных систем, отчетность регламентная, а объем измеряется десятками терабайт. По некоторым оценкам, в таком режиме классическое хранилище или специализированная аналитическая СУБД справляются успешно, и менять архитектуру ради новизны не нужно.Где риск: с ростом объемов масштабирование дорожает, а для сырых данных, событий, файлов и машинного обучения такое хранилище неудобно. Добавляется зависимость от поставщика закрытых решений.Что заложить сразу: слоистую модель (сырые данные, детальный слой, витрины), единые справочники и владельцев ключевых показателей. «К2Тех» отмечает возврат интереса к управлению мастер-данными (MDM – единые нормализованные справочники клиентов, товаров и контрагентов): они дают прямую экономию, убирая дублирующие закупки и неточности в логистике и запасах. Отдельной строкой – репликация на вторую площадку и проверка восстановления.2. Озеро данныхОзеро данных (англ. Data Lake) подходит там, где появились события, журналы приложений, телеметрия, файлы, тексты и изображения – данные, которые неудобно сразу приводить к строгой модели. Оно позволяет недорого хранить большие объемы почти в любом формате, поэтому востребовано для машинного обучения и задач, ценность которых еще предстоит выяснить.Где риск: без транзакций и гарантий целостности озеро быстро превращается в болото – никто не понимает, что где лежит и можно ли этому доверять.Что заложить сразу: каталог данных и владельцев с первого дня, зоны хранения (сырые, очищенные, подготовленные), правила именования и контроль качества на входе. Данные стоит класть в объектное хранилище (дешевое файловое хранилище с единым интерфейсом доступа, например S3) в открытых форматах.3. Озеро-складData Lakehouse (озеро-склад данных) соединяет дешевое объектное хранилище озера с открытым табличным форматом, который добавляет транзакции, снимки состояния и изменение схемы. Компании годами держали хранилище и озеро параллельно: двойная инфраструктура, задержка между появлением данных и отчетом, риск рассинхронизации копий. Lakehouse убирает этот дуализм, но оправдан он не всегда. Одного объема данных недостаточно, нужны несколько признаков одновременно:- данных десятки или сотни терабайт, и они продолжают расти;
- кроме таблиц нужны полуструктурированные и неструктурированные данные;
- одни и те же таблицы хранятся в нескольких копиях (озеро, хранилище, витрины, среда машинного обучения), а значительная часть процессов только переносит их между системами;
- требуются обновления, удаления и запоздавшие данные в реальном времени (захват изменений, CDC);
- нагрузка сильно меняется во времени, и хранение с вычислениями выгодно масштабировать раздельно.