Озера данных

Кажется, что в настоящее время он нужен каждой организации. Это так же модно и модно, как и в области управления данными, но о чем весь этот шум вокруг озер данных? В этом посте мы рассмотрим наиболее важные варианты использования, а также некоторые основные характеристики озер данных — и, таким образом, выясним, почему в одних случаях они нам абсолютно необходимы, а в других — нет.

Что такое озеро данных?

Для начала нам нужно общее определение. Мне нравится вариант от Gartner, он точен и понятен:

«Озеро данных — это набор экземпляров хранения различных ресурсов данных, дополнительных к исходным источникам данных (…) хранящихся в почти точной (…) копии исходного формата».

Итак, мы говорим здесь не о предварительно обработанных витринах данных, а о необработанной копии ваших операционных систем. Но зачем нам это нужно, когда у нас уже есть данные в исходных системах?

Цель озера данных состоит в том, чтобы предоставить необработанное представление данных только самым высококвалифицированным аналитикам, чтобы помочь им изучить свои методы уточнения данных и анализа независимо от каких-либо компрометаций системы записи. которые могут существовать в традиционном хранилище аналитических данных. Это должен быть единый репозиторий всех типов данных и, следовательно, универсальный инструмент для беспрепятственного анализа всех данных в организации.

В основном существует два типа озер данных: озера данных на основе Hadoop и озера реляционных данных, тогда как в настоящее время Hadoop встречается гораздо чаще.

Хранилище сравнительных данных

Должны ли предприятия уже иметь какое-то хранилище данных (DWH) — заслуживает ли оно этого названия в некоторых из этих случаев — это другой вопрос. Но разве DWH не является своего рода озером данных? Прадип Менон прекрасно описал разницу между Data Lake и DWH в своем посте Demystifying Data Lake Architecture:

«Озеро данных хранит данные в самой чистой форме, обслуживает множество заинтересованных сторон, а также может использоваться для упаковки данных в форме, удобной для использования конечными пользователями. С другой стороны, хранилище данных уже подготовлено и упаковано для определенных целей».

Таким образом, наиболее важным моментом для большинства бизнес-пользователей является следующее: озера данных хранят данные, которые обычно не используются конечными пользователями. Сначала он должен быть предварительно обработан, например. в виде DWH или киосков данных. Различие заключается в способе обработки данных: в DWH это обычно ETL (Extract Transform Load), тогда как в Data Lakes это ELT (Extract Load Transform).

Существуют сотни сообщений в блогах и статей об этих различиях. Если вы хотите узнать больше по этому вопросу, KD-Nuggets, Talend иGrazitti являются полезными источниками.

Единственное, что здесь действительно следует придерживаться: НЕТ, это не одно и то же, но ДА, оба имеют право на существование, поскольку они оптимизированы для разных целей.

Преимущества недостатки

Итак, давайте вернемся к нашим озерам данных и зачем они нам нужны. Важным моментом с точки зрения бизнеса является доступность данных. По мере того, как общая скорость в бизнесе увеличивается, традиционные архитектуры часто не успевают за изменениями. Это приводит к отсутствию или, по крайней мере, очень неэффективной поддержке принятия решений на основе данных. При наличии озер данных управленческие решения всегда могут основываться на своевременном качественном анализе.

Основными техническими преимуществами являются масштабируемость, вы можете легко подключать новые источники данных и гибкость, так как структурированные/полуструктурированные/неструктурированные данные можно хранить и делать доступными для аналитики. Благодаря такой гибкости схемы мы уже находимся на этапе использования концепции озер данных для включения методов расширенной аналитики и машинного обучения.

Хорошо, масштабируемость, гибкость и аналитика в реальном времени — все это звучит потрясающе — почему бы не иметь их у всех? Потому что он вам просто не нужен, если у вас нет нестабильной бизнес-среды. У вас просто нет источников данных, которые заставляют вас делать большие данные или анализировать их в реальном времени. Если вам нужно надежное ретроспективное (например, с ежедневными пакетными загрузками) решение для составления отчетов со сложными вычислениями и агрегированием: остановитесь на хранилище данных.

Разрушение ажиотажа

Действительно ли вся эта реклама озер данных существенна? Я бы сказал, что да, потому что данные являются наиболее важным активом, когда речь идет о практическом использовании искусственного интеллекта. И в этом контексте речь идет не только об объеме данных, но и о их качестве, глубине и доступности.

С одной стороны, просто неправильные данные, очевидно, влияют на качество анализа, но то же самое относится и к дублированным, устаревшим или ошибочно помеченным данным. С другой стороны, отсутствие глубины данных, например. с точки зрения метаданных является проблемой, поскольку описательные данные часто теряются при их извлечении с помощью процессов ETL. Как только эта информация потеряна, ее можно восстановить только из исходных систем (если она все еще доступна там).

Часто даже целесообразно получить внешние данные, чтобы обогатить собственные собственные данные или предоставить контрольные показатели для критических областей бизнеса. Вы можете взглянуть на наш пост о стратегическом сборе данных, чтобы узнать больше о важности и подходах к получению правильных данных.

Наконец, но, возможно, самое главное, концепции расширенной аналитики и машинного обучения в режиме реального времени становятся возможными, когда мы используем озеро данных в сочетании с потоковыми процессами в рамках лямбда-архитектуры. В двух словах, архитектуры Lambda представляют собой комбинацию двух потоков данных для обеспечения аналитики в реальном времени, а также предопределенной пакетной обработки.

Концепция хорошо описана в этом кратком введении в архитектуры обработки данных.

Ключевые выводы

• Озера данных предназначены для быстрого приема необработанных, подробных исходных данных, чтобы обеспечить возможности обработки на лету для исследования, аналитики и операций.
• Каталогизация данных и управление имеют решающее значение для успешного и устойчивого внедрения
• Хранилища данных и озера данных дополняют друг друга — оба имеют право на существование для своих конкретных вариантов использования.

Источники:

https://www.gartner.com/it-glossary/data-lake
https://medium.com/@rpradeepmenon/demystifying-data-lake-architecture-30cf4ac8aa07
https://www.kdnuggets.com/2014/06/data-lakes-vs-data-warehouses.html
https://www.talend.com/resources/elt-vs- etl/
https://www.grazitti.com/blog/data-lake-vs-data-warehouse-what-one-should-you-go-for/
https: //medium.com/appanion/strategic-data-acquisition-6aa351d91ffb
https://towardsdatascience.com/a-brief-introduction-to-two-data-processing-architectures-lambda-and-kappa -for-big-data-4f35c28005bb
https://aws.amazon.com/de/big-data/datalakes-and-analytics/what-is-a-data-lake/
> https://tdwi.org/articles/2017/03/29/executive-summary-data-lakes.aspx