Проектирование и разработка хранилищ данных DWH
Многие начинающие специалисты не совсем понимают, зачем нужен DWH, если имеется стандартная СУБД. На самом деле, DWH является достаточно важным компонентом любой БД и нормальная работа компании без него невозможна, поскольку нельзя будет провести глубокий бизнес-анализ без остановки основной базы. В этом материале мы подробнее поговорим о DWH и рассмотрим особенности разработки подобных хранилищ.
DWH (или Data Warehouse) представляет собой своеобразный склад с данными, собранными за всё время функционирования компании. Здесь могут храниться самые разные данные: от координат и телефонов клиентов до отчётов по выручке за все месяцы. Несмотря на то, что DWH по сути своей является той же базой данных, от «рабочей» БД она отличается достаточно сильно. Некоторые не могут понять разницу, однако она довольно существенна.
Начнём с того, что у каждого отдела в компании есть своя база данных: у маркетологов, отдела кадров и так далее. А вот в DWH можно найти сведения, касающиеся любого отдела. Как правило, DWH и «боевая» базы различаются по структуре, ведь первая хранит в себе вообще все сведения, а вторая предназначена для конкретных задач. Однако стоит рассмотреть основные различия подробнее:
Обычные базы содержат в себе только сведения, предназначенные для конкретных подсистем. DWH же хранит сведения, которые могут относиться к совершенно разным подсистемам. Именно поэтому DataWarehouse по размеру обычно гораздо больше обычных рабочих баз.
В рабочей БД содержится только та информация, которая является актуальной. А в DWH можно найти сведения за несколько десятков лет (если, конечно, компания соответствует подобному возрасту) – сюда пишутся не столько копии актуальных состояний, сколько исторические данные и агрегированные значения.
Изначально вся информация попадает в рабочие базы данных и только потом, по истечении определённого промежутка времени потихоньку начинает переноситься в DWH. Причём перенос всегда осуществляется вручную – специализированного софта для автоматизации процесса нет.
Стоит заметить, что подобная база данных является необходимой для компании любого размера. Ведь сохранённые в ней сведения используются для бизнес-аналитики – процесса анализа данных и получения определённой информации, на основе которой руководство будет принимать необходимые решения для улучшения состояния фирмы. Занимается анализом компетентный специалист (состоящий в штате компании или приглашённый со стороны).
Конечно, аналитики могли бы получить необходимые сведения из рабочей базы и не нужно было бы тратить ресурсы на поддержку своеобразного «склада». Но так делать ни в коем случае нельзя. Дело в том, что обычно для анализа требуется достаточно много информации. И если рабочая БД будет выполнять запрос аналитика, другие аспекты её работы просто будут парализованы. В итоге, компания потеряет время и деньги.
К тому же, если компания большая, то у каждого отдела будет своя БД и для каждой из них потребуется запрашивать доступ, отдельно запрашивать пароли. При таком раскладе на получение необходимой информации могут уйти месяцы. А в DWH вся нужная информация будет под рукой – останется только её извлечь и проанализировать. К тому же, скорость чтения в таких базах существенно выше, чем в рабочих.
По сути, без DHW и нормального анализа управление бизнесом невозможно, так как руководитель не сможет проанализировать ошибки прошлого для того, чтобы избежать их в будущем. Шансов на успех в таком случае крайне мало.
Каждое хранилище данных, созданное по любому из методов, обязательно включает в себя несколько ключевых компонентов:
Ядро. Это основная составляющая любого хранилища данных, обеспечивающая целостность поступающей информации. Она организует данные в соответствии с заданными параметрами.
Зона сбора данных. Этот компонент отвечает за сбор всей входящей информации из различных источников.
Аналитическая часть. Её функция — предоставление отчетности по запросу владельца.
Сервис. Этот компонент ответственен за управление и надежное взаимодействие с тремя предыдущими. Он осуществляет постоянный мониторинг состояния каждого компонента в режиме реального времени и оперативно устраняет возможные ошибки.
На данный момент существует несколько наиболее часто используемых методик разработки базы DWH. Стоит коротко рассмотреть их:
Стоит рассмотреть процесс проектирования БД c помощью методики 7D подробнее, так как именно она используется в большинстве случаев.
Это начальный этап, который включает в себя в том числе разработку концепции будущей базы. Проджект-менеджер при этом постоянно контактирует с представителями бизнеса, ведь ему необходимо при проектировании учитывать их требования. В этом случае фундаментом для будущей БД являются правильные ответы на вопросы что, где, как, кто, когда, зачем.
Проджект-менеджер на этом этапе занимается детерминацией ролей и требований по визуализации данных для заказчиков, а также для пользователей. Этап Discover является одним из самых важных в процессе проектирования БД, поскольку малейшая ошибка на данном этапе планирования может привести к тому, что создать базу вообще будет невозможно.
Второй этап предназначен для проектирования семантических и схематических реализаций DWH. При этом на данном этапе можно воспользоваться двумя методами проектирования: создавать логические и концептуальные реализации совместно с пространственными моделями в виде многомерных кубов с данными или воспользоваться матрицей принятия решений для выявления чётких требований бизнеса к СХД.
Информация, потребная для данного этапа проектирования аккумулируется из нескольких внутренних и внешних источников. На этом же этапе проектируются связи, по которым информация будет поступать в DWH (или же продумывается ссылка на внешний источник информации). Здесь же происходит разделение на несколько основных уровней: технологический и уровень приложений. На каждом выполняются свои задачи.
На технологическом уровне происходит вычисление пространства, необходимого для БД, а также рассчитываются вычислительные мощности, которые будут необходимы для нормального функционирования DWH. На этом же уровне закладываются расчёты «на вырост»: то есть, специалист планирует возможный рост БД и прогнозирует объём требуемого места на накопителе под такую возможность.
На уровне приложений составляется примерный список ПО, которое будут использовать как администраторы для обслуживания БД, так и обычные пользователи для своих нужд. На этом же уровне проектируются информационно-аналитические системы, которые будут использоваться для генерации отчётов по запросу. На этом же уровне многие специалисты рекомендуют создавать визуализацию будущей БД для демонстрации заказчику.
Этот этап обычно делится на два уровня. На первом специалист проектирует визуальное отображение DWH, конфигурирует размеры самой базы, присваивает имена объектам в хранилище для пользователей или владельцев бизнеса (исключительно по предварительному согласованию). На этом же уровне происходит начальная индексация БД, которая должна полностью соответствовать предварительно выбранной стратегии.
На втором уровне разрабатываются схемы импорта и экспорта информации для DWH. Также здесь происходит проверка пакетов для сервисов преобразования данных и интеграции (DTS, SQL). Отдельно происходит тестирование сервиса обработки информации из внешних источников (то есть, тех, которые не входят в базу данных). Обработка информации из внешних источников является одной из важнейших особенностей любой DWH.
На этом этапе спроектированное хранилище запускается и тестируется его работа. Причём запуск БД осуществляется исключительно в нерабочее время (например, на выходных). Это связано с возможными рисками для работоспособности всей системы (в том числе и «боевой»). Также данная процедура проводится постепенно, а не параллельно. Это потому, что DWH нужно запускать, используя определённый порядок шагов и никак иначе.
Первый шаг включает в себя инсталляцию и настройку аппаратной части БД: то есть, происходит работа над серверами, системами хранения данных, коммутаторами и инженерной частью. На втором шаге разворачивается программное обеспечение на ранее установленном оборудовании (при этом в обязательном порядке производится тестирование). Финальный шаг – установка всех компонентов хранилища данных (инсталлируются сами базы и запускается ETL).
Только после выполнения всех перечисленных выше шагов начинается импорт данных в DWH, а конечным пользователям предоставляется необходимый софт.
Этот этап предназначен для мониторинга DWH в процессе функционирования. Ведь проблемы могут запросто возникнуть при повседневной работе пользователей. Внедрённая система мониторинга также предназначена для отслеживания процесса обновления БД и её основных компонентов, а также для проведения регулярного технического обслуживания для поиска возможных проблем и ошибок.
Данная система не только выполняет резервное копирование базы в случае необходимости, но также тестирует скорость восстановления БД из конкретного бэкапа. Для выполнения тестирования предоставляется отдельная виртуальная среда (своеобразная песочница), в которой можно делать практически всё, что требуется. Такое решение позволяет проводить необходимые тесты и при этом не мешать работе основной базы.
Любая база данных нуждается в качественной защите от угроз любого характера. Условно угрозы можно разделить на физические и логические. К первым можно отнести природные катаклизмы, физические повреждения носителей информации, а также случайное или намеренное повреждение коммуникаций. Способом борьбы с угрозами физического типа считается регулярное резервное копирование данных.
К логическим угрозам относятся сбои в ПО, некорректные обновления программной части, устаревшие драйверы, вирусы и другое вредоносное ПО, а также хакерские атаки. От вирусов и атак лучше всего помогает превентивная система защиты, которая представляет собой файрволл с тонко настроенными параметрами. А от системных сбоев опять-таки спасает своевременное создание резервной копии.
Этот этап является финальным и предполагает процедуру вывода из рабочей среды тех компонентов DWH, которые утратили свою актуальность. Существует три возможных варианта вывода: без замены, переключение или перенос данных. Первый способ предполагает создание нового компонента базы с нуля. Он используется только в тех случаях, когда нет никакой возможности обновить компонент DWH.
Переключение используют, если есть возможность перенести все данные и функции с морально устаревшего компонента на новый в кратчайшие сроки. При этом пользователи никакой разницы увидеть не должны. Перенос данных используется на рабочих БД, когда нет возможности быстро перенести данные: в этом случае запускается перенос и отключается старый компонент только после полного переноса функций и данных.
Anchor Model и Data Vault – это диаметрально противоположные гибкие методологии проектирования DWH, которые в последнее время набирают популярность среди специалистов. У каждого из методов есть свои приверженцы, которые искренне считают, что тот вариант, который они используют лучше. Погружаться в дебри проектирования DWH с использованием данных методов не стоит, но рассказать об основных особенностях можно.
Anchor Model (якорная модель) — это методология проектирования хранилищ данных (DWH), разработанная Ларсом Рейманом и Хансом Ёрнерем. Она предоставляет подход к созданию гибкой и расширяемой структуры DWH, который позволяет эффективно управлять изменениями в бизнес-процессах и требованиях к данным. Вот некоторые особенности создания DWH с использованием Anchor Model:
Идентификация якорей (anchors). Якоря представляют собой ключевые понятия в бизнес-процессах организации. Это сущности, которые имеют устойчивое значение и прямое отражение в данных (например, клиенты, продукты, заказы и так далее). Определение якорей является одним из первоочередных шагов.
Определение контекста. Каждый якорь должен иметь контекст, который описывает его свойства и отношения с другими якорями. Например, у клиента могут быть свойства как имя, контактная информация, и прочее.
Введение промежуточного слоя. В Anchor Model предусмотрен промежуточный слой, который позволяет организовать более сложные связи и агрегации данных.
Итеративный процесс. Разработка DWH на основе Anchor Model часто включает в себя итерации, поскольку бизнес-требования могут меняться, и модель должна быть гибкой и адаптированной к этим изменениям.
Документация. Создание документации для модели — важный аспект. Это позволяет команде легче понимать и поддерживать структуру данных.
Data Vault — это методология построения хранилища данных (DWH), разработанная Дэном Линстедом (Dan Linstedt). Она предоставляет гибкую и масштабируемую архитектуру для хранения и управления данными. Особенности создания БД в этом случае:
Разделение данных на три слоя. Data Vault предполагает обязательное наличие трёх слоёв: Hubs (хабы, ядра) — содержат уникальные наборы данных (бизнес-ключи, например, клиенты, продукты), Links (связи) — описывают отношения между ядрами(позволяют устанавливать связи между бизнес-ключами из разных ядер, например, заказы, которые связывают клиентов с продуктами), Satellites (сателлиты, спутники) — содержат атрибуты с подробной информацией о бизнес-ключах во времени (например, изменения в атрибутах клиента со временем).
Модель не описывает бизнес-правила. Данная методология сфокусирована на хранении и управлении данными, а не на описании бизнес-правил. Это делает еёболее гибкой и способной адаптироваться к изменяющимся требованиям.
Отслеживание изменений и история данных. Data Vault поддерживает хранение истории изменений, что позволяет анализировать данные на разных временных отрезках.
Гибкость и масштабируемость. Модель позволяет легко добавлять новые источники данных, расширять модель и адаптироваться к изменяющимся бизнес-потребностям.
Распределённое хранение данных. Data Vault обычно использует распределённое хранение данных, что обеспечивает высокую доступность и отказоустойчивость.
Инкрементальная загрузка данных. Загрузка данных в случае использования данной методологии часто происходит инкрементально, что позволяет минимизировать воздействие на операционные системы и обеспечивает более быстрое обновление данных.
Метаданные и управление метаданными. Data Vault требует наличия хорошо организованных метаданных для эффективного управления DWH и обеспечения его поддержки.
Хранилище DWH является крайне желательным (или даже обязательным) практически для любой компании, поскольку с его помощью компетентные специалисты проводят аналитику бизнес-процессов. На основе полученных аналитиком данных, руководитель принимает решения, призванные оптимизировать работу компании. К тому же, из DWHможно достать любую информацию в том случае, если основные базы отказали.
Для проектирования DWH компетентными специалистами могут быть использованы несколько методик, но наиболее популярной является 7D, позволяющая создать DWHпрактически без использования «рабочих» баз. К тому же, подобная концепция существенно облегчает процесс администрирования БД. Однако крайне важно не забывать создавать резервные копии данных, чтобы можно было легко восстановить информацию в случае какого-нибудь форс-мажора.
Витрина данных (Data Mart)
Современные компании генерируют огромные объемы данных, которые требуют систематизации и эффективного управления. Однако в условиях постоянного роста бизнеса использование единого корпоративного хранилища данных (Data Warehouse) не всегда оказывается достаточным. В таких случаях на помощь приходят витрины данных (Data Mart) — компактные и специализированные решения для хранения и анализа информации, заточенные под конкретные бизнес-задачи.
Self-Service BI
Облачное хранилище: определение, плюсы и минусы,...
Облачное хранилище представляет собой современный способ хранения данных, который избавляет от необходимости использовать локальные серверы и физические носители. Оно позволяет централизовать управление информацией и обеспечивает удобный доступ к файлам через интернет. Благодаря своей гибкости и простоте, облачное хранение данных активно применяется как крупными компаниями, так и частными пользователями. В этой статье мы рассмотрим, зачем необходимо облачное хранилище, как оно функционирует, какие преимущества и ограничения имеет, а также дадим рекомендации по его выбору.
Оставьте контактные данные и мы свяжемся с вами в ближайшее время
Отправить
Пн-Пт 09:00-18:00
Я даю свое согласие на обработку персональных данных
