В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Лариса Меньшикова
экономический советник
департамента информационных систем
Банка России, к.ф.-м.н., доцент МИРЭА
Для эффективной работы аналитических приложений необходим единый непротиворечивый источник данных в историческом разрезе для загрузки в ВД этих приложений. Перед загрузкой данных в ХД их необходимо извлечь из источников и согласовать разнородные данные из различных источников.
Это можно сделать средствами, основная задача которых – извлечь данные из разных систем, привести их к согласованному виду и загрузить в хранилище:
На вход систем ETL/ELT поступают разнородные данные, которые необходимо сравнить, очистить, привести к единым форматам, обработать по требуемым вычислительным алгоритмам.
Программно-аппаратный комплекс должен обладать значительной пропускной способностью. Но еще важнее для него – это высокая вычислительная производительность. Поэтому лучшие из них способны обеспечивать высокую степень параллелизма вычислений, и даже работать с кластерами и вычислительными гридами.
Таким образом, вся информация об источниках данных используется на этапе ETL, поэтому средства ETL должны быть абстрагированы средствами ведения метаданных.
Сравнивая ETL и ELT, мы видим, что преимущества при загрузке и преобразовании данных неочевидны, ELT сталкивается с ограничениями SQL при преобразовании данных, и экономия на программно-аппаратном комплексе ELT приводит к финансовым затратам на создание программно-аппаратной тестовой копии ЦХД, потому не стоит менять типовые средства ETL на, как правило, доморощенные, более высокопроизводительные, но нетипизируемые средства ELT.
Данную архитектуру можно порекомендовать в том случае, если на предприятии внедрены разрозненные независимые витрины, и можно объединить содержащиеся в них данные, согласовать их между собой и проводить дальнейший анализ, используя уже все эти данные.
Эта архитектура востребована там, где единая модель данных или не нужна, или невозможна, и где для отчетов руководство использует сравнительно небольшой объем данных без необходимости детализации их происхождения и исходных составляющих. Поэтому на следующем этапе встает необходимость радикальной переработки, а по сути, создания заново глобального хранилища данных, ориентированного на хранение не отчетов, а показателей, из которых будут собираться отчеты.
С моей точки зрения, наиболее конструктивна идея соединить концепции ХД и в OLAP использовать ХД в качестве единственного источника интегрированных данных для всех ВД.
На первом уровне поддерживаются витрины данных на основе системы управления многомерными базами данных, предназначенной для оперативного анализа "сырых" данных. Такие СУБД почти идеально подходят для целей разработки OLAP-систем. Витрина не должна быть обязательно полностью сформированной. Она может содержать ссылки на ХД и добирать информацию по мере поступления запросов. Это несколько увеличивает время отклика, но снимает ограничения объема многомерной БД.
На втором уровне реализуется ЦХД с использованием реляционной СУБД. В нем хранятся интегрированные детализированные данные. СУБД обеспечивает эффективное хранение и управление данными большого объема, но не слишком хорошо соответствует потребностям OLAP-систем, в частности многомерного представления данных.
На третьем уровне поддерживаются различные витрины данных. При необходимости на этом уровне можно размещать детальные данные в реляционном или многомерном виде.
Вышеописанное многоуровневое ХД иногда называют глобальным хранилищем данных. Глобальное ХД напрямую реализует идею единого непротиворечивого источника достоверных данных для анализа. Помимо централизованного варианта, оно допускает распределенный в сети вариант с единым механизмом управления.
Данная архитектура позволяет проводить анализ всей совокупности данных большого объема.
Операционный склад данных ОСД (англ. ODS – Operational Data Store) – это предметно-ориентированный, интегрированный, изменяющийся набор данных, который содержит текущую (не историческую) детализированную информацию – оперативный склад данных. ОСД был предложен в 1998 г., с тем чтобы сократить время задержки между поступлением информации в ЦХД и возможностью ее оперативной обработки.
Однако, кроме стратегического анализа данных, многим компаниям требуется иметь возможность получать оперативные отчеты по данным из нескольких транзакционных систем (оперативный анализ).
Кроме задач оперативного анализа данных, ОСД могут использоваться при интеграции транзакционных систем. В этом случае они называются "оперативная база данных" – ODB (англ. operational database) В случае использования ODB информационные потоки между системами строятся таким образом, что обмен данными происходит между транзакционной системой и ODB, а не напрямую между транзакционными системами. Общее количество интерфейсов между системами, таким образом, сокращается. В качестве примера подобного ODB можно привести справочник контрагентов. Как правило, информация о контрагентах содержится в большинстве транзакционных систем. При этом в каждой информационной системе учитывается какой-то свой блок информации и выделить одну систему в качестве главной (в которой будут заводиться контрагенты, а затем распространяться в другие системы) не всегда возможно. Для решения данной задачи создается ODB, в которую из транзакционных систем попадает информация о контрагентах (из каждой системы свой блок информации). Таким образом, получаем единый справочник контрагентов, в котором содержится максимально полная информация. При этом в ODB должен быть реализован механизм поиска "двойников", по которому система будет определять, что такой контрагент уже существует.
Прямая работа пользовательских программ с ЦХД допустима, если пользовательские запросы не препятствуют нормальному функционированию ЦХД, если между пользователями и КХД имеются высокоскоростные линии связи или если случайный доступ ко всем данным не ведет к серьезным потерям. Администрирование прямого доступа пользователей к КХД представляет собой чрезвычайно сложную задачу.
Витрины данных, содержащие информацию, предназначенную для выделенной группы пользователей, снижают риски нарушения требования информационной безопасности.
Причиной необходимости создания витрин данных является требование к надежности КХД, которое часто определяется, как пять или четыре девятки. Это означает, что КХД может простаивать не более 5 минут в год (99,999%) или не более часа в год (99,99%). Создание комплекса с такими характеристиками является сложной и весьма недешевой инженерной задачей. Требования к защите от терактов, саботажа и стихийных бедствий еще более усложняют построение программно-технического комплекса и осуществление соответствующих организационных мероприятий. Наличие витрин данных резко снижает нагрузку на КХД как по количеству пользователей, так и по объему данных в хранилище, так как эти данные могут быть оптимизированы под хранение, а не под обслуживание запросов. При использовании средств SRD (Sample, Restructure, Delivery – выборка, реструктуризация, доставка) количество пользователей сокращается до 1. В этом случае вся логика информационного снабжения витрин сосредотачивается в SRD. Витрины могут быть оптимизированы под обслуживание пользовательских запросов.
В случае если приложения реализованы с использованием сервис-ориентированной архитектуры (СОА), то вместо средств ETL/ELT в ЦХД и вместо средств SRD в ВД используется интеграционная шина, предназначенная для интеграции Web-сервисов и приложений, которая выполняет следующие функции:
ЦХД, ОСД, системы ведения метаданных и НСИ обращаются к шине как независимые приложения с запросами к источникам данных на обновление данных; при этом возрастает нагрузка на системы – источники данных, так как одна и та же информация многократно передается по запросам в ЦХД, ОСД, а также в системы управления метаданными и НСИ. В витрины необходимо передавать большой объем данных, что может быть решено с помощью передачи двоичных объектов. Необходимая реструктуризация данных не может быть возложена на шину и должна выполняться либо в ЦХД, либо в витрине. Эта функция может быть решена с помощью сервиса-посредника, принимающего данные и передающего их в витрины данных после реструктуризации. То есть мы возвращаемся к идее средства SRD с шинным интерфейсом.
Таким образом, интеграционная шина может быть использована в архитектуре КХД как транспортная среда между источниками данных и ETL и между SRD и витринами данных в тех случаях, когда компоненты КХД территориально разнесены и находятся за межсетевыми экранами в соответствии со строгими требованиями к защите информации.
Облачное хранилище данных – модель онлайн-хранилища, в котором данные хранятся на многочисленных распределенных в сети серверах, предоставляемых в пользование клиентам третьей стороной, внутренняя структура серверов клиенту в общем случае не видна. Данные хранятся и обрабатываются в так называемом облаке, которое представляет собой, с точки зрения клиента, один большой виртуальный сервер.
Опубликовано: Журнал "Технологии и средства связи" #1, 2012
Посещений: 13992
Статьи по теме
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
