Озеро данных — это система или репозиторий данных, хранящихся в естественном/сыром формате, [1] обычно объектные блоки или файлы. Озеро данных — это обычно единое хранилище данных, включающее необработанные копии исходных системных данных, данные датчиков, социальные данные и т. д., [2] и преобразованные данные, используемые для таких задач, как отчетность , визуализация , расширенная аналитика и машинное обучение . Озеро данных может включать структурированные данные из реляционных баз данных (строки и столбцы), полуструктурированные данные ( CSV , журналы, XML , JSON ), неструктурированные данные ( электронные письма , документы, PDF-файлы ) и двоичные данные (изображения, аудио , видео). [3] Озеро данных может быть создано локально (в центрах обработки данных организации) или в облаке (с использованием облачных сервисов ).
Джеймс Диксон, тогдашний главный технический директор Pentaho , ввел этот термин в 2011 году [4] , чтобы противопоставить его киоску данных , который представляет собой меньшее хранилище интересных атрибутов, полученных из необработанных данных. [5] Продвигая озёра данных, он утверждал, что киоскам данных присуще несколько присущих им проблем, таких как разрозненность информации . PricewaterhouseCoopers (PwC) заявила, что озёра данных могут «положить конец разрозненности данных». [6] В своём исследовании озёр данных они отметили, что предприятия «начинают извлекать и размещать данные для аналитики в едином репозитории на основе Hadoop».
Многие компании используют облачные сервисы хранения данных , такие как Google Cloud Storage и Amazon S3 , или распределенную файловую систему, такую как распределенная файловая система Apache Hadoop (HDFS). [7] Постепенно растет академический интерес к концепции озер данных. Например, Personal DataLake в Кардиффском университете — это новый тип озера данных, который нацелен на управление большими данными отдельных пользователей, предоставляя единую точку сбора, организации и обмена персональными данными. [8]
Ранние озера данных, такие как Hadoop 1.0, имели ограниченные возможности, поскольку поддерживали только пакетно-ориентированную обработку ( Map Reduce ). Взаимодействие с ними требовало знаний Java, Map Reduce и инструментов более высокого уровня, таких как Apache Pig , Apache Spark и Apache Hive (которые также изначально были пакетно-ориентированными).
Плохо управляемые озера данных в шутку называют болотами данных. [9]
В июне 2015 года Дэвид Нидл охарактеризовал «так называемые озера данных» как «один из наиболее спорных способов управления большими данными ». [10] PwC также осторожно отметила в своем исследовании, что не все инициативы по озерам данных успешны. Они цитируют Шона Мартина, технического директора Cambridge Semantics :
Мы видим, как клиенты создают большие кладбища данных, сбрасывая все в распределенную файловую систему Hadoop (HDFS) и надеясь что-то с этим сделать в будущем. Но затем они просто теряют счет тому, что там находится. Главная проблема заключается не в создании озера данных, а в использовании возможностей, которые оно предоставляет. [6]
Они описывают компании, которые создают успешные озера данных, как компании, которые постепенно совершенствуют свои озера по мере того, как они выясняют, какие данные и метаданные важны для организации.
Другое замечание заключается в том, что термин «озеро данных» бесполезен, поскольку он используется в самых разных смыслах. [11] Он может использоваться для обозначения, например: любых инструментов или методов управления данными, которые не являются хранилищами данных ; конкретной технологии для внедрения; резервуара необработанных данных; концентратора для разгрузки ETL ; или центрального концентратора для аналитики с самообслуживанием.
Хотя критика озер данных оправдана, во многих случаях она применима и к другим проектам в области данных. [12] Например, определение хранилища данных также изменчиво, и не все усилия по созданию хранилищ данных были успешными. В ответ на различные критические замечания McKinsey отметила [13] , что озеро данных следует рассматривать как модель обслуживания для предоставления бизнес-ценности в рамках предприятия, а не как технологический результат.
Data lakehouses — это гибридный подход, который может принимать различные форматы необработанных данных, как data lake, но при этом обеспечивать транзакции ACID и обеспечивать качество данных, как data warehouse . [14] [15] Архитектура data lakehouse пытается устранить несколько критических замечаний data lakes, добавляя возможности хранилища данных, такие как поддержка транзакций, принудительное применение схем, управление и поддержка различных рабочих нагрузок. По словам Oracle, data lakehouses объединяют «гибкое хранение неструктурированных данных из data lake и функции и инструменты управления из data warehouses». [16]
Если представить себе хранилище бутилированной воды — очищенной, упакованной и структурированной для удобства потребления — озеро данных представляет собой большой водоем в более естественном состоянии. Содержимое озера данных поступает из источника, чтобы заполнить озеро, и различные пользователи озера могут приходить, чтобы исследовать, нырять или брать образцы.
Магуайр, главный полевой технолог подразделения HP Big Data Business Unit, обсудил один из наиболее спорных способов управления большими данными, так называемые озера данных.[ постоянная мертвая ссылка ]