Dwh что это за программа

Содержание

Как проходит интервью системных аналитиков DWH в Тинькофф

Привет! Я Мария Фоменко, заместитель руководителя управления хранилищ данных и отчетности в Тинькофф. Расскажу о направлении DWH и о том, как попасть к нам в команду, что спрашивают на скрининге HR и на секциях системного анализа DWH.

Статья будет полезна тем, кто планирует расти в профессии, интересуется работой в большой компании или хочет работать именно в Тинькофф. Если узнали себя в любом из пунктов, добро пожаловать под кат 😊

Data Warehouse в Тинькофф

Наша команда занимается данными в компании. Наша миссия — распространять data-driven подход в компании, создавать единую платформу и пространство работы с данными.

Команда DWH делится на два блока:

Технический или core-блок создает платформу данных как продукт. Ключевая задача специалистов этого блока — создавать и развивать инфраструктуру нашей платформы.

Мы пишем собственные инструменты загрузки и преобразования данных и внедряем лучшие из существующих на рынке. Развиваем методологии работы с данными и их визуализации. Делимся best practice с компанией, предоставляем self-service для 3000+ пользователей платформы.

Команда состоит из разработчиков, SRE-инженеров, продакт-менеджеров и архитекторов. Мы любим open source, многое пишем с нуля на Java, Python, Scala и Golang

Бизнес-блок с помощью платформы данных, разработанной core-специалистами, предоставляет data as a product для всех бизнес-направлений Тинькофф.

Бизнес-блок состоит из команд, каждая из которых закреплена за какой-то бизнес-линией Тинькофф. Команды строят аналитическую модель данных, создают ключевую управленческую и операционную отчетность для своего направления, занимаются data governance и решают вопросы качества данных.

Команда состоит из системных аналитиков DWH, разработчиков ETL, data-инженеров, QA-инженеров, бизнес-аналитиков BI

Несмотря на то что большая команда DWH разделена на микрокоманды по задачам, у всех общий фокус на результат. При этом у каждой специализации есть не только свои стандарты, но и общие гайды и матрицы развития, все команды действуют в едином пространстве и на единой платформе.

Системные аналитики DWH входят в бизнес-блок и занимаются исследованием источников, проработкой требований заказчика, проектированием модели данных, составлением ТЗ для разработчиков, развитием data governance и разработкой data quality правил.

Этапы отбора

В Тинькофф отбор проходит в три этапа: HR-скрининг, техническое интервью из двух частей и финальное интервью. Вот как они выглядят в таблице:

Этап

Секция

Время

2. Техническое интервью

Секция SQL + логика

Секция системный анализ DWH

3. Финальное интервью

Знакомство с командой

Первый этап — интервью с рекрутером по телефону. Он спрашивает об опыте, мотивации, желаемом уровне дохода, ожиданиях, технических интересах. Уточняет опыт работы с СУБД, какие задачи с данными приходилось решать, какие с ними были сложности. Интересуется планами на ближайшее время: с чем хочется поработать, что нравится в работе.

Второй этап — техническое интервью. Состоит из двух секций: по SQL и логике и секции системного анализа DWH. На них проверяют базовые знания и уровень погружения в область хранилищ данных. Тех, кто успешно прошел первые два шага, приглашают на финальное интервью с командой.

Третий этап — финальное интервью. Там кандидаты знакомятся с командами, обсуждают особенности проекта и конкретные задачи, над которыми предстоит работать в первое время.

Техническое интервью — секция SQL + логика

На этом этапе проверяются знания и навыки по работе с данными. DWH — это петабайты данных, тысячи пользователей и сотни тысяч аналитических запросов в день. Нам важно знать, на каком уровне человек умеет работать с данными, какие конструкции приходилось писать, есть ли опыт оптимизации запросов.

Задача секции SQL — узнать уровень владения SQL, понять, что человек мыслит данными. Сложность задач, которые будут на собеседовании, определяются уровнем знаний системного аналитика. Начальный уровень он определяет самостоятельно, а потом подтверждает знание обязательных конструкций для этого и следующих уровней.

На уровне Junior собеседование всегда начинается с задач уровня Junior, а вот на уровнях Middle или Senior — с уровня Middle и продолжается по ситуации: вверх или вниз.

Часть секции отведена логическим задачам, по ходу которых отмечается, как системный аналитик раскручивает алгоритм решения, его аналитические способности.

Техническое интервью — секция системный анализ DWH

Цель этой секции — проверить на реальном кейсе навыки общения с бизнес-заказчиками: может ли системный аналитик переложить бизнес-процесс на сущности хранилища.

Решение задач проходит в формате диалога. Есть несколько сценариев, с которыми работаем на собеседовании: если у кандидата был опыт работы с DWH, то идут вопросы по платформе, а потом задачи. Если опыта нет — только задачи. В секцию входят вопросы про опыт работы с хранилищами данных, основные понятия, с какими подходами и методологиями приходилось сталкиваться.

Тайминг: сколько времени идет каждый этап

Первичный телефонный разговор длится 20–30 минут. Если все пройдет хорошо, то рекрутер согласует дату и время для технического интервью.

Техническое интервью разбито по двум разным дням и занимают около 90 минут каждое. На секцию системного анализа DWH проходят те, кто успешно справился с секцией по логике и SQL. После секций рекрутер собирает информацию по результатам технического интервью и направляет их заинтересованным командам. У них есть день, чтобы дать обратную связь, но на практике они отвечают в течение пары часов. Заинтересованные команды практически сразу присылают отклики. Тогда рекрутер возвращается к системному аналитику и зовет его на следующий этап — итоговое интервью. Это уже не собеседование, а знакомство с командами. После созвона рекрутер попросит назвать, какой проект понравился больше всего, а через день возвращается с финальным решением. Если аналитику подходят задачи и нравится команда, он получает оффер. Обычно процесс его согласования длится 1–2 дня.

Как быстрее получить оффер

Компании, для отбора в которые нужно пройти несколько этапов интервью, все чаще проводят One Day Offer — формат, когда на все эти этапы отводится один день. Для компании это возможность быстро нанять специалистов, а для кандидата — получить оффер. За один день можно пообщаться с командой, узнать о проектах, пройти технические секции и принять оффер, если работа подойдет по условиям, а задачи — по скиллам.

В декабре Тинькофф проводит первый One Day Offer для системных аналитиков DWH. Если любите данные и вам интересен такой формат, присоединяйтесь.

Источник

Что такое DWH

Стойкая потребность в корпоративных хранилищах данных появилась еще в 90-х годах 20-го столетия. В этот период в бизнес-среде активно стали применяться информационные системы. Они применялись компаниями для контроля многих показателей эффективности работы, обеспечивая возможность мгновенно реагировать на их изменения. Каждое из приложений локально автоматизировало процесс производства или продажи товара, выполнение бухгалтерских расчетов, проведение банковских операций, позволяло составлять аналитику. Основные сложности на этом этапе состояли в разных рабочих схемах различных систем, что приводило к расхождению информации. Не было возможности получать консолидированные данные, позволяющие создать полноценную картину из отдельных прикладных систем.

Решить данную проблему призвано корпоративное хранилище данных – Data Warehouse, или DWH. Это предметно-ориентированная база данных, позволяющая автоматически готовить консолидированные отчеты и выполнять интеграцию бизнес-анализа. Благодаря ей пользователь получает возможность своевременно принимать правильные решения по управлению на основе целостной информационной картины. Так в чем отличие DWH от обычных баз данных? Почему она настолько привлекает внимание бизнес-аналитиков? Нужна ли она вашей компании? Постараемся найти ответы на эти вопросы.

Отличия DWH от других баз данных

Data Warehouse – это хранилище данных, которые нужны вашей компании для принятия решений. От обычных баз они отличаются:

То есть ответ запрос: DWH что это прост – это отдельная от оперативной системы база для хранения архивной информации от разных источников. Она работает совместно с процессами извлечения, загрузки или преобразования корпоративных данных (ETL). В результате получается единая система для хранения корпоративных сведений и работы с ними.

Зачем нужен DWH нужен бизнесу?

DWH хранилище – обязательный спутник любой бизнес-аналитики (BI, Business Intelligence). Оно принимает непосредственное участие в анализе данных и позволяет получать информацию, которая потребуется персоналу или руководителю при принятии соответствующих решений. На примере это выглядит так:

Если не использовать Data Warehouse, причину падения прибыли пришлось бы искать наугад, каждый раз проверяя теорию на практике до тех пор, пока не будет выявлена проблема. А это все заняло бы очень много времени. Ненамного быстрее была бы и работа с классическими базами данных. Маркетологу пришлось бы заходить в разные хранилища, пытаясь отыскать в них нужную информацию, сопоставлять ее.

Но это не единственные преимущества применения DWH. Единое хранилище данных обеспечивает:

На основе Data Warehous создаются и индивидуальные решения под большие объемы данных. Многие разработчики создают персональные коробочные и облачные проекты специально под такие задачи.

Структура DWH

Хранилище данных – это сложная технология с непростой архитектурой, состоящая из нескольких уровней:

Разработкой DWH должны заниматься опытные люди. Те, кто обладает глубокими профессиональными знаниями в данной области. Только так можно будет получить продукт, простой и эффективный в использовании.

Эффективность DWH в бизнес-аналитике

Современная бизнес-аналитика в комплексе с единым хранилищем данных открывает новые возможности для управления бизнесом. Специалисты получили уникальные ресурсы для построения теории и проведения экспериментов, подтверждающих или опровергающие ее, оперируя огромным количеством реальных показателей. В итоге в работу запускается не теоретическая модель, а реально работающий проект, который гарантированно дает высокий результат.

Правильное управление компанией – это не только повышение прибыли. Оно может быть направлено на расширение производственных мощностей, повышение благосостояния сотрудников, лояльности со стороны клиентов, формирования солидного образа и другие мероприятия, которые в перспективе будут способствовать стабильности бизнеса. И все эти показатели позволяет анализировать комплекс из Business Intelligence и Data Warehous. А что было бы без них? Как правило, это попадание пальцем в небо, тория вероятности, которую можно проверить только на практике. А это трата времени и денег, нанесение ущерба бизнесу.

Более подробные консультации из данной области, нюансах создания продукта высокого качества и техническую поддержку можно получить у специалистов компании Xelent.

Источник

Что такое DWH и почему без них данные компании почти бесполезны

Тем, кто работает в крупном бизнесе, периодически приходится слышать три магические буквы — DWH. Узнав расшифровку этой аббревиатуры — data warehouse, можно догадаться, что это имеет отношение к данным. А вот чем DWH отличается от простых баз данных, почему вокруг них снуют рои бизнес-аналитиков и зачем вашей компании иметь такую штуку — это всё еще непонятно. Разбираемся в статье.

DWH — что это и в чем отличие от баз данных

Data warehouse — склад всех нужных и важных для принятия решений данных компании.

Но есть же всякие базы данных внутри фирмы, разве они не DWH? Например, СУБД с клиентами, складскими запасами или покупками. Где разница между обычной базой данных и DWH?

Короче говоря, DWH — это система данных, отдельная от оперативной системы обработки данных. В корпоративных хранилищах в удобном для анализа виде хранятся архивные данные из разных, иногда очень разнородных источников. Эти данные предварительно обрабатываются и загружаются в хранилище в ходе процессов извлечения, преобразования и загрузки, называемых ETL. Решения ETL и DWH — это (упрощенно) одна система для работы с корпоративной информацией и ее хранения.

Что дают DWH-решения для BI и принятия решений в компании

Понятное дело, что просто так тратить деньги и время на консервирование кучи разных записей, которые и так можно накопать в других базах данных, никто не станет. Ответ заключается в том, что DWH необходима для того, чтобы делать BI — business intelligence.

Что такое BI с DWH? Бизнес-аналитика (BI) — это процесс анализа данных и получения информации, помогающей компаниям принимать решения.

Если бы такого аналитического отчета не было — управленцам пришлось бы искать проблему наугад.

Логичный вопрос: казалось бы, зачем держать для этого всего DWH? Аналитики вполне могут ходить в базы данных разных систем и просто выдергивать оттуда то, что им надо.

Ответ: так, конечно, тоже можно делать. Но — не нужно. И вот почему:

Для работы с большими данными используют различные решения, обрабатывающие информацию из DWH. SAS, VK Cloud Solutions (бывш. MCS) и другие компании предлагают различные варианты коробочных и облачных решений под такие задачи.

Источник

Системный аналитик DWH и его отличия от других подобных профессий

Аналитик DWH — э то специализированный системный аналитик, который выполняет практически те же функции, но с ориентацией на DWH.

DWH — это Data WareHouse, по своей сути это специализированная система управления и обработки данных в бизнес-кругах. Почему именно в бизнесе? Потому что там в базы данных стекается информация различного рода, но не вся она одинаково полезна для бизнес-решений. Поэтому такую информацию делят : в DWH-хранилища отправляют только ту информацию, которая необходима будет компании для принятия важных стратегических бизнес-решений.

DWH и обычные базы данных

Прежде че м объяснить, кто такой аналитик DWH, важно отметить основные отличия между обычными базами данных и DWH.

Итак, эти два вида хранилищ отличаются между собой по следующим пунктам:

Объем сохраняемых данных. Обычные базы данных сохраняют только актуальную информацию касаемо деятельности компании. Поэтому объем сохраняемой информации будет не очень велик, если сравнивать с DWH. Потому что в DWH она нужна для анализа. А чтобы анализ был успешным, нужно сохранять прошлые достижения и показатели компании, чтобы было с чем сравнивать. А это значит, что в DWH могут храниться большие объемы данных, включающие в себя все самое важно е с момента создания компании.

Получается, что DWH не участвует в хранении оперативной информации — в нее попада ю т только уже предварительно проанализированные сведения из разных баз данных для дальнейшей работы с ними.

Нужны ли базы DWH бизнесу?

У вас может сложит ь ся такое впечатление, что DWH — это просто дублирование информации, которая и так есть в других базах данных. Для чего она нужна, если можно извлечь ту же самую информацию из других БД?

DWH дают компаниям следующее:

Быстрый доступ к необходимым данным. Разница в скорости доступа к данным с DWH и без DWH ощущается с ростом компании. Чем крупнее компания, тем медленнее у нее будет доступ к необходимым данным без DWH.

Хранение. В DWH хранится вся важная информация о компании, которая не «затеряется» в тоннах информа ционного мусора.

Устойчивость к отказам. Когда разрабатывают DWH, то их изначально готовят к тому, что в них будет хранит ь ся большое количество сведений и с этим «большим количество м » нужно будет оперативно работать. То есть DWH изначально подготавливают к большим нагрузкам.

Современный большой бизнес строится на аналитике. Бизнес-аналитика невозможна без DWH и специалистов, работающих с такими данными. Поэтому важность DWH для большого бизнеса даже не обсуждается. Однако, чтобы такие базы данных приносили бизнесу эффективность и успех, в компании должен быть «сильный» аналитик DWH.

Аналитик DWH

Аналитик DWH — это специалист, который умело оперирует бизнес-данными и способен на их основе оптимизировать эффективность работы компании. Для этого аналитик DWH должен уметь не только хорошо обрабатывать данные, но и быть экспертом в той области, где функционирует компания, в которой он работает.

Кто такой аналитик DWH

Основная задача аналитика DWH — это работа с уже полученными данными для баз данных типа DWH. Он должен уметь:

собирать, выявлять, извлекать, анализировать и правильно использовать данные для DWH-хранилищ;

выявлять потребности бизнеса в данных, которыми он управляет;

правильно распределять данные в DWH;

подготавливать необходимые отчеты по требованию вышестоящего руководства;

следить за целостностью и сохранностью DWH-баз;

работать со специализированным программным обеспечением и языками программирования для DWH-баз;

визуализировать отчеты для понимания « не профессионалами»;

работать с современными методиками и инструментами для описания бизнес-процессов;

Необходимые навыки и умения аналитика DWH формируются требованиями компании, где он работает. Но в обще м а налитик DWH должен понимать аналитические процессы, уметь работать с базами данных типа DWH и отлично знать сферу деятельности компании, где он трудится.

Заключение

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Обзор гибких методологий проектирования DWH

Разработка хранилища — дело долгое и серьезное.

Многое в жизни проекта зависит от того, насколько хорошо продумана объектная модель и структура базы на старте.

Общепринятым подходом были и остаются различные варианты сочетания схемы “звезда” с третьей нормальной формой. Как правило, по принципу: исходные данные — 3NF, витрины — звезда. Этот подход, проверенный временем и подкрепленный большим количеством исследований — первое (а иногда и единственное), что приходит в голову опытному DWH-шнику при мысли о том, как должно выглядеть аналитическое хранилище.

С другой стороны — бизнесу в целом и требованиям заказчика в частности свойственно быстро меняться, а данным — расти как “вглубь”, так и “вширь”. И вот тут проявляется основной недостаток звезды — ограниченная гибкость.

И если в вашей тихой и уютной жизни DWH-разработчика внезапно:

Что значит «гибкость»

Для начала давайте определимся, какими свойствами должна обладать система, чтобы ее можно было назвать “гибкой”.

Отдельно стоит оговориться, что описываемые свойства должны относиться именно к системе, а не к процессу ее разработки. Поэтому если вы хотели почитать про Agile как методологию разработки, лучше ознакомиться с другими статьями. Например, тут же, на Хабре, есть масса интересных материалов (как обзорных и практических, так и проблемных).

Это не значит, что процесс разработки и структура ХД совсем никак не связаны. В целом разрабатывать по Agile хранилище гибкой архитектуры должно быть существенно легче. Однако на практике чаще встречаются варианты и с разработкой по Agile классического DWH по Кимбаллу и DataVault — по вотэрфолу, чем счастливые совпадения гибкости в двух ее ипостасях на одном проекте.

И так, какими же возможностями должно обладать гибкое хранилище? Тут можно выделить три пункта:

Ниже я рассмотрю две самых популярных для ХД методологии гибкого проектирования — Anchor model и Data Vault. За скобками остаются такие прекрасные приемы, как например EAV, 6NF(в чистом виде) и всё, относящееся к NoSQL решениям — не потому, что они чем-то хуже, и даже не потому, что в этом случае статья грозила бы приобрести объем среднестатистического дисера. Просто всё это относится к решениям несколько другого класса — либо к приемам, которые вы можете применять в специфических случаях, независимо от общей архитектуры вашего проекта (как EAV), либо к глобально другим парадигмам хранения информации (как, например, графовые БД и другие варианты NoSQL).

Проблемы “классического” подхода и их решения в гибких методологиях

1. Жесткая кардинальность связей

В основу такой модели закладывается четкое разделение данных на измерения (Dimension) и факты (Fact). И это, черт побери, логично — ведь анализ данных в подавляющем большинстве случаев сводится именно к анализу определенных численных показателей (фактов) в определенных разрезах (измерениях).

При этом связи между объектами закладываются в виде связей между таблицами по внешнему ключу. Это выглядит вполне естественно, но сразу же приводит к первому ограничению гибкости — жесткому определению кардинальности связей.

Это значит, что на этапе проектирования таблиц вы должны точно определить для каждой пары связанных объектов могут ли они относиться как многие-ко-многим, или только 1-ко-многим, и “в какую сторону”. От этого напрямую зависит в какой из таблиц будет первичный ключ а в какой — внешний. Изменение этого отношения при получении новых требований с большой вероятностью приведет к переработке базы.

Например, проектируя объект “кассовый чек” вы, опираясь на клятвенные заверения отдела продаж, заложили возможность действия одной промо-акции на несколько чековых позиций (но не наоборот):

А через некоторое время, коллеги ввели новую маркетинговую стратегию, в которой на одну и ту же позицию могут действовать несколько промо-акций одновременно. И теперь вам надо доработать таблицы, выделив связь в отдельный объект.

(Все производные объекты, в которых происходит джойн чека на промо, теперь тоже нуждаются в доработке).

Связи в Data Vault и Anchor Model

Избежать такой ситуации оказалось довольно просто: не надо верить отделу продаж для этого достаточно все связи изначально хранить в отдельных таблицах и обрабатывать как многие-ко-многим.

Такой подход был предложен Дэном Линстедтом (Dan Linstedt) как часть парадигмы Data Vault и полностью поддержан Ларсом Рённбэком (Lars Rönnbäck) в Якорной Модели (Anchor Model).

В итоге получаем первую отличительную особенность гибких методологий:

Связи между объектами не хранятся в атрибутах родительских сущностей, а представляют собой отдельный тип объектов.

В Data Vault такие таблицы-связки называются Link, а в Якорной МоделиTie. На первый взгляд они очень похожи, хотя названием их различия не исчерпываются (о чем пойдет разговор ниже). В обеих архитектурах таблицы-связки могут связывать любое количество сущностей (не обязательно 2).

Эта на первый взгляд избыточность дает существенную гибкость при доработках. Такая структура становится толерантной не только к изменению кардинальностей существующих связей, но и к добавлению новых — если теперь у чековой позиции появится ещё и ссылка на пробившего ее кассира, появление такой связки станет просто надстройкой над существующими таблицами без влияния на какие-либо существующие объекты и процессы.

2. Дублирование данных

Вторая проблема, решаемая гибкими архитектурами, менее очевидна и свойственна в первую очередь измерениям типа SCD2 (медленно меняющиеся измерения второго типа), хотя и не только им.

В классическом хранилище измерение обычно представляет собой таблицу, которая содержит суррогатный ключ (в качестве PK) а также набор бизнес-ключей и атрибутов в отдельных колонках.

Если измерение поддерживает версионность, к стандартному набору полей добавляются границы времени действия версии, а на одну строку в источнике появляется несколько версий в хранилище (по одной на каждое изменение версионных атрибутов).

Если измерение содержит хотя бы один часто изменяющийся версионный атрибут, количество версий такого измерения будет внушительным (даже если остальные атрибуты не версионные, или никогда не изменяются), а если таких атрибутов несколько — количество версий может расти в геометрической прогрессии от их количества. Такое измерение может занимать существенный объем дискового пространства, хотя большая часть хранящихся в нем данных — просто дубли значений неизменных атрибутов из других строк.

При этом очень часто применяется ещё и денормализация — часть атрибутов намеренно хранятся в виде значения, а не ссылки на справочник или другое измерение. Такой подход ускоряет доступ к данным, снижая количество джойнов при обращении к измерению.

Как правило, это приводит к тому, что одна и та же информация хранится одновременно в нескольких местах. Например, информация о регионе проживания и принадлежности категории клиента может одновременно храниться в измерениях “Клиент”, и фактах “Покупка”, “Доставка” и “Обращения в колл-центр”, а также в таблице-связке “Клиент — Клиентский менеджер”.

В целом описанное выше относятся и к обычным (не версионным) измерениям, но в версионных могут иметь иной масштаб: появление новой версии объекта (особенно задним числом), приводит не просто к обновлению всех связанных таблиц, а к каскадному появлению новых версий связанных объектов — когда Таблица 1 используется при построении Таблицы 2, а Таблица 2 — при построении Таблицы 3 и т.д. Даже если ни один атрибут Таблицы 1 не участвует в построении Таблицы 3 (а участвуют другие атрибуты Таблицы 2, полученные из иных источников), версионное обновление этой конструкции как минимум приведет к дополнительным накладным расходам, а как максимум — к лишним версиям в Таблице 3, которая тут вообще “не при чем” и далее по цепочке.

3. Нелинейная сложность доработки

При этом каждая новая витрина, строящаяся на основании другой, увеличивает количество мест, в которых данные могут “разойтись” при внесении изменений в ETL. Это, в свою очередь, приводит к возрастанию сложности (и длительности) каждой следующей доработки.

Если вышеописанное касается систем с редко дорабатываемыми ETL-процессами, жить в такой парадигме можно — достаточно просто следить за тем, чтобы новые доработки корректно вносились во все связанные объекты. Если же доработки происходят часто, вероятность случайно “упустить” несколько связей существенно возрастает.

Если вдобавок учесть, что “версионный” ETL существенно сложнее, чем “не версионный”, избежать ошибок при частой доработке всего этого хозяйства становится достаточно сложно.

Хранение объектов и атрибутов в Data Vault и Anchor Model

Необходимо отделить то, что изменяется, от того, что остается неизменным. То есть хранить ключи отдельно от атрибутов.

При этом не стоит путать не версионный атрибут с неизменным: первый не хранит историю своего изменения, но может меняться (например, при исправлении ошибки ввода или получении новых данных) второй — не меняется никогда.

Точки зрения на то, что именно можно считать неизменным в Data Vault и Якорной модели расходятся.

С точки зрения архитектуры Data Vault, неизменным можно считать весь набор ключей — натуральные (ИНН организации, код товара в системе-источнике и т.п) и суррогатные. При этом остальные атрибуты можно разделить по группам по источнику и/или частоте изменений и для каждой группы вести отдельную таблицу с независимым набором версий.

В парадигме же Anchor Model неизменным считается только суррогатный ключ сущности. Всё остальное (включая натуральные ключи) — просто частный случай его атрибутов. При этом все атрибуты по умолчанию независимы друг от друга, поэтому для каждого атрибута должна быть создана отдельная таблица.

В Data Vault таблицы, содержащие ключи сущностей, называются Хабами (Hub). Хабы всегда содержат фиксированный набор полей:

Все остальные атрибуты сущностей хранятся в специальных таблицах, называемых Сателлитами (Satellit). Один хаб может иметь несколько сателлитов, хранящих разные наборы атрибутов.

Распределение атрибутов по сателлитам происходит по принципу совместного изменения — в одном сателлите могут храниться не версионные атрибуты (например, дата рождения и СНИЛС для физ.лица), в другом — редко изменяющиеся версионные (например, фамилия и номер паспорта), в третьем — часто изменяющиеся (например, адрес доставки, категория, дата последнего заказа и.т.п). Версионность при этом ведется на уровне отдельных сателлитов, а не сущности в целом, поэтому распределение атрибутов целесообразно проводить так, чтобы пересечение версий внутри одного сателлита было минимальным (что сокращает общее количество хранимых версий).

Также, для оптимизации процесса загрузки данных, в отдельные сателлиты часто выносятся атрибуты, получаемые из различных источников.

Сателлиты связываются с Хабом по внешнему ключу (что соответствует кардинальности 1-ко-многим). Это значит, что множественные значение атрибутов (например, несколько контактных номеров телефона у одного клиента) поддерживается такой архитектурой “по умолчанию”.

В Якорной модели (Anchor Model) таблицы, хранящие ключи, называются Якорями (Anchor). И хранят они:

Например, если данные об одной и той же сущности могут поступать из разных систем, в каждой из которых используется свой натуральный ключ. В Data Vault это может приводить к достаточно громоздким конструкциям из нескольких хабов (по одному на источник + объединяющая мастер-версия), в Якорной модели же натуральный ключ каждого источника попадает в свой атрибут и может использоваться при загрузке независимо от всех остальных.

Но тут кроется и один коварный момент: если в одной сущности объединяются атрибуты из различных систем, скорее всего существуют некоторые правила “склейки”, по которым система должна понимать, что записи из разных источников соответствуют одному экземпляру сущности.

В Data Vault эти правила скорее всего будут определять формирование “суррогатного хаба” мастер-сущности и никак не влиять на Хабы, хранящие натуральные ключи источников и их исходные атрибуты. Если в какой-то момент правила склейки поменяются (или придет обновление атрибутов, по которым она производится), достаточно будет переформировать суррогатные хабы.

В Якорной модели же такая сущность скорее всего будет храниться в единственном якоре. Это значит, что все атрибуты, независимо от того, из какого источника они получены, будут привязаны к одному и тому же суррогату. Разделить ошибочно слитые записи и в целом отслеживать актуальность склейки в такой системе может оказаться существенно труднее, особенно, если правила достаточно сложные и часто изменяются, а один и тот же атрибут может быть получен из разных источников (хотя точно возможно, т.к. каждая версия атрибута сохраняет ссылку на свой источник).

В любом случае, если в вашей системе предполагается реализация функционала дедубликации, слияния записей и других элементов MDM, стоит особенно внимательно ознакомиться с аспектами хранения натуральных ключей в гибких методологиях. Вероятно, более громоздкая конструкция Data Vault внезапно окажется более безопасной с точки зрения ошибок слияния.

Якорная модель также предусматривает дополнительный тип объекта, называемый Узлом (Knot) по сути это специальный вырожденный вид якоря, который может содержать всего один атрибут. Узлы предполагается использовать для хранения плоских справочников (например пол, семейное положение, категория обслуживания клиентов и т.п). В отличии от Якоря, Узел не имеет связанных таблиц атрибутов, а его единственный атрибут (название) всегда хранится в одной таблице с ключем. Узлы связываются с Якорями таблицами-связями (Tie) также, как якоря друг с другом.

Однозначного мнения по поводу использования Узлов нет. Например, Николай Голов, активно продвигающий применение Якорной модели в России, считает (не безосновательно), что ни для одного справочника нельзя точно утверждать, что он всегда будет статическим и одноуровневым, поэтому для всех объектов лучше сразу использовать полноценный Якорь.

Еще одно важное различие Data Vault и Якорной модели состоит в наличии атрибутов у связей:

В Data Vault Связи являются таким же полноценными объектами, как и Хабы, и могут иметь собственные атрибуты. В Якорной модели Связи используются только для соединения Якорей и собственных атрибутов иметь не могут. Это различие дает существенно разные подходы к моделированию фактов, о чем пойдет речь далее.

Хранение фактов

До этого мы говорили в основном про моделирование измерений. С фактами дело обстоит чуть менее однозначно.

Такой подход выглядит интуитивно понятным. Он дает простой доступ к анализируемым показателям и в целом похож на традиционную таблицу фактов (только показатели хранятся не в самой таблице, а в “соседней”). Но есть и подводные камни: одна из типовых доработок модели — расширение ключа факта — вызывает необходимость добавления в Link нового внешнего ключа. А это в свою очередь “ломает” модульность и потенциально вызывает необходимость доработок других объектов.

В Якорной модели Связь не может иметь собственных атрибутов, поэтому такой подход не прокатит — абсолютно все атрибуты и показатели обязаны иметь привязку к одному конкретному якорю. Вывод из этого простой — для каждого факта тоже нужен свой якорь. Для части того, что мы привыкли воспринимать как факты, это может выглядеть естественно — например, факт покупки прекрасно сводится к объекту “заказ” или “чек”, посещение сайта — к сессии и т.п. Но встречаются и факты, для которых найти такой естественный “объект-носитель” не так просто — например, остатки товаров на складах на начало каждого дня.

Соответственно, проблем с модульностью при расширении ключа факта в Якорной модели не возникает (достаточно просто добавить новую Связь к соответствующему Якорю), но проектирование модели для отображения фактов менее однозначно, могут появляться “искусственные” Якоря, отображающие объектную модель бизнеса не очевидно.

Как достигается гибкость

Получившаяся конструкция в обоих случаях содержит существенно больше таблиц, чем традиционное измерение. Но может занимать существенно меньше дискового пространства при том же наборе версионных атрибутов, что и традиционное измерение. Никакой магии тут, естественно, нет — всё дело в нормализации. Распределяя атрибуты по Сателлитам (в Data Vault) или отдельным таблицам (Anchor Model), мы уменьшаем (или совсем исключаем) дублирование значений одних атрибутов при изменении других.

Для Data Vault выигрыш будет зависеть от распределения атрибутов по Сателлитам, а для Якорной модели — практически прямо пропорционален среднему количеству версий на объект измерения.

Однако выигрыш по занимаемому месту — важное, но не главное преимущество отдельного хранения атрибутов. Вместе с отдельным хранением связей, такой подход делает хранилище модульной конструкцией. Это значит, что добавление как отдельных атрибутов, так и целых новых предметных областей в такой модели выглядит как надстройка над существующим набором объектов без их изменения. И это именно то, что делает описанные методологии гибкими.

Также это напоминает переход от штучного производства к массовому — если в традиционном подходе каждая таблица модели уникальна и требует отдельного внимания, то в гибких методологиях — это уже набор типовых “деталей”. С одной стороны, таблиц становится больше, процессы загрузки и выборки данных должны выглядеть сложнее. С другой — они становятся типовыми. А значит, могут быть автоматизированы и управляться метаданными. Вопрос “как будем укладывать?”, ответ на который мог занимать существенную часть работ по проектированию доработок, теперь просто не стоит (как и вопрос о влиянии изменения модели на работающие процессы).

Это не значит, что аналитики в такой системе совсем не нужны — кто-то все еще должен проработать набор объектов с атрибутами и разобраться откуда и как всё это загружать. Но объем работ, а также вероятность и цена ошибки существенно снижаются. Как на этапе анализа, так и при разработке ETL, которая в существенной части может свестись к редактированию метаданных.

Темная сторона

Всё вышеописанное делает оба подхода действительно гибкими, технологичными и пригодными для итеративной доработки. Разумеется есть и “бочка дегтя”, о которой вы, думаю, уже догадываетесь.

Декомпозиция данных, лежащая в основе модульности гибких архитектур, приводит к увеличению количества таблиц и, соответственно, накладных расходов на джойны при выборке. Для того, чтобы просто получить все атрибуты измерения, в классическом хранилище достаточного одного селекта, а гибкая архитектура потребует целого ряда джойнов. Причем если для отчетов все эти джойны можно написать заранее, то аналитики, привыкшие писать SQL руками, будут страдать вдвойне.

Есть несколько фактов, облегчающих такое положение:

При работе с большими измерениям почти никогда не используются одновременно все его атрибуты. Это значит, что джойнов может быть меньше, чем кажется при первом взгляде на модель. В Data Vault можно также учесть предполагаемую частоту совместного использования при распределении атрибутов по сателлитам. При этом сами Хабы или Якори нужны в первую очередь для генерации и маппинга суррогатов на этапе загрузки и редко используются в запросах (особенно это касается Якорей).

Все джойны — по ключу. Кроме того, более “сжатый” способ хранения данных снижает накладные расходы на сканирование таблиц там, где оно необходимо (например при фильтрации по значению атрибута). Это может приводить к тому, что выборка из нормализованной базы с кучей джойнов будет даже быстрее, чем сканирование одного тяжелого измерения с большим количеством версий на строку.

Например, вот в этой статье есть подробный сравнительный тест производительности Якорной модели с выборкой из одной таблицы.

Многое зависит от движка. У многих современных платформ есть внутренние механизмы оптимизации джойнов. Например, MS SQL и Oracle умеют “пропускать” джойны на таблицы, если их данные не используются нигде, кроме других джойнов и не влияют на финальную выборку (table/join elimination), а MPP Vertica по опыту коллег из Авито, показала себя как прекрасный движок для Якорной модели с учетом некоторой ручной оптимизации плана запроса. С другой стороны, хранить Якорную модель, например, на Click House, имеющем ограниченную поддержку join, пока выглядит не очень хорошей идеей.

Кроме того, для обеих архитектур существуют специальные приемы, облегчающие доступ к данным (как с точки зрения производительности запросов, так и для конечных пользователей). Например, Point-In-Time таблицы в Data Vault или специальные табличные функции в Якорной модели.

Итого

Основная суть рассмотренных гибких архитектур состоит в модульности их “конструкции”.

Именно это свойство позволяет:

Приложения

Типы сущности Data Vault

Типы сущностей Anchor Model

Подробнее про Anchor Model:

Сводная таблица с общими чертами и различиями рассмотренных подходов:

Источник

Операционные системы и программное обеспечение