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