Чем отличаются Data Lake и Data Warehouse, кому нужны исходные и подготовленные данные и почему эти подходы могут дополнять друг друга.
Две задачи одной компании
Представим условную службу доставки. Руководителю нужен регулярный отчёт по срокам, а исследователю — возможность изучить подробные события перемещения заказов. Первый ожидает согласованные показатели, второй пока выясняет, какие закономерности стоит искать.
Оба работают с данными одной компании, но им удобны разные способы их организации. Отсюда возникает разговор об озере данных, или Data Lake, и аналитическом хранилище, или Data Warehouse. Выбирать между названиями без понимания пользователей и задач было бы преждевременно.
Озеро сохраняет разнообразные материалы
В объяснении AWS озеро данных описывается как место для структурированных и неструктурированных сведений, которые можно сохранять в исходном виде. Речь может идти как о таблицах, так и о других форматах, требующих отдельной обработки.
В нашей условной доставке это могли бы быть события приложения и выгрузки из разных систем. Сохранённые исходники дают возможность вернуться к деталям при новом вопросе. Но наличие материалов ещё не означает, что из них сразу получится понятный и достоверный отчёт.
Хранилище помогает отвечать на повторяющиеся вопросы
Аналитическое хранилище обычно ориентировано на подготовленные данные и согласованный анализ. Такое различие назначения рассматривает сравнение AWS. Пользователь получает возможность работать с уже определёнными сущностями и показателями.
Для условной службы доставки команда могла бы договориться, что считать опозданием, как учитывать перенос по просьбе клиента и по какой дате относить заказ к месяцу. Тогда регулярные отчёты опирались бы на одни правила, а не на личное понимание каждого сотрудника.
Порядок нужен в обоих случаях
В озере нельзя просто складывать всё без пояснений и надеяться разобраться позже. В нашем примере полезно знать источник события, время поступления, смысл полей и ответственного за набор. Иначе исследователь потратит время на выяснение того, что уже было известно при загрузке.
Хранилище также не гарантирует качество автоматически. Если правило опоздания выбрано неверно или часть заказов потерялась, аккуратный отчёт останется ошибочным. Контроль полноты, понятные определения и управление доступом нужны независимо от выбранной организации данных.
Почему подходы могут работать вместе
Представим, что команда сначала сохраняет подробные события, затем готовит из них согласованные данные для еженедельного отчёта. Позже появляется новый вопрос о задержках на определённом этапе. Исследователь возвращается к деталям и проверяет, достаточно ли их для нового расчёта.
Это условный пример совместного использования, а не обязательная архитектура для любой компании. Нельзя заранее считать озеро дешёвым, а хранилище дорогим: итог зависит от объёма хранения, обработки, сопровождения и требований. Современные платформы могут совмещать возможности, поэтому ярлык продукта не заменяет изучения его устройства.
С чего начать обсуждение
Перечислите вопросы, на которые команда должна отвечать регулярно, и те, которые пока исследует. Затем опишите доступные источники, нужную историю, допустимую задержку обновления и людей, отвечающих за смысл данных. Это даст основу для разговора об архитектуре.
Для нашей службы доставки полезный первый шаг — разобрать один показатель от исходного события до отчёта. Где появляются исключения? Можно ли восстановить прошлый расчёт? Кто объяснит расхождение? Ответы покажут, чего не хватает сейчас, и помогут обсуждать систему предметно, без покупки технологии только из-за популярного названия.
Что почитать дальше
Следующий шаг
Если хотите развиваться в этом направлении, посмотрите программу «Архитектор данных». Сопоставьте темы с вашей подготовкой и задачами, которые хотите решать самостоятельно. Полезно заранее записать, что уже получается, где нужна практика и какие вопросы стоит обсудить перед началом обучения.
