Дата лейк это что

Озеро, хранилище и витрина данных

Рассмотрим три типа облачных хранилищ данных, их различия и области применения.

Озеро данных

Озеро данных (data lake) — это большой репозиторий необработанных исходных данных, как неструктурированных, так и частично структурированных. Данные собираются из различных источников и просто хранятся. Они не модифицируются под определенную цель и не преобразуются в какой-либо формат. Для анализа этих данных требуется длительная предварительная подготовка, очистка и форматирование для придания им однородности. Озера данных — отличные ресурсы для городских администраций и прочих организаций, которые хранят информацию, связанную с перебоями в работе инфраструктуры, дорожным движением, преступностью или демографией. Данные можно использовать в дальнейшем для внесения изменений в бюджет или пересмотра ресурсов, выделенных коммунальным или экстренным службам.

Хранилище данных

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

Витрина данных

Витрина данных (data mart) — это хранилище данных, предназначенное для определенного круга пользователей в компании или ее подразделении. Витрина данных может использоваться отделом маркетинга производственной компании для определения целевой аудитории при разработке маркетинговых планов. Также производственный отдел может применять ее для анализа производительности и количества ошибок, чтобы создать условия для непрерывного совершенствования процессов. Наборы данных в витрине данных часто используются в режиме реального времени для аналитики и получения практических результатов.

Озеро, хранилище и витрина данных: ключевые различия

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

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

Хранилище данных можно организовать одним из трех способов:

Витрина данных содержит небольшой по сравнению с хранилищем и озером объем данных, которые разбиты на категории для применения конкретной группой людей или подразделением компании. Витрина данных может быть представлена в виде различных схем (звезды, снежинки или свода), которые определяются логической структурой данных. Формат свода данных (data vault) является самым гибким, универсальным и масштабируемым.

Существует три типа витрин данных:

IBM предлагает различные решения для облачного хранения и интеллектуального анализа данных.

Источник

Дата лейк это что

+7 (495) 41-41-121

Data Lake

Data Lake

Data Lake (Озеро данных) – это метод хранения данных системой или репозиторием в натуральном (RAW) формате, который предполагает одновременное хранение данных в различных схемах и форматах. Обычно используется blob-объект (binary large object) или файл. Идея озера данных в том чтобы иметь логически определенное, единое хранилище всех данных в организации (enterprise data) начиная от сырых, необработанных исходных данных (RAW data) до предварительно обработанных (transformed) данных, которые используются для различных задач: отчеты, визуализация, аналитика и машинное обучение.

Data Lake (озеро данных) включает структурированные данные из реляционных баз данных (строки и колонки), полуструктурированные данные (CSV, лог файлы, XML, JSON), неструктурированные данные (почтовые сообщения, документы, pdf) и даже бинарные данные (видео, аудио, графические файлы).

Data Lake (озеро данных), кроме методов хранения и описания данных, предполагает определение источников и методов пополнения данных. При этом используются следующие термины:

Data Lake (озеро данных) может использовать единый репозиторий в качестве хранилища данных (HDFS, EDW, IMDG, Cloud и т.д.) либо использовать модульную концепцию источников хранения данных для разных требований по безопасности, скорости, доступности при соблюдении условий хранения данных: неизменяемые RAW данные, согласованное время хранения (retention time), доступность.

Источник

Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop

В этой статье я хочу рассказать про следующий этап развития DWH в Тинькофф Банке и о переходе от парадигмы классического DWH к парадигме Data Lake.

Свой рассказ я хочу начать с такой вот веселой картинки:

Да, ещё несколько лет назад картинка была актуальной. Но сейчас, с развитием технологий, входящих в эко-систему Hadoop и развитием ETL платформ правомерно утверждать то, что ETL на Hadoop не просто существует но и то, что ETL на Hadoop ждет большое будущее. Далее в статье расскажу про то, как мы строим ETL на Hadoop в Тинькофф Банке.

От задачи к реализации

Перед управлением DWH была поставлена большая задача – анализировать интересы и поведение интернет посетителей сайта банка. У DWH образовалось два новых источника данных, больших данных – это clickstream с портала (www.tinkoff.ru) и RTB (Real-Time Bidding) платформа банка. Два источника порождают колоссальный объём текстовых полуструктурированных данных, что конечно для традиционного DWH, построенного в банке на массивно параллельной СУБД Greenplum, совсем не подходит. В банке был развернут кластер Hadoop, на основе дистрибутива Cloudera, он то и лег в основу целевого хранилища данных, а точнее озера данных, для внешних данных.

Концепция построения озера

Важно было на начальных этапах продумать и зафиксировали концептуальную архитектуру, которой нужно будет придерживаться в ходе моделирования новых структур для хранения данных и работы по загрузке данных. Мы очень не хотели превратить наше озеро в болото данных 🙂 Как и в классическом DWH, мы выделили основные концептуальные слои данных (см. Рис. 1).

Data Vault и как мы его готовим

Проанализировав тренды развития технологий Hadoop, мы решили использовать этот подход и засучив рукава принялись моделировать Data Vault для выше озвученной задачи.

Собственно, хочу рассказать несколько концептов, которые мы используем. Например, в загрузке визитов интернет-пользователей по страницам мы не сохраняем каждый раз URL визита. Все URL-ы мы выделили, в терминах Data Vault, в отдельный хаб (см. Рис. 2). Такой подход позволяет значительно сэкономить место в HDFS и более гибко работать с URL-ами на этапе загрузки и дальнейшей обработки данных.

Рис.2 Data Vault для визитов

Ещё один концепт относится к области загрузки интернет пользователей. Мы не получаем на этапе загрузки в DDS единого интернет пользователя, а загружаем данные в разрезе систем источников. Таким образом загрузки в Data Vault из разных источников не зависят друг от друга.

Реки ETL в озере данных

Вот и подошли к самому интересному. Концепцию продумали, моделирование провели, создали структуры данных, теперь хорошо бы было бы это все наполнить данными.

Для того что бы обеспечить стабильный поток данных (файлов) в слой RAW мы используем Apache Flume. Для обеспечения отказоустойчивости и независимости от кластера Hadoop мы разместили Flume на отдельном сервере – получили такой как бы File Gate, перед кластером Hadoop. Ниже приведу пример настройки агента Flume для передачи портального syslog:

Таким образом, мы получили стабильный поток данных в слой RAW. Дальше нужно разложить эти данные в модель, наполнить Data Vault, ну короче нужен ETL на Hadoop.

Барабанная дробь, гаснет свет, на сцену выходит Informatica Big Data Edition. Не буду в красках и много рассказывать про этот ETL инструмент, постараюсь коротко и по делу.

Лирическое отступление. Хочется сразу отметить, что Informatica Platform (в которую входит BDE), это не та всем знакомая Informatica PowerCenter. Это принципиально новая платформа интеграции данных от корпорации Informatica, на которую сейчас постепенно переносят весь тот большой набор полезных функций из старого и всеми любимого PowerCenter.

Теперь по делу. Informatica BDE позволяет достаточно быстро разрабатывать ETL процедуры (маппинги), среда очень удобная и не требует длительного обучения. Маппинг транслируется в HiveQL и выполняется на кластере Hadoop, Informatica обеспечивает удобный мониторинг, последовательность запуска ETL процессов, обработку ветвлений и исключительных ситуаций.

Например, вот так выглядит маппинг, который наполняет хаб интернет юзеров нашего портала (см. Рис. 3).

Оптимизатор Informatica BDE транслирует этот маппинг в HiveQL и сам определяет шаги исполнения (см. Рис. 4).

Рис.4 План выполнения

Informatica BDE позволяет гибко управлять параметрами среды выполнения. Например, мы у себя настроили следующие параметры:

Маппинги можно объединять в потоки. Например, у нас данные из отдельных систем источников загружаются в отдельных потоках (см. Рис. 5).

Рис.5 Поток загрузки данных

Informatica BDE обладает удобным инструментом администрирования и мониторинга (см. Рис. 6).

Рис.6 Мониторинг исполнения потока данных

Из преимуществ Informatica BDE можно выделить следующее:

Из недостатков можно выделить следующее:

В целом инструмент Informatica BDE весьма хорошо показал себя при работе с Hadoop и у нас на него дальше очень большие планы в части ETL на Hadoop. Думаю, в скором времени напишем ещё более предметные статьи о реализации ETL на Hadoop на Informatica BDE.

Результаты

100Gb текстовых логов и получаем в Data Vault примерно на порядок меньше данных, на основе которых собираются витрины данных. Загрузка в модель происходит на ночном регламенте, загружается дневной инкремент данных. Длительность загрузки составляет

2 часа. С этими данными, выполняя Ad-hoc запросы, работают аналитики через Hue и IPython.

Источник

Что такое озера данных и почему в них дешевле хранить big data

Сейчас все вокруг твердят про пользу big data. В итоге бизнес пытается работать с масштабными базами данных, но сталкивается с проблемой — все данные разнородные и неструктурированные, перед загрузкой в базы их нужно долго обрабатывать. В итоге работа с big data оказывается слишком сложной и дорогой, а часть данных теряется, хотя могла бы принести пользу в будущем.

Помочь с этим могут data lake — озера данных, которые помогают быстро и недорого работать с большими объемами неструктурированных данных. Расскажем о их особенностях, ключевых отличиях озер от обычных баз данных и о сферах, в которых они будут наиболее полезны.

Что такое data lake

На русский язык data lake переводится как «озеро данных». Оно представляет собой огромное хранилище, в котором разные данные хранятся в «сыром», то есть неупорядоченном и необработанном виде. Данные в data lake как рыба в озере, которая попала туда из реки, — вы точно не знаете, какая именно там рыба и где она находится. А чтобы «приготовить» рыбу, то есть обработать данные, ее нужно еще поймать.

Мы в своей жизни чаще всего сталкиваемся именно с неструктурированными данными. Видеоролики, книги, журналы, документы Word и PDF, аудиозаписи и фотографии — все это неструктурированные данные, и все они могут хранится в Data Lake.

Как работает озеро данных

Data lake — это огромное хранилище, которое принимает любые файлы всех форматов. Источник данных тоже не имеет никакого значения. Озеро данных может принимать данные из CRM- или ERP-систем, продуктовых каталогов, банковских программ, датчиков или умных устройств — любых систем, которые использует бизнес.

Уже потом, когда данные сохранены, с ними можно работать — извлекать по определенному шаблону в классические базы данных или анализировать и обрабатывать прямо внутри data lake.

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

Еще одним примером инструмента обработки данных в data lake являются BI-системы, помогающие бизнесу решать задачи углубленной аналитики (data mining), прогнозного моделирования, а также визуализировать полученные результаты. Область использования многогранна — от финансового менеджмента до управления рисками и маркетинга.

Чем озера данных отличаются от обычных баз данных

Ключевое отличие озер данных от обычных баз данных — структура. В базах данных хранятся только четко структурированные данные, а в озерах — неструктурированные, никак не систематизированные и неупорядоченные.

Пример: представим, что есть вольное художественное описание вашей целевой аудитории: «Девушки возрастом 20–30 лет, незамужние, обычно без детей, работающие на низких руководящих должностях. И мужчины 18–25 лет, женатые, без детей, без четкого места работы». Такое описание — неструктурированные данные, которые можно загрузить в data lake.

Чтобы эти данные о целевой аудитории стали структурированными, их нужно обработать и преобразовать в таблицу:

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

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

Есть и другие различия между базами данных и озерами данных:

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

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

Типы данных. В базах хранятся таблицы с конкретными цифрами и текстом, распределенными по четкой структуре.

В озерах лежат любые данные: картинки, видео, звук, файлы, документы, разнородные таблицы.

Гибкость. У базы данных гибкость низкая — еще на старте нужно определить актуальные для нее типы данных и структуру. Если появятся данные новых форматов — базу придется перестраивать.

У озер гибкость максимальная, потому что ничего не нужно определять заранее. Если вы вдруг решите записывать новые данные, например, видео с камер для распознавания лиц, озеро не придется перестраивать.

Стоимость. Базы данных стоят дороже, особенно если требуется хранить много данных. Нужно организовывать сложную инфраструктуру и фильтрацию, все это требует денег.

Озеро данных стоит намного дешевле — вы платите исключительно за занятые гигабайты.

Понятность и доступность данных. Данные в базе легко смогут прочитать и понять любые сотрудники компании, с ними могут работать бизнес-аналитики.

Чтобы структурировать данные в озере требуются технические специалисты, например Data Scientist.

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

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

Кому и зачем нужны озера данных

Озера данных можно использовать в любом бизнесе, который собирает данные. Маркетинг, ритейл, IT, производство, логистика — во всех этих сферах можно собирать big data и загружать их в data lake для дальнейшей работы или анализа.

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

Например, вы используете на производстве сложное оборудование, которое часто ломается. Вы внедряете IoT, интернет вещей — установили датчики для контроля за состоянием оборудования. Данные с этих датчиков можно собирать в Data Lake без фильтрации. Когда данных накопится достаточно, вы сможете их проанализировать и понять, из-за чего случаются поломки и как их предотвратить.

Или можно использовать data lake в маркетинге. Например, в ритейле и e-commerce можно хранить в data lake разрозненную информацию о клиентах: время, проведенное на сайте, активность в группе в соцсетях, тон голоса при звонках менеджеру и регулярность покупок. Потом эту информацию можно использовать для глобальной и масштабной аналитики и прогнозирования поведения клиентов.

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

Исследование ANGLING FOR INSIGHT IN TODAY’S DATA LAKE показывает, что компании, внедрившие Data Lake, на 9% опережают своих конкурентов по выручке. Так что можно сказать, что озера данных нужны компаниям, которые хотят зарабатывать больше, используя для этого анализ собственных данных.

Чем опасны data lake

У озер данных есть одна серьезная проблема. Любые данные, попадающие в data lake, попадают туда практически бесконтрольно. Это значит, что определить их качество невозможно. Если у компании нет четкой модели данных, то есть понимания типов структур данных и методов их обработки, плохо организовано управление озером, в нем быстро накапливаются огромные объемы неконтролируемых данных, чаще всего бесполезных. Уже непонятно, откуда и когда они пришли, насколько релевантны, можно ли их использовать для аналитики.

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

Чтобы озеро не стало болотом, нужно наладить в компании процесс управления данными — data governance. Главная составляющая этого процесса — определение достоверности и качества данных еще до загрузки в data lake. Есть несколько способов это сделать:

Настроить такую фильтрацию проще, чем каждый раз структурировать данные для загрузки в базу данных. Если процесс налажен, в data lake попадут только актуальные данные, а значит, и сама база будет достоверной.

Управление данными — это не факультативная, а приоритетная задача. В компании должен быть отдельный сотрудник, ответственный за data governance. Обычно это Chief Data Officer, CDO.

Источник

Data Lake – от теории к практике. Методы интеграции данных Hadoop и корпоративного DWH

В этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как Hadoop — задача интеграции данных Hadoop и данных корпоративного DWH. В Data Lake в Тинькофф Банке мы научились эффективно решать эту задачу и дальше в статье я расскажу, как мы это сделали.

Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop).

Задача

Лирическое отступление. Выше на рисунке изображено живописное озера, а точнее система озер – одно поменьше, другое побольше. То, что поменьше, красивое такое, облагороженное, с яхтами – это корпоративное DWH. А то, что виднеется на горизонте и не помещается на картинке в силу своих размеров – это Hadoop. Лирическое отступление окончено, к делу.
Задача у нас была достаточно тривиальная с точки зрения требований, и нетривиальная с точки зрения выбора технологии и реализации. Нам надо было прорыть канал между этими двумя озерами, наладить простой и эффективный способ публикации данных из Hadoop в DWH и обратно в рамках регламентных процессов, проистекающих в Data Lake.

Выбор технологии

Далее расскажу про преимущества и недостатки каждого из них.

Sqoop

Sqoop — это средство, предназначенное для передачи данных между кластерами Hadoop и реляционными базами данных. С его помощью можно импортировать данные из системы управления реляционной базой данных (реляционной СУБД), например, SQL Server, MySQL или Oracle, в распределенную файловую систему Hadoop (HDFS), преобразовать данные в системе Hadoop с использованием MapReduce или Hive, а затем экспортировать данные обратно в реляционную СУБД.

Т.к. в задаче изначально не предполагалась трансформация, то вроде бы Sqoop идеально подходит для решения поставленной задачи. Получается, что как только появляется потребность публикации таблицы (или в Hadoop, или в Greenplum), необходимо написать задание (job) на Sqoop и это задание научиться вызывать на одном из планировщиков (SAS или Informatica), в зависимости от регламента.
Всё хорошо, но Sqoop работает с Greenplum через JDBC. Мы столкнулись с крайне низкой производительностью. Тестовая таблица в 30 Gb выгружалась в Greenplum около 1 часа. Результат крайне неудовлетворительный. От Sqoop отказались. Хотя в целом, это очень удобный инструмент для того что бы, например, выгрузить разово в Hadoop, данные какой-либо не очень большой таблицы из реляционной БД. Но, для того что бы строить регламентные процессы на Sqoop, нужно четко понимать требования к производительности работы этих процессов и исходя из этого принимать решение.

Informatica Big Data Edition

Informatica Big Data Edition мы используем как ELT движок обработки данных в Hadoop. Т.е. как раз с помощью Informatica BDE мы строим в Hadoop те витрины, которые нужно опубликовать в Greenplum, где они станут доступны другим прикладным системам банка. Вроде как логично, после того как ELT процессы отработали на кластере Hadoop, построили витрину данных, сделать push этой витрины в Greenplum. Для работы с СУБД Greenplum в Informatica BDE есть PWX for Greenplum, который может работать как в режиме Native, так и в режиме Hive. Т.е., как только появляется потребность публикации таблицы из Hadoop в Greenplum, необходимо написать задание (mapping) на Informatica BDE и это задание вызвать на планировщике Informatica.
Всё хорошо, но есть нюанс. PWX for Greenplum в режиме Native работает как классический ETL, т.е. вычитывает из Hive данные на ETL сервер и уже на ETL сервере поднимает сессию gpload и грузит данные в Greenplum. Получается, что весь поток данных упирается в ETL-сервер.
Далее провели эксперименты в режиме Hive. PWX for Greenplum в режиме Hive работает без участия ETL сервера, ETL сервер только управляет процессом, вся работа с данными происходит на стороне кластера Hadoop (компоненты Informatica BDE устанавливаются так же и на кластер Hadoop). В этом случае сессии gpload поднимаются на узлах кластера Hadoop и грузят данные в Greenplum. Здесь мы не получаем узкое место в виде ETL сервера и производительность работы такого подхода получилась достаточно хорошей — тестовая таблица в 30 Gb выгружалась в Greenplum около 15 минут. Но PWX for Greenplum в режиме Hive работал, на момент проведения исследований, нестабильно. И есть ещё один важный момент. Если требуется сделать обратную публикацию данных (из Greenplum в Hadoop) PWX for Greenplum работает через ODBC.
Для решения задачи было принято решение не использовать Informatica BDE.

SAS Data Integration Studio

SAS Data Integration Studio мы используем как ELT движок обработки данных в Greenplum. Здесь получается другая картина. Informatica BDE строит необходимую витрину в Hadoop, далее SAS DIS делает pull этой витрины в Greenplum. Или иначе, SAS DIS строит какую-либо витрину в Greenplum, далее делает push этой витрины в Hadoop. Вроде бы красиво. Для работы с Hadoop в SAS DIS есть специальные компонент SAS Access Interface to Hadoop. Проводя параллель с PWX for Greenplum, у SAS Access Interface to Hadoop нет режима работы Hive и поэтому все данные польются через ETL сервер. Получили неудовлетворительную производительность работы процессов.

gphdfs

gphdfs – утилита, входящая в состав СУБД Greenplum, позволяющая организовать параллельный транспорт данных между сегмент серверами Greenplum и узлами с данными Hadoop. Провели эксперименты с публикацией данных и из Hadoop в Greenplum, и обратно – производительность работы процессов просто поразила. Тестовая таблица в 30 Gb выгружалась в Greenplum около 2 минут.

Анализ полученных результатов

Для наглядности в таблице ниже приведены результаты исследований.

Вывод получился двусмысленный — с наименьшими проблемами в производительности работы процессов, мы получаем утилиту, которую совершенно неприемлемо использовать в разработке ETL процессов как есть. Мы задумались… ELT платформа SAS Data Integration Studio позволяет разрабатывать на ней свои компоненты (трансформы) и мы решили, для того что бы снизить трудоемкость разработки ETL процессов и снизить сложность интеграции в регламентные процессы, разработать два трансформа, которые облегчат работу с gphdfs без потери производительности работы целевых процессов. Далее расскажу о деталях реализации.

Реализация трансформов

У этих двух трансформов достаточно простая задача, выполнить последовательно набор операций вокруг Hive и gphdfs.
Пример (дизайн) трансформа для публикации данных из Hadoop в Greenplum.

Разработчику остается добавить этот трансформ в job (задание) и указать названия входной и выходной таблиц.
Разработка такого процесса занимает около 15 минут.

По аналогии был реализован трансформ для публикации данных из Greenplum в Hadoop.

ВАЖНО. Ещё один из бенефитов который мы получили решив эту задачу, мы потенциально готовы организовывать процесс offload-а данных из корпоративного DWH в более дешевый Hadoop.

Источник