Управление жизненным циклом информации

Изменение ценности информации с течением времени.

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

Управление жизненным циклом информации (Information Lifecycle Management - ILM)

Проблемы клиента

· • В настоящее время расходы на хранение составляют более 15% ИТ-бюджетов

· • Ежегодно объемы данных растут более чем на 50%

· • В большинстве случаев дисковые устройства хранения используются менее чем на 50%, 40% из них являются избыточными

· • В мире существуют более 20 тысяч нормативных актов, включающих требования к хранению данных

Многоуровневое хранение – подход к определению различных уровней хранения для снижения затрат на хранение. Каждый уровень имеет различные степени защиты, производительности, частоты доступа к данным и пр. Информация хранится и передается между уровнями, исходя из ее ценности с течением времени.Процесс реализации ILM-стратегии состоит из 4 видов деятельности:

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

Для классов информации следует задать уровень обслуживания с точки зрения производительности (количество операций ввода/вывода в секунду IOPS), доступности (например, 99.999%, ежедневный backup, ежечасное создание «снимков» — snapshot), катастрофоустойчивости или специальных требований как WORM (WriteOnce Read Many – не стираемый архив).

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

С другой стороны, пользователи могут переоценить предъявляемые требования. В этом случае лучше провести статистический анализ с помощью инструментов класса Storage Resource Management (Управление ресурсами хранения). Например, сотрудники финансового департамента просят предоставить скорость доступа к финансовым отчетам за последний год не ниже 1 сек. реакции приложения, мотивируя необходимостью в частом использовании данных за текущий финансовый год, в то время как статистика их доступа показывает, что около 70% их доступа приходится на данные текущего квартала и лишь 20% доступа – на другие кварталы финансового года. В описанной ситуации лучше разделить данное требование на два класса информации в зависимости от даты последнего доступа.

Фиксированный контент

По мере устаревания информации она все меньше подлежит изменению, становится «фиксированной», но к ней продолжают обращаться пользователи. Такие данные называют фиксированным контентом. Это документы, сообщения электронной почты, web-страницы.Несмотря на то, что традиционные технологии (оптические диски, ленточные носители и магнитные диски) позволяют хранить контент, ни одна из них не отвечает уникальным требованиям по хранению фиксированного контента и доступа к нему. Система хранения с контентной адресацией (CAS) Архитектура предназначена для безопасного онлайнового хранения и извлечения фиксированного контента.В отличие от доступа к данным файлового или блочного уровня, при котором используются имена файлов и физическое размещение хранимых данных, CAS хранит данные пользователя и их атрибуты в виде отдельных объектов. Примеры: · Электронные документы (контракты, претензии, вложения электронных писем, финансовые аналитические таблицы)· Цифровые записи (документы, исторические справки, чеки, фотографии, исследования)· Мультимедийные данные (медицинские рентгенограммы, томограммы; видеофильмы, видеонаблюдение, голосовая почта, радио) Архив представляет собой хранилище, в котором размещен фиксированный контент.Архивы часто хранятся на устройствах однократной записи и многократного считывания (WORM), например CD. Однако традиционный процесс архивирования не оптимизирован для распознавания контента, поэтому один и тот же контент может быть заархивирован несколько раз. Кроме того ленты и оптические носители подвержены износу, что важно для мультимедийной информации. Частые изменения в технологии ведут к дополнительным затратам на преобразование медиафайлов в новые форматы. В банковской деятельности, финансовой сфере, медицине есть специальные стандарты, касающиеся архивных данных (достоверность, целостность, доступность).CAS – альтернатива ленточным и оптическим носителям.· Подлинность контента (достоверность достигается путем создания уникального адреса контента и его автоматической непрерывной проверки)· Целостность контента (неизменность – при изменении контента присваивается новый адрес, а не заменяется контент)· Независимость от местоположения (уникальный идентификатор контента для извлечения данных)· Единичное хранение (уникальная подпись каждого экземпляра объекта) · Контроль за сохранностью данных (объект и метаобъект, хранящий атрибуты объекта и нормативы (сроки хранения))· Защита на уровне записи и утилизации (резервная копия)· Независимость от технологии· Быстрый поиск записанных данных Примеры: Больница: Рентгенограммы (от 15 Мб до 1 Гб). Хранение локально 60-90 дней. Необходимо хранить минимум 7 лет. Банк. Изображения чеков (25 Кб). 50-90 млн. чеков в месяц.
В первые 60 дней 250000-45000 запросов для верификации. Далее 1 запрос на 10000 чеков. Размер архива до 100 Тб. Реализация EMC Centera: RAID (redundant array of independent disks — избыточный массив независимых жёстких дисков) — массив из нескольких дисков, управляемых контроллером, взаимосвязанных скоростными каналами и воспринимаемых внешней системой как единое целое. До 32 узлов. 1 узел более 1 Тб. Масштабируется для хранения до петабайт содержанияАрхитектура Centera – избыточный массив независимых узлов (RAIN) Требование – непрерывность бизнеса Причины недоступности информации: запланированные простои (80%), незапланированные (20%), катастрофы (<1%)CBMO - среднее время между отказамиCBB – среднее время восстановленияДИ – время работоспособного состояния - часть периода времени, когда система готова к выполнению требуемых функций.ДИ = CBMO / (CBMO+CBB), %

ДИ,%	Время простоя, %	Время простоя в год	Время простоя в неделю
98	2	7,3 дня	3 ч. 22 мин.
99	1	3,65 дня	1 ч. 41 мин.
99,8	0,2	17 ч. 31 мин.	20 мин. 10 сек.
99,9	0,1	8 ч. 45 мин.	10 мин. 5 сек.
99,99	0,01	52,5 мин.	1 мин.
99,999	0,001	5,25 мин.	6 сек.
99,9999	0,0001	31,5 сек	0,6 сек.

Средняя время простоя в час = средняя потеря производительности в час + средняя потеря дохода в час, гдеПотеря производительности в час = (ФОТ в неделю)/(среднее кол-во рабочих часов в день)Средняя потеря дохода в час = (общий доход организации в неделю) / (среднее кол-во часов в неделю, когда организация открыта) Аварийное восстановление Аварийный перезапуск (с помощью зеркальных копий) Директивный срок восстановления (RPO). Момент времени, к которому система должна быть восстановлена после простоя. Если RPO – 6 час., то копия должна создаваться минимум 1 раз в 6 час. Если RPO – 0, то данные синхронно перенаправляются в удаленное местоположение. Директивное время восстановления (RTO). Промежуток времени, за который системы, приложения и функции восстанавливаются после простоя. Разное оборудование при разном RTO. RTO 72 часа – восстановление с магнитных лент, RTO 4 часа – хранилище данных, RTO менее 1 часа – кластерные серверы с зеркалированием

Извлечение данных (ETL)

Извлечение данных из разнотипных источников и перенос их в ХД с целью дальнейшей аналитической обработки связаны с рядом проблем:

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

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

· Исходные данные, как правило, являются «грязными» (отсутствующие, неточные или бесполезные данные с точки зрения практического применения), что мешает их корректному анализу.

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

ETL — комплекс методов, реализующих процесс переноса исходных данных из различных источников в аналитическое приложение или поддерживающее его хранилище данных.

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

Извлечение данных.

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

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

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

· извлечение данных при помощи встроенных в СУБД механизмов импорта/экспорта данных. Использование таких механизмов, как правило, обеспечивает более быстрое извлечение данных, чем с помощью команд SQL;

· извлечение данных с помощью специально разработанных приложений.

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

Преобразование данных

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

· Преобразование типов данных:

· Преобразования, связанные с нормализацией или денормализацией схемы данных

· Преобразования ключей, связанные с обеспечением соответствия бизнес-ключей суррогатным ключам ХД.

· Преобразования, связанные с обеспечением качества данных в ХД.

Как правило, данные источников не обладают необходимым уровнем качества данных. Заметим, что данные в ХД должны быть:

· точными – данные должны содержать правильные количественные значения метрик или давать объяснения, почему невозможно такие значения иметь;

· полными – пользователи ХД должны знать, что имеют доступ ко всем релевантным данным;

· согласованными – никакие противоречия в данных не допускаются: агрегаты должны точно соответствовать подробным данным;

· уникальными – одни и те же объекты предметной области должны иметь одинаковые наименования и идентифицироваться в ХД одинаковыми ключами;

· актуальными – пользователи ХД должны знать, с какой частотой данные обновляются (т.е. на какую дату данные действительны).

Очистка

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

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

Очистку данных можно разделить на следующие типы:

· конвертация и нормализация данных (приведение к одинаковому кодированию текста, форматам даты и т. д.);

· стандартизация написания имен, представления адресов, устранение дубликатов;

· стандартизация наименований таблиц, индексов и т.д.;

· очистка, основанная на бизнес-правилах предметной области.

Загрузка данных

Основная цель процесса загрузки данных состоит в быстрой загрузке данных в ХД.

Особенности:

1) Загрузка данных, основанная на использовании команд обновления SQL, является медленной. Поэтому загрузка с помощью встроенных в СУБД средств импорта/экспорта является предпочтительной.

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

3) Следует максимально использовать параллелизм при загрузке данных.

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

Обобщенная структура процесса ETL

Архитектуры хранилищ данных

Реляционные ХД используют классическую реляционную модель, характерную для оперативных регистрирующих OLTP-систем. Данные хранятся в реляционных таблицах, но образуют специальные структуры, эмулирующие многомерное представление данных. Такая технология обозначается аббревиатурой ROLAP — Relational OLAP.

Многомерные ХД реализуют многомерное представление данных на физическом уровне в виде многомерных кубов. Данная технология получила название MOLAP — Multidimensional OLAP.

Гибридные ХД сочетают в себе свойства как реляционной, так и многомерной модели данных. В гибридных ХД детализированные данные хранятся в реляционных таблицах, а агрегаты — в многомерных кубах. Такая технология построения ХД называется HOLAP — Hybrid OLAP.

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