Три принципа разработки хранилища данных

По оценкам Gartner, от 70 до 80 процентов новых проектов бизнес-аналитики терпят неудачу. Это связано с множеством причин, от неправильного выбора инструмента до отсутствия связи между ИТ-отделом и заинтересованными сторонами бизнеса. Успешно реализовав проекты бизнес-аналитики в разных отраслях, я надеюсь поделиться своим опытом в этом сообщении в блоге и выделить основные причины, по которым проекты бизнес-аналитики терпят неудачу. В этой статье будут представлены контрмеры на случай отказа, основанные на трех принципах, которыми следует руководствоваться при построении хранилищ данных. Следование этим концепциям хранилища данных должно помочь вам, как разработчику хранилища данных, ориентироваться на пути разработки, избегая обычных выбоин или даже воронок реализаций BI.

Реализация хранилища данных бизнес-аналитики

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

• Ценность: проекты бизнес-аналитики могут длиться многие месяцы или даже годы. Однако важно показать преимущества хранилища данных заинтересованным сторонам вашего бизнеса на самом раннем этапе проекта, чтобы обеспечить постоянное финансирование и интерес. В идеале заинтересованным сторонам следует продемонстрировать некоторую значимую коммерческую ценность новой системы в течение первых трех недель проекта.
• BI с самообслуживанием: дни ожидания от ИТ-отдела выполнения запросов на данные или проведения анализа данных прошли. Успех любого проекта BI теперь измеряется тем, насколько хорошо он позволяет бизнес-пользователям самостоятельно извлекать выгоду из системы.
• Стоимость: Проекты BI обычно имеют относительно высокие первоначальные затраты на реализацию. Чтобы уравновесить и компенсировать высокие первоначальные затраты, важно проектировать склады с низкими затратами на техническое обслуживание. Если клиенту требуется полноценная команда разработчиков бизнес-аналитики для проверки/диагностики проблем с качеством данных, внесения рутинных изменений в модели данных или обработки сбоев ETL, система будет дорогостоящей для бюджета и рискует быть отключенной через некоторое время. .
• Адаптивность: способность адаптироваться к изменяющимся требованиям бизнеса имеет решающее значение. Важно помнить о бесчисленном количестве инструментов бизнес-аналитики, доступных на рынке, и о том, с какой скоростью они развиваются, добавляя дополнительные функции и функции. В сочетании с тем, что бизнес постоянно развивается, требования к складу будут меняться; адаптивность требует, чтобы хранилища данных были спроектированы таким образом, чтобы в будущем можно было использовать альтернативные инструменты бизнес-аналитики, такие как различные серверные части или инструменты визуализации, и чтобы их можно было адаптировать к часто непредвиденным изменениям требований.

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

Что такое хранилище данных?

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

Хранилища данных часто рассматриваются как системы бизнес-аналитики, созданные для удовлетворения повседневных потребностей бизнес-структуры в отчетности. К ним не предъявляются такие же требования к производительности в реальном времени (в стандартных реализациях), как к системам данных OLTP, и в то время как системы OLTP будут содержать данные, относящиеся только к одному небольшому подмножеству бизнеса, хранилища данных стремятся охватить все данные, относящиеся к бизнес .

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

Хранилище данных состоит из многих компонентов, и это не просто база данных:

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

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

Первый принцип хранилища данных: качество данных превыше всего

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

Чтобы обеспечить доверие пользователей к системе хранилища данных, любые недостоверные данные, обнаруженные бизнес-пользователями, должны быть расследованы в приоритетном порядке. Чтобы помочь в этих усилиях, в платформу должны быть встроены структуры передачи данных и управления данными, чтобы гарантировать, что любые проблемы с данными могут быть идентифицированы и быстро устранены персоналом службы поддержки. Большинство платформ интеграции данных интегрируют в той или иной степени решения для обеспечения качества данных, такие как DQS в MS SQL Server или IDQ в Informatica.

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

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

Второй принцип хранилища данных: переверните треугольник

На этом рисунке показано разделение усилий при реализации и использовании большинства хранилищ данных.

Большая часть усилий затрачивается на создание и обслуживание хранилища, в то время как добавленная стоимость от наличия хранилища для бизнес-аналитики составляет гораздо меньшую часть усилий. Это еще одна причина, по которой проекты бизнес-аналитики часто терпят неудачу. Иногда в цикле проекта требуется слишком много времени, чтобы показать клиенту какую-либо значимую ценность, и когда система, наконец, установлена, по-прежнему требуется много усилий ИТ-отдела, чтобы извлечь из нее какую-либо ценность для бизнеса. Как мы уже говорили во введении, проектирование и развертывание систем бизнес-аналитики может быть дорогостоящим и длительным процессом. Таким образом, заинтересованные стороны справедливо рассчитывают быстро начать пожинать плоды своих усилий по бизнес-аналитике и хранению данных. Если никакой добавленной стоимости не материализуется, или если результаты просто слишком поздние, чтобы иметь какую-либо реальную ценность, ничто не мешает им выдернуть вилку из розетки.

Второй принцип разработки хранилища данных — перевернуть треугольник, как показано здесь.

Ваш выбор инструментов бизнес-аналитики и инфраструктур, которые вы внедряете, должен гарантировать, что большая часть усилий, затрачиваемых на склад, будет направлена ​​на извлечение ценности для бизнеса, а не на ее создание и поддержание. Это обеспечит высокий уровень вовлеченности заинтересованных сторон вашего бизнеса, поскольку они сразу увидят ценность инвестиций в проект. Что еще более важно, вы позволяете бизнесу быть самодостаточным в извлечении ценности, не имея такой сильной зависимости от ИТ.

Вы можете придерживаться этого принципа, следуя методологиям поэтапной разработки при создании хранилища, чтобы обеспечить максимально быстрое развертывание производственных функций. Следование стратегии витрины данных Кимбалла или методологиям проектирования хранилища данных Data Vault от Linstedt поможет вам разработать системы, которые строятся поэтапно, обеспечивая при этом плавный учет изменений. Используйте семантический уровень на своей платформе, такой как куб MS SSAS или даже юниверс Business Objects, чтобы обеспечить простой для понимания бизнес-интерфейс для ваших данных. В первом случае вы также предоставите пользователям простой механизм запроса данных из Excel — по-прежнему самого популярного инструмента анализа данных.

Внедрение инструментов бизнес-аналитики, поддерживающих бизнес-аналитику с самообслуживанием, таких как Tableau или PowerBI, только поможет повысить вовлеченность пользователей, поскольку интерфейс для запроса данных теперь значительно упрощен по сравнению с написанием SQL.

Сохранение исходных данных в озере данных перед заполнением базы данных поможет предоставить исходные данные пользователям на самом раннем этапе процесса адаптации. По крайней мере, опытные пользователи, такие как специалисты по количественному анализу бизнеса, теперь смогут обрабатывать исходные данные (через необработанные файлы), подключая такие инструменты, как Hive/Impala, поверх файлов. Это поможет сократить время, необходимое бизнесу для анализа новой точки данных, с недель до дней или даже часов.

Третий принцип хранилища баз данных: Plug and Play

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

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

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

Например, производительность ETL значительно повышается при использовании хранимых процедур в базе данных для создания новых данных бизнес-аналитики, а не при извлечении и обработке данных вне базы данных с помощью Python или SSIS. Что касается уровня отчетов, инструменты визуализации будут предлагать определенные функции, которые недоступны в других — например, Power BI поддерживает пользовательские запросы MDX, а Tableau — нет. Моя цель не в том, чтобы защищать отказ от хранимых процедур или отказ от кубов SSAS или Tableau в ваших системах. Мое намерение состоит в том, чтобы просто пропагандировать важность внимательности при обосновании любых решений, связанных с тесной связью вашей платформы с ее инструментами.

Еще одна потенциальная воронка находится на уровне интеграции. Такой инструмент, как SSIS, очень легко использовать для интеграции данных благодаря его возможностям отладки или простоте использования с платформой SQL Server. Однако перенос сотен пакетов SSIS на другой инструмент стал бы очень дорогим проектом. В тех случаях, когда вы в основном делаете «EL», попробуйте использовать общий инструмент для обработки. Использование языка программирования, такого как Python или Java, для написания одного универсального загрузчика для загрузки вашего промежуточного слоя поможет сократить количество отдельных пакетов SSIS, которые вам потребовались бы в противном случае. Этот подход не только помогает снизить затраты на обслуживание и будущую миграцию, но также помогает автоматизировать больше аспектов процесса загрузки данных, избавляя от необходимости писать новые отдельные пакеты (в соответствии с принципом 2).

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

Подведение итогов

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

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