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

Только за созданием подобного сейфа и особенно поддержкой кроются жуткие монстры, пугающие в первую очередь бизнес, а уже потом IT-отдел.

В этой статье рассмотрим наиболее частые проблемы, касающиеся хранилищ данных, с которыми сталкивается менеджмент компании, а также способы их решения. Поэтому здесь не будет никаких айтышных технических особенностей, Кимбаллов, Лямбда-архитектур и прочих.

Основные проблемы

Прежде, чем приступить к описательной части, следует подчеркнуть несколько важных для понимания моментов:

• во-первых, деньги – главное (капитализм ведь победил). Если проблема сейчас или в будущем не приведет к потере денег или недополученной прибыли, это не проблема

• во-вторых, чаще всего основные затраты, связанные с хранилищем данных – ФОТ. Самое дорогое – это люди (в прямом и переносном смысле). Железки или ПО тоже могут быть внушительной статьей затрат, но затраты на персонал или услуги аутсорса практически всегда (гораздо) дороже

Создание хранилища данных

Какие есть основные проблемы при создании хранилища данных с нуля?

Проблемы:

• Процесс долгий, трудозатратный и, как вы уже догадались, дорогой

• У компании не хватает собственных ресурсов (людей с экспертизой)

Возможные решения:

• Забить и не создавать хранилище

Да, самое эффективное и не рискованное решение – не делать ХД. Заставить своих сотрудников и дальше руками готовить вам отчетность, вручную собирать необходимые для анализа данные и манипулировать ими в excel-е.

Иногда это действительно эффективнее и рациональнее, чем полноценное ХД, особенно если за аналитику и отчетность отвечает один-два сотрудника и создание ХД с нуля обойдется как 500+ их зарплат, а на скорость подготовки отчетности вам все равно.

• Сделать «тяп-ляп»

Не смейтесь, но это тоже весьма эффективное в некоторых случаях средство. Особенно, когда топ-менеджмент не понимает, зачем в принципе требуется хранилище, или/и хочет получить первые результаты «вчера». В таком случае подходит наколеночное решение за пару недель или месяц, которое наглядно покажет менеджменту важность хранилища, может в дальнейшем прожить какое-то время и даже развиваться.

Конечно же, в данном случае следует держать в голове, что потом обязательно потребуется это переделывать. И лучше раньше, чем позже, иначе будет «туго» и крайне больно. А самое главное – дороже!

• Воспользоваться услугами консалтинга

В некоторых случаях, это прямо палочка-выручалочка. Нанимаете фирму, платите им, чаще даже дешевле, чем если бы платили своим собственным IT-шникам, и получаете результат в приемлемые сроки. Красота и прелесть. Казалось бы, решение найдено, расходимся, но не тут-то было.

Главная страшилка – «консалтинговая игла». Та ситуация, когда ИТ-продукт ваш, но вас он не слушается и вам не подчиняется. Если встает потребность в доработке хранилища, что возникает весьма часто, своими силами уже доработать вы не сможете, потому как нет экспертизы. Даже банальное обслуживание: стабильная загрузка данных и обновление отчетов, исправление ошибок и т.д. – теперь вам не подвластно. И каждый раз вы должны обращаться к консалтинговой компании. А это зависимость, которая может привести в дальнейшем к еще большим проблемам.

Также при работе с консалтингом обязательно требуется хорошо составленное и подробное ТЗ. Консалтинг, который берет на себя обязанность составление оного документа, как правило, стоит уже на порядок дороже.

• Набрать специалистов

Самый правильный вариант из представленных. Только, в то же самое время, самый сложный, долгий и дорогой.

Развитие и поддержка хранилища данных

Далее проблемы при развитии и поддержании «на плаву» хранилища.

Проблемы:

• ИТ не успевает за требованиями бизнеса

Наверное, одна из основных проблем для бизнеса в части аналитики и хранилищ данных.

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

Даже если у каждого бизнес-подразделения есть свои разработчики или для подобных задач используются внешние ресурсы, сроки выполнения требований по созданию отчета или формированию набора данных нередко длительные и не удовлетворяют бизнес, которому часто нужно «здесь и сейчас».

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

• Дорогое администрирование

Хранилище данных требуется обслуживать: резервное копирование, мониторинг выполнения потоков данных, разграничение прав доступа, контроль доступности сервера и данных, отслеживание проблемных SQL-запросов и много другое.

Почему дорогое? Все эти действия выполняют люди, которые дорогие.

Решения есть и все они эффективны:

1. Облачные сервисы – переносят задачи администрирования на вендора

2. Специальное ПО – устанавливается в инфраструктуре клиента и автоматизирует процессы администрирования

3. Разработать собственное ПО – собственными силами автоматизировать процессы администрирования

• Дорогие лицензии на ПО или необходимость «переехать»

Я говорил, что практически всегда самая затратная статья – ФОТ. Помня это, не стоит забывать и про лицензионные отчисления на ПО, которые тоже могут быть весьма ощутимыми.

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

В предыдущем предложении я уже задействовал слово, которое и является решением для данной проблемы – миграция. Она помогает и в случае просто дорого программного обеспечения (миграция на opensource), так и в случае ухода вендора.

Но миграция – задача из категории «безумие». И ее сложность растет прямо пропорционально количеству объектов в хранилище. Поэтому сроки каждой миграции весьма объемны, делая ее…(мое любимое слово в этой статье)…дорогой.

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

С администрированием проблема решена, а вот как быть с остальными «кошмарами», связанными с созданием и развитием хранилища?

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

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

1.      Анализ

Заказчик передает требования исполнителю – ИТ.

Команда ИТ:

• внимательно их изучает и уточняет

• изучает систему-источник, из которого потребуется тащить необходимые заказчику данные

• определяет, как структурировать вытащенные с источника данные

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

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

1.  Загрузка данных в сыром виде

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

В рамках данного процесса с данными могут проводиться минимальные операции по обработке. Но чаще всего данные банально копируются с источника и вставляются в хранилище данных.

2. Обработка данных

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

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

3. Создание отчета

Создать отчет или отчетную витрину с процессом обновления. Дополнительно протестировать результаты отчета на корректность.

Не всегда обязательный шаг, ведь часто требуется просто создание структурированного слоя данных (3 шаг) и проведения аналитики над ним.

4. Внедрение

Перенос с тестовой среды на продуктивную.

Смотря на данные шаги, напрашиваются следующие выводы:

• Загрузка и преобразование данных – одни из самых затратных этапов процесса.

На схеме, конечно, объемы трудозатрат показаны условно, ведь у разных задач длительности этапов могут быть разные. Но чаще всего на практике распределение трудозатрат именно такое.

• Большая часть процесса, а именно все этапы кроме аналитики могут быть частично или полностью автоматизированы.

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

Автоматизация процесса

Стоит сказать, что идея не нова. Есть множество решений по автоматизации процесса разработки хранилищ данных.

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

Другими словами, они не автоматизируют процесс разработки, а лишь в некоторых местах упрощают его.

Дополнительный недостаток - разработчику, хорошо знающему SQL и основные популярные ETL-инструменты (SSIS, OGG, AirFlow), придется наращивать экспертизу в других инструментах, тратя на это свое драгоценное время.

Некоторые компании разрабатывают собственные решения для упрощения жизни своим разработчикам. Но такое могут позволить себе крупные фирмы, имеющие достаточный ИТ-ресурс и бюджет, что нельзя сказать про средний бизнес, который до сих пор живет в Excel, но очень хочет чего-то большего. Дополнительно такие инструменты чаще не подвластны обычным аналитикам в силу своей сложности.

Исходя из всего написанного выше, инструмент автоматизации должен обладать следующими отличительными характеристиками:

• Автоматически генерирует процесс загрузки и обработки данных, требуя от аналитика/разработчика минимальных действий

• Легок и понятен обычному аналитику, не имеющему навыков разработчика

• Позволяет дорабатывать логику обработки данных средствами SQL, который знают все аналитики

• Позволяет легко вносить доработки в структуру хранилища данных без риска ее поломать

• Упрощает процесс разработки отчетных витрин и их обновления

• Автоматически тестирует и внедряет

• Работает на бесплатном (opensource) ПО

Сам процесс разработки или развития хранилища с использованием подобного инструмента должен выглядеть так:

1. Аналитика

От этого пока никуда не денешься, ведь поручить данную обязанность машине с текущим развитием AI не представляется возможным. Следовательно, и длительность этапа сократить не получится.

2. Подготовка данных

Данный этап должен требовать от исполнителя наименьшее количество действий:

1. Указать откуда загружать данные (источники)

2. Указать куда и в какой структуре загружать данные (сформировать модель данных)

Процесс загрузки (ETL) должен формироваться автоматически. Для проведения дополнительных манипуляций с данными должен использоваться только SQL. Тем самым, длительность этого этапа заметно сокращается.

3. Создание отчетных витрин

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

4. Внедрение

Пользователь всего лишь указывает, какие объекты требуется перенести на продуктивную среду, и данные объекты с процессами их обновления автоматически переносятся.

Итоги

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

Конечно, не всем компаниям будет возможно заметно сократить сроки разработки в силу некоторых причин:

• модель данных слишком сложна из-за сложности бизнеса

• гигантский объем данных, требующий специальной оптимизации

• скорость доставки данных из источника в хранилище должна исчисляться минутами и другое

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

Мы попытались создать подобный инструмент. О полученных результатах (положительных и отрицательных) за счет его использования, наверное, расскажу в следующих статьях.

И напоследок: важны не сами данные, а их анализ. Поэтому, как можно меньше времени тратьте на их подготовку и как можно больше на аналитику.