Озеро данных без управления - это болото, а не актив
Почему data lake без политики доступа и управления превращается в неуправляемое хранилище, из которого никто не может получить достоверные данные.
Идея озера данных звучит убедительно: собрать всё в одном месте, дать аналитикам доступ и позволить им работать с данными без ограничений. На практике большинство крупных data lake через 18-24 месяца превращаются в то, что в индустрии называют «data swamp» - болото данных. Много информации, мало возможности ей доверять.
Я видел это достаточно раз, чтобы считать это не исключением, а стандартным исходом при отсутствии нескольких конкретных практик.
Что идёт не так
Проблема не в технологии - S3, HDFS, GCS справляются со своей работой. Проблема в том, что в погоне за «давайте просто положим всё туда» пропускаются три вещи:
Каталог данных. Кто знает, что именно лежит в озере? Если новый аналитик должен потратить день на выяснение того, какая таблица актуальная и какую из трёх версий customer_id использовать - это не озеро данных, это свалка с нечёткими ярлыками.
Контроль доступа. «Все могут всё» - это не политика, это отсутствие политики. Персональные данные клиентов, финансовая отчётность и логи приложений требуют разных уровней доступа. Когда это не разграничено, возникают одновременно проблемы безопасности и GDPR.
Качество и происхождение данных. Кто положил эту таблицу? Когда она обновлялась последний раз? Она актуальная или это snapshot 2016 года, который никто не удалил? Без ответов на эти вопросы аналитики принимают решения на основе данных, которым не стоит доверять.
Минимально необходимый контроль
Это не призыв строить сложную governance-инфраструктуру до того, как появились данные. Это про минимальный набор практик, без которых озеро данных становится проблемой быстрее, чем активом.
Схема именования и зонирование. Разделить хранилище на зоны: raw (сырые данные), curated (обработанные), sandbox (эксперименты). Это простое соглашение снижает путаницу на порядок.
Метаданные при загрузке. Источник, время загрузки, владелец, краткое описание. Заполнение этого при добавлении новых данных - обязанность того, кто добавляет, а не отдельная задача на «потом».
Разграничение по уровням доступа. Минимум три уровня: публичный (открытый для всей компании), ограниченный (по запросу), конфиденциальный (PII и финансовые данные). Это не про сложные ACL - это про осознанную политику.
Проверка качества при загрузке. Базовые проверки: есть ли данные, нет ли очевидных аномалий, совпадает ли схема. Не сложный data quality framework, а минимальные gate checks.
Кто за это отвечает
Управление озером данных - это не технический вопрос, это операционный. Кто-то конкретный должен владеть каталогом, утверждать политику доступа и принимать решения о том, что устарело и может быть удалено.
В большинстве организаций это либо никто, либо «все немного» - что в практике неотличимо от «никто». Пока этот вопрос не решён организационно, техническое решение не поможет.
Коротко
Data lake работает, когда у него есть хозяин. Это человек или команда, которые отвечают за то, чтобы данные в нём были понятны, доверенными и доступными нужным людям с нужными правами. Без этого добавление ещё одного петабайта данных только делает проблему хуже.