Ты делаешь Datavault неправильно
часть 1
Модель данных не может существовать в вакууме. Она должна быть основана на структуре бизнеса и опираться на его бизнес-объекты. Прежде чем разрабатывать модель данных требуется смоделировать бизнес. Это базовый принцип, при начале работы с DataVault.
Модель данных должна отражать бизнес-объекты, отражать бизнес-процессы. Если она не соотносится с бизнес-процессами, возникает хаос: аналитикам приходится реализовывать свою логику связи бизнес-объектов, что снижает качество данных и увеличивает время подготовки отчетов.
Хабы должны отражать бизнес-объекты, которые существуют в реальном мире, а не быть техническим абстракциями.
При проектировании модели данных требуется в первую очередь ориентироваться на бизнес-область, а не на сами данные из источника.
Если вы проектируете модель данных не опираясь на бизнес-область, вы делаете Datavault неправильно
Рассмотрим распространенные ошибки и антипаттерны при построении DataVault
Если Hub не отражает какой-либо бизнес-объект — это ошибка! К примеру, Hub — контактные данные клиента. Клиент является бизнес-объектом, а его контактные данные — свойством.
Также в качестве натурального ключа не могут выступать изменяемые ключи. К примеру, ФИО клиента или его номер телефона. Даже ID клиента, который формируется в определенной Системе, не совсем хороший идентификатор, ведь при миграции в другую Систему ID явно изменится, но это сложно решаемая проблема. Главное, чтобы бизнес-ключи не изменялись хотя бы в рамках одной Системы.
Hub — центральный элемент в модели данных DataVault. Hub обязан отражать ключевые бизнес-объекты, вокруг которых совершаются бизнес-процессы.
DataVault основывается на использовании шаблонов и повторяемых паттернов, что делает процесс разработки ETL/ELT процессов легко автоматизируемым.
Ручная разработка ETL/ELT приводит к множеству проблем:
- Повторение кода — одни и те же операции пишутся вручную или копируются
- Несогласованные изменения — изменение в общей логике предобработки данных потребуется переписывания всех ранее созданных ETL/ELT
- Человеческий фактор — человек всегда делает ошибки
А главное — теряется вся ценность от использования DataVault! Ведь вы попросту кратно увеличиваете время на разработку модели данных, нежели бы использовали классическую Звезду/Снежинку.
Ручное написание кода – это антипаттерн!
Идемпотентность (простыми словами) — это когда одна и та же операция запускается несколько раз без изменения результатов после первого запуска. В случае с DWH, это когда запуск одного и того же ETL/ELT подряд (без изменения исходных данных) не приводит к дублированию или к изменению данных в таблицах DataVault.
На самом деле правило применимо не только к DataVault, но и к любой методологии построения модели данных. Но его часто забывают.
Если ваши бизнес-правила не идемпотентны, вы делаете DataVault неправильно
Сателлит — это описание бизнес-объекта (будь то хаб или линк). Свойства бизнес-объектов должны распределяться по разным группам (то есть сателлитам) для уменьшения избыточного дублирования данных при изменении значения в одном столбце, для облечения поиска требуемого свойства аналитику, а также для ускорения отработки SQL-запросов путем сужения таблицы.
Если вы все свойства бизнес-объекта «запихиваете» в сателлит, это ошибка, ведь в первую очередь теряется гибкость, которая является ключевой особенностью DataVault.
Стоит заметить, что и противоположная ситуация, когда создается слишком много сателлитов (чуть ли не каждый отдельный столбец в отдельном сателлите) не эффективна, ведь тем самым вы банально усложняете работу для аналитиков, а главное — большое количество join ведет к значительному «удорожанию» SQL-запросов.
Если вы недостаточно разбиваете бизнес-объекты на саттелиты, вы делаете Datavault неправильно
закажите
демо-версию
datapulse
демо-версию
datapulse
оставьте ваши контакты и наш менеджер свяжется с вами
Закрыть
Получить бесплатный доступ к DataPulse
Наш менеджер свяжется с вами для предоставления бесплатного доступа и презентует наш сервис
