Может ли хранилище данных включать озеро данных?
Я хочу понять хранилище данных и озеро данных более подробно.
Мне кажется, есть другая информация к теме. Inmon определяет хранилище данных как
предметно-ориентированный, интегрированный, изменяющийся во времени и энергонезависимый сбор данных для поддержки процесса принятия решений руководством
Теперь я понимаю, что это всего лишь форма архитектуры и не подразумевает никаких технологий. Это означает, что базовые данные могут быть любой структурой, которая также может быть хранилищем объектов S3. Более того, Waas et al. в архитектуре ELT по требованию для бизнес-аналитики в нужное время. Расширение Vision предложило хранилище данных с процессом интеграции данных ELT.
Когда дело доходит до озер данных, я нашел следующее определение
хранилище масштабируемого хранилища, которое хранит огромное количество необработанных данных в своем собственном формате ("как есть") до тех пор, пока оно не потребуется, плюс системы обработки (ядро), которые могут принимать данные без ущерба для структуры данных
взяты из данных управления озером.
Теперь хранилище данных может быть более строгим озером данных? Был аргумент, что хранилище данных должно использовать ETL, но, по мнению Инмона, определение не включает каких-либо ограничений на преобразование данных? Если интеграция данных может быть ELT и преобразование является гибким, например, оно может быть легко расширено. Хранилище данных очень похоже на озеро данных.
мои предположения верны или я смотрю на это с искаженным углом.
2 ответа
Хранилище данных и озеро данных являются независимыми системами, которые служат различным целям, могут / должны быть взаимодополняющими, и оба являются частью более широкой архитектуры данных. Озеро данных, как концепция, может быть просто еще одним источником данных для многомерных моделей в хранилище данных (хотя технологическая реализация озер данных позволяет осуществлять прямой запрос необработанных данных).
Вы можете думать о озере данных как о "зоне посадки", где несколько систем выгружают данные в "сложном / необработанном формате", например, MP3-файлы из звонков в службу поддержки клиентов, сжатые журналы с веб-серверов. Он предназначен для исторических целей и для дальнейшей обработки в формате, который можно легко проанализировать / отчитать, например, извлечение текста из файлов MP3.
Хранилище данных также агрегирует данные из разных систем, но данные моделируются в формате, подходящем для отчетности (например, в многомерной модели), его модель отражает процессы и транзакции бизнеса / домена и обычно высоко курируется.
Представьте себе случай: если вы регистрируете посещения своего интернет-магазина с использованием журналов веб-сервера, вы можете хранить журналы в сжатом виде ("данные транзакций") в озере данных, а затем обрабатывать данные в многомерной модели (например, такой), которая будет "Копия данных транзакций, специально структурированных для запросов и анализа", поэтому бизнес-пользователи могут легко изучить их в Excel или каком-либо другом инструменте отчетности.
Хранилище данных было создано для решения проблемы аналитической обработки данных на уровне предприятия и структурированных данных, т.е.
- данные поступают со всей организации и обычно доставляются в хранилище с использованием процессов ETL из различных источников.
- Данные на складе структурированы и управляются в формате, оптимизированном для интенсивных аналитических преобразований. Большинство хранилищ структурируют данные как Columnar Store и предоставляют интерфейс типа SQL для работы с данными.
Озеро данных, с другой стороны, было создано, чтобы быть единой зоной хранения для всех данных вашей организации. Данные в необработанном формате прямо из приложений. Вы также можете обрабатывать данные в озере, либо перемещая их в хранилище, либо напрямую использовать их в системах обработки распределенных больших данных.
Итак, из этого мы видим, что хранилище данных — это не озеро данных.
- так как у него нет неструктурированных данных
- может использоваться только для приложений OLAP с интенсивными вычислениями