Проектирование и построение хранилища данных (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 как для администраторов, так и для пользователей. ПО также включает в себя информационно-аналитические системы для формирования отчетов.
На данном уровне рекомендуется создавать визуальное изображение будущей модели для более наглядного показа заказчикам.
Успешным считается проектирование, когда обе полученные модели соответствуют задачам ИС управления и отображают аналитику под бизнес-задачи. Созданные на втором этапе модели должны удовлетворять в полном объеме шести вопросам, которые были озвучены на первом этапе.
А в Вашей организации есть хранилище данных?
Источник: vc.ru
Хранилище данных пугает бизнес: проблемы DWH для бизнеса
Давным-давно стало очевидно, что хранилище данных вещь полезная, а часто – просто необходимая. Повышение эффективности принимаемых решений, контроль и оптимизация бизнес-процессов, создание цельной картины о бизнесе, качественное прогнозирование и многое другое. Все эти тезисы уже сотни раз озвучивались при описании хранилищ данных. Данные – новое золото, а хранилище данных – сейф для него
Только за созданием подобного сейфа и особенно поддержкой кроются жуткие монстры, пугающие в первую очередь бизнес, а уже потом IT-отдел.
В этой статье рассмотрим наиболее частые проблемы, касающиеся хранилищ данных, с которыми сталкивается менеджмент компании, а также способы их решения. Поэтому здесь не будет никаких айтышных технических особенностей, Кимбаллов, Лямбда-архитектур и прочих.
Основные проблемы
Прежде, чем приступить к описательной части, следует подчеркнуть несколько важных для понимания моментов:
- во-первых, деньги – главное (капитализм ведь победил). Если проблема сейчас или в будущем не приведет к потере денег или недополученной прибыли, это не проблема
- во-вторых, чаще всего основные затраты, связанные с хранилищем данных – ФОТ. Самое дорогое – это люди (в прямом и переносном смысле). Железки или ПО тоже могут быть внушительной статьей затрат, но затраты на персонал или услуги аутсорса практически всегда (гораздо) дороже
Создание хранилища данных
Какие есть основные проблемы при создании хранилища данных с нуля?
Проблемы:
- Процесс долгий, трудозатратный и, как вы уже догадались, дорогой
- У компании не хватает собственных ресурсов (людей с экспертизой)
Возможные решения:
- Забить и не создавать хранилище
Да, самое эффективное и не рискованное решение – не делать ХД. Заставить своих сотрудников и дальше руками готовить вам отчетность, вручную собирать необходимые для анализа данные и манипулировать ими в excel-е.
Иногда это действительно эффективнее и рациональнее, чем полноценное ХД, особенно если за аналитику и отчетность отвечает один-два сотрудника и создание ХД с нуля обойдется как 500+ их зарплат, а на скорость подготовки отчетности вам все равно.
Не смейтесь, но это тоже весьма эффективное в некоторых случаях средство. Особенно, когда топ-менеджмент не понимает, зачем в принципе требуется хранилище, или/и хочет получить первые результаты «вчера». В таком случае подходит наколеночное решение за пару недель или месяц, которое наглядно покажет менеджменту важность хранилища, может в дальнейшем прожить какое-то время и даже развиваться.
Конечно же, в данном случае следует держать в голове, что потом обязательно потребуется это переделывать. И лучше раньше, чем позже, иначе будет «туго» и крайне больно. А самое главное – дороже!
- Воспользоваться услугами консалтинга
В некоторых случаях, это прямо палочка-выручалочка. Нанимаете фирму, платите им, чаще даже дешевле, чем если бы платили своим собственным IT-шникам, и получаете результат в приемлемые сроки. Красота и прелесть. Казалось бы, решение найдено, расходимся, но не тут-то было.
Главная страшилка – «консалтинговая игла». Та ситуация, когда ИТ-продукт ваш, но вас он не слушается и вам не подчиняется. Если встает потребность в доработке хранилища, что возникает весьма часто, своими силами уже доработать вы не сможете, потому как нет экспертизы.
Даже банальное обслуживание: стабильная загрузка данных и обновление отчетов, исправление ошибок и т.д. – теперь вам не подвластно. И каждый раз вы должны обращаться к консалтинговой компании. А это зависимость, которая может привести в дальнейшем к еще большим проблемам.
Также при работе с консалтингом обязательно требуется хорошо составленное и подробное ТЗ. Консалтинг, который берет на себя обязанность составление оного документа, как правило, стоит уже на порядок дороже.
Самый правильный вариант из представленных. Только, в то же самое время, самый сложный, долгий и дорогой.
Развитие и поддержка хранилища данных
Далее проблемы при развитии и поддержании «на плаву» хранилища.
Проблемы:
- ИТ не успевает за требованиями бизнеса
Наверное, одна из основных проблем для бизнеса в части аналитики и хранилищ данных.
Бизнес-подразделения «дерутся» за место в квартальном бэклоге команды развития ХД, доказывая, что именно их данные должны быть загружены в ХД и именно их отчет должен быть реализован. Проводятся десятки длительных совещаний, на которых определяется приоритетность задач. А некоторые задачи висят месяцами или даже кварталами.
Даже если у каждого бизнес-подразделения есть свои разработчики или для подобных задач используются внешние ресурсы, сроки выполнения требований по созданию отчета или формированию набора данных нередко длительные и не удовлетворяют бизнес, которому часто нужно «здесь и сейчас».
Простыми словами, от появления потребности в аналитике у бизнеса до результата может пройти много времени, решение на основе данных не будет принято и деньги будут потеряны.
Хранилище данных требуется обслуживать: резервное копирование, мониторинг выполнения потоков данных, разграничение прав доступа, контроль доступности сервера и данных, отслеживание проблемных SQL-запросов и много другое.
Почему дорогое? Все эти действия выполняют люди, которые дорогие.
Решения есть и все они эффективны:
- Облачные сервисы – переносят задачи администрирования на вендора
- Специальное ПО – устанавливается в инфраструктуре клиента и автоматизирует процессы администрирования
- Разработать собственное ПО – собственными силами автоматизировать процессы администрирования
- Дорогие лицензии на ПО или необходимость «переехать»
Я говорил, что практически всегда самая затратная статья – ФОТ. Помня это, не стоит забывать и про лицензионные отчисления на ПО, которые тоже могут быть весьма ощутимыми.
Дополнительной проблемой в последнее время стал уход иностранных вендоров, что заставило использующие их решения компании задуматься над миграцией своих хранилищ данных.
В предыдущем предложении я уже задействовал слово, которое и является решением для данной проблемы – миграция. Она помогает и в случае просто дорого программного обеспечения (миграция на opensource), так и в случае ухода вендора.
Но миграция – задача из категории «безумие». И ее сложность растет прямо пропорционально количеству объектов в хранилище. Поэтому сроки каждой миграции весьма объемны, делая ее…(мое любимое слово в этой статье)…дорогой.
Подводя итоги, большинство проблем касаются процесса разработки хранилища, который выполняют люди. Дорогие люди. К сожалению, дорогие не только сердцу, но и кошельку.
С администрированием проблема решена, а вот как быть с остальными «кошмарами», связанными с созданием и развитием хранилища?
Процесса разработки хранилища данных
Сперва рассмотрим сам процесс разработки и определим места, которые мы могли бы автоматизировать. Сразу оговорюсь, что в данной статье процесс крайне упрощен и в реальной жизни может выглядеть значительно сложнее.
1. Анализ
Заказчик передает требования исполнителю – ИТ.
- внимательно их изучает и уточняет
- изучает систему-источник, из которого потребуется тащить необходимые заказчику данные
- определяет, как структурировать вытащенные с источника данные
- определяет, как будет выглядеть запрашиваемый финальный отчет или набор данных
Этот шаг весьма важен, ведь данный анализ должен помочь избежать рисков последующего переделывания, влияния на уже ранее загруженные данные и, не дай бог, передаче заказчику некорректного результата.
1. Загрузка данных в сыром виде
После того, как было определено из каких мест системы-источника и какие конкретно данные необходимо вытаскивать, разрабатывается процесс загрузки данных. Именно процесс, ведь выполняться он должен не единожды, а на регламентной основе.
В рамках данного процесса с данными могут проводиться минимальные операции по обработке. Но чаще всего данные банально копируются с источника и вставляются в хранилище данных.
2. Обработка данных
Переложив данные в хранилище, требуется их структурировать, очистить, дополнить и множество других операций по обработке, чтобы можно было эти данные в дальнейшем использовать в отчетности или проводить над ними анализ.
В рамках данного шага также создается процесс по обработке данных, выполняющихся с некой периодичностью.
3. Создание отчета
Создать отчет или отчетную витрину с процессом обновления. Дополнительно протестировать результаты отчета на корректность.
Не всегда обязательный шаг, ведь часто требуется просто создание структурированного слоя данных (3 шаг) и проведения аналитики над ним.
4. Внедрение
Перенос с тестовой среды на продуктивную.
Смотря на данные шаги, напрашиваются следующие выводы:
- Загрузка и преобразование данных – одни из самых затратных этапов процесса.
На схеме, конечно, объемы трудозатрат показаны условно, ведь у разных задач длительности этапов могут быть разные. Но чаще всего на практике распределение трудозатрат именно такое.
- Большая часть процесса, а именно все этапы кроме аналитики могут быть частично или полностью автоматизированы.
Загрузка и по большей части преобразование данных в необходимую структуру нередко требуют ряда типизированных действий, которые легко могут быть автоматизированы.
Автоматизация процесса
Стоит сказать, что идея не нова. Есть множество решений по автоматизации процесса разработки хранилищ данных.
Но все схожие ПО имеют один общий недостаток – они сложны и, по сути, повторяют логику ETL-инструментов (инструментов по разработке процессов загрузки данных), отличаясь лишь дизайном и дополнительными функциями. Эти функции в некоторых местах упрощают разработку процессов загрузки данных, но незначительно.
Другими словами, они не автоматизируют процесс разработки, а лишь в некоторых местах упрощают его.
Дополнительный недостаток — разработчику, хорошо знающему SQL и основные популярные ETL-инструменты (SSIS, OGG, AirFlow), придется наращивать экспертизу в других инструментах, тратя на это свое драгоценное время.
Некоторые компании разрабатывают собственные решения для упрощения жизни своим разработчикам. Но такое могут позволить себе крупные фирмы, имеющие достаточный ИТ-ресурс и бюджет, что нельзя сказать про средний бизнес, который до сих пор живет в Excel, но очень хочет чего-то большего. Дополнительно такие инструменты чаще не подвластны обычным аналитикам в силу своей сложности.
Исходя из всего написанного выше, инструмент автоматизации должен обладать следующими отличительными характеристиками:
- Автоматически генерирует процесс загрузки и обработки данных, требуя от аналитика/разработчика минимальных действий
- Легок и понятен обычному аналитику, не имеющему навыков разработчика
- Позволяет дорабатывать логику обработки данных средствами SQL, который знают все аналитики
- Позволяет легко вносить доработки в структуру хранилища данных без риска ее поломать
- Упрощает процесс разработки отчетных витрин и их обновления
- Автоматически тестирует и внедряет
- Работает на бесплатном (opensource) ПО
Сам процесс разработки или развития хранилища с использованием подобного инструмента должен выглядеть так:
- Аналитика
От этого пока никуда не денешься, ведь поручить данную обязанность машине с текущим развитием AI не представляется возможным. Следовательно, и длительность этапа сократить не получится.
- Подготовка данных