Data wall что это
Введение в Data Vault
Большинство компаний сегодня накапливают различные данные, полученные в процессе работы. Часто данные приходят из различных источников — структурированные и не очень, иногда в режиме реального времени, а иногда они доступны в строго определенные периоды. Все это разнообразие нужно структурированно хранить, чтоб потом успешно анализировать, рисовать красивые отчеты и вовремя замечать аномалии. Для этих целей проектируется хранилище данных (Data Warehouse, DWH).
Существует несколько подходов к построению такого универсального хранилища, которые помогают архитектору избежать распространенных проблем, а самое главное обеспечить должный уровень гибкости и расширяемости DWH. Об одном из таких подходов я и хочу рассказать.
Кому будет интересна эта статья?
Data Vault состоит из трех основных компонентов — Хаб (Hub), Ссылка (Link) и Сателлит (Satellite).
Хаб — основное представление сущности (Клиент, Продукт, Заказ) с позиции бизнеса. Таблица-Хаб содержит одно или несколько полей, отражающих сущность в понятиях бизнеса. В совокупности эти поля называются «бизнес ключ». Идеальный кандидат на звание бизнес-ключа это ИНН организации или VIN номер автомобиля, а сгенерированный системой ID будет наихудшим вариантом. Бизнес ключ всегда должен быть уникальным и неизменным.
Хаб так же содержит мета-поля load timestamp и record source, в которых хранятся время первоначальной загрузки сущности в хранилище и ее источник (название системы, базы или файла, откуда данные были загружены). В качестве первичного ключа Хаба рекомендуется использовать MD5 или SHA-1 хеш от бизнес ключа.
Ссылка
Таблицы-Ссылки связывают несколько хабов связью многие-ко-многим. Она содержит те же метаданные, что и Хаб. Ссылка может быть связана с другой Ссылкой, но такой подход создает проблемы при загрузке, так что лучше выделить одну из Ссылок в отдельный Хаб.
Сателлит
Все описательные атрибуты Хаба или Ссылки (контекст) помещаются в таблицы-Сателлиты. Помимо контекста Сателлит содержит стандартный набор метаданных (load timestamp и record source) и один и только один ключ «родителя». В Сателлитах можно без проблем хранить историю изменения контекста, каждый раз добавляя новую запись при обновлении контекста в системе-источнике. Для упрощения процесса обновления большого сателлита в таблицу можно добавить поле hash diff: MD5 или SHA-1 хеш от всех его описательных атрибутов. Для Хаба или Ссылки может быть сколь угодно Сателлитов, обычно контекст разбивается по частоте обновления. Контекст из разных систем-источников принято класть в отдельные Сателлиты.
Как с этим работать?
* Картинка основана на иллюстрации из книги Building a Scalable Data Warehouse with Data Vault 2.0
Сначала данные из операционных систем поступают в staging area. Staging area используется как промежуточное звено в процессе загрузки данных. Одна из основных функций Staging зоны это уменьшение нагрузки на операционные базы при выполнении запросов. Таблицы здесь полностью повторяют исходную структуру, но любые ограничения на вставку данных, вроде not null или проверки целостности внешних ключей, должны быть выключены с целью оставить возможность вставить даже поврежденные или неполные данные (особенно это актуально для excel-таблиц и прочих файлов). Дополнительно в stage таблицах содержатся хеши бизнес ключей и информация о времени загрузки и источнике данных.
После этого данные разбиваются на Хабы, Ссылки и Сателлиты и загружаются в Raw Data Vault. В процессе загрузки они никак не агрегируются и не пересчитываются.
Business Vault — опциональная вспомогательная надстройка над Raw Data Vault. Строится по тем же принципам, но содержит переработанные данные: агрегированные результаты, сконвертированные валюты и прочее. Разделение чисто логическое, физически Business Vault находится в одной базе с Raw Data Vault и предназначен в основном для упрощения формирования витрин.
Когда нужные таблицы созданы и заполнены, наступает очередь витрин данных (Data Marts). Каждая витрина это отдельная база данных или схема, предназначенная для решения задач различных пользователей или отделов. В ней может быть специально собранная «звезда» или коллекция денормализованных таблиц. Если возможно, таблицы внутри витрин лучше делать виртуальными, то есть вычисляемыми «на лету». Для этого обычно используются SQL представления (SQL views).
Заполнение Data Vault
Здесь все довольно просто: сначала загружаются Хабы, потом Ссылки и затем Сателлиты. Хабы можно загружать параллельно, так же как и Сателлиты и Ссылки, если конечно не используется связь link-to-link.
Есть вариант и вовсе выключить проверку целостности и загружать все данные одновременно. Как раз такой подход соответствует одному из основных постулатов DV — «Загружать все доступные данные все время (Load all of the data, all of the time)» и именно здесь играют решающую роль бизнес ключи. Суть в том, что возможные проблемы при загрузке данных должны быть минимизированы, а одна из наиболее распространенных проблем это нарушение целостности. Подход, конечно, спорный, но лично я им пользуюсь и нахожу действительно удобным: данные все равно проверяются, но после загрузки. Часто можно столкнуться с проблемой отсутствия записей в нескольких Хабах при загрузке Ссылок и последовательно разбираться, почему тот или иной Хаб не заполнен до конца, перезапуская процесс и изучая новую ошибку. Альтернативный вариант — вывести недостающие данные уже после загрузки и увидеть все проблемы за один раз. Бонусом получаем устойчивость к ошибкам и возможность не следить за порядком загрузки таблиц.
Преимущества и недостатки
[+] Гибкость и расширяемость.
С Data Vault перестает быть проблемой как расширение структуры хранилища, так и добавление и сопоставление данных из новых источников. Максимально полное хранилище «сырых» данных и удобная структура их хранения позволяют нам сформировать витрину под любые требования бизнеса, а существующие решения на рынке СУБД хорошо справляются с огромными объемами информации и быстро выполняют даже очень сложные запросы, что дает возможность виртуализировать большинство витрин.
[+] Agile-подход из коробки.
Моделировать хранилище по методологии Data Vault довольно просто. Новые данные просто «подключаются» к существующей модели, не ломая и не модифицируя существующую структуру. При этом мы будем решать поставленную задачу максимально изолированно, загружая только необходимый минимум, и, вероятно, наша временнáя оценка для такой задачи станет точнее. Планирование спринтов будет проще, а результаты предсказуемы с первой же итерации.
[–] Обилие JOIN’ов
За счет большого количества операций join запросы могут быть медленнее, чем в традиционных хранилищах данных, где таблицы денормализованы.
[–] Сложность.
В описанной выше методологии есть множество важных деталей, разобраться в которых вряд ли получится за пару часов. К этому можно прибавить малое количество информации в интернете и почти полное отсутствие материалов на русском языке (надеюсь это исправить). Как следствие, при внедрении Data Vault возникают проблемы с обучением команды, появляется много вопросов относительно нюансов конкретного бизнеса. К счастью, существуют ресурсы, на которых можно задать эти вопросы. Большой недостаток сложности это обязательное требование к наличию витрин данных, так как сам по себе Data Vault плохо подходит для прямых запросов.
[–] Избыточность.
Довольно спорный недостаток, но я часто вижу вопросы об избыточности, поэтому прокомментирую этот момент со своей точки зрения.
Многим не нравится идея создания прослойки перед витринами данных, особенно если учесть, что таблиц в этой прослойке примерно в 3 раза больше, чем могло бы быть в третьей нормальной форме, а значит в 3 раза больше ETL-процессов. Это так, но и сами ETL процессы будут значительно проще за счет своего однообразия, а все объекты в хранилище достаточно просты для понимания.
Кажущаяся избыточной архитектура построена для решения вполне конкретных задач, и конечно не является серебряной пулей. В любом случае я бы не рекомендовал что-то менять до того момента, пока описанные выше преимущества Data Vault не станут востребованы.
Развитие DATA VAULT и переход к BUSINESS DATA VAULT
Категории
Свежие записи
Наши услуги
В предыдущей статье я рассказал об основах DATA VAULT, описал основные элементы DATA VAULT и их назначение. На этом нельзя считать тему DATA VAULT исчерпанной, необходимо поговорить о следующих ступенях эволюции DATA VAULT.
И в этой статье я сконцентрируюсь на развитии DATA VAULT и переходу к BUSINESS DATA VAULT или просто BUSINESS VAULT.
Причины появления BUSINESS DATA VAULT
Следует отметить, DATA VAULT имея определенные сильные стороны не лишен недостатков. Одним из таких недостатков является сложность в написании аналитических запросов. Запросы имеют значительное количество JOIN’ов, код получается длинным и громоздким. Также данные попадающие в DATA VAULT не подвергаются никаким преобразованиям, поэтому с точки зрения бизнеса DATA VAULT в чистом виде не имеет безусловной ценности.
Именно для устранения этих недостатков методология DATA VAULT была расширена такими элементами как:
Давайте более детально разберем назначение этих элементов.
PIT таблицы
Как правило один бизнес объект (HUB) может иметь в своем составе данные с различной частотой обновления, например, если мы говорим о данных характеризующих человека, мы можем сказать, что информация о номере телефона, адресе или электронной почте имеет более высокую частоту обновления, чем скажем, ФИО, данные паспорта, семейное положение или пол.
Поэтому, при определении сателлитов, следует иметь ввиду частоту их обновления. Почему это важно?
Если в одной таблице хранить атрибуты с различной частотой обновления, придется добавлять строку в таблицу при каждом обновлении самого часто изменяемого атрибута. Как следствия – рост объема дискового пространства, увеличение времени исполнения запросов.
Теперь, когда мы разделили сателлиты по частоте обновления, и можем загружать в них данные независимо, следует обеспечить возможность получения актуальных данных. Лучше, без использования излишних JOIN’ов.
Поясню, например, требуется получить актуальную (по дате последнего обновления) информацию из сателлитов имеющих разную частоту обновления. Для этого потребуется не только сделать JOIN, но и создать несколько вложенных запросов (к каждому сателлиту содержащему информацию) с выбором максимальной даты обновления MAX(Дата обновления). С каждым новым JOIN’ом такой код разрастается, и очень быстро становится сложным для понимания.
PIT таблица призвана упростить такие запросы, PIT таблицы заполняются одновременно с записью новых данных в DATA VAULT. PIT таблица:
Таким образом у нас есть информация об актуальности данных по всем сателлитам на каждый момент времени. Используя JOIN’ы к PIT таблице, мы можем полностью исключить вложенные запросы, естественно с условие, что PIT заполняется каждый день и без пропусков. Даже, если пропуски в PIT имеют место, получить актуальные данные можно лишь используя один вложенный запрос к самому PIT’у. Один вложенный запрос отработает быстрее чем вложенные запросы к каждому сателлиту.
BRIDGE
Таблицы типа BRIDGE также используется для упрощения аналитических запросов. Однако отличием от PIT является средством упрощения и ускорения запросов между различными хабами, линками и их сателлитами.
Таблица содержит все необходимы ключи для всех сателлитов, которые часто используются в запросах. Кроме того, при необходимости хешированные бизнес ключи могут дополняться ключами в текстовом виде, если наименования ключей нужны для анализа.
Дело в том, что без использования BRIDGE, в процессе получения данных находящихся в сателлитах принадлежащим разным хабам, потребуется произвести JOIN не только самих сателлитов, но и линков связывающих хабы.
Наличие или отсутствие BRIDGE определяется конфигурацией хранилища, необходимостью оптимизации скорости исполнения запросов. Универсального пример BRIGE придумать сложно.
PREDEFINED DERIVATIONS
Еще одним типом объектов, который приближает нас к BUSINESS DATA VAULT являются таблицы содержащие предварительно рассчитанные показатели. Такие таблицы действительно важны для бизнеса, они содержат информацию, агрегированную по заданным правилам и позволяют получить к ней доступ относительно просто.
Архитектурно PREDEFINED DERIVATIONS представляют из себя, ничто иное, как еще один сателлит определенного хаба. Он, как и обычный сателлит содержит бизнес ключ и дату формирования записи в сателлите. На этом, однако, сходства заканчиваются. Дальнейший состав атрибутов такого «специализированного» сателлита определяется бизнес пользователями на основе наиболее востребованных, предварительно рассчитанных показателей.
Например, хаб содержащий информацию о сотруднике, может включать в себя сателлит с такими показателями, как:
Логично включать PREDEFINED DERIVATIONS в состав PIT таблицы этого же хаба, тогда можно без труда получить срезы данных по сотрудника на конкретно выбранную дату.
ВЫВОДЫ
Как показывает практика использование DATA VAULT бизнес пользователями несколько затруднительно по нескольким причинам:
Чтобы упростить доступ к данным, DATA VAULT расширяется дополнительными объектами:
В следующей статье я планирую рассказать, на мой взгляд, самое интересное, для тех, кто работает с BI. Я представлю способы создания таблиц – фактов и таблиц – измерений на базе DATA VAULT.
Материалы статьи основаны:
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Data Science ‘по ту сторону изгороди’
Кадр из мультфильма «Over the Garden Wall» (2014)
Большое количество курсов по аналитике данных и питону создает впечатление, что «два месяца курсов, пандас в руках» и ты data science специалист, готовый порвать любую прямоугольную задачу.
Однако, изначально просто счёт относился к computer science, а data science было более широким и междисциплинарным понятием. В классическом понимании data scientist — «T-shape» специалист, который оцифровывает и увязывает административные и предметные вертикали/горизонтали компаний через математические модели.
Далее немного иллюстрирующих примеров.
Задачки
Упомянем большую часть используемых ниже библиотек.
Формирование иерархического списка работ
Задачка является классической в тематике управления проектами. Есть записи по выполненным работам в виде
с дополнительным атрибутарным наполнением этих работ. Требуется построить иерархическую схему
WBS (Work breakdown structure). Т.е. создать прямоугольное представление со всеми этапами и подэтапами, как они встречаются в работах и с формированием цифровых иерархических идентификаторов для каждого элемента.
Вариант решения «в лоб»
Классический data.frame / pandas подход, который предлагают в первую очередь, на первый взгляд может показаться логичным и красивым.
Альтернативный вариант
Попробуем посмотреть на задачу иным образом. Один из способов — генерация графа (дерево является частным случаем) и анализ путей по графам для каждого терминального элемента. Можно, но будет не то чтобы просто.
Сшивка цепочек идентификаторов
Требуется «выдернуть» меньший id и к нему присоединить все связанные.
Вариант решения «в лоб»
Какие обычно возникают мысли. Конечно же циклы или рекурсии с джойнами, при этом придется обрабатывать каждую строчку отдельно, поскольку неизвестно отношение между этими друзьями. Все что нам известно — привязываем к минимальному идентификатору (пример задачки — идентификаторы посылок при их консолидации или передаче партнерам).
Код с этими экспериментами приводить не буду — будет много и некрасиво. Важно учесть, что в реальной задаче число таких записей измеряется десятками миллионов.
Альтернативный вариант
Посмотрим на эту задачку с высоты птичьего полета. Что это напоминает? Да это же описание ребер графа!
И тогда задачка сводится к задаче связности, а именно к поиску всех нод, которые связаны с интересующей нас. Имеем одну строчку кода.
Ответ и графическая иллюстрация
Треугольная матрица
Вариант решения «в лоб»
Будем считать функцию только для треугольной матрицу. Сэкономим лишь на времени вычисления, но не на памяти.
Альтернативный вариант
Как это можно сделать? Да очень просто, мы имеем дело с тривиальной арифмитической прогрессией с шагом 1 и начальным значением 1.
Тогда номер индекса (количество ячеек от начала) будет выражаться формулой.
Матрица в альтернативном варианте формируется исключительно для сравнения результатов. Но, если есть немного памяти, то можно задачу упростить еще сильнее. Идея в том, что мы генерируем полное представление индексов для итерирования и потом формуем его под нашу задачу. Получаем линейный массив, который потом хорошо отдается на параллельные вычисления. Фактически, формируем список заданий на вычисление, не обязательно «треугольное», можно и с вычетами.
Манипуляции с прямоугольными представлениями
Очень типичная задача, когда нужно провести некоторые линейные трансформации и с данными. И ведь вроде простая задача, но всегда можно копнуть чуть глубже.
Можно ли это сделать без циклов?
Вариант решения «в лоб»
Если не использовать циклы (сознательно пропустим это упражнение), то руки и память тут же подсовывает итераторы. Круто, но по своей сути это цикл, спущенный на уровень ниже. Способ решения задачи при этом никак не меняется. Манипуляции с памятью остаются в накладных. Кручу-верчу, вектор собрать хочу.
Альтернативный вариант
И вот получается альтернативное решение, если кто знает еще проще — пишите. Конструируем матрицу по горизонтали, собираем урожай по вертикали.
Квадратно-гнездовой метод посадки (аналогия из сельского хозяйства), прямой менеджмент памяти, (пандас, привет!).
Подготовка time-series
Есть time series, содержащий данные сигналов с датчика влажности воздуха (время сигнала и влажность соответственно). Между сигналами в среднем 5 минут. Требуется вставить строки, если между сигналами больше 5 минут, причем строк нужно вставить столько, сколько кратно 5 минутому разрыву (т.е. разрыв в сигналах 16 минут требует вставки 3-х строк). 
Вариант решения «в лоб»
Следующий шаг — затащить артиллерию ML и начать говорить о missing data imputation с применение деревьев или еще чего-нибудь. Круто это все! Но может можно спуститься на землю?
Альтернативный вариант
Какие есть соображения?
Однако, некорректно делать округление времени, ошибки могут оказаться очень значимыми, особенно на производных.
Что делать? Да все давно уже придумано. Можно воспользоваться интерполяцией существующей точки сплайнами (привет, Corel Draw и Adobe Illustrator) по сформированной вручную регулярной сетке. Причем, в зависимости от предметной области, можно делать интерполяцию CDF, а потом считать производную.
В рамках альтернативного пути возникает еще несколько дорожек.
Для очистки регулярного time-series хорошо использовать методы и алгоритмы из цифровой обработки данных (DSP), в частности частотные фильтры с применением преобразования Фурье.
Можно time-series трансформировать так, что частота дискретизации подпадает под 44кГц — для всяких преобразований и фильтраций можно воспользоваться софтом для редактирования аудио (Audacity, например, или же коммерческое ПО). Масса всяких фильтров и трансформаций, как во временнОм представлении, так и в частотном. Визуальное представление результатов операций. Удобно. Популярный time-series по продажам товаров вполне неплохо трансформируются на шкалу 44 кГц.
Если уж идти дальше по такому пути, то и графические редакторы иногда бывают удобны для прототипирования визуализации. Механизм слоев позволяет визуально покрутить различные наложения, особенно в случае сложного пересечения тепловых карт или наложения на геоподложки. Не обязательно все крутить в стеке DS.
Комбинаторные задачки
Рассмотрим на примере школьной задачки, не погружаясь в enterprise пучины.
В заборе 7 досок. Каждую доску надо покрасить в один из 4-х цветов, причём соседние доски должны быть покрашены в разные цвета. Сколькими способами это можно сделать?
Вариант решения «в лоб»
Понятно, что эта задачка на комбинаторику. Но подобные задачки встречаются часто и в программировании. И тут начинаются страшные огороды. Можно использовать метод Монте-Карло для генерации комбинаций и потом попарно сравнивать элементы, с целью исключения запрещенных комбинаций. Семь досок, еще куда ни шло, можно написать все сравнения. 1 и 2, 2 и 3, 3 и 4 и т.д.
В лучшем случае что-то подобное.
Конкретно в этой детской задаче решение выглядит компактным.
Но как поступать, когда этих досок 100+ или вообще неопределенное число?
Начинают предлагать итераторы, анонимные функции, вложенные циклы и т.д.
Тяжко, трудоемко и медленно!
Альтернативный вариант
Механизм перевода в текст и подключения регулярных выражений часто позволяет свернуть страницы мозголомного кода с ошибками свернуть в одну-две строки поиска по регуляркам. Используем модную конструкцию r»(. )
Числовая аннигиляция
Вариант решения «в лоб»
Тут встречаются два варианта.
Первый — цикл в цикле. Два бегущих указателя, начинаем сравнивать каждое с каждым и исключать пары. О скорости и говорить нечего.
Второй — построить матрицу, аналогично матрице расстояний. Для десятка чисел может и ок, но для миллионов — полная тоска.
Альтернативный вариант
Вспомним детскую обучающую игру — взвешивание цифр.
По сути нам надо искать антиподов — одинаковый модуль, разный знак. Вот и будем «развешивать» разнознаковые числа на разные плечи весов. Что это означает в переводе на алгоритм? Считаем расстояние от 0 (ищем антиподов), поглощаем их с помощью суммы по группам удаленности. Всего две строки кода.
Парсинг полуструктурированного csv
Все мечтают получать на вход чистые прямоугольные данные. Но, как правило, приезжает вечно всякая ерунда. И начинаются всякие мучения по парсингу и последующему преобразованию в широкое/длинное представление, группировку/разгруппировку. Разве что данные изолентой не скручивают. Особо досадно бывает, когда данные вроде локально и структурированы, но глобально они свалены в кучу.
Вот типичный пример. Отлично, вроде как csv, только на этапе выгрузки перемешали строки из различных колонок. Никакой парсер съесть это не может.
Вариант решения «в лоб»
Взять Excel и руками привести файл в порядок. Выгрузку изменить нельзя, хорошо, что она есть хоть в таком виде.
Альтернативный вариант
Зададимся рядом вопросов.
Остановились, выдохнули, подумали.
Оказывается задача пустяковая, все решается в несколько строк (а выгрузка там немаленькая и регулярная). И не нужны разрабы, админы, базовики и прочие.
Еще немного задачек
В предыдущих публикациях проскакивали примеры подобного плана, дам просто списком:
Заключение
Примеров можно приводить множество, стоит только немного посмотреть по сторонам. Очень часто оказывается, что наточить пилу и топор куда полезнее и эффективнее, чем безудержно махать, вырабатывая нормочасы.