Проектирование и разработка хранилищ данных DWH
Содержание
Многие начинающие специалисты не совсем понимают, зачем нужен DWH, если имеется стандартная СУБД. На самом деле, DWH является достаточно важным компонентом любой БД и нормальная работа компании без него невозможна, поскольку нельзя будет провести глубокий бизнес-анализ без остановки основной базы. В этом материале мы подробнее поговорим о DWH и рассмотрим особенности разработки подобных хранилищ.
DWH (или Data Warehouse) представляет собой своеобразный склад с данными, собранными за всё время функционирования компании. Здесь могут храниться самые разные данные: от координат и телефонов клиентов до отчётов по выручке за все месяцы. Несмотря на то, что DWH по сути своей является той же базой данных, от «рабочей» БД она отличается достаточно сильно. Некоторые не могут понять разницу, однако она довольно существенна.
В чём разница между DWH и основной БД
Начнём с того, что у каждого отдела в компании есть своя база данных: у маркетологов, отдела кадров и так далее. А вот в DWH можно найти сведения, касающиеся любого отдела. Как правило, DWH и «боевая» базы различаются по структуре, ведь первая хранит в себе вообще все сведения, а вторая предназначена для конкретных задач. Однако стоит рассмотреть основные различия подробнее:
Обычные базы содержат в себе только сведения, предназначенные для конкретных подсистем. DWH же хранит сведения, которые могут относиться к совершенно разным подсистемам. Именно поэтому DataWarehouse по размеру обычно гораздо больше обычных рабочих баз.
В рабочей БД содержится только та информация, которая является актуальной. А в DWH можно найти сведения за несколько десятков лет (если, конечно, компания соответствует подобному возрасту) – сюда пишутся не столько копии актуальных состояний, сколько исторические данные и агрегированные значения.
Изначально вся информация попадает в рабочие базы данных и только потом, по истечении определённого промежутка времени потихоньку начинает переноситься в DWH. Причём перенос всегда осуществляется вручную – специализированного софта для автоматизации процесса нет.
Что даёт DWH компании
Стоит заметить, что подобная база данных является необходимой для компании любого размера. Ведь сохранённые в ней сведения используются для бизнес-аналитики – процесса анализа данных и получения определённой информации, на основе которой руководство будет принимать необходимые решения для улучшения состояния фирмы. Занимается анализом компетентный специалист (состоящий в штате компании или приглашённый со стороны).
Конечно, аналитики могли бы получить необходимые сведения из рабочей базы и не нужно было бы тратить ресурсы на поддержку своеобразного «склада». Но так делать ни в коем случае нельзя. Дело в том, что обычно для анализа требуется достаточно много информации. И если рабочая БД будет выполнять запрос аналитика, другие аспекты её работы просто будут парализованы. В итоге, компания потеряет время и деньги.
К тому же, если компания большая, то у каждого отдела будет своя БД и для каждой из них потребуется запрашивать доступ, отдельно запрашивать пароли. При таком раскладе на получение необходимой информации могут уйти месяцы. А в DWH вся нужная информация будет под рукой – останется только её извлечь и проанализировать. К тому же, скорость чтения в таких базах существенно выше, чем в рабочих.
По сути, без DHW и нормального анализа управление бизнесом невозможно, так как руководитель не сможет проанализировать ошибки прошлого для того, чтобы избежать их в будущем. Шансов на успех в таком случае крайне мало.
Архитектура DWH
Каждое хранилище данных, созданное по любому из методов, обязательно включает в себя несколько ключевых компонентов:
Ядро. Это основная составляющая любого хранилища данных, обеспечивающая целостность поступающей информации. Она организует данные в соответствии с заданными параметрами.
Зона сбора данных. Этот компонент отвечает за сбор всей входящей информации из различных источников.
Аналитическая часть. Её функция — предоставление отчетности по запросу владельца.
Сервис. Этот компонент ответственен за управление и надежное взаимодействие с тремя предыдущими. Он осуществляет постоянный мониторинг состояния каждого компонента в режиме реального времени и оперативно устраняет возможные ошибки.
Методы создания 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
Anchor Model и Data Vault – это диаметрально противоположные гибкие методологии проектирования DWH, которые в последнее время набирают популярность среди специалистов. У каждого из методов есть свои приверженцы, которые искренне считают, что тот вариант, который они используют лучше. Погружаться в дебри проектирования DWH с использованием данных методов не стоит, но рассказать об основных особенностях можно.
Особенности создания DWH с помощью Anchor Model
Anchor Model (якорная модель) — это методология проектирования хранилищ данных (DWH), разработанная Ларсом Рейманом и Хансом Ёрнерем. Она предоставляет подход к созданию гибкой и расширяемой структуры DWH, который позволяет эффективно управлять изменениями в бизнес-процессах и требованиях к данным. Вот некоторые особенности создания DWH с использованием Anchor Model:
Идентификация якорей (anchors). Якоря представляют собой ключевые понятия в бизнес-процессах организации. Это сущности, которые имеют устойчивое значение и прямое отражение в данных (например, клиенты, продукты, заказы и так далее). Определение якорей является одним из первоочередных шагов.
Определение контекста. Каждый якорь должен иметь контекст, который описывает его свойства и отношения с другими якорями. Например, у клиента могут быть свойства как имя, контактная информация, и прочее.
Введение промежуточного слоя. В Anchor Model предусмотрен промежуточный слой, который позволяет организовать более сложные связи и агрегации данных.
Итеративный процесс. Разработка DWH на основе Anchor Model часто включает в себя итерации, поскольку бизнес-требования могут меняться, и модель должна быть гибкой и адаптированной к этим изменениям.
Документация. Создание документации для модели — важный аспект. Это позволяет команде легче понимать и поддерживать структуру данных.
Особенности создания DWH в Data Vault
Data Vault — это методология построения хранилища данных (DWH), разработанная Дэном Линстедом (Dan Linstedt). Она предоставляет гибкую и масштабируемую архитектуру для хранения и управления данными. Особенности создания БД в этом случае:
Разделение данных на три слоя. Data Vault предполагает обязательное наличие трёх слоёв: Hubs (хабы, ядра) — содержат уникальные наборы данных (бизнес-ключи, например, клиенты, продукты), Links (связи) — описывают отношения между ядрами(позволяют устанавливать связи между бизнес-ключами из разных ядер, например, заказы, которые связывают клиентов с продуктами), Satellites (сателлиты, спутники) — содержат атрибуты с подробной информацией о бизнес-ключах во времени (например, изменения в атрибутах клиента со временем).
Модель не описывает бизнес-правила. Данная методология сфокусирована на хранении и управлении данными, а не на описании бизнес-правил. Это делает еёболее гибкой и способной адаптироваться к изменяющимся требованиям.
Отслеживание изменений и история данных. Data Vault поддерживает хранение истории изменений, что позволяет анализировать данные на разных временных отрезках.
Гибкость и масштабируемость. Модель позволяет легко добавлять новые источники данных, расширять модель и адаптироваться к изменяющимся бизнес-потребностям.
Распределённое хранение данных. Data Vault обычно использует распределённое хранение данных, что обеспечивает высокую доступность и отказоустойчивость.
Инкрементальная загрузка данных. Загрузка данных в случае использования данной методологии часто происходит инкрементально, что позволяет минимизировать воздействие на операционные системы и обеспечивает более быстрое обновление данных.
Метаданные и управление метаданными. Data Vault требует наличия хорошо организованных метаданных для эффективного управления DWH и обеспечения его поддержки.
Выводы
Хранилище DWH является крайне желательным (или даже обязательным) практически для любой компании, поскольку с его помощью компетентные специалисты проводят аналитику бизнес-процессов. На основе полученных аналитиком данных, руководитель принимает решения, призванные оптимизировать работу компании. К тому же, из DWHможно достать любую информацию в том случае, если основные базы отказали.
Для проектирования DWH компетентными специалистами могут быть использованы несколько методик, но наиболее популярной является 7D, позволяющая создать DWHпрактически без использования «рабочих» баз. К тому же, подобная концепция существенно облегчает процесс администрирования БД. Однако крайне важно не забывать создавать резервные копии данных, чтобы можно было легко восстановить информацию в случае какого-нибудь форс-мажора.
Читайте также
Большие данные — Big Data в...
Big data — большие данные в...
Нормализация базы данных SQL
Остались вопросы?
Оставьте контактные данные и мы свяжемся с вами в ближайшее время
8 (499) 288-83-57
Москва