Облачное хранилище данных

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

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

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

Как работает облачное хранилище

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

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

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

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

Это интересно: Как защитить данные в облаке с помощью BoxCryptor

Плюсы и минусы облачного хранилища

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

Достоинства облака:

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

Недостатки облачного хранилища:

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

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

Как выбрать облачное хранилище

Размер облачного хранилища

Объяснять тут особо не нужно. Если вам нужен большой объем памяти, к примеру 5, 10 или 15 Гб, то найти такой вариант бесплатно возможно. А вот уже выше придется заплатить.

Отзывы о компании

Если компания, предоставляющее место для хранения себя зарекомендовала, то вы можете смело пользоваться их услугами. Не стоит использовать малознакомые сервисы. В качестве примера могу привести Dropbox, Облако Mail.ru, SkyDrive и прочие.

Увеличения объема хранилища

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

Программное обеспечение для компьютера и смартфона

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

Ограничения

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

Какие выбрать облачные хранилища 2017 года

• Облако Mail.ru – 100 Гб бесплатно.
• Mega – 50 Гб бесплатно
• MediaFire – 10 Гб бесплатно. Для получения дополнительного пространства, нужно поработать.
• SkyDrive – 25 Гб бесплатно.
• Copy – 15 Гб бесплатного пространства. За каждого приведенного клиента даётся 5 Гб.
• 4Sync – 15 Гб бесплатного пользования.
• Google Диск – бесплатно 15 Гб.
• Яндекс Диск – примерно 10-20 Гб бесплатного пространства.
• Dropbox – 5 Гб бесплатно, а к примеру 1 Тб за 100 долларов.

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

Какое облачное хранилище вы используете?

Рост вычислительных мощностей и развитие технологий виртуализации платформы x86 с одной стороны, и распространение ИТ-аутсорсинга с другой стороны привели к концепции utility computing (ИТ как коммунальная услуга). Почему бы не платить за ИТ так же, как за воду или электричество – ровно столько и ровно тогда, когда это нужно, и не более.
В этот момент и появилась концепция облачных вычислений – потребление ИТ услуг из «облака», т.е. из некоего внешнего пула ресурсов, не заботясь о том, как и откуда берутся эти ресурсы. Так же, как мы не заботимся об инфраструктуре насосных станций водоканала. К этому моменту была проработана и другая сторона концепции – а именно понятие ИТ-услуг и как ими управлять в рамках ITIL / ITSM.
Был разработан целый ряд определений облаков (облачных вычислений), но при этом не следует относиться к ним как к истине в последней инстанции – это лишь способ формализовать способы предоставления utility computing.

• «Облачные вычисления – это технология распределенной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис» Википедия
• «Облачные вычисления представляют собой модель для обеспечения удобного сетевого доступа к общему пулу настраиваемых вычислительных ресурсов (например, сетей, серверов, систем хранения данных, приложений и услуг) по требованию, которые можно быстро выделить и предоставить с минимальными управленческими усилиями или минимальным вмешательством со стороны поставщика услуг» NIST
• «Облачные вычисления – это парадигма обеспечения сетевого доступа к масштабируемому и гибкому пулу распределяемых физических или виртуальных ресурсов, предоставляемых в режиме самообслуживания и администрируемых по требованию» ISO/IEC 17788:2014. Information technology — Cloud computing — Overview and vocabulary.

Согласно NIST существует три основных типа облаков:

1. IaaS – Infrastructure as a Service — Инфраструктура как сервис
2. PaaS – Platform as a Service — Платформа как сервис
3. SaaS — Software as a Service Программное обеспечение как сервис

Для совсем упрощенного понимания разницы давайте рассмотрим модель Pizza-as-a-Service:
NIST определяет следующие необходимые черты ИТ услуги, позволяющие считаться облачной.

• Универсальный сетевой доступ (broad network access) – услуга должна иметь универсальный сетевой интерфейс, дающий возможность подключения и использования услуги практически кому угодно с минимальными требованиями. Пример – чтобы использовать электрическую сеть 220В достаточно подключиться к любой розетке со стандартным универсальным интерфейсом (вилка), который не меняется от того, чайник это будет, пылесос или ноутбук.
• Измеримость сервиса (measured service) – ключевой характеристикой облачной услуги является измеримость сервиса. Возвращаясь к аналогии с электричеством – вы оплатите ровно столько, сколько потребили с минимальной гранулярностью, вплоть до затрат на один раз вскипятить чайник, если за весь месяц вы были в доме один раз и выпили чашку чая.
• Самостоятельное конфигурирование сервисов по требованию (on demand self service) – облачный провайдер предоставляет заказчику возможность разумного конфигурирования сервиса, без необходимости взаимодействия с сотрудниками провайдера. Для того, чтобы вскипятить чайник совершенно необязательно заранее связываться с Энергосбытом и заранее их предупреждать и получать разрешение. С момента как дом подключен (заключен договор) все потребители могут самостоятельно распоряжаться предоставленной мощностью.
• Мгновенная эластичность (rapid elasticity) – облачный провайдер предоставляет ресурсы с возможностью мгновенного наращивания / снижения мощности (в определенных разумных рамках). Как только чайник включен – провайдер немедленно выдает в сеть 3 кВт мощности, и как только выключен – снижает выдачу до нуля.
• Объединение ресурсов в пул (resource pooling) – внутренние механизмы провайдера услуг позволяют объединять отдельные генерирующие мощности в общий пул (бассейн) ресурсов с дальнейшим предоставлением ресурсов как услуги различным потребителям. Включая чайник, нас менее всего волнует с какой конкретно электростанции поступает мощность. И все остальные потребители потребляют эту мощность вместе с нами.

Важно понимать, что описанные выше характеристики облака взяты не с потолка, а являются логическим выводом из концепции utility computing. И публичная услуга должна обладать этими характеристиками в рамках концепции. При несоответствии той или иной характеристике услуга не становится хуже и не становится «ядовитой», она всего лишь перестает быть облачной. Ну а кто сказал, что все услуги должны?
Почему я об этом отдельно говорю? За прошедшие 10 лет с момента появления определения NIST было много споров об «настоящей облачности» согласно определения. В США до сих пор иногда применяется в судебной сфере формулировка «соответствует букве закона, но не духу» — и в случае с облачными вычислениями главное именно дух, ресурсы в аренду в два клика мышью.
Необходимо отметить, что вышеперечисленные 5 характеристик применимы к публичному облаку, но при переходе к частному большинство из них становятся опциональными.

• Универсальный сетевой доступ (broad network access) – в рамках частного облака организация полностью контролирует как генерирующие мощности, так и клиентов-потребителей. Таким образом, данную характеристику можно считать автоматически выполняемой.
• Измеримость сервиса (measured service) – это ключевая характеристика концепции utility computing, оплата по факту потребления. Но как же оплачивать организации самой себе? В данном случае идет деление генерации и потребления внутри компании, ИТ становится провайдером, а бизнес-подразделения потребителями услуг. И взаиморасчет происходит между подразделениями. Возможно два режима работы: chargeback (при реальных взаиморасчетах и движении финансов) и showback (в виде отчетности в потреблении ресурсов в руб, но без движения финансов).
• Самостоятельное конфигурирование сервисов по требованию (on demand self service) – внутри организации может быть общая ИТ служба, и в этом случае характеристика теряет смысл. Однако при наличии собственных ИТ-специалистов или администраторов приложений в бизнес-подразделениях необходимо организовывать портал самообслуживания. Вывод – характеристика опциональна и зависит от структуры бизнеса.
• Мгновенная эластичность (rapid elasticity) – в рамках организации теряет смысл ввиду фиксированности набора оборудования для организации частного облака. Может ограниченно применяться в рамках внутренних взаиморасчетов. Вывод – для частного облака неприменимо.
• Объединение ресурсов в пул (resource pooling) – на сегодня уже практически не существует организаций, не применяющих серверную виртуализацию. Соответственно можно считать данную характеристику автоматически выполняемой.

Вопрос: Так что же такое все таки это ваше частное облако? Что компании нужно купить и внедрить, чтобы его построить?
Ответ: частное облако – это переход к новой административной модели взаимодействия ИТ-Бизнес, который на 80% состоит из административных мер и только на 20 из технологий.
Оплата только за потребленные ресурсы и легкий вход, без необходимости закопать несколько сотен миллионов нефти в капитальных затратах, обусловили новый технологический ландшафт и появление компаний-миллиардеров. Например современные гиганты Dropbox и Instagram появились как стартапы на AWS с нулевой собственной инфраструктурой.
Необходимо отдельно подчеркнуть, что инструменты управления облачными услугами становятся значительно более опосредованными, а ключевой обязанностью ИТ директора становится подбор поставщиков и контроль качества. Давайте рассмотрим проблематику этих двух новых обязанностей.
Появившись как альтернатива классической тяжелой инфраструктуре с собственными ЦОДами и железом, облака обманчиво легки. В облако легко войти, но вот вопрос выхода обычно обходится стороной. Как и в любой другой отрасли облачные провайдеры стремятся к защите бизнеса и усложнении конкуренции. Единственный серьезный конкурентный момент возникает лишь при первичном выборе поставщика облачных услуг, а далее поставщик приложит максимум усилий, чтобы заказчик от него не ушел. Причем далеко не все усилия будут направлены на качество услуг или их ассортимент. Прежде всего, это поставка уникальных услуг и использование нестандартного системного ПО, затрудняющего переход к другому провайдеру. Соответственно, при выборе поставщика услуг необходимо одновременно формировать план перехода от этого поставщика (по сути полноценный DRP – disaster recovery plan) и продумывать архитектуру хранения данных и резервных копий.
Второй важный аспект новых обязанностей ИТ директора – контроль качества услуг от поставщика. Практически все облачные провайдеры соблюдают SLA по собственным внутренним метрикам, что можем иметь крайне опосредованное значение к бизнес-процессам заказчика. И соответственно внедрение собственной системы мониторинга и контроля становится одним из ключевых проектов при переносе значимых ИТ систем к облачному провайдеру. Продолжая тему SLA необходимо подчеркнуть, что абсолютное большинство облачных провайдеров ограничивают ответственность за неисполнение SLA в месячный абонентский платеж или в долю от платежа. Например, AWS и Azure при превышении порога в доступности в 95% (36 часов в месяц) сделают 100% скидки к абонентской плате, а Яндекс.Облако – 30%.

Ну и конечно же, не надо забывать, что облака бывают не только в исполнении мастодонтов класса Amazon и слонов класса Яндекса. Облака бывают и поменьше — размером с кошку, или даже мышь. Как показал пример CloudMouse, иногда облако просто берет и заканчивается. Вы не получите ни компенсации, ни скидки — вы не получите ничего, кроме тотальной потери данных.
Ввиду указанных выше проблем с реализацией ИТ систем высокого класса бизнес критичности в облачных инфраструктурах в последние годы наблюдается явление «облачной репатриации».
К 2020 году для облачных вычислений пройден пик раздутых ожиданий и концепция находится на пути к канаве разочарований (согласно хайп циклу Гартнер). Согласно исследованиямIDCи 451 Research до 80% корпоративных заказчиков возвращают и планируют возвращать нагрузки из облаков в собственные ЦОДы по причинам:

• Повысить доступность / производительность;
• Сократить расходы;
• Для соответствия требованиям ИБ.

Что же делать и как все «на самом деле»?

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

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

Словарь бизнес-терминов. Академик.ру . 2001 .

Смотреть что такое «ИНФОРМАЦИОННОЕ ХРАНИЛИЩЕ» в других словарях:

информационное хранилище — ▲ хранилище картотека. библиотека. фильмотека. фонотека. фототека. инонотека. глиптотека. пинакотека. дендротека. игротека. книгохранилище. | компактус. фонд. банк. касса. альбом (# для марок). кляссер … Идеографический словарь русского языка

Информационное хранилище (Архитектура предприятия) — Информационное хранилище в системной архитектуре Совокупность информационных систем, включая базы данных и справочники, реализующих функциональность по описанию метаданных, по сбору, очистке, обогащению, консолидации первичной информации из… … Википедия

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

ГОСТ Р 43.2.1-2007: Информационное обеспечение техники и операторской деятельности. Язык операторской деятельности. Общие положения — Терминология ГОСТ Р 43.2.1 2007: Информационное обеспечение техники и операторской деятельности. Язык операторской деятельности. Общие положения оригинал документа: 3.1 абстрактный знак: Знак, выражающий абстрактное понятие в визуально… … Словарь-справочник терминов нормативно-технической документации

Архитектура предприятия — это наиболее общее и всестороннее представление предприятия, как хозяйствующего субъекта, имеющего краткосрочные и долгосрочные цели ведения своей основной деятельности, определенные миссией на региональном и мировом рынке, и стратегией развития … Википедия

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

Бэк-офис (Архитектура предприятия) — Бэк офис в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, организационно штатных подразделений, реализующих журнальный (регистровый) учет операций, совершенных… … Википедия

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

Отчётность (архитектура предприятия) — Отчётность в системной архитектуре Совокупность информационных систем, включая базы данных и справочники, автоматизирующих построение отчётности на основе данных из информационного хранилища. Примеры систем отчётности: система управленческой… … Википедия

Учёт (архитектура предприятия) — Учёт в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, органанизационно штатных подразделений, бизнес процессы, реализующих ведение бухгалтерского учета и отчетности… … Википедия

Распределенная обработка данных обязательно предполагает наличие банков и баз данных. Однако база данных — это не место, куда просто складывают данные: ими нужно пользоваться, актуализировать, изменять форматы и связи и совершать множество других действий. Если бессистемно наполнять базу информацией, то через некоторое время ею невозможно будет пользоваться — времени на поиск нужных данных будет уходить все больше и больше, пространство базы переполнится. В связи с этим данные необходимо «очищать» и структурировать, а для эффективной работы с ними требуются системы управления работой баз данных (Data Base Management System — DBMS). Индустрия создания баз данных и СУБД берет свое начало в 1960-е гг. и к настоящему времени достаточно развита, однако термин «хранилище данных» в современном понимании его появился относительно недавно. Идея хранилищ данных оказалось востребованной, так как во многих видах государственной, деловой, научной, социальной деятельности необходимы тематически объединенные и исторически очищенные совокупности данных. При этом постоянно возрастала потребность в более дешевых, точных и структурированных данных, а также большей оперативности получения, обработки и интегрирования данных.

К концу 1980-х гг., когда была в полной мере осознана необходимость интеграции корпоративной информации и надлежащего управления этой информацией, появились технические возможности для создания соответствующих систем, которые первоначально были названы «хранилищами информации» (Information Warehouse). Лишь в 1990-е гг., с выходом книги Билла Инмона, хранилища получили свое нынешнее наименование «хранилища данных» (Data Warehouse — DW).

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

В основе концепции хранилищ данных лежат три основополагающие идеи:

• 1) интеграция ранее разъединенных детализированных данных (исторические архивы, данные из традиционных систем обработки документов, разрозненных баз, данных, данные из внешних источников) в едином хранилище данных;
• 2) тематическое и временное структурирование, согласование и агрегирование;
• 3) разделение наборов данных, используемых для операционной (производственной) обработки, и наборов данных, применяемых для решения задач анализа.

Данные, помещаемые в хранилище, должны отвечать определенным требованиям: предметной ориентированности, интегрированности, поддержки хронологии и неизменяемости (табл. 11.1)

Таблица 11.1 Требования к данным, помещаемым в хранилище

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

Все данные о разных бизнес-объектах взаимно согласованы и хранятся в едином общекорпоративном хранилище

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

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

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

Понятие «хранилище данных» в первоначальном понимании было основано на понятии «распределенной витрины данных» (Distributed Data Mart — DDM). Вследствие этого в классическом исполнении хранилище данных было прежде всего репозиторием (сквозной базой данных) информации предприятия. Среда хранилища была предназначена только для чтения и состояла из детальных и агрегированных данных, которые полностью очищены и интегрированы. Кроме того, в репозитории хранится обширная и детальная история данных на уровне транзакций. С точки зрения архитектурного решения такое хранилище данных реализует свои функции через подмножество зависимых витрин данных (рис. 11.10).

Достоинствами архитектуры классического хранилища данных являются:

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

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

Рис. 11.10. Хранилище данных, реализующее свои функции через подмножество зависимых витрин данных

Кроме этого, при фильтрации и рафинировании «сырых» данных для такого хранилища обычно теряется очень много информации, которая может быть чрезвычайно полезной при бизнес-анализе. В связи с этим возникло понимание того, что хранилище, помимо механизмов извлечения данных (On-Line Transactional Processing— OLTP), репозитория и витрин, должно иметь соответствующее пространство для организации «сырых» данных и их многомерного анализа в режиме реального времени OLAP.

На сегодняшний день существует два основных подхода к архитектуре хранилищ данных . Это так называемые корпоративная информационная фабрика Инмона (рис. 11.11) и хранилище данных с архитектурой шины Кимболла (рис. 11.12).

Работа корпоративной информационной фабрики (Corporate Information Factory — CIF) начинается со скоординированного извлечения данных из источников. После этого загружается реляционная база данных, содержащая соответствующие очищенные и согласованные («атомарные») данные. Получившееся нормализованное хранилище используется для того, чтобы наполнить информацией дополнительные репозитории презентационных данных, т.е. данных, подготовленных для анализа. Эти репозитории, в частности, включают в себя специализированные хранилища для изучения и добычи данных на базе применения технологий извлечения полезной информации из «сырых данных» (Data Mining — DM). После этого основной и, в случае необходимости, дополнительные репозитории используются для формирования

Рис. 11.11. Корпоративная информационная фабрика Инмона

Рис. 11.12. Хранилище данных с архитектурой шины Кимболла

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

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

• ? использование реляционной модели организации атомарных данных и пространственной — для организации суммарных данных;
• ? итеративный или «спиральный» подход при создании больших хранилищ данных, т.е. «строительство» не сразу, а по частям. Это позволяет вносить изменения в небольшие блоки данных или программных кодов и избавляет от необходимости перепрограммировать значительные объемы данных. То же самое можно сказать и о потенциальных ошибках: они также будут локализованы в пределах сравнительно небольшого массива без риска испортить все данные хранилища разом;
• ? организация атомарных данных, что обеспечивает высокую степень детальности интегрированных данных и соответственно предоставляет корпорациям широкие возможности для манипулирования ими и изменения формата и способа представления данных по мере необходимости;
• ? рассмотрение хранилища данных в качестве концептуально и физически целостного объекта, а не механической коллекции разрозненных витрин данных.

Альтернативным подходом к архитектуре хранилищ данных является подход Кимболла — хранилище с архитектурой шины (Data Warehouse Bus — DWB) (см. рис. 11.12). В этой модели первичные данные преобразуются в информацию, пригодную для использования, на этапе подготовки данных. При этом обязательно принимаются во внимание требования к скорости обработки информации и качеству данных. Как и в модели Инмона, подготовка данных начинается со скоординированного извлечения данных из источников. Ряд операций совершается централизованно, например поддержание и хранение общих справочных данных, другие действия могут быть распределенными — в зависимости от поступившего запроса.

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

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

В качестве оригинальных особенностей подхода Кимболла можно отметить: использование двухуровневой архитектуры, которая включает в себя стадию подготовки данных, недоступную для конечных пользователей, и хранилище данных с архитектурой шины как таковое. В состав последнего входят несколько витрин атомарных данных, несколько витрин агрегированных данных и персональная витрина данных, но оно не содержит одного физически целостного или централизованного хранилища данных — это дает гибкость при использовании данных и пространственной модели организации данных с архитектурой «звезда» (Star Scheme).

Таким образом, хранилище данных с архитектурой шины обладает следующими характеристиками:

• ? является пространственным;
• ? включает в себя как данные о транзакциях, так и суммарные данные;
• ? содержит витрины данных, посвященные только одной предметной области или имеющие только одну таблицу фактов (Fact Table);
• ? может содержать множество витрин данных в пределах одной базы данных, отражающих показатели бизнес-процессов.

Хранилище данных Кимболла не является единым физическим репозиторием (в отличие от подхода Инмона). Это виртуальное хранилище — коллекция витрин данных, каждая из которых имеет архитектуру типа «звезда».

На рис. 11.13 показана схема типизированного корпоративного хранилища данных. Вопросы его проектирования, выбора

Рис. 11.13. Схема типизированного корпоративного хранилища данных

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

6.4. Информационные хранилища

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

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

• анализировать информацию во временном аспекте;
• формировать произвольные запросы к системе;
• обрабатывать большие объемы данных;
• интегрировать данные из различных регистрирующих систем.

Решением данной проблемы стала реализация технологии информационных хранилищ (складов данных).

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

Внутренние базы — локальные базы функциональных подсистем предприятия: базы бухгалтерского учета; базы финансового учета; базы кадрового учета и т. д.

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

Таблица 6.4. Отличия базы данных от информационного хранилища

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

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

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

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

Технология помещения данных в информационное хранилище представлена на рис. 6.16.

Данные, содержащиеся в информационном хранилище, обладают следующими свойствами:

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

Существует три вида информационных хранилищ:

• витрины данных;
• информационные хранилища двухуровневой архитектуры;
• информационные хранилища трехуровневой архитектуры.

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

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

Информационные хранилища трехуровневой архитектуры имеют структуру, представленную на рис. 6.19.

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

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

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