{"id":13650,"url":"\/distributions\/13650\/click?bit=1&hash=b4a44ea9299acb416ac92e110a87e80acc960de1a8f124e06d52ec1ea62c252a","title":"\u041a\u0430\u043a \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u044b\u0439 \u0434\u043e\u043c \u043a\u0430\u043a \u0432 Sims","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
Dynamicsun

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

Перевод статьи "Три принципа разработки хранилища данных" - автор Toptal Data Warehouse Developer Chamitha Wanaguru.

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

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

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

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

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

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

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

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

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

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

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

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

Важно разграничивать понятия базы и хранилища данных:

База данных - это средство, с помощью которого вы храните свои данные.

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

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

Итак, обсудим 3 основных принципа разработки хранилища данных.

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

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

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

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

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

Второй принцип хранилища данных: создавайте ценность для бизнеса

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

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

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

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

Третий принцип хранилища баз данных: Подключи и пробуй

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

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

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

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

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

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

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

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

0
Комментарии
Читать все 0 комментариев
null