Проектирование и построение хранилища данных (data warehouse) – задача масштабная и длительная. Необходимо учесть много факторов и нюансов, рассчитать бюджет и только на последнем этапе создавать DWH.
Рассмотрим создание хранилища данных поэтапно, рассказав о каждом шаге и возможных подводных камнях.
Для чего нужно DWH
Хранилище данных представляет собой предметно-ориентированную БД, которая аккумулирует всю информацию внутри организации в единую систему.
Данные в DWH используются не только для хранения, но и для дальнейшего анализа информации и предоставления консолидированных отчетов. На их основе руководители бизнеса принимают важные стратегические и управленческие решения.
В хранилище данных находится информация в течение многих десятков лет, что позволяет проводить более точную аналитику. При этом сам процесс анализа не влияет на производительность информационных систем, как происходит в случае использования обычных баз данных.
Архитектура DWH
Хранилище данных, построенное любым из методов, обязательно состоит из нескольких компонентов:
- Ядро. Главная часть любой DWH – обеспечивает целостность входящих данных. Структурирует полученную информацию согласно заданным параметрам.
- Область сбора информации. Компонент, который собирает всю входящую информацию с разных источников.
- Аналитическая часть отвечает за предоставления отчетности по требованию владельца.
- Сервис. Компонент отвечает за управление и стабильное взаимодействие трех предыдущих. Мониторит в режиме онлайн состояние каждого компонента и оперативно устраняет ошибки.
Методы создания DWH
Построение хранилища данных происходит по разным методикам.
- Классический метод. В его основе лежит разделение данных на две группы: измерения и факты. Связь между ними представлена в виде классических таблиц с внешним ключом. Возникает неудобство при добавлении новой составляющей в таблице, поскольку жесткая привязка таблиц к внешнему ключу не позволяет гибко менять структура data warehouse.
- Метод Инмона. По задумке создателя способа, сначала проектируется централизованное хранилище данных, а дальше добавляются витрины с информацией. При таком подходе загрузка входящей информации в data warehouse значительно упрощается, но увеличивается время при обработке запросов.
- Метод Кимбалла. В отличие от предыдущего способа DWH создается на основе витрин. Другими словами, сначала они заполняются необходимой информацией, а после проектируется централизованное хранилище.
- Метод 7D. Назван так по названиям этапов, которые включены в него: Discover, Design, Develop, Deploy, Day to day, Defend и Decommission.
Проектирование DWH с помощью 7D
Этап 1. Discover
Сначала анализируются требования к создаваемому хранилищу данных. Менеджер проекта тесно сотрудничает с представителями бизнеса, так как необходимо учитывать их задачи.
Чтобы получить необходимые данные, следует ответить на шесть главных вопросов: Что? Как? Где? Кто? Когда? Зачем?. Ответы на вопросы являются фундаментом будущей DWH.
Менеджер проекта детерминирует роли и требования по визуализации данных для заказчиков и пользователей.
Это очень важный этап, поскольку малейшая ошибка на нем приводит к невозможности создания хранилища данных.
Этап 2. Design
На втором шаге проектируются семантические и схематические реализации DWH. Для проектирования можно воспользоваться двумя методами:
- Создать концептуальные и логические реализации DWH совместно с пространственными моделями в виде многомерных кубов данных.
- Воспользоваться матрицей принятия решений для вычисления четких требований бизнеса к хранилищу данных.
Информация, которая используется на втором этапе, аккумулируется с разных внешних и внутренних источников. При этом на втором шаге сразу задаются параметры, по которым информация будет импортироваться в data warehouse либо работать со ссылкой на внешний источник.
Разделение происходит по двум уровням. На технологическом вычисляется необходимый размер дискового пространства для хранения и обработки поступающей информации. Параллельно сразу рассчитываются вычислительные мощности, которые потребуются для стабильной и быстрой работы DWH.
Закладываются расчеты на вырост. Другими словами, планируется значение, на которое ежегодно будут расти требования DWH к дисковому пространству и вычислительным мощностям аппаратной части.
Коммуникации, инженерные системы, кабелирование – также закладываются на технологическом уровне второго этапа.
На уровне приложений составляется список программного обеспечения, которое будет использоваться в DWH как для администраторов, так и для пользователей. ПО также включает в себя информационно-аналитические системы для формирования отчетов.
На данном уровне рекомендуется создавать визуальное изображение будущей модели для более наглядного показа заказчикам.
Успешным считается проектирование, когда обе полученные модели соответствуют задачам ИС управления и отображают аналитику под бизнес-задачи. Созданные на втором этапе модели должны удовлетворять в полном объеме шести вопросам, которые были озвучены на первом этапе.
Этап 3. Develop
Третий шаг обычно разбивают на два для более эффективной разработки. На первом проектируется визуальное отображение компонента DWH, конфигурируются размеры самой БД и присваиваются имена объектам хранилища данных для пользователей и владельцев бизнеса по согласованию. Также происходит индексация информации на основе принятой стратегии.
Вторая часть третьего этапа заключается в разработке схем импорта\экспорта информации для data warehouse, проверка пакетов для сервисов преобразования данных (DTS) и интеграции SQL (SSIS) с последующим конфигурированием после успешного теста. При этом отдельно тестируется сервис обработки информации с внешних источников данных, которые не импортированы в DWH.
Если разбивать этап разработки хранилища данных по трем уровням, то будет следующая ситуация. На технологическом анализируются, тестируются и детерминируются продукты, которые будут импортироваться в данную информационную систему. Операция выполняется для шести последних уровней модели OSI.
Этап разработки вычисляет необходимые серверные мощности для будущего data warehouse и требования к аппаратной части систем хранения данных, необходимых для стабильной и эффективной работы.
На уровне приложений разрабатывают программное обеспечение для конечного потребителя хранилища данных. Здесь очень важно обозначить четкие критерии в ТЗ, чтобы пользователи могли работать с разработанным ПО.
Внедряют программу обучения и тестирования программных продуктов в специально выделенной и изолированной от производственной части виртуальной среде.
Этап 4. Deploy
Во-первых, запуск хранилища данных происходит только в нерабочее время, как правило, в выходные дни.
Во-вторых, данный этап происходит постепенно, а не параллельно. Это связано с тем, что внедрение data warehouse необходимо выполнять строго по определенным шагам.
Сначала происходит инсталляция и конфигурирование аппаратной части DWH. К ним относятся серверы, системы хранения данных, коммутаторы и инженерная часть.
Следующий шаг – развертывание программного обеспечения на установленном оборудовании с обязательным тестированием.
Финальной частью этапа внедрения является установка всех компонентов хранилища данных: инсталлируются базы данных и запускаются сервисы ETL. После этого происходит импорт данных в DWH и предоставление конечным пользователям прикладного ПО.
Этап 5. Day-to-Day
Данный этап необходим для мониторинга data warehouse, так как проблемы могут возникнуть непосредственно при повседневной работе пользователей. Система наблюдения также отслеживает процесс обновления компонентов DWH и их регулярное техническое обслуживание на предмет ошибок и возможных проблем.
Система резервного копирования на данном этапе не только работает в строго заданном режиме, но и периодически тестирует бэкапы на скорость восстановления БД из любой резервной копии. Для этого выделяется изолированная программная среда, в которой администраторы могут проводить абсолютно любые тесты.
Data warehouse разрастается по мере увеличения количества пользователей, объема используемой информации и требований, которые появляются у бизнеса со временем.
Поскольку компания не стоит на месте, а постоянно развивается, то одной из главных задач администратора DWH является отслеживание «горячих» и «холодных» данных. По мере расширения компании необходимость в некоторой части информации отпадает, но появляются новые запросы. Это приводит к изменениям форм предоставления информации из других источников.
Этап 6. Defend
Любую информацию необходимо защищать как от внешних угроз, так и от внутренних. На данном шаге создается защитный барьер для хранилища данных, который максимально учитывает каждый фактор.
Угрозы разделяют на физические и логические. К первому типу относят природные катаклизмы (наводнения, торнадо и другие стихийные бедствия), повреждения аппаратной части оборудования, случайное и преднамеренное повреждение телекоммуникаций и т. д.
В качестве мер защиты от физических угроз для DWH служат такие меры, как создание локальных и удаленных резервных копий, построение географически распределенного метрокластера с синхронной репликацией данных, разграничение прав доступа пользователей, дублирование критически важных компонентов хранилища данных и др.
Логические угрозы включают в себя программные сбои, некорректное обновление приложений, устаревшие драйвера, удаление информации, вирусные атаки и т. д. Лучшим способом защиты от логических атак служит превентивная система защиты. Как правило, правильно настроенный межсетевой экран блокирует многие внешние атаки до их начала.
Своевременное обновление программного обеспечения закрывает многие уязвимости, которые могут привести к нестабильной работе приложения.
Этап 7. Decommission
Последний этап построения хранилища данных заключается в выводе из рабочей среды компонентов DWH, которые перестали быть актуальными или морально устарели без возможности обновления.
Доступно три возможных метода: без замены, переключение и перенос данных. Первый вариант подразумевает создание полностью нового компонента взамен устаревшего. Метод используется в ситуациях, когда нет возможности обновить элемент data warehouse.
Переключение используют в ситуациях, когда морально устаревшая БД (или любой другой элемент) может быть в кратчайшие сроки заменен другим. Все данные и функции со старого компонента полностью переносятся на новый, а пользователи не заметят дайнтайма во время переноса.
Последний вариант схож с предыдущим, но не может быстро перенести необходимые данные. В этом случае администраторы оставляют функционировать две базы данных, но при этом происходит перенос информации и функций. Когда все завершается, пользователей переключают на новый элемент и только после этого отключают старый.
Если вы хотите реализовать свое десктоп- или веб-приложение, создание прототипа – рациональное и экономически выгодное решение. Вы сможете в процессе разработки тестировать логики и идеи, проверять функциональность, наглядно видеть дизайн.
Обратитесь к нашим специалистам — сэкономьте время и финансовые затраты! В результате вы получите безупречно работающее приложение с необходимым функционалом и правами доступа.
