Виртуальные данные

Виртуальные хранилища данных

Виртуальные данные

к библиотеке   к оглавлению   визуальные среды — 4GL   технологии программирования

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

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

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

Кроме того, неизбежной проблемой при использовании ХД в бизнес-аналитике является избыточность.

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

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

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

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

Преодолеть вышеперечисленные проблемы позволяет концепция виртуального хранилища данных (ВХД).

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

Определение

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

Преимущества такого подхода очевидны.

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

При работе с ВХД пользователь, можно сказать, имеет дело с «иллюзией» хранилища данных (рис. 13). Виртуальность предполагает, что ВХД существует только до тех пор, пока работает соответствующее приложение. Как только оно завершает работу, виртуальное хранилище прекращает существование.

Рис. 13. Виртуальное ХД

Концепция ВХД имеет ряд недостатков по сравнению с ХД, где информация консолидируется физически.

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

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

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

А ВХД следует использовать в системах, ориентированных на анализ оперативной информации, актуальной только в течение ограниченного периода.

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

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

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

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

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

В одном случае запрос связывает фирму с данными из таблицы «Поставки», а в другом — с данными из таблицы «Отгрузки».

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

Рис. 14. Вариант организации ВХД

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

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

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

к библиотеке   к оглавлению   визуальные среды — 4GL   технологии программирования

Знаете ли Вы, что такое «Большой Взрыв»?Согласно рупору релятивистской идеологии Википедии «Большой взрыв (англ. Big Bang) — это космологическая модель, описывающая раннее развитие Вселенной, а именно — начало расширения Вселенной, перед которым Вселенная находилась в сингулярном состоянии. Обычно сейчас автоматически сочетают теорию Большого взрыва и модель горячей Вселенной, но эти концепции независимы и исторически существовало также представление о холодной начальной Вселенной вблизи Большого взрыва. Именно сочетание теории Большого взрыва с теорией горячей Вселенной, подкрепляемое существованием реликтового излучения…»В этой тираде количество нонсенсов (бессмыслиц) больше, чем количество предложений, иначе просто трудно запутать сознание обывателя до такой степени, чтобы он поверил в эту ахинею.На самом деле взорваться что-либо может только в уже имеющемся пространстве.Без этого никакого взрыва в принципе быть не может, так как «взрыв» — понятие, применимое только внутри уже имеющегося пространства. А раз так, то есть, если пространство вселенной уже было до БВ, то БВ не может быть началом Вселенной в принципе. Это во-первых.Во-вторых, Вселенная — это не обычный конечный объект с границами, это сама бесконечность во времени и пространстве. У нее нет начала и конца, а также пространственных границ уже по ее определению: она есть всё (потому и называется Вселенной).В третьих, фраза «представление о холодной начальной Вселенной вблизи Большого взрыва» тоже есть сплошной нонсенс.

Что могло быть «вблизи Большого взрыва», если самой Вселенной там еще не было? Подробнее читайте в FAQ по эфирной физике.

НОВОСТИ ФОРУМАРыцари теории эфира

Источник: http://bourabai.ru/tpoi/olap01-7.htm

Архитектура хранилищ данных: традиционная и облачная

Виртуальные данные

Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал. Предлагаю и вам познакомиться с данной статьей в моем переводе. и дополнения только приветствуются!
(Источник картинки)

Введение

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

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

Облачные хранилища данных имеют ряд отличий от традиционных хранилищ:

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

Традиционная архитектура хранилища данных

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

Трехуровневая архитектура

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

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

Kimball vs. Inmon

Два пионера хранилищ данных: Билл Инмон и Ральф Кимбалл предлагают разные подходы к проектированию.

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

Хранилище данных — это просто сочетание различных витрин данных, которые облегчают отчетность и анализ. Проект хранилища данных по принципу Кимбалла использует подход «снизу вверх».

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

Модели хранилищ данных

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

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

Звезда vs. Снежинка

Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.

Схема типа «звезда» имеет централизованное хранилище данных, которое хранится в таблице фактов.

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

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

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

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

ETL vs. ELT

ETL и ELT — два разных способа загрузки данных в хранилище.

ETL (Extract, Transform, Load) сначала извлекают данные из пула источников данных. Данные хранятся во временной промежуточной базе данных.

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

Затем структурированные данные загружаются в хранилище и готовы к анализу.

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

Организационная зрелость

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

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

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

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

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

Новые архитектуры хранилищ данных

В последние годы хранилища данных переходят в облако. Новые облачные хранилища данных не придерживаются традиционной архитектуры и каждое из них предлагает свою уникальную архитектуру. В этом разделе кратко описываются архитектуры, используемые двумя наиболее популярными облачными хранилищами: Amazon Redshift и Google BigQuery.

Amazon Redshift

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

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

На каждом узле данные хранятся в блоках, называемых срезами.

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

Redshift использует архитектуру MPP (Massively Parallel Processing), разбивая большие наборы данных на куски, которые назначаются слайсам в каждом узле. Запросы выполняются быстрее, потому что вычислительные узлы обрабатывают запросы в каждом слайсе одновременно. Узел Leader Node объединяет результаты и возвращает их клиентскому приложению. Клиентские приложения, такие как BI и аналитические инструменты, могут напрямую подключаться к Redshift с использованием драйверов PostgreSQL JDBC и ODBC с открытым исходным кодом. Таким образом, аналитики могут выполнять свои задачи непосредственно на данных Redshift. Redshift может загружать только структурированные данные. Можно загружать данные в Redshift с использованием предварительно интегрированных систем, включая Amazon S3 и DynamoDB, путем передачи данных с любого локального хоста с подключением SSH или путем интеграции других источников данных с помощью API Redshift.

Google BigQuery

Архитектура BigQuery не требует сервера, а это означает, что Google динамически управляет распределением ресурсов компьютера. Поэтому все решения по управлению ресурсами скрыты от пользователя. BigQuery позволяет клиентам загружать данные из Google Cloud Storage и других читаемых источников данных.

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

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

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

Panoply

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

Интеллектуальная инфраструктура данных Panoply включает в себя следующие функции:

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

По ту сторону облачных хранилищ данных

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

Однако пользователи по-прежнему сталкиваются с рядом проблем при их настройке:

  • Загрузка данных в облачные хранилища данных нетривиальна, а для крупномасштабных конвейеров данных требуется настройка, тестирование и поддержка процесса ETL. Эта часть процесса обычно выполняется сторонними инструментами;
  • Обновления, вставки и удаления могут быть сложными и должны выполняться осторожно, чтобы не допустить снижения производительности запросов;
  • С полуструктурированными данными трудно иметь дело — их необходимо нормализовать в формате реляционной базы данных, что требует автоматизации больших потоков данных;
  • Вложенные структуры обычно не поддерживаются в облачных хранилищах данных. Вам необходимо преобразовать вложенные таблицы в форматы, понятные хранилищу данных;
  • Оптимизация кластера. Существуют различные варианты настройки кластера Redshift для запуска ваших рабочих нагрузок. Различные рабочие нагрузки, наборы данных или даже различные типы запросов могут потребовать иной настройки. Для достижения оптимальной работы, необходимо постоянно пересматривать и при необходимости дополнительно настраивать конфигурацию;
  • Оптимизация запросов — пользовательские запросы могут не соответствовать передовым методам и, следовательно, будут выполняться намного дольше. Вы можете работать с пользователями или автоматизированными клиентскими приложениями для оптимизации запросов, чтобы хранилище данных могло работать так, как ожидалось
  • Резервное копирование и восстановление — несмотря на то, что поставщики хранилищ данных предоставляют множество возможностей для резервного копирования ваших данных, их нетривиально настроить и они требуют мониторинга и пристального внимания

Ссылка на оригинальный текст: panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud

Источник: https://habr.com/post/441538/

Виртуализация данных

Виртуальные данные

30.03.2011 Леонид Черняк

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

Теперь на первый план выходят не физические способы работы с устройствами (device centric), а логические методы работы с данными (data centric).

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

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

Виртуализация данных началась с воплощения различного рода сценариев, предназначенных для использования сервисных архитектур в форме таких технологических направлений, как информация как сервис (Information as a Service) и информация по требованию (Information On Demand, IOD). И то и другое не столько технологии, сколько концептуальный взгляд на них.

Концепцию «информация как сервис» впервые предложила в 2006 году аналитик IDC Сандра Роджерс в отчете Information as Service to the Enterprise, а идеи IOD примерно с того же времени стали частью глобальной пропагандистской кампании IBM.

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

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

Концепция IaaS получила развитие в таких трудах Forrester Research, как Enterprise Information Virtualization and the Information Fabric («Информационная инфраструктура и виртуализация корпоративной информации») и The Forrester Wave: Information-As-A-Service. До 2008 года аналитики Forrester использовали термин Enterprise Data Virtualization, но потом, следуя моде на злоупотребление словом без должного понимания его смысла, в компании заменили слово «данные» на «информацию».

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

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

Попробуем разобраться, что это означает и как соотносится с федерацией данных (Data Federation), интеграцией данных (Data Integration) и другими близкими понятиями.

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

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

Рис. 1. Общая схема виртуализации данных

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

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

При этом могут быть применены самые разные технические приемы:

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

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

Рис. 2. Компоненты системы виртуализации

То, что называют интеграцией информации предприятия (Enterprise Information Integration, EII), можно рассматривать как эмбриональный период виртуализации данных, который распространялся в основном на данные в табличных формах.

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

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

Самый примитивный — основной уровень (Basic Data Virtualization), затем идут средний, или продвинутый (Advanced Data Virtualization), и верхний, интеллектуальный (Intelligent Data Management).

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

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

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

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

Уровень Advanced Data Virtualization отличается использованием метаданных, хранимых в соответствующих каталогах, а технологии используют сведения о внутренних структурах источников данных и превращают все, в том числе и реляционные данные, в объекты. Объектный подход дает возможность реализовать желаемую связь типа «один ко многим» (hub and spoke).

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

Для материализации Advanced Data Virtualization используется постоянно работающий сервер метаданных (Persistent Metadata Server), который может не только выполнять предписанные ему функции, но и поддерживать работу Intelligent Data Management, обеспечивая как горизонтальное (увеличение числа источников), так и вертикальное масштабирование (наращивание функциональности). Преимущество Persistent Metadata Server в том, что такие системы работают на два-три порядка быстрее, чем реляционные СУБД, это происходит потому, что они имеют дело только с ссылками на данные. В отличие от Basic Data Virtualization, все в конечном итоге сводится к переадресации и установлению связей между источниками данных и потребителями, что обеспечивает глобализацию данных. Серверы могут собираться из специализированных программных лезвий (Application Software Blades), предназначенных для работы с приложениями таких компаний, как SAP, PeopleSoft или Siebel.

Применение решений класса Intelligent Data Management ведет к гармонизации данных – синхронизации по данным двух и более приложений. Подобного рода процесс должен обеспечивать работу в реальном времени и быть полностью автоматизированным. В конечном счете он должен приводить к единому пространству данных (One Data Continuum).

***

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

EII,Big Data,федерализация данных

Поделитесь материалом с коллегами и друзьями

Источник: https://www.osp.ru/os/2011/05/13009440/

Виртуальные данные

Виртуальные данные

Определение 1

Виртуальные данные — это симуляция реальных данных в информационной сфере.

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

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

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

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

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

Ничего непонятно?

Попробуй обратиться за помощью к преподавателям

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

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

В этой формулировке уже нет неопределённости и всё становится понятным с точки зрения логики.

Процесс виртуализации данных

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

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

Замечание 1

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

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

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

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

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

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

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

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

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

  • Наиболее простой или базовый (основной) уровень.
  • Уровень средней продвинутости (или продвинутый).
  • Самый высокий или интеллектуальный уровень.

Методы основного уровня являются по сути перемещением данных из одного места хранения на другое и их объединению, а применяемые при этом технологические приёмы предполагают работу со специалистами, которые занимаются администрированием данных.

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

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

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

Источник: https://spravochnick.ru/informacionnye_tehnologii/virtualnye_dannye/

Виртуальная реальность: обзор технологии комнат данных

Виртуальные данные

Юристы, которые занимаются сделками M&A (конечно, не только они), быстро привыкают к большому объему документов, с которыми надо знакомиться. Гигабайты данных подвергаются системному скрупулезному анализу, тщательно выверяются формулировки, цифры, сроки, обязательства и проч.

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

Это можно сделать, отправив запрошенные файлы по электронной почте или используя облачные хранилища вроде iCloud, Google Drive или Dropbox. Проблема обоих вариантов — безопасность. Может кто-то не знал, но небезопасно обмениваться важными документами просто по почте или скинув ссылку на Dropbox. В этой заметке рассмотрим полезную технологию, которая решает эти задачи.

Речь идет о виртуальных комнатах данных (у кого есть версия перевода получше — предлагайте; в оригинале — Virtual Data Room — VDR).

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

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

По этой причине, например, компания IBM ограничивает своих сотрудников от применения Dropbox и прочих аналогичных инструментов (https://www.slashgear.com/ibm-blocks-dropbox-and-icloud-as-well-as-siri-23229571/).

На рынке выделяются две группы VDR. В первую группу можно включить три наиболее известные VDR: Merrill Datasite (https://www.merrillcorp.com), RR Donnelley (https://yourvirtualdataroom.com) и Intralinks (http://www2.intralinks.

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

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

Вторая группа включает компании SecureDocs (https://www.securedocs.com) V-Rooms (https://www.vaultrooms.com) и Ansarada (http://info.ansarada.com). Эти системы более удобны в пользовании и сравнительно недорогие. 

Стоит отметить, что кроме указанных выше, особых отличий нет. Обе группы объединяет приоритет безопасности, например, все они соответствуют «золотому стандарту» для электронных финансовых операций — 256-битному AES SSL шифрованию и требуют мультифакторной аутентификации.

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

Есть возможности по установке динамичной подложки (dynamic watermarks), которые будут отражаться на каждом загруженном в VDR файле и могут сохранять информацию о дате загрузки, названии проекта, и даже имени и даже IP-адресе загрузившего файл лица.

https://www.youtube.com/watch?v=x1iEldMf4ZQ

Существует несколько факторов при выборе VDR. 

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

Цена. Большинство разработчиков строят ценовую политику на основе используемого места и количества времени, в течение которого VDR открыта.

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

Если же вы планируете пользоваться VDR регулярно для большого количества сделок в год, то приобретение подписки — ваш выбор. 

Удобство и функционал. Здесь необходимо учитывать формат файлов, с которыми может работать система, можно ли загружать zip, на каких ОС она доступна (Mac?). Если вы работаете с международными сделками, важно чтобы VDR была открыто круглосуточно и поддерживала несколько языков. Обратите внимание на то, есть ли бесплатная демо-версия. 

PS: Хотите следить за новостями Legal Tech? Подписывайтесь на канал Legal Tech News в Telegram, который я веду совместно с Закон.ру: https://t.me/LegalTechNews

Источник: https://zakon.ru/blog/2018/06/13/virtualnaya_realnost_obzor_tehnologii_komnat_dannyh

Booksm
Добавить комментарий