Может показаться, что в последние годы многое изменилось в сфере сбора и хранения данных. Такие вещи, как NoSQL, «Big Data», различные графические и потоковые технологии изменили “ландшафт”, но “фундамент” остался прежним.
На моей текущей работе мы используем Amazon Redshift в качестве хранилища данных. Однако, если бы мы построили традиционное хранилище данных, используя Oracle или построили “озеро данных”, используя Hadoop — суть осталась бы прежней.
Вся суть сводится к этапу предварительной обработки и трем отдельным уровням(схемам, если используете Amazon Redshift): Staging, Master и Reporting. В этой статье я подробно о них расскажу.
Предварительная обработка
К сожалению, не все данные создаются в одинаковых условиях, но, тем не менее, это данные, и поэтому они несут в себе ценность.
Чтобы справиться со сложностями при работе с внешними данными, предварительная обработка является почти обязательным условием, особенно при сборе данных из разных источников. Основная цель этапа предварительной обработки — получить данные в совместимом с хранилищем данных формате.
Обработка включает, но не ограничивается этим:
- Конвертирование Excel-таблиц в формат CSV
- Парсинг JSON данных (Мы обрабатываем каждый объект одной строки одного столбца, и позволяем Redshift парсить его. Но ничего не мешает вам самим парсить объекты, если вам это нравится.)
- Очистка поврежденных или ошибочных файлов данных
После того как закончите, вам понадобится место для файлов, откуда потом они будут выгружаться в хранилище данных.
Например, можно поместить все файлы в Amazon S3. Он универсальный, дешевый и совместим со многими технологиями. Amazon S3 отлично совместим с Amazon Redshift.
Staging
“Staging” уровень— это основа для любого хранилища данных.
Хорошее хранилище данных берет данные из разных источников. Каждый источник имеет свои нюансы, стили и соглашения об именовании.
“Staging” уровень— это место, куда вы отправляете файлы из разных источников, например с Amazon S3, и временно храните, пока они не будут обработаны дальше.
Как погрузочная площадка на настоящем складе (хранилище). Место, где выгружают грузы, не является их конечным пунктом назначения. Это просто промежуточная зона.
Данный уровень позволяет вам поместить все данные в пределах хранилища, готовые для дальнейшей обработки и моделирования.
Я считаю, что данные, находящиеся на “Staging” уровне, практически не должны обрабатываться (на стадии предварительной обработки вы можете внести некоторые изменения, но, в целом, данные должны остаться нетронутыми). Можете оставить нетронутыми исходные имена столбцов и таблиц. Это облегчит отслеживание проблем в источнике при поступлении сообщений об ошибке.
Staging уровень нужно рассматривать как промежуточный.
Это последний уровень, на котором данные должны оставаться практически необработанными. Далее, данные должны соответствовать стандартам хранилищ данных.
Master
Уровень “Master” — это место, где входящие данные обретают реальную форму.
Schema master должна содержать правильно смоделированные таблицы с соответствующими им названиями. Названия столбцов должны быть скорректированы в соответствии с их типами данных.
Это позволяет понять, что за таблицы и какие данные в них содержатся, улучшая удобство использования. Напоминает старый способ хранения документов.
При перемещении данных из уровня “Staging” в “Master”, следует выполнить такие вещи, как:
- Стандартизировать все форматы дат и часовых поясов в один формат (если необходимо)
- Округлить десятичные дроби
- Подправить строки, возможно где-то нужно исправить употребление заглавных букв или удалить начальные и конечные пробелы
- Стандартизировать адреса в один формат
- Разделить данные на несколько столбцов или извлечь их из JSON
Также, я бы потратил дополнительное время, чтобы убедиться, что названия столбцов совпадают с названиями присоединившихся столбцов.
Например, у вас есть пользовательские данные, и, возможно, рекламные данные о пользователях из нескольких веб-логов — все они хранятся в MongoDB. Эти источники содержат уникальный идентификатор пользователя. Однако не все могут назвать этот идентификатор одинаково.
Стандартизируя названия столбцов, вам или любому другому пользователю ваших данных, становится очень легко интуитивно понять, какие данные можно объединять, а какие нет.
Для инженера данных это является конечной целью.
У вас есть чистые, соответствующим образом названные, правильно смоделированные данные, готовые для любых исследований или расчетов, которые будут выполняться в дальнейшем.
Reporting
Основная работа выполнена. Мы подготовили, загрузили, смоделировали и очистили данные. Теперь мы хотим показать всему миру наши новенькие блестящие данные. Тут на сцену выходит уровень “Reporting”.
На этом этапе, если вы используете хранилище данных типа “row-based” как в Oracle — можете дополнительно создать таблицу фактов и витрину данных. Это вполне разумный сценарий использования для уровня “Reporting”, так как вы можете прикрепить любой достойный инструмент отчетности и в итоге будете готовы ко всему.
Тем не менее, некоторые из этих традиционных методов хранения данных имеют эффективность только с учетом хранения “row-based” хранилищ в Oracle. Эти системы эффективны при объединении данных, но при строках с множеством столбцов они неэффективны, главным образом из-за “row-based” подхода, при котором мы имеем дело со всей строкой, даже если для запроса требуется всего несколько столбцов.
Если вы используете хранилище данных типа “columnar-based”, как Amazon Redshift — ваш подход должен быть иным. Redshift предпочитает широкие таблицы и денормализацию — композицию нескольких таблиц в одну.
Преимущества моделирования ваших данных при использовании Redshift включают:
- Повышение эффективности, так как Redshift счастлив работать с широкими таблицами
- Простота использования для конечных пользователей и аналитиков, так как им не нужно бороться с соединениями
- Проще сделать запрос, так как все данные, необходимые для запрошенного содержимого, расположены в одном месте
Например, вы хотите составить отчет о своих клиентах. У вас есть таблица клиентов, таблица заказов, маркетинговая таблица и некоторые данные веб-аналитики на уровне “Master”.
В Redshift на уровне “Reporting” вы будете создавать таблицы клиентов. Они будут содержать стандартные данные о клиенте (за исключением их личных данных, так как они не требуются для отчетности), такие как дата регистрации, возможно, почтовый индекс и т.д.
Можете указать, зарегистрировались ли они на мобильном устройстве, или установили приложение для смартфона/десктопа.
В таблице заказов можете указать общее потраченное количество денег на сегодняшний день, дату первого и последнего заказа, количество заказов.
В маркетинговой таблице все то же самое, плюс можете указать такие факты, как число отправленных электронных писем, что пользователь открывал, нажимал и т.д.
Из веб-аналитики вы можете вытащить такую информацию, как: дата последнего посещения веб-сайта, любимое устройство пользователя, наиболее распространенный тип устройства среди пользователей (настольный компьютер, мобильный и т.д.)
Все это выливается в супер широкую таблицу клиентов, где есть все необходимое. Ваши аналитики могут использовать данные из этой таблицы, чтобы рассчитать скорость сбора данных, изменения в использовании устройств среди клиентской базы, кто из клиентов приносит наибольшую прибыль (и какие черты их объединяют), отток клиентов и взаимодействие с клиентами и многое другое.
Все это можно выяснить, использовав один источник. А большая часть тяжелой работы выполнена, благодаря мощности хранилища данных.
Хранилища данных — удовольствия не из дешевых и они предназначены для извлечения данных. Выжмите из хранилища максимум возможного, сделайте как можно больше. Заставьте своих аналитиков составлять отчеты, вместо ожидания, когда Server Reporting Services сделает отчеты за них.
Если вы сделаете хранилище данных быстрым и удобным, не только аналитики захотят использовать его для своей работы.
Итог
Следуя этому простому методу, вы сможете построить полностью функционирующее хранилище данных, которое не только легко расширить, но и понять.
Уровни Staging, Master и Reporting являются логически взаимосвязанными, но в тоже время я предпочитаю держать их физически разделенными, поскольку это не только делает хранилище более чистым, но и позволяет ограничить то, что пользователи могут увидеть из предыдущих уровней.
Перевод статьи Lewis Gavin: How to architect the perfect Data Warehouse
