Архитектура озера данных: как создать хорошее озеро данных
Озера данных — это репозитории для хранения больших объемов данных. Безусловно, одной из замечательных особенностей этого решения является тот факт, что вы можете хранить в нем все свои данные в собственном формате.
Например, вас могут заинтересовать следующие вещи:
- Операционные данные (продажи, финансы, запасы)
- Автоматически сгенерированные данные (устройства IoT, журналы)
- Данные, созданные людьми (сообщения в социальных сетях, электронные письма, веб-контент), поступающие либо изнутри, либо извне организации.
Расслоение
Мы можем думать об озерах данных как об отдельных репозиториях. Но у нас есть возможность разделить их на отдельные слои. Исходя из нашего опыта, мы можем выделить 3-5 слоев, которые применимы в большинстве случаев. Вот они:
- Сырой
- Стандартизированный
- Очищено
- Применение
- Песочница
«Стандартизированно» и «Песочница» считаются необязательными для большинства реализаций. Давайте углубимся в детали, чтобы помочь вам понять их назначение.
- Сырой уровень или уровень необработанных данных — также называется уровнем приема/областью приземления, поскольку он буквально является стоком нашего озера данных. Основная его цель — загружать данные как можно быстрее и эффективнее. Для этого данные должны оставаться в исходном формате. На этом этапе мы не допускаем никаких преобразований. С необработанными данными мы можем вернуться к моменту времени, поскольку сохраняется архив. Не допускается переопределение данных - обработку дубликатов и разных версий одних и тех же данных. Несмотря на то, что вышеизложенный подход разрешен, такие данные все же необходимо организовать в папки. Исходя из нашего опыта, мы советуем клиентам начинать с общего разделения: предметная область/источник данных/объект/год/месяц/день приема/необработанные данные. Важно отметить, что конечным пользователям не следует предоставлять доступ к этому уровню. Данные здесь не готовы к использованию, они требуют больших знаний с точки зрения надлежащего и релевантного потребления. Необработанные данные очень похожи на известный промежуточный этап DWH.
- Стандартизированный уровень данных – может рассматриваться как необязательный в большинстве реализаций. Если мы ожидаем, что наше озеро данных будет быстро расти, это правильное направление. Основная цель данного уровня — повысить производительность при передаче данных из области необработанных данных в область организованных данных. Тут включены как ежедневные преобразования, так и загрузки по требованию. В то время как в области необработанных данных, данные хранятся в собственном формате, на стандартизированном уровне мы выбираем формат, который лучше всего подходит для очистки. Структура такая же, как и в предыдущем слое, но при необходимости ее можно разделить на более мелкие зерна.
- Уровень очищенных данных — также называется кураторским слоем/согласованным слоем. Данные преобразуются в наборы и могут храниться в файлах или таблицах. Назначение данных, а также их структура на данном этапе уже известны. Перед этим слоем следует ожидать очистки и преобразований. Также распространена денормализация и объединение разных объектов. Из-за всего вышеперечисленного это самая сложная часть всего озера данных. Что касается организации ваших данных, структура довольно проста и понятна. Например: Назначение/Тип/Файлы. Обычно конечным пользователям предоставляется доступ только к этому уровню.
- Уровень данных приложения — также называется доверенным уровнем/защищенным уровнем/производственным уровнем, получен из очищенных данных и дополнен любой необходимой бизнес-логикой. Это могут быть суррогатные ключи, совместно используемые приложением, безопасность на уровне строк или что-либо еще, относящееся к приложению, использующему этот уровень. Если какое-либо из ваших приложений использует модели машинного обучения, рассчитанные в вашем озере данных, вы также получите их отсюда. Структура данных останется такой же, как и в очищенных данных.
- Уровень данных песочницы — еще один слой, который можно считать необязательным, предназначен для работы продвинутых аналитиков и специалистов по данным. Здесь они могут проводить свои эксперименты по поиску закономерностей или корреляций. Всякий раз, когда у вас возникает идея обогатить свои данные любым источником из Интернета, «Песочница» — подходящее место для этого.
Пока данные проходят через озеро, вы можете думать об этом как о следующем шаге логической обработки данных.
Архитектура озера данных: важные компоненты
Ранее мы рассмотрели самые важные части озер данных, а именно их слои; Теперь мы можем перейти к другим логическим компонентам, которые формируют наше решение. Давайте посмотрим на диаграмму ниже:
- Безопасность — даже если вы не будете раскрывать озера данных широкой аудитории, все же очень важно, чтобы вы тщательно продумали этот аспект, особенно на начальном этапе и при разработке архитектуры. Это не реляционные базы данных с целой артиллерией механизмов безопасности. Будьте осторожны и никогда не недооценивайте этот аспект.
- Регламентность – Мониторинг и регистрация (или родословная) операций в какой-то момент станут критически важными для оценки производительности и настройки озера данных.
- Метаданные – данные о данных, то есть, в основном, все схемы, интервалы перезагрузки, дополнительные описания назначения данных с описаниями того, как они предназначены для использования.
- Управляющий— в зависимости от размера Озера, который вам может понадобиться, необходимо выделить группу или представителя этой обязанности «владельца озера», возможно, с помощью некоторых решений в метаданных.
- Мастер-Данные (нормативно-справочная информация) — неотъемлемая часть предоставления готовых к использованию данных. Вам нужно либо найти способ сохранить НСИ в Озере, либо ссылаться на неё при выполнении процессов ELT.
- Архив – если у вас есть дополнительное реляционное решение DWH. Вы можете столкнуться с некоторыми проблемами, связанными с производительностью и хранением в этой области. Озера данных часто используются для хранения некоторых архивных данных, изначально поступивших из DWH.
- Разгрузка — и опять же, если у вас есть другие реляционные решения DWH, вы можете захотеть использовать эту область, чтобы разгрузить некоторые процессы ETL, которые потребляют время/ресурсы, и перенести в ваше Озеро данных, что может быть намного дешевле и быстрее.
- Оркестрация + ELT — поскольку данные передаются с сырого уровня через очищенный на уровень песочницы и приложения, вам нужен инструмент для оркестрации потока. Скорее всего, вам так же потребуются преобразования данных. В таком случае вы выбираете инструмент оркестровки, способный это сделать, или используете дополнительные ресурсы для их выполнения.
Другие важные аспекты
Вы можете думать об Озере данных как о Святом Граале самоорганизующегося хранилища. Я много раз слышал фразу «Давайте просто оставим как есть, и все будет хорошо». На самом деле реальность другая, и при таком подходе мы получим нечто под названием «Болото данных».
Буквально это реализация Озера данных для хранения, но в ней отсутствует либо четкое разделение на слои, либо другие компоненты, обсуждаемые в статье. Со временем оно становится настолько беспорядочным, что получить нужные данные становится практически невозможно. Мы не должны умалять важность безопасности, регламентности, метаданных, мастер-данных и управляющего.
Хорошо спланированный подход к проектированию этих областей необходим для любой реализации Озера данных. Я настоятельно рекомендую всем подумать о желаемой структуре, с которой они хотели бы работать. С другой стороны, излишняя строгость в этих областях вызовет пустыню данных (противоположность болота данных). Само Озеро данных должно быть связано с расширением прав и возможностей людей, а не с чрезмерным регулированием.
Большинство из вышеперечисленных проблем можно решить, спланировав желаемую структуру внутри ваших слоев Озера данных и назначив ответственными надежных владельцев.
Из нашего опыта мы видим, что на организацию Озера данных могут влиять:
- Разбиение по времени
- Шаблоны загрузки данных (в режиме реального времени, потоковая передача, инкрементная, полная загрузка, однократная)
- Тематические области/источник
- Границы безопасности
- Последующее приложение/цель/использование
- Владелец/управляющий
- Политики хранения (временные, постоянные, фиксированные по времени)
- Воздействие на бизнес (критическое, высокое, среднее, низкое)
- Конфиденциальная классификация (Общедоступная информация, Только для внутреннего использования, Конфиденциальная информация для поставщиков/партнеров, Информация, позволяющая установить личность, Конфиденциальная – финансовая)
Подведение итогов
Подводя итог, давайте пробежимся по основным задачам, которых должно достичь внедрение любого озера данных. С учетом вышеизложенного их объяснение будет простым:
- «3 v» (Скорость, Разнообразие, Объем). Мы можем оперировать разнообразными данными большого объема с невероятной скоростью. Важным фактом является то, что скорость означает не только время обработки, но и время окупаемости, поскольку проще создавать прототипы и исследовать данные.
- Сокращение усилий по приему данных (необработанный слой), задержка работы по планированию схемы и созданию моделей до тех пор, пока не станет известна ценность данных.
- Упрощение сценариев расширенной аналитики, новых вариантов использования с новыми типами данных. Запуск MVP (минимально жизнеспособный продукт) с данными, которые готовы к использованию. Это экономит время и деньги.
- Эффективное хранение больших объемов данных. Не нужно думать, будут ли данные использоваться, их можно сохранить на всякий случай. Надлежащим образом регламентируемые и управляемые данные можно собирать до того дня, когда мы поймем, что они могут быть ценными.
