Будучи участником многочисленных проектов по преобразованию сложных типов данных, могу подтвердить статистику, согласно которой 85% проектов по обработке данных терпят неудачу.
Вот основные причины этих неудач.
- Трансформирование стеков данных.
- Недостаточная подготовленность данных.
- Некомпетентность команды.
- Нетерпеливость заинтересованных сторон.
- Чрезмерное усердие руководства.
- Отсутствие инвестиций, необходимых для изменения организационной культуры.
Все проекты начинаются с благими намерениями. Однако нередко в ходе работы возникают вышеперечисленные проблемы. Неудачные проекты либо доводят до финиша всеми силами, либо бросают в поисках следующей более выгодной инициативы.
Как же избежать этого? Познакомимся с планом успешной работы над проектом по созданию хранилища данных.
Шаг №1. Определение основных бизнес-целей
Прежде чем браться за очередной “блестящий” проект, стоит сделать паузу.
Действительно ли вам нужно хранилище данных (DWH)? Наверняка у вас уже есть реализованный проект DWH, если только вы не работаете в недавно запущенном стартапе. Так уж необходимо создавать новый DWH? Если да, то убедитесь, что четко понимаете основные бизнес-задачи.
Обычно они заключаются в решении важной задачи: как получить больший доход, снизить регуляторный риск, улучшить отчетность на уровне совета директоров и т. д.
Помните: ключ к задаче > технология, используемая для ее решения.
Четко осознайте потребности компании — создавайте отчетные истории, которые помогут сосредоточиться на конечном результате.
Ниже представлен пример отчетной истории.
Мне, как менеджеру по маркетингу, необходимо знать количество продуктов, купленных клиентом в прошлом году, чтобы внести предложение о повышении продаж.
Из приведенной выше истории вытекает необходимость агрегировать количество продуктов для каждого клиента на основе продаж за прошлый год. Создание целого каталога отчетных историй поможет управлять бизнесом и его требованиями к данным.
Разработка концептуальных моделей
Когда каталог отчетных историй будет составлен, можно переходить к их подтверждению путем создания простых концептуальных моделей. Концептуальные модели — это абстрактные представления о сущностях и их взаимосвязях.
Концептуальная модель должна интерпретировать бизнес-процесс так, чтобы было понятно даже пятикласснику.
Концептуальная модель также может быть более подробной, интерпретирующей связи сущностей (“один ко многим”, “один к одному” или “многие ко многим”) и отражающей мощность этих связей.
- Клиент должен быть уникальным: один и тот же клиент не должен быть учтен дважды.
- У него может быть 0 или больше заказов: он может быть в базе данных, но никогда ранее не делал заказов.
- Заказ должен включать 1 или несколько продуктов: заказ не может быть создан без включения продукта.
- Продукт может присутствовать в 0 или нескольких заказах: продукт может быть в наличии, но никогда не продаваться или продаваться много раз.
Теперь у вас есть:
- каталог отчетных историй, из которого выбраны необходимые данные;
- концептуальная модель с предельно ясной интерпретацией взаимосвязей.
Все это должно быть создано и утверждено совместно с конечными пользователями.
Шаг №2. Создание физической модели данных
Теперь заполняем предыдущую концептуальную модель данных. Клиент как сущность теперь может быть детализирован в таких атрибутах, как:
- имя клиента;
- номер телефона;
- адрес;
- уникальные идентификаторы.
В физическую модель вводятся такие типы данных, как строка, целое число и прочие, а также первичные и внешние ключи.
Вернемся к первоначальной отчетной истории:
Мне, как менеджеру по маркетингу, необходимо знать количество продуктов, купленных клиентом в прошлом году, чтобы внести предложение о повышении продаж.
Достаточно ли информации в физической модели данных, чтобы решить эту задачу? Скорее всего, нет! На данном этапе нужно определиться с тем, как сформировать эти данные в DWH. Можно использовать несколько различных методов, таких как размерное моделирование в схеме “звезда” или нормализация в 3-й обычной форме в модели “снежинка”.
В данном случае подойдет простая размерная модель с фактами (количественными) и измерениями (качественными).
Теперь у нас достаточно информации в таблице фактов, чтобы агрегировать количество продуктов для каждого клиента за любую дату (последний год, последние пять лет) с общей суммой продаж. Эта модель также позволяет взять срезы (вертикальные/горизонтальные) и подмножества данных более чем одним способом.
Профиль известных атрибутов данных
На этом этапе необходимо начать профилирование известных исходных данных.
Бесчисленное количество проектов DWH терпят неудачу из-за низкого качества данных и отсутствия тестирования реальных данных. Выполните эту работу заранее: составьте профиль данных, выявите проблемы с качеством данных и попытайтесь устранить их до разработки конвейеров данных.
Шаг №3. Схема решения с отражением конечного результата
Шаг №3 можно выполнять одновременно с шагом №2, если количественный состав команды и сложность задач позволят это сделать. Конечного пользователя не волнует ни DWH-проект, ни причудливая звездообразная схема размерной модели. Им нужно, чтобы проблема была решена.
Помните: ключ к задаче > технология, используемая для ее решения!
На этом этапе создайте несколько макетов/прототипов конечных отчетов по клиентским запросам. Это позволит быстро понять и сформировать образ конечного продукта. У конечного пользователя может быть видение, которое он не смог связно сформулировать на этапе выявления потребностей. Макет не обязательно должен использовать реальные данные или быть средством построения отчетности. Он может быть просто создан в Powerpoint.
Шаг № 4. Создание, тестирование и итерация
Будем считать, что к этому моменту уже приняты несколько проектных и экологических решений, включая физическую модель данных, требования к истории, утвержденные схемы, а также создание и настройка среды.
Теперь приступим к ETL-решениям (извлечению, преобразованию и загрузке данных) или созданию конвейеров данных. Данные должны быть перемещены из исходной системы в физическое хранилище данных.
Во время перемещения данных необходимо учитывать результаты профилирования, полученные на этапе №2, типы данных и, если требуется преобразование, объем истории, который надо извлечь. Потребуется также итеративное проведение модульного тестирования отдельных компонентов конвейера.
После создания достаточно большой части конвейера необходимо провести сквозное интегральное тестирование системы: нужно убедиться, что точки интеграции работают так, как ожидается.
Интегральное тестирование обычно решает судьбу всего процесса.
Если конвейер уже достаточно зрелый, чтобы выдать результат (например, отчетные параметры, общую сумму продаж, количество продуктов и т. д.), было бы разумно подтвердить цифры с помощью конечного пользователя. Опять же, привлечение конечного пользователя на протяжении всего процесса итерации, помогающего принять решение, избавит от массы проблем на более поздних этапах проекта.
Шаг №5. Запуск проекта на стадии полной готовности
Мы с нетерпением ждем даты запуска. Однако системе DWH следует “созреть”. Следовательно, дата запуска не должна иметь большого значения.
Некоторые проектные решения, возможно, придется пересмотреть на этапе “созревания”, если в ходе проверки на реальных данных будет доказана их ошибочность. Это воспринимается особенно болезненно, когда изменения требуют много времени и затрагивают многие компоненты. Именно поэтому рекомендуется проводить широкое профилирование данных на начальном этапе.
Если для создания конечного отчета требуется гораздо больше времени, чем ожидалось, настройку производительности придется проводить на постоянной основе.
У администратора базы данных могут возникнуть требования по сбору статистики по данным, созданию индексов, применению сжатия в отношении повторяющихся дат и т. д., прежде чем можно будет полностью положиться на DWH.
Опять же, судя по собственному опыту, могу сказать: ожидать, что DWH будет работать в первый день запуска в производство, было бы наивно.
По мере развития проекта командам, работающим с ним, потребуется обучение использованию DWH. Также будут внедряться принципы управления данными, а качество данных и процесс очистки подвергнутся формализации. Вокруг проекта должна быть создана целая операционная модель, гарантирующая, что DWH будет соответствовать своему назначению.
Заключение
Это не исчерпывающий план действий. Возможно, в нем упущены несколько этапов, которые я посчитал менее важными в контексте данной статьи. Надеюсь, пяти основных шагов будет достаточно для того, чтобы вы извлекли необходимые уроки для себя и своего проекта DWH.
Читайте также:
- Как построить идеальное хранилище данных
- Эффективное итерирование по строкам в Pandas DataFrame
- Все что нужно знать о древовидных структурах данных
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Hanzala Qureshi: How to Create a Data Warehouse in 5 Important Steps
