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 не станут востребованы.
Строим Data Vault на данных TPC-H – Greenplum + dbtVault
Привет! На связи Артемий – энтузиаст в сфере Data Warehousing, Analytics, DataOps.
Уже продолжительное время я занимаюсь моделированием DWH с использованием dbt, и сегодня пришло время познакомить вас с package для построения Data Vault – dbtVault.
Готовим датасет TPC-H
Поднимаем кластер Greenplum в Яндекс.Облаке
Погружаемся в кодогенерацию и макросы dbtVault
Cимулируем инкрементальное наполнение Data Vault
Кодогенерация для Data Vault
Подход к построению Хранилища Данных на основе методолгии Data Vault или гибридных, схожих с ней, обретает новый виток популярности и интереса в последнее время. Это неудивительно – несмотря на сложность и обилие объектов в БД, преимущества и гибкость однозначно перевешивают в долгосрочной перспективе:
Единая логическая модель данных – мыслим бизнес-сущностями, а не системами-источниками
Возможность быстрого, параллельного и инкрементального наполнения Хранилища
Гибкость расширения модели и схемы данных – новые сущности и атрибуты
Хэш-сумма для генерации суррогатных ключей и отслеживания изменений атрибутов
Простая схема Data Vault
И любой, кто когда-либо изучал Data Vault согласится, что обойтись без инструментов кодогенерации будет весьма затруднительно. Инструменты этого класса призваны решить ряд задач:
Генерация кода по шаблонам для десятков и сотен объектов
Построение графа зависимостей (DAG)
Одним из таких инструментов является проект dbtVault, который представляет из себя модуль для dbt.
Готовим исходные данные – TPC-H
Мы будем работать со знаменитым датасетом для сравнения производительности баз данных (benchmarking) TPC-H. Это синтетические данные, описывающие предметную область оптовых поставок-продаж. К тому же, при генерации можно указать scale factor и получить данные в кратном объеме (х10, х100, х1000).
Для тех, кому не терпится приступить к моделированию, я заботливо сгенерировал исходные файлы общим объемом 10Гб и разместил в Yandex Object Storage:
В github gist есть инструкция по генерации файлов самостоятельно: Generate data with DBGen
Готовим кластер Greenplum в Яндекс.Облаке
В целях демонстрации я предлагаю использовать кластер Greenplum в Яндекс.Облаке. Следующей конфигурации будет достаточно для работы с нашим датасетом:
Альтернативно – можно пробовать использовать любую другую СУБД семейства PostgreSQL: Redshift, Vertica, Greenplum. Еще более альтернативно – с минимальными адаптациями код может быть исполнен почти в любой СУБД на ваш выбор. Об этом чуть ниже.
Наполним Greenplum данными
Сначала создадим определения для таблиц:
DDL scripts to create table
Затем наполним таблицы данными. На машине с установленной CLI-утилитой psql загрузим csv-файлы в базу:
Ура! Теперь мы готовы к наполнению Data Vault.
Инициируем проект dbt
1. Склонируйте себе репо с проектом dbt dbtvault_greenplum_demo
2. Настройте подключение к СУБД Greenplum
dbt будет искать файл с описанием подключения (хост/порт/логин/пасс) в директории
Пример содержимого файла profiles.yml :
3. Установите dbt версии 0.19.0
Проект был подготовлен и протестирован именно на этой версии. dbt – это не что иное как python-приложение. Есть множество вариантов установки dbt. Но самый простой вариант – использовать готовый Pipfile в репозитории:
Проверьте корректность установки и подключение к СУБД:
4. Импортируем модуль dbtVault
Здесь начинается особая магия. Для кодогенерации Data Vault нам понадобится зависимость (модуль или package) dbtVault. Оригинальная версия модуля предназначена для работы только с СУБД Snowflake. Но после ряда нехитрых манипуляций модуль готов к работе с Greenplum (PostgreSQL): 47e0261.
Устанавливаемые модули объявляются в файле packages.yml проекта:
Установим модуль командой:
Cимулируем инкрементальную загрузку данных для TPC-H
Одно из ключевых преимуществ Data Vault в быстром инкрементальном наполнении детального слоя данных. Из статического датасета TPC-H мы попытаемся симулировать ежедневные инкрементальные пакеты данных, нарезая исходный набор данных по дням.
Всего в TPC-H имеем 4 атрибута с датами:
В итоге, из 8-ми таблиц исходного TPC-H мы формируем слой Raw Stage состоящий из 3-х таблиц:
raw_inventory – статический датасет складского учета
raw_orders – заказы, которые будем грузить подневно
raw_transactions – транзакции к заказам
Готовим слой Stage
А теперь давайте приступим к подготовке атрибутов, необходимых для наполнения Data Vault.
Хэш-суммы для суррогатных ключей и отслеживания изменений
Константы и метаданные
Для подготовки этого слоя моделей мы воспользуемся макросом dbtvault.stage() :
В рамках самого кода модели мы задаем метаданные и передаем в качестве аргументов в макрос:
Таблица с исходными данными: source_model
В результате, к исходным данным добавляется ряд новых и необходимых атрибутов:
Наполняем Raw Data Vault день за днём
Каждая модель типа hub, link, satellite собирается соответствующим макросом. Пример:
Мы готовы к наполнению нашего детального слоя Data Vault:
Обработан пакет данных за одни сутки 1992-01-08
Сформировано 25 моделей за 19 секунд
Среди них: 7 hubs, 8 links, 11 satellites
Обратите внимание на то, что повторный запуск за те же самые сутки будет выполнен почти мгновенно и вставит 0 записей. Это происхоит потому, что таблицы Data Vault наполняются инкрементально и те записи, которые уже попали в детальный слой, вставлены повторно не будут!
Чтобы загрузить инкремент за следующие сутки, просто поменяйте значение переменной load_date в файле dbt_profiles.yml на следующий день и запустите загрузку повторно:
Дальнейшие шаги
1. Посмотрите историю адаптации исходного проекта для нашего демо на Greenplum – commit history:
2. Изучите документацию проекта, визуальный граф моделей (DAG) в автоматически сгенерированном веб-приложении:
4. Ознакомьтесь с литературой по теме:
5. Приходите на live сессии и вебинары
Я и мои коллеги стремимся делиться своим лучшим опытом и знаниями в рамках занятий на курсах Data Engineer и Analytics Engineer:
Практики от лидеров отрасли в рамках живого общения
Ваучер Яндекс.Облака на все эксперименты и задания
3 вебинара в программе только по теме 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 и переход к 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 бизнес пользователями несколько затруднительно по нескольким причинам:
Материалы статьи основаны: