Введение

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

Регистрирующие системы создавались для автоматизации рутинных операций по ведению бизнеса – выписка счетов, оформление договоров, проверка состояния склада и т.д., и основными пользователями таких систем был линейный персонал. Основными требованиями к таким системам были обеспечение транзакционности вносимых изменений, и максимизация скорости их выполнения. Именно эти требования определили выбор реляционных СУБД и модели представления данных "сущность-связь" в качестве основных используемых технических решений при построении регистрирующих систем.

Для менеджеров и аналитиков в свою очередь требовались системы, которые бы позволяли:

Анализировать информацию во временном аспекте;

Формировать произвольные запросы к системе;

Обрабатывать большие объемы данных;

Интегрировать данные из различных регистрирующих систем.

Очевидно, что регистрирующие системы не удовлетворяли ни одному из вышеуказанных требований. В регистрирующей системе информация актуальна только на момент обращения к базе данных, в следующий момент времени по тому же запросу можно получить совершенно другой результат. Интерфейс регистрирующих систем рассчитан на проведение жестко определенных операций и возможности получения результатов на нерегламентированный (ad-hoc) запрос сильно ограничены. Возможность обработки больших массивов, данных также мала из-за настройки СУБД на выполнение коротких транзакций и неизбежного замедления работы остальных пользователей.

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

В основе концепции хранилища данных лежат две основные идеи - интеграция разъединенных детализированных данных (детализированных в том смысле, что они описывают некоторые конкретные факты, свойства, события и т.д.) в едином хранилище и разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа. Определение понятия "хранилище данных" первым дал Уильям Г. Инмон в своей монографии. 

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

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

Основная часть

1 Хранилище данных. Основные понятия

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

Для множества людей хранилище данных - это некая совокупность данных объединенных из различных источников, структурированная и оптимизированная для доступа к ним при помощи средств создания запросов OLAP (on-line analytical processing - оперативной аналитической обработки). Этот взгляд изначально распространялся поставщиками средств OLAP. Для других хранилище данных - это фактически некая база данных, содержащая данные более чем из одного источника, собранные для целей управления информацией. Это определение не является ни полезным, ни очевидным, поскольку такие базы данных служили для принятия решений задолго до возникновения самого термина "хранилище данных".

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

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

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

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

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

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

При таком объединении и исключении многих бизнес-данных, значительная часть информации может быть потеряна. В случае изменения требований к запрашиваемой информации, понадобятся другие сочетания бизнес-информации, в результате звездообразная или многомерная структура вскоре станет бесполезной. С другой стороны, нормализованная (упорядоченная) структура, содержащая данные делового уровня, сможет обеспечить любые альтернативные сочетания данных. И хотя для некоторых данных создать такую структуру не возможно, из-за ограничений по объему и/или по производительности, не следует отказываться от сохранения деловых данных низкого уровня в хранилище данных. Так как зачастую это единственная возможность предупредить потребности в соответствующей информации в будущем;

- оптимизированные модели, такие как схема "звезда", как правило, менее гибки по сравнению с нормализованными структурами. Нормализованные модели легче перестраиваются в случае изменения правил или требований бизнеса.

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

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

Стоимость проектов по хранению данных обычно довольно высока. Это объясняется, в первую очередь, необходимостью собрать, "очистить" и обобщить данные из различных источников, часто из наследственных систем. Такая работа весьма трудоемка и занимает много времени, в тоже время, она является необходимым звеном успеха для проекта - плохо интегрированные данные низкого качества - это неполная или бесполезная для управления информация. Стоимость извлечения, отбора и обобщения данных составляет 60-80% от общей стоимости обычного проекта по хранению данных, как и для любого другого проекта разработки средств для поддержки принятия решений.

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

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

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

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

Корпоративное хранилище данных (Data Warehouse) – это не система ключевых показателей эффективности (КПЭ, KPI), это не большая база данных, это не аналитический OLAP-инструмент, это не интеллектуальная система, позволяющая добывать новые данные и получать статистические зависимости, это не система единой НСИ – это все не ХД, если говорить о нем в контексте отдельно взятого пункта.

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

Потенциальные клиенты на корпоративное хранилище данных и что они получают?

Как определить потенциальных корпоративных клиентов, которым необходимо хранилище данных?

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

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

У клиента должна быть нормально работающая инфраструктура (серверов, соединенных витой пары или по USB порту, быть не должно). Если инфраструктуры у клиента нет – ему ее нужно продать.

Какие выгоды клиент получает от внедрения корпоративного хранилища данных?

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

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

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

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

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

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

Компоненты корпоративного хранилища данных предприятия

2 Принципы организации облачных хранилищ данных

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

Таких вариантов всего два:

Синхронизация файлов между несколькими устройствами.

Цель: обеспечить наличие актуальной информации на любом вашем устройстве.

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

Создание резервной копии ваших файлов.

Цель: обеспечить надёжное дополнительное хранилище для ваших данных.

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

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

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

Облачное хранилище данных, реальный пример использования №1: резервные копии файлов

Резервные копии своих файлов я условно делю на две категории:

1. Резервные копии файлов старых проектов. 

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

2. Резервные копии текущих проектов. При активной работе над проектом, в котором много постоянно изменяющихся файлов, создание ежедневной (или даже более частой) резервной копии просто необходимо. Для этого используется программу SyncBackFree, которая создаёт по расписанию или по моему запросу архив с нужными мне данными и помещает его в папку на жёстком диске компьютера. Содержимое этой папки копируется в облачное хранилище данных.

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

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

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

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

Этот архив будет автоматически помещён в облачное хранилище данных как резервная копия и далее скопирован на те компьютеры, для которых была указана синхронизация папки "Backups".

Таким образом, делается не одна резервная копия в облаке, а имеется возможность автоматически её растиражировать и на другие компьютеры, при необходимости!

Стоит учесть, что для этого способа должен быть быстрый, безлимитный Интернет и достаточно большой объём облачного хранилища данных. Также некоторые облачные хранилища накладывают ограничения на размер файлов для бесплатного использования (например, Box): у "облака" не должно быть такого ограничения.

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

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

Облачное хранилище данных, реальный пример использования №2: установка portable программ

Очень удобно в облачном хранилище данных создать папку "Program Files" и установить в неё portable-версии программ, которыми вы часто пользуетесь. Это касается Windows-программ.

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

Тоже самое можно сделать в облачном хранилище данных. Тогда на всех компьютерах, которые подключены к этому "облаку" будут автоматически установлены необходимые программы. Причём с одинаковыми настройками!

Облачное хранилище данных, реальный пример использования №3: размещение приватной информации

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

Например, список паролей для сайтов, вашу книгу контактов, банковскую информацию или домашнюю бухгалтерию. Особенно удобно так хранить пароли для сайтов.

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

Облачное хранилище данных, реальный пример использования №4: работа над проектом

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

Файлы проекта можно дополнительно защитить шифрованием. 

При этом "облако" обязательно должно иметь возможность хранения нескольких версий файлов, с возможностью загрузки файла любой версии.  Это, например, поддерживает Диск Google. 

Так можно получить примитивный вариант системы управления версиями, известной всем программистам.

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

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

Облачное хранилище данных, реальный пример использования №5: размещение файлов

Это - самый простой вариант использования облачного хранилища данных.

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

Заключение

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

Стоит только проанализировать информацию своего предприятия, как сразу становится ясно, как оно сможет развиваться, как изменятся требования к хранению его продуктов и покупательский спрос, а также как рынок будет реагировать на появление любой новинки. Именно в расчете на такие возможности многие крупнейшие компании начали строить - или уже построили - хранилища данных. Согласно недавнему исследованию META Group, 90 - 95% компаний списка Fortune 2000 активно применяют хранилища данных, чтобы добиться преимущества в конкурентной борьбе и получить значительно большую отдачу от своих инвестиций.

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

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

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

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

Вопрос о том, во сколько может обойтись разработка хранилища данных, сродни вопросу о том, насколько высоки деревья - деревья вообще. По мнению экспертов, разработки хранилища для небольшого подразделения может стоить от 400 до 600 тыс. долл.; автоматизация большого подразделения на большом предприятии “выливается” в сумму от 800 тыс. до 1,5 млн. долл.; большой корпорации придется израсходовать около 15 млн. долл. Цена зависит от объема данных и продолжительности их хранения. Столь же разнятся и сроки разработки - от шести месяцев до двух лет при создании крупного хранилища данных для большого предприятия.

Так или иначе, вкладывать средства в хранилище данных просто необходимо. В таком случае хочется хотя бы знать, как скоро они окупятся? За редкими исключениями, возврат инвестиций зависит от проекта, архитектуры и правильности управления хранилищем. Трехлетнее изучение опыта 62 организаций, проведенное International Data Corporation (IDC) показало, что эти организации истратили на хранилища данных в среднем 2,2 млн. долл. - и получили 400-процентный возврат своих инвестиций.

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

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

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

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