Проектирование и разработка хранилищ данных DWH

В чём разница между DWH и основной БД

Начнём с того, что у каждого отдела в компании есть своя база данных: у маркетологов, отдела кадров и так далее. А вот в DWH можно найти сведения, касающиеся любого отдела. Как правило, DWH и «боевая» базы различаются по структуре, ведь первая хранит в себе вообще все сведения, а вторая предназначена для конкретных задач. Однако стоит рассмотреть основные различия подробнее:

Что даёт DWH компании

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

Конечно, аналитики могли бы получить необходимые сведения из рабочей базы и не нужно было бы тратить ресурсы на поддержку своеобразного «склада». Но так делать ни в коем случае нельзя. Дело в том, что обычно для анализа требуется достаточно много информации. И если рабочая БД будет выполнять запрос аналитика, другие аспекты её работы просто будут парализованы. В итоге, компания потеряет время и деньги.

К тому же, если компания большая, то у каждого отдела будет своя БД и для каждой из них потребуется запрашивать доступ, отдельно запрашивать пароли. При таком раскладе на получение необходимой информации могут уйти месяцы. А в DWH вся нужная информация будет под рукой – останется только её извлечь и проанализировать. К тому же, скорость чтения в таких базах существенно выше, чем в рабочих.

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

Методы создания DWH

На данный момент существует несколько наиболее часто используемых методик разработки базы DWH. Стоит коротко рассмотреть их:

•  Классический вариант. Основан на методике разделения данных на две основные группы: измерения и факты. Между ними настраивается связь в виде классической таблицы с внешним ключом. Данная метода весьма неплоха, но при её использовании могут возникнуть проблемы с добавлением в таблицу новой информации, поскольку существует жёсткая привязка к внешнему ключу.
•  Метод Инмона. Особенность данного варианта состоит в том, что изначально проектируется центральное хранилище, а уже от него по соответствующим связям создаются витрины, которые и содержат информацию. Недостаток этого способа заключается в том, что время на обработку запроса существенно увеличивается. Но при этом упрощается процесс добавления новых данных.
•  Метод Кимбалла. Здесь наоборот – сначала создаются витрины с информацией и только потом проектируется центральное хранилище. Соответственно, время на обработку запроса уменьшается, но и процесс добавления новых сведений остаётся всё таким же простым. Это один из самых популярных методов.
• Метод 7D. Данный вариант используют чаще всего. Его название образовано от первых букв этапов, входящих в процесс: Discover, Design, Develop, Deploy, Day to day, Defend и Decommission. Этот метод является наиболее продвинутым и современным. Его признают многие специалисты в области проектирования баз данных.

Проектирование DWH с помощью 7D

Стоит рассмотреть процесс проектирования БД c помощью методики 7D подробнее, так как именно она используется в большинстве случаев.

№1. Discover

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

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

№2. Design

Второй этап предназначен для проектирования семантических и схематических реализаций DWH. При этом на данном этапе можно воспользоваться двумя методами проектирования: создавать логические и концептуальные реализации совместно с пространственными моделями в виде многомерных кубов с данными или воспользоваться матрицей принятия решений для выявления чётких требований бизнеса к СХД.

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

На технологическом уровне происходит вычисление пространства, необходимого для БД, а также рассчитываются вычислительные мощности, которые будут необходимы для нормального функционирования DWH. На этом же уровне закладываются расчёты «на вырост»: то есть, специалист планирует возможный рост БД и прогнозирует объём требуемого места на накопителе под такую возможность.

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

№3. Develop

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

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

№4. Deploy

На этом этапе спроектированное хранилище запускается и тестируется его работа. Причём запуск БД осуществляется исключительно в нерабочее время (например, на выходных). Это связано с возможными рисками для работоспособности всей системы (в том числе и «боевой»). Также данная процедура проводится постепенно, а не параллельно. Это потому, что DWH нужно запускать, используя определённый порядок шагов и никак иначе.

Первый шаг включает в себя инсталляцию и настройку аппаратной части БД: то есть, происходит работа над серверами, системами хранения данных, коммутаторами и инженерной частью. На втором шаге разворачивается программное обеспечение на ранее установленном оборудовании (при этом в обязательном порядке производится тестирование). Финальный шаг – установка всех компонентов хранилища данных (инсталлируются сами базы и запускается ETL).

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

№5. Day-to-Day

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

Данная система не только выполняет резервное копирование базы в случае необходимости, но также тестирует скорость восстановления БД из конкретного бэкапа. Для выполнения тестирования предоставляется отдельная виртуальная среда (своеобразная песочница), в которой можно делать практически всё, что требуется. Такое решение позволяет проводить необходимые тесты и при этом не мешать работе основной базы.

№6. Defend

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

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

№7. Decommission

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

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

Anchor Model и Data Vault

Выводы

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

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