Mark Madsen, HOW TO BUILD AN ENTERPRISE DATA LAKE: IMPORTANT CONSIDERATIONS BEFORE JUMPING IN http://resources.idgenterprise.com/original/AST-0163853_how-to-build-an-enterprise-data-lake.pdf
Данная статья рассказывает о том, как спроектировать озеро данных.
Озеро данных (data lake) представляет собой единую систему для хранения и обработки всех данных, которые нужны предприятию для анализа и аналитики.
Ключевые принципы озера данных - оно должно быть быстрым, обеспечивать простой механизм для сбора и хранения любой информации, независимо от формата, структуры, скорости поступления и т.д.
Озеро данных должно предоставлять инфраструктуру для хранения такого большое количества данных, какое возможно, поскольку неимение данных тогда, когда они нужны, может дорого обойтись, а сбор данных относительно дешёвая операция.
Озеро данных предоставляет не только хранилище для данных, но также является местом, где можно их обрабатывать.
Озеро данных должно предоставлять возможность как хранить данные в сыром виде (без обработки), если вы не знаете, будет ли кто-нибудь ещё их использовать или предоставляют ли они ценность для кого-нибудь; так и обрабатывать их, если данные будут пере использоваться или использоваться часто разными людьми.
Самым наивным подходом к созданию озера можно назвать сбор и хранение данных в чистом виде на одном из кластеров Hadoop. Помимо того что это решение не является масштабируемым, оно также приводит к тому, что людям приходится делать одну и ту же работу по поиску, анализу и обработке данных каждый раз, когда они хотят ими воспользоваться.
Наивный подход к построению озера также связан с несколькими заблуждениями о данных и о том, как их можно использовать. Данный метод предполагает, что люди обладают навыками поиска и обработки необходимых данных, но это не так для большинства аналитиков. Перед тем как получить данные, люди должны их проанализировать, но в жизни люди хотят быстро получать конкретные данные. Данные не должны храниться всегда одинаково, независимо от структуры и формата, необходимо использовать различные методы для хранения различных типов данных, чтобы осуществлять поиск и каталогизацию.
Озеро данных должно удовлетворять трём главным потребностям: получение данных, обработка данных (управление данными) и предоставление доступа к данным.
Получение данных должно быть разделено с управлением данных. Отделение получения данных от управления данными позволяет получать данные в одно время, а обрабатывать их в другое. Это предполагает также, что вы должны построить подсистему получения данных с неизменяемым хранилищем данных для необработанных данных. При этом вы сохраняете все исходные данные и можете хранить все ваши измененные или полученные данные отдельно. Неизменяемое хранилище данных позволяет записывать данные так быстро, как они поступают.
Доступ к данным должен быть независимым от получения и управления. Некоторые люди хотят получить доступ к необработанным данным, некоторые хотят обработанные структурированные данные, а другие хотят обрабатывать свои собственные данные. Люди не являются единственными потребителями данных - озеро должно поддерживать приложения, которые независимо контролируют обработку данных.
Трехстороннее разделение функций в озере означает, что повторное использование данных может быть осуществлено, когда это действительно требуется. Разделение позволяет получить необработанные данные, которые не были изменены, данные, которые стандартизованы, и данные, которые очищаются и структурируются для конкретного использования.
Есть несколько принципов, которыми нужно руководствоваться при создании озера:
Вот несколько требований к функциональности Data Lake. Озеро данных должно:
Сохранение данных.
Перемещение данных.Озеро данных должно предоставлять интерфейсы для перемещения данных из других систем, перемещения данных в рамках озера или из озера в другие системы.
Доступ к данным.Сервисы для доступа к данным должны обеспечивать внешним приложениям доступ к данным независимо от формата или типа хранения данных.
Фреймворки для обработки. Есть много различных фреймворков для различных типов работ, потому что ни один не решает все проблемы в равной степени. Выбор определяется задачей, которую вы хотите решать. При проектировании важно попытаться сохранить количество фреймворков к минимуму.
Инструменты для управления потоками данных. Озеро данных должно иметь инструменты для потоков данных, чтобы давать необходимый уровень абстракции, который позволял бы разработчиком не заниматься такими вещами, как построение конвейеров данных, а заниматься например написанием логики для потоков данных.
Планирование и управление рабочими процессами. Для координации многочисленных потоков данных и работ, которые могут выполняться в озере, нужно предоставить инструменты для планирования и управления рабочими процессами, которые должны определять приоритеты для различных работ; управлять зависимостями между заданиями; развёртывать процессы; отслеживать неполадки при работе процессов, работ или приложений; запускать восстановление, перезапуск или процедуру очистки после проблем; мониторить рабочие процессы, чтобы узнать, что работает, а что нет, а также узнать, что всё работает должным образом.
Метаданные. Все данные, загруженные в озеро или созданные в пределах озера, должны иметь метаданные, потому что важно знать, откуда и когда пришли данные, формат данных, а также информацию об использовании. Это нужно для эффективного поиска данных, отслеживания изменений, которые были проделаны над ними, отслеживания зависимости в данных и отслеживания использования конфиденциальных данных.
Курирование данных. Данный сервис должен предоставлять интерфейсы и базовые услуги, необходимые для индексирования данных, архивирования устаревших данных и всего того, что называется курированием данных.
Службы платформы. Базовая платформа, на которой построено озеро данных, должна предоставлять необходимые для озера службы. Управление хранением данных, координация процессов, управление ресурсами, шифрование, аутентификация, мониторинг, логирование и безопасность - это службы, которые должны быть предоставлены . Если их нет, то они также должны быть созданы.
Данные в озере хранятся в четырёх областях, это сделано для того, чтобы изолировать друг от друга данные, которые претерпевают различные степени обработки.
Зона сбора сырых данных. В этой зоне данные не претерпевают или претерпевают малые изменения и записываются в исходном формате. Это сделано для быстрого доступа к необработанным данным.
Этот район озера должен быть неизменным; данные поступают как есть, без попыток очистить или стандартизировать их.
Зона управления для обработанных и стандартизированных данных. Некоторые данные более ценные или используются чаще, чем другие данные. В этом случае данные могут быть стандартизированы, обработаны или очищены и сделаны доступными в других зонах озера.
Зона для общих или предназначенных для конкретного использования данных. Когда данные являются общими для большой части организации, они находится в этой части озера. Это небольшая часть из имеющихся данных, использование которых широко распространено.
Данные , которые предназначены для определенной цели, также принадлежит в этой области.
Переходная зона для временных или одноразовых данных. Эта зона может рассматриваться как место, в котором люди могут работать с данными, не затрагивая другие данные. Это может быть загрузка внешнего файла или подготовка данных для модели машинного обучения.
Использование различных зон обеспечивает гибкость. По мере того как использование или ценность конкретных данных увеличиваются, можно затратить ресурсы для того чтобы перевести данные в формат, более подходящий для многоразового использования.
В то же время эта архитектура требует работы для поддержания. Данные не будут сами переходить из одной зоны в другую. Нужны определённые правила для того чтобы определить, когда данные должны быть размещены в различных областях.
Озеро данных представляет собой систему для хранения данных с определённой архитектурой, которая удовлетворяет принципам проектирования, таким как: изоляция изменений, чтобы уменьшить влияние быстро меняющихся компонентов на более стабильные части системы; использование сервисов вместо монолитной архитектуры; а также следует принципу того, что архитектура данных также важна, как и архитектура самой технологии