Светлое будущее

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

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

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

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

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

Продолжение

Медленно меняющиеся измерения (часть 2)

Владелец хранилища данных должен решить, как реагировать на изменения в описаниях размерных сущностей, таких как «Сотрудник», «Клиент», «Продукт», «Поставщик», «Местоположение» и другие. За 30 лет изучения этого вопроса, я обнаружил, что необходимы только три различных типа реакций. Я называл эти медленно меняющиеся размеры (SCD) типами 1, 2 и 3. В прошлой статье, я описал Тип 1 (SCD Type 1), который перезаписывает измененные данные в измерении. В этой статье я разберу типы 2 и 3 (SCD Type 2 и SCD Type 3).

Тип 2 (SCD Type 2): добавление новой записи измерения

Давайте изменим сценарий предыдущей статьи, где я переписал поле «Город проживания» в записи сотрудника Ральфа Кимбалла, и предположим, что Ральф Кимбалл действительно переехал из Санта-Крус в Боулдер-Крик 18 июля 2008 года. Предположим, что наша политика заключается в точном отслеживании домашних адресов сотрудников в хранилище данных. Это классическое изменение SCD Type 2.

SCD Type 2 требует, чтобы мы выпустили новую запись сотрудника для Ральфа Кимбалла с 18 июля 2008 года. Это имеет много интересных побочных эффектов, а каких - узнаете у нас на сайте! Продолжение

Медленно меняющиеся измерения (часть 1)

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

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

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

Три типа

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

Продолжение

Различия между хранилищем данных и бизнес-аналитикой

Попробуйте спросить своего коллегу, в чем разница между бизнес-аналитикой и хранилищем данных. Я считаю, что многие люди, даже те, кто работает в BI-проектах и BI-индустрии, не понимают разницы. Большинство из них считают, что эти 2 термина взаимозаменяемы. Кто-то предпочитает использовать один термин вместо другого лишь потому, что он просто «звучит лучше». Многие полагают, что бизнес-аналитика – это не только хранилище данных, а нечто большее. Но если их спросить: «Какие системы бизнес-аналитики не являются системами хранилищ данных» или «какая часть бизнес-аналитики не является хранилищем данных», то большинство затрудняется ответить.

В наши дни термин «бизнес-аналитика», а не «хранилище данных» является нормой, используемой большинством поставщиков в отрасли. Большинство из них называют/классифицируют свои инструменты как программное обеспечение бизнес-аналитики, а не программное обеспечение хранилища данных. Название продукта Cognos – «Cognos 8 Business Intelligence». BusinessObjects обозначают себя как «BI-софтверная компания» и «мировой лидер в области программного обеспечения BI». Название одного из продуктов Hyperion – «Hyperion System 9 BI +». SAS Enterprise BI Server предоставляет полностью интегрированный комплексный набор программного обеспечения для бизнес-аналитики. Microsoft продвигает SQL Server 2005 как комплексную платформу бизнес-аналитики. Кажется, что только Kimball Group последовательно использует термин «хранилище данных». Билл Инмон, как изобретатель этого термина, также использует термин «хранилище данных».

Итак, давайте перейдем к деталям. Продолжение.

Азбука хранилища данных

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

Глоссарий состоит из 2 уровней. На первом уровне термины расположены в алфавитном порядка, а на втором – нет. Таким образом, лучший способ использовать этот глоссарий – поиск по странице (Ctrl-F).

Людям свойственно ошибаться, так что я уверен, что в этой статье есть ошибки. Я был бы признателен, если бы вы в чем-то поправили меня, используя комментарии под публикацией или написав мне на vrainardi@gmail.com.

Что меня сподвигло к написанию этой статьи: я заметил, что многие люди, работающие с хранилищем данных, часто не понимают некоторую стандартную терминологию. Даже самый простой термин, такой как «измерение», может быть для них иностранным словом. Мое намерение состоит в том, чтобы обеспечить «быстрый поиск», позволяя им понять термин примерно за 15 секунд или около того.

Почему бы им не использовать интернет-поиск или Википедию? Зачем создавать еще что-то? Потому что:

1. Для поиска информации в интернете требуется больше времени, особенно если вы новичок.
2. Страницы результатов поиска могут быть технически неправильными.
3. Иногда я придерживаюсь своего мнения или предпочитаю иначе расставлять акценты.

Archiving – Архивирование: подход, заключающийся в удалении старых данных из таблицы фактов и хранении их в другой таблице (обычно в другой базе данных). Довольно часто старые данные просто удаляются и больше нигде не хранятся. 

Продолжение 

 перевод статьи Vincent Rainardi

Таблица фактов со смешанными гранулами

Таблица фактов со смешанными гранулами – это таблица фактов, в которой у нас есть меры с различной гранулярностью. Например, одна мера является еженедельной, а другая – ежемесячной. В этом посте я хотел бы рассказать о преимуществах и недостатках этого подхода. Kimball Group однозначно заявила, что меры в таблице фактов должны иметь одинаковую гранулярность (см. главу 2 книги Кимбалла – The Data Warehouse Toolkit).

Но всегда проще объяснить на примере:

Это – витрина данных. В ней представлены еженедельные и ежемесячные меры, но отсутствуют ежедневные. Нужно ли нам создавать две таблицы фактов, одну еженедельную и одну ежемесячную, например вот такие (№1):

Или мы должны создать таблицу фактов смешанных гранул, например такую (№2):

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

select D.Week, sum(F.WeeklyMeasure) from FactMixedGrain F
join DimDate D on F.DimDate = D.DimDate group by D.Week

Результат:

select D.Month, sum(F.MonthlyMeasure) from FactMixedGrain F
join DimDate D on F.DimDate = D.DimDate group by D.Month

Результат:

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

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

Продолжение

Может ли машинное обучение заменить BI?

В течение последних 20 лет компании искали закономерности в данных вручную с помощью срезов данных. Найденные шаблоны применялись для принятия бизнес-решений. Однако в последние 2 года наметилась новая тенденция: внедрение машинного обучения для поиска закономерностей в данных и использование его для интеллектуальной аналитики.

Business Intelligence (Бизнес-аналитика)

Это – пример типичной информационной панели BI для продаж (источник). На панели мониторинга представлены данные о продажах. Сверху – это продажи и прибыль с течением времени и по продукту. А внизу – продажи по продавцам и прибыль по клиентскому сегменту и товарной группе.

На основании этих данных компания может принимать такие бизнес-решения, как:

1. Увеличить или уменьшить маржинальную прибыль для определенной группы продуктов.
2. Сосредоточить маркетинговые усилия на конкретном потребительском сегменте, чтобы увеличить продажи.
3. Реструктурировать отделы продаж, чтобы повысить эффективность продаж.

Таким образом, BI помогает руководству лучше управлять бизнесом, позволяя лучше понимать текущие и прошлые бизнес-ситуации.

Машинное обучение (ML – machine learning)

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

Продолжение