RSS

Хранилище данных – нужно ли оно вам?

10 января 2020 gromych

Принимаете ли вы бизнес-решения на основе данных из электронных таблиц или отдельных баз данных с нестандартными структурами и форматами? Видите ли вы несогласованность данных в разных отделах? Как вы решаете вопрос с разрешениями и уровнями доступа к ограниченным данным?

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

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

У компаний есть приложения, которые обрабатывают и хранят тысячи, даже миллионы транзакций каждый день. Возможность создавать, извлекать, обновлять и удалять эти данные стала реальностью благодаря базам данных, также называемым онлайн-системами обработки транзакций (OLTP). Хотя эти базы данных традиционно были реляционными (SQL Server, Oracle, MySQL, DB2 и т. Д.), в последнее время популярность получили нереляционные базы данных (Cassandra, MongoDB, Redis и т. д.) или файловые системы (такие как Hadoop) как альтернатива для хранения необработанных данных.

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

  1. Корпоративное хранилище данных – предоставляет центральное хранилище, предназначенное для поддержки принятия решений для всей компании.
  2. Оперативное хранилище данных – аналогично корпоративному хранилищу по объему, но данные обновляются почти в реальном времени и могут использоваться для оперативной отчетности.
  3. Витрина данных – это подмножество хранилища данных, используемое для поддержки определенного региона, бизнес-единицы или функциональной области (т. е. продажи).

Каковы основные различия между системами OLTP и OLAP?

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

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

Где находятся хранилища данных?

Поскольку объемы данных растут в геометрической прогрессии, хранилище данных становится критически важным, и следует учитывать оборудование, которое хранит, обрабатывает и обеспечивает средство перемещения данных. Хранилища данных могут размещаться на локальных ресурсах, в облаке или в сочетании этих двух сред. Ваше решение может зависеть от требований по хранению критически важных приложений организации на месте. Если вы ищете облачные решения, примите во внимание промышленные нормы, безопасность, видимость, доступность, задержку и надежность поставщиков облачных услуг. (Вот некоторые из ведущих поставщиков облачных услуг: Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud, Rackspace, Verizon Cloud и VMware.)

Так как же выглядит типичная реализация хранилища данных?

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

Сбор данных

Уровень сбора данных состоит из различных хранилищ данных – сюда входят системы ERP, CRM, электронные таблицы Excel, даже базы данных Access, содержащие корпоративные данные или данные из отделов. Подсистемы хранения, используемые этими приложениями, обычно не структурированы для упрощения запросов или навигации (если прямой доступ вообще возможен). Собственные отчеты могут быть возможны в некоторых из этих приложений, однако функциональные возможности, как правило, очень ограничены, а отчеты ограничены только данными в единой системе.

Чистка

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

Хранение

Слой Хранения представляет денормализованное хранилище данных, которое описано далее в этом посте. Хотя есть несколько моделей проектирования, подход Kimball – самый популярный вариант, в котором информация организована в таблицы измерений и фактов и объединена в звездообразные схемы для простоты использования.

Распространение

Уровень Распространения не является формальным уровнем, а представляет собой представление всех различных способов использования данных, находящихся в хранилище данных. Сюда входят: запросы с помощью инструмента отчетов/сводных панелей BI, прямые запросы SQL или даже автоматические извлечения для подачи в другие, не связанные системы.

Преимущества наличия хранилища данных

Хранилища данных помогут вам принимать более обоснованные решения по многим причинам:

  • Улучшенная бизнес-аналитика: при интеграции нескольких источников вы принимаете решения на основе ВСЕХ ваших данных.
  • Своевременный доступ к данным: быстрый доступ к критически важным данным в одном централизованном месте.
  • Повышение качества и согласованности данных: данные по всей организации стандартизированы и хранятся в одном и том же формате, поэтому все отделы принимают решения на основе единых данных.
  • Исторический анализ: поскольку хранилище данных хранит большие объемы старых данных, вы можете определить тенденции с помощью анализа по сравнению с прошлым годом.
  • Быстрое время отклика на запрос. Большинство хранилищ данных моделируют, строят и оптимизируют для доступа и чтения, что означает быстрое создание отчетов.
  • Анализ данных: вы можете исследовать «Большие данные», чтобы предсказать будущие тенденции.
  • Безопасность: хранилище данных упрощает представление, предоставляя доступ к определенным данным квалифицированным конечным пользователям, исключая при этом другие.
  • Аудит: данные, хранящиеся надлежащим образом в хранилище данных, обеспечивают полный журнал аудита, когда именно данные были загружены и из какого источника (источников).
  • Поддержка аналитических инструментов: аналитические инструменты, которые предлагают возможности детализации, работают лучше всего при извлечении данных из хранилища данных.
  • Требования государственного регулирования: благодаря хранилищу данных легче соблюдать требования Сарбейнса-Оксли и других связанных с этим правил, чем с некоторыми транзакционными системами.
  • Создание метаданных: описания данных могут храниться в хранилище данных, чтобы пользователи понимали данные в хранилище, что значительно упрощает создание отчетов.
  • Масштабируемость: если у вас есть объемы исторических данных, требующие консолидации, хранилище данных обеспечивает легкий доступ в общем месте и возможность масштабирования в будущем.
  • Производительность в режиме реального времени. Хранилище данных может объединять данные с разнородных источников с возможностями сохранения истории, как только данные станут доступны.

Что может произойти, если у вас нет хранилища данных

Давайте рассмотрим примерный сценарий: у компании XYZ есть три системы, которые используются для отслеживания потенциальных клиентов, в процессе продаж:

  • Приложение 1, веб-инструмент, используется для лидов от рекламы на сайте.
  • Приложение 2 используется для получения контактов потенциальных клиентов для прозвона, а также используется клиентскими службами для управления клиентом.
  • Приложение 3 используется для управления клиентами и постоянной поддержки существующих клиентов.

Четкого набора правил, чтобы определить, какой тип данных должен существовать в каждой из трех систем и когда данные должны перемещаться из приложения 1 в приложение 2 не существует. Из-за отсутствия согласованности и правил компания XYZ сталкивается со следующими проблемами:

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

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

3 вопроса, которые нужно задать, рассматривая хранилище данных

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

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

1. Храните ли вы данные в различных исходных системах?

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

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

2. Испытываете ли вы проблемы с производительностью при составлении отчетов по операционным системам?

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

3. Есть ли у вас единый «источник правды»?

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

Альтернативы традиционному хранилищу данных

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

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

Озера данных

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

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

  1. Все данные извлекаются и загружаются из исходной системы
  2. Все типы данных поддерживаются
  3. Преобразование и моделирование данных выполняется в соответствии с требованиями анализа

Самообслуживание в BI

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

  1. Случайные пользователи – обладают ограниченным набором навыков BI и требуют простых условий
  2. Опытные пользователи – опытные пользователи BI с возможностью анализировать данные и создавать новые отчеты и информационные панели с нуля.
  3. Бизнес-аналитики – имеют продвинутые навыки BI в области исследования, моделирования и развертывания сред BI.

Вот некоторые из самых популярных инструментов самообслуживания BI, доступных на рынке: Qlik, Tableau, Power BI, Sisense, Ateryx и Birst.

Нереляционные (без SQL)

Нереляционные БД – это архитектурный подход к проектированию баз данных, который не основан на традиционном представлении данных. Системы управления реляционными базами данных организуют данные в виде таблиц, столбцов, строк или схем для операций CRUD (создание, чтение, обновление и удаление). Для сравнения, базы данных NoSQL основаны не на реляционных структурах, а на более гибких моделях данных, обеспечивающих скорость, масштабируемость и гибкость. Это ключевые характеристики, необходимые для работы с «большими данными».

На рынке сегодня доступны различные типы баз данных NoSQL, и они делятся на четыре основные категории:

  1. Нереляционная база данных типа «ключ-значение» – эти базы данных используют связи между элементами в качестве модели данных, так что ключ связан только с одним значением в наборе. Обычно сохраненное значение является BLOB-объектом. Это означает, что никто не знает, каково значение данных, пока ключ не будет представлен в качестве идентификатора для обеспечения доступа. Базы данных типа «ключ-значение» включают DynamoDB, Azure Table Storage, Riak, и Redis.
  2. Базы данных документов – они хранят и извлекают документы в нескольких форматах, таких как XML, JSON и BSON. Вот популярные примеры таких хранилищ документов – Elastic, MongoDB, CouchDB, Terrastore, RavenDB, и Azure DocumentDB.
  3. Широкоформатные базы данных. Эти базы данных хранят данные в таблицах со строками и столбцами, аналогично традиционным реляционным базам данных. Однако имена и форматы столбцов могут варьироваться от строки к строке в таблице. Другими словами, столбцы связанных данных сгруппированы вместе, что позволяет извлекать связанные данные в одной операции запроса. С другой стороны, реляционные базы данных хранят строки в разных местах на диске, которые требуют многократного ввода-вывода для извлечения данных. Вот примеры таких БД: Hadoop, Cloudera, Cassandra, HBase, Amazon DynamoDB и Hypertable.
  4. Базы данных графиков. Эти базы данных используют структуры графиков для хранения, сопоставления и запроса взаимосвязей между объектами. Вот примеры таких БД: Sparksee, InfiniteGraph, New4J и OrientDB.

Опубликовано в рубрике Бизнес анализ, Технологии
«
»
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

64 queries in 0,210 seconds