Что такое 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 представляют из себя, ничто иное, как еще один сателлит определенного хаба. Он, как и обычный сателлит содержит бизнес ключ и дату формирования записи в сателлите. На этом, однако, сходства заканчиваются. Дальнейший состав атрибутов такого «специализированного» сателлита определяется бизнес пользователями на основе наиболее востребованных, предварительно рассчитанных показателей.
Например, хаб содержащий информацию о сотруднике, может включать в себя сателлит с такими показателями, как:
ВЫВОДЫ
Как показывает практика использование DATA VAULT бизнес пользователями несколько затруднительно по нескольким причинам:
Материалы статьи основаны:
Витрины данных DATA VAULT
В предыдущих статьях, мы познакомились с основами DATA VAULT, расширением DATA VAULT до более подходящего для анализа состояния и созданием BUSINESS DATA VAULT. Настало время завершать серию третьей статьей.
Как я анонсировал в предыдущей публикации, эта статья будет посвящена теме BI, а точнее подготовке DATA VAULT в качестве источника данных для BI. Рассмотрим, как создать таблицы фактов и измерений и, тем самым, создать схему звезда.
Когда я начал изучать англоязычные материалы по теме создания витрин данных над DATA VAULT у меня возникло ощущение достаточной сложности процесса. Так как статьи имеют внушительный объем, там присутствуют отсылки к изменениям в формулировках, появившихся в методологии Data Vault 2.0, обозначается важность этих формулировок.
Однако, углубившись в перевод, стало понятно, что процесс этот не так уж и сложен. Но, возможно у вас сложится другое мнение.
И так, давайте переходить к сути.
Таблицы измерений и фактов в DATA VAULT
Самое сложная для понимания информация:
На этом теория, в принципе заканчивается.
Но, все же, на мой взгляд, необходимо отметить пару понятий, которые могут встретиться в статьях о методологии DATA VAULT:
Понятие “Information Marts” появилось в методологии Data Vault 2.0, оно заменило старое понятие “Data Marts”. Это изменение обусловлено осознанием задачи по реализации модели данных для построения отчетов как преобразование данных в информацию. Схема “Information Marts”, в первую очередь, должна обеспечивать бизнес пригодной для принятия решений информацией.
Достаточно многословные определения отражают два простых факта:
Создание витрины, хранящей актуальную информацию каждого атрибута нескольких сателлитов, входящего в хаб, например, номер телефона, адрес, ФИО, подразумевает использование PIT таблицы, через обращение к которой легко получить все даты актуальности. Витрины такого типа относят к “Information Marts”.
Оба подхода актуальны как для измерений, так и фактов.
Для создания витрин, хранящих информацию о нескольких линках и хабах может быть задействовано обращение к BRIDGE таблицам.
Этой статьей я завершаю цикл о концепции DATA VAULT, надеюсь информация, которой я поделился будет полезна в реализации ваших проектов.
Как всегда, в завершении, несколько полезных ссылок:
Основы Data Vault
В настоящее время, в сфере анализа данных и BI, уже не возможно не встретить такое понятия как DATA VAULT. Однако, на мой взгляд, есть некоторый недостаток информации по этой теме, особенно в русскоязычном сегменте интернета.
Можно найти интересные статьи о применении DATA VAULT в компаниях, однако основы и методология освещены недостаточно.
В англоязычном сегменте, дела обстоят значительно лучше. Можно купить книги авторов-изобретателей методологии DATA VAULT, но есть и статьи в открытом доступе, которые уделяют внимание именно основам.
Будучи вдохновленным одной из таких статей, я попытаюсь передать базовые вещи методологии DATA VAULT на русском языке.
DATA VAULT – истоки
Основной предпосылкой появление DATA VAULT стала возрастающая изменчивость окружающей среды и необходимость быстро реагировать на эти изменения. Например, появляется новый источник данных с нехарактерной до этого момента грануляцией данных в EDW (Enterprise Data Warehouse). Предполагается, что методология DATA VAULT позволит быстрее добавить данные нового источника. Кроме того, использую DATA VAULT легче построить систему, позволяющую хранить исторические данные.
Анатомия DATA VAULT
Важным отличием DATA VAULT от других подходов к построению хранилищ данных является необходимость загрузки данных в идентичном источнику состоянии. Процесс переноса данных из источников в DATA VAULT не предполагает никаких преобразований и дополнений. Подход DATA VAULT подразумевает возможность сверки с источником. Процесс трансформации данных будет осуществлен позже, при построении витрин данных основанных на DATA VAULT.
Концентраторы (HUBS)
HUB являются ядром DATA VAULT. Сформированные должным образом HUB’ы позволяют объединить различные источники данных в вашем корпоративном хранилище. Важно, чтобы источники были независимы. Исходя из этого, каждый HUB должен иметь свой собственный уникальный бизнес ключ (Business Key), не ассоциированный с иными бизнес объектами.
При формировании записей HUB’а не следует использовать суррогатные ключи, ключи должны быть основаны на идентифицируемом бизнес объекте или бизнес объектах.
Идентифицируемым бизнес объектом может являться колонка или совокупность колонок, с помощью которых бизнес может идентифицировать требуемый объект, например, VIN код автомобиля.
Это важнейший аспект методологии DATA VAULT, построение модели должно базироваться на существующих бизнес процессах и соответственно бизнес терминологии и объектах. Такой подход позволит выстроить необходимое для реализации бизнес целей хранилище, а не просто перенести логику существующих источников.
Структура HUB’а очень простая, он содержит:
Связи (LINKS)
Связи – это основа гибкости и способности к масштабированию моделей DATA VAULT. Связи создаются таким образом, чтобы позволить изменять и расширять модель по прошествии времени, добавлять новые объекты и устанавливать новые связи, не изменяя уже существующих и работающих структур и процессов загрузки данных.
В DATA VAULT связи между всеми элементами реализованы посредством LINK’ов. Важно отметить, что HUB’ы не имеют внешних ключей и для связи между ними следует использовать LINK’и. Функция LINK’а заключается в фиксации связи между элементами данных на самом нижнем уровне грануляции.
Другим примером использования LINK’ов являются транзакции, так как транзакции затрагивают несколько HUB’ов.
LINK является таблицей пересечения бизнес ключей нескольких HUB’ов обеспечивающих связь типа многие ко многим. LINK таблица обеспечивающая связь должна иметь как минимум два родительских HUB’а, в случае представления транзакций LINK содержит несколько HUB’ов.
Также, как и HUB LINK таблица имеет простую структуру:
Сателлиты (SATELLITES)
В этой структуре хранятся все описательные, не используемые в ключах, атрибуты. Важной функцией SATELLITE является поддержание истории изменения данных.
Для достижения этих целей первичный ключ состоит из двух частей:
SATELLITE – единственный элемент имеющих двухкомпонентный ключ.
При необходимости можно добавить источник формирования записи, однако следует отметить, что это не одинаковый с HUB’ом источник, в HUB’ах фиксируется источник первой записи, а в SATELLITE источник каждой записи, который может меняться.
Выводы
Я попытался описать базовые понятия DATA VAULT, его основные элементы, которые в кратце можно охарактеризовать:
HUB — позволяют обеспечить бизнес-ориентированность хранилища и обеспечивают возможность интеграции дополнительных источников данных.
LINK — обеспечивают связь между сущностями.
SATELLITE — хранят характеристики и обеспечивают историческое хранение данных.
Все это в совокупности наделяет DATA VAULT большей чем стандартные подходы к разработке хранилищ данных гибкостью и приспособляемостью, обеспечивает возможностью контроля над данными и их историей, а также позволяет масштабировать хранилище.
Но, как правило DATA VAULT или Raw DATA VAULT, имеет дальнейшее развитие, обусловленное достаточной сложностью аналитических запросов к нему. И следующим этапом эволюции является Business DATA VAULT, здесь уже имеют место дополнительные сущности, такие как: PIT и BRIDGE таблицы. Речь о Business DATA VAULT пойдет в следующих статьях, если эта публикация будет иметь положительный отклик.
Материалы статьи основаны:
Введение в 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 не станут востребованы.
HP Vertica, проектирование хранилища данных, больших данных
О чем статья
Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.
Постановка задачи
10 млн. активных пользователей,
100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты,
10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (
100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.
Выбор методологии
На основании анализа приведенных выше требований методология “Звезда” была отброшена первой. В рамках данной методологии не предусмотрено штатных механизмов для неразрушающего расширения модели. Другими словами, для добавления в модель новых сущностей (новых измерений, новых фактов) необходимо расширение старых таблиц, а значит — модификация ETL процессов.
Таким образом, при каждом расширении существует риск допустить ошибку и нарушить работоспособность старой функциональности.
Кроме того, модель данных “Звезда” испытывает сложности при поддержании историчности данных. Историчность данных измерений реализуема посредством реализации медленно меняющихся измерений типа 2 (slow changing dimension type 2). Однако такой подход приводит к кратному росту количества строк в таблице фактов, а реализовать историчность фактов в данной модели крайне сложно.
Подход Инмона слишком общий, его можно использовать для создания собственной методологии… после того как будут отброшены все существующие, уже готовые и проверенные методологии.
Методология Data Vault выглядела крайне многообещающе в контексте данной задачи. Data Vault не предусматривает разделения таблиц на факты и измерения, в ней допустимо независимое поддержание историчности любых полей данных, за исключением бизнес-ключей. Историчность поддерживается посредством реализации медленно меняющихся измерений типа 2 (slow changing dimension type 2, с двумя датами — from_date, датой начала действия данных и to_date, датой конца действия данных).
Data Vault поддерживает неразрушающий рост модели. Другими словами, при выявлении новых бизнес-сущностей или новых связей между старыми бизнес-сущностями модель хранилища Data Vault может быть расширена без внесения правок в старые таблицы и ETL процессы. Старая логика просто продолжит работать независимо от изменений.
Также Data Vault значительно упрощает распараллеливание ETL процессов за счет полной независимости процессов загрузки Хабов (сущностей) и Сателитов (атрибутов сущностей). Только при загрузке Линков (связей сущностей) возможны зависимости, требующие выполнить одни ETL процессы раньше других.
Все приведенные выше преимущества модели Data Vault актуальны и для Anchor Modeling, поэтому дальнейшие решения принимались на основании нагрузочных экспериментов с промышленными данными в среде СУБД Vertica.
5 млн.
• Забор данных из исходных систем, очистка и обогащение — идентичный для обеих методологий, занимал около 10 минут.
• Добавление данных в узкие таблицы Anchor Modeling запускалось как 20 независимых потоков. Каждый из них запускался одновременно и завершался за время от 40 секунд до 2 минут.
• Добавление данных в единственную широкую таблицу Data Vault занимало от 7 до 9 минут.
• Контрольный запуск добавления данных в широкую таблицу Data Vault, без параллельно работающей вставки в таблицы Anchor Modeling, показал такие-же цифры, от 7 до 9 минут.
Эксперимент показал, что при росте количества уже хранящихся в таблице строк данных до 5 млрд. вставка в модель Data Vault начинает работать в