Несколько поколений ИТ-специалистов получили образование, базирующееся на статистической теории информации, и они не подвергают сомнению тождественность понятий «информация» и «данные». Статистическая теория Клода Шеннона (а точнее — теория трансляции сигналов) не акцентируется на различиях между данными и информацией, поскольку с точки зрения передачи данных в этом нет нужды. Пока в компьютерном мире доминировала коммуникационная модель (иначе ее можно назвать «жестко связанной»), такого представления было достаточно, но с появлением слабо связанных систем возникла необходимость в соответствующем определении понятия «информация».
Эти системы должны не только передавать или хранить информацию в виде последовательности битов, но и интерпретировать получаемые процессами и модулями сообщения. Иными словами, нужно учитывать символическое представление информации и ее смысл. Если не углубляться в философские и кибернетические определения, а довольствоваться уровнем прагматики, можно довольствоваться формулой «информация = данные + метаданные». В ее справедливости можно убедиться на примере распределенных хранилищ данных.
Хранилище данных — централизованное или децентрализованное?
Для решения задач управления современным предприятием необходим единый информационный архив с хорошими средствами доступа к данным. Как ответ на эту потребность сравнительно недавно сложилась категория программных средств, названная средствами управления контентом предприятия (Enterprise Content Management, ECM). Несколько лет назад оформилось еще одно, близкое к ECM направление — интеграция контента предприятия (Enterprise Content Integration, ECI). А намного раньше были изобретены хранилища данных (Data Warehouse), которые, казалось бы, решают сходные задачи. Попробуем разобраться, как соотносятся хранилища данных, ECM и ECI.
Из возможных подходов к созданию хранилищ данных более традиционен централизованный подход; в его рамках местом хранения служит какая-либо одна СУБД, обычно реляционная. Меньшее распространение получил распределенный подход; он подразумевает, что данные не перемещаются в хранилища, зато используется механизм виртуализации доступа. Децентрализованный подход можно считать предпосылкой появления ECM и ECI.
Тот, кто когда-то изучал в вузе марксистско-ленинскую философию, помнит, что в ней источником развития провозглашается диалектическое противоречие. Актуальный пример такого противоречия можно обнаружить в области хранилищ данных: на сей раз конфликтуют централизованный и распределенный подходы к созданию хранилищ данных. Как обычно, реформаторы отличаются более радикальными взглядами, а консерваторы занимают оборонительную позицию. В потоке полемики наибольший резонанс вызвала статья «радикала» Майкла Картера с категоричным названием «Смерть хранилищ данных» (The death of data warehousing), опубликованная на известном сайте looselycoupled.com, который посвящен слабосвязанным и распределенным решениям.
Позиция Картера объяснима. Он является основателем и руководителем заслуживающей самого пристального внимания компании CXO Systems, которая поставляет инструментальные средства для высшего командного состава предприятий (соответствующие должности принято обозначать аббревиатурами CEO, COO, CTO, CFO, CIO и т.д.). В качестве технологической базы в CXO Systems используют слабо связанные системы анализа и моделирования, а целью объявляют создание информационной бизнес-сети (Business Information Network). Понятно, что интересы Картера связаны с распределенными системами и что он является противником централизованных хранилищ данных.
Картер обосновывает утверждение о смерти хранилищ данных тем, что старый технологический цикл (сбор и хранение данных, преобразование их в информацию и генерация отчетов) не соответствует потребностям современным предприятий. Он приводит следующие данные. Для создания централизованного хранилища необходимы в среднем 5 млн. долл., для поддержки — примерно 1 млн. долл. ежегодно, а главное, в таком решении не учитываются многочисленные распределенные источники информации. О смерти хранилищ данных Картер говорит осторожно, помня урок не оправдавшихся пророчеств о скорой кончине мэйнфреймов. По его мнению, хранилища данных — такие же динозавры, как мэйнфреймы, но ни те ни другие не должны исчезнуть. Централизованные хранилища позволяют решать специфические задачи, такие как «отложенный» (post-mortem) анализ, но их неспособность сохранять актуальные данные критична при создании более оперативных систем.
Как бы то ни было, заявляет Картер, централизованные хранилища обязаны уйти с основной сцены. В них сложно помещать данные, не менее трудно — извлекать из них нужные сведения, а работать с ними в оперативном режиме практически невозможно. О низкой эффективности использования классических хранилищ свидетельствуют аналитики. Более 80% компаний с доходом 500 млн. долл. имеют хранилища данных, но примерно 93% хранящихся в них данных остаются невостребованными. Высокая стоимость, сложность и недостаточное использование ресурсов — вот причины, по которым хранилища данных уступят место системам с распределенным интеллектом (distributed intelligence).
Статья Картера была опубликована два года назад, и теперь он выдвигает еще несколько весомых аргументов в подтверждение справедливости своих воззрений. Во-первых, за это время произошли заметные подвижки в разработке систем управления предприятиями, действующих в режиме реального времени (Real Time Enterprise, RTE). Важнейшие компоненты такой системы — аналитика в режиме реального времени и мониторинг бизнес-активности. Во-вторых, заметное развитие получили решения категории SOA, изменившие представления об архитектуре информационных систем. В-третьих, оформилось новое технологическое направление Application Oriented Network (AON), пока представленное преимущественно разработками компаний Cisco Systems и DataPower (последняя недавно приобретена корпорацией IBM). В-четвертых, считает Картер, бизнес-аналитика (Business Intelligence, BI) нового поколения станет «убойным приложением» для распределенных хранилищ данных, которое и обеспечит их будущее.
Вполне естественно, приверженцы традиционных взглядов высказывают свои контраргументы. Эта ситуация вполне типична: проповедникам новых, еще не отработанных технологий оппонируют эксперты, обладающие опытом работы с определенной технологией. Когда-то спорили о том, что лучше, паровая тяга или гужевая, электрическая лампочка или керосиновая… Обычно в таких случаях спорящие говорят на разных языках, но аргументы консерваторов нельзя упускать из виду.
С Картером полемизирует Марк Риттман, обладатель всех титулов и званий в области СУБД и хранилищ данных, которые только можно получить в Oracle, и нештатный проповедник технологий этой компании. Для качественной загрузки хранилища данными, отмечает Риттман, требуется выполнить большой объем экспертной работы. Форматы и структура данных, поступающих из разных источников, сильно различаются, и их необходимо согласовать. Следовательно, эффективность бизнес-аналитики обеспечивается не столько поддерживающими технологиями, сколько управлением определениями данных, их схемами и потоками, а такое управление невозможно без большой доли человеческого труда. Значит, решение проблем бизнес-аналитики не сводится к внедрению программных приложений, а зависит от непрерывной переоценки реального состояния бизнеса. В ее возможности и состоит преимущество централизованного подхода, воплощаемого с участием экспертов.
Противоречия между потенциалом технологий и экспертизой обнаружились еще при первых попытках создания витрин данных (data mart). Их общность с распределенными хранилищами заключается в том, что в обоих случаях предпринимаются попытки строить хранилища данных «снизу вверх» (от данных к содержанию) и без экспертизы. По мнению многих авторитетных специалистов, в том числе самого «отца хранилищ данных» Билла Инмона, создать таким способом действующую систему бизнес-аналитики весьма сложно. Процедуры извлечения, преобразования и загрузки данных (extract, transform, load, ETL), требуют значительного времени. До недавних пор работа хранилищ данных в режиме реального времени (или близком к нему) была принципиально невозможна.
К примеру, для уменьшения задержек при получении измененных или новых данных из управляемой системы, снижения затрат на ETL и на модернизацию содержимого хранилищ данных в последнее поколение СУБД Oracle включены такие опции, как захват измененных данных, использование внешних таблиц и таблиц функций, команды MERGE, а также быстрое обновление «материализованных» представлений. Для Oracle следующим этапом стало создание специализированного средства для строительства хранилища данных Oracle Warehouse Builder 10gR2.
DW против VDW
Первые попытки покуситься на классические хранилища данных были предприняты лет десять-пятнадцать назад, но тогда традиционные решения одержали убедительную победу над виртуальными хранилищами данных (Virtual Data Warehouse, VDW). VDW строились на основе программных средств промежуточного слоя и обеспечивали доступ к распределенным данным — казалось бы, что еще нужно? Исход противостояния обусловила слабость программного обеспечения промежуточного слоя. VDW нацеливались на аналитику, подразумевающую выполнение сложных запросов и обработку значительных объемов разнородных данных. И они порождали значительную нагрузку на операционные системы, адаптированные к типичной нагрузке, то есть к небольшим объемам транзакционных данных. Поэтому концепция распределенного доступа к информации, реализуемая VDW, уступила централизованной парадигме, воплощенной в хранилищах данных. Суть ее заключена в аббревиатуре ETL: extract — выделение данных из внешних источников; transform — трансформация их в форму, удобную для аналитики; load — загрузка в хранилище.
Но идея виртуализации хранимых данных без использования процессов ETL оказалась жизнеспособной. Она вышла из небытия несколько лет назад, сначала — под названием интеграции информации предприятия (Enterprise Information Integration, EII). Хранилища данных так и не получили массового распространения, поскольку создание специальных хранилищ исключительно для целей аналитики оказалось непростой задачей, решение которой обходится недешево. Мало того, рентабельность вложений в них трудно оценить, поскольку они служат для «отложенной» глубинной аналитики. Такая аналитика была и будет востребована, но у компаний возникла потребность и в аналитике иного типа. Самыми актуальными темами стали управление бизнес-процессами (Business Process Management, BPM) и мониторинг бизнес-активности (Business Activity Monitoring, BAM), а потому понадобилась аналитическая работа в реальном времени. Теперь нужно подвергать анализу не только накопленные «исторические» данные, но и любые иные, в том числе транзакционные и внешние.
При очевидном родстве с VDW подход EII (сегодня для его обозначения используют аббревиатуру ECI) отличается большей глобальностью. Он предполагает создание карт (в терминологии бизнес-аналитики — «семантического уровня»), на которых представлено распределение гетерогенных корпоративных данных. Такие карты являются оболочкой, скрывающей от пользователей и разработчиков приложений все сложности хранения разнородных данных во внутренней части информационных систем. Это решение не стало откровением, ведь еще до появления хранилищ данных некоторые производители генераторов отчетных документов, например — компания Business Objects, создавали подобные семантические уровни, для того чтобы непрофессиональные пользователи могли делать запросы без применения языка SQL.
Хранилища в контексте инновационных волн
Рождение централизованного и децентрализованного решений разделяет почти три десятилетия. Логично предположить, что это две качественно разные инновации; фундаментом для такого вывода могут послужить исследования циклической природы инноваций. Теорию технологических циклов, иллюстрируемую волновым графиком, разработал наш соотечественник Николай Дмитриевич Кондратьев (1892-1938). У него было несколько последователей в Европе и Америке, каждый из которых создал собственную версию такого графика. Наибольшую известность получили труды австрийского экономиста Йозефа Шумпетера (1883-1950), а одну из последних редакций графика инновационных волн предложил аналитик Норман Пуаре из компании Merrill Lynch.
Результаты исследований показывают, что со времен индустриальной революции раз в 50 лет происходит смена лидирующей технологии, иначе говоря, основной инновационной парадигмы. По классификации Пуаре насчитывается шесть волн смены парадигмы (см. рисунок). Предыдущими были текстильная, железнодорожная, автомобильная и компьютерная. Сейчас возникает трудно переводимая на русский язык Distributed Intelligence — условно «волна распределенного интеллекта». А последней «видимой» волной представляются нанотехнологии, биотехнологии и, возможно, новые виды энергии.
С позиций инновационных циклов централизованное и децентрализованное решения различаются прежде всего расположением на разных кривых: первое относится к классической компьютерной волне, а второе — к волне распределенного интеллекта. Другими словами, это представители разных технологических поколений, причем одному решению присущ высокий уровень зрелости, а другое только начинает развиваться и наделено всеми соответствующими недостатками. Данные подходы не конкурируют между собой, ведь для каждого из них есть собственная ниша.
ECM и ECI
Объем неструктурированных данных растет со скоростью 200% в год. Ответом на изменившуюся реальность стало новое направление работы с данными — управление контентом предприятия (Enterprise Content Management, ECM). Сегодня ECM находится в центре внимания прессы и аналитиков; соответствующей тематике посвящено немало статей, в том числе опубликованных в журнале «Открытые системы». Бизнес тоже проявляет к ECM заметный интерес, и мировой рынок соответствующих программных средств быстро растет: в 2005 году он составил 2,1 млрд. долл., а в 2008 году, как прогнозируется, увеличится почти вдвое.
Стандартизацию в области ECM координирует Ассоциация управления информацией и изображениями (Association for Information and Image Management, AIIM). Она входит в число старейших профессиональных сообществ — ей более 60 лет и когда-то она была основана как Национальная ассоциация по работе с микрофильмами. Столь глубокие корни, безусловно, связывают ECM с той классической информатикой, которая появилась задолго до начала использования компьютеров для хранения и обработки данных. Увы, «старые связи» держали ECM в своеобразной провинции, в стороне от основного потока развития современных компьютерных систем.
Как следствие, нет консолидированного взгляда на задачи ECM. В 2005 году AIIM предложила крайне странное определение: «Управление контентом предприятия — это сумма технологий, используемых для выделения, менеджмента, хранения, длительного сохранения и распространения контента и документов, относящихся к организационным процессам». К сожалению, это определение настолько общо, что в него «вписываются» многие несхожие технологии. Так, в опубликованном в феврале нынешнего года аналитическом отчете CMS Report перечислено свыше десяти программных технологий, попадающих в категорию ERM, в том числе: управление документами (Document Management, DM); управление Web-контентом (Web Content Management, WCM); работа с изображениями (imaging); управление конфигурацией программного обеспечения (Software Configuration Management, SCM); управление знаниями (Knowledge Management, KM); управление цифровыми активами (Digital Asset Management, DAM); управление записями (Record Management, RM); управление обучением (Learning Management, LM); управление данными об продуктах (Product Data Management, PDM). Очевидно, что при таком разнообразии подходов выработать общую стройную идеологию корпоративных систем управления контентом (что удалось сделать для транзакционных систем на базе СУБД) явно не удастся. Но целостный взгляд на контент предприятия необходим, поэтому единственным выходом остается применение интеграционных подходов, в какой-то мере опробованных при интеграции приложений. Соответствующее направление поначалу получило название Enterprise Information Integration (EII), а несколько позже — более «узкое» Enterprise Content Integration (ECI).
Под интеграцией информации понимают абстрагирование данных, то есть выделение контента, и обеспечение доступа к гетерогенным данным на основе контента. Довольно неожиданным оказался термин «контекстуализация данных» (data contextualization). Прежде слово contextualization использовалось только в связи с переводом Священного писания и необходимостью адаптировать его к той среде, в которой жили новообращенные. Ныне этим термином обозначают адаптацию данных средствами ECI к системам, использующим однородные данные, — от электронных таблиц и текстовых редакторов до систем корпоративного уровня, таких как BI, BAM, ERP, CRM, SCM, BPM и т. п.
Три подхода к ECI
Проблемы, возникающие в связи с фрагментарностью контента предприятия, можно устранять несколькими способами. Зачастую эти способы подразумевают непосредственное участие человека в процессе решения, и их называют ориентированными на пользователя (User oriented Integration, UI). Подход на базе UI применяется в нескольких решениях ECM, но области его действия можно определить как корпоративный поиск (Enterprise Search) и корпоративные порталы (Enterprise Portal).
Системы корпоративного поиска способны индексировать и искать данные, хранящиеся в разных распределенных репозиториях. Используются две альтернативные архитектуры поиска, которые, по аналогии со средствами виртуализации систем хранения, можно назвать out-of-band и in-band. В первой агенты-«пауки» периодически просматривают репозитории и строят единый индекс распределенного контента. Во второй (ее иногда называют «федеративным поиском» — federated search) задействуется концентратор, который направляет запросы в разные репозитории, потом объединяет результаты поиска и предоставляет их пользователю. Особенность такого доступа к распределенному контенту состоит в его однонаправленности: можно обнаружить документ или изображение, но нельзя хранить новую версию или дополнять текущую метаданными.
Корпоративный поиск позволяет преодолеть сложности работы с распределенным контентом, но не является решением проблемы. На пользовательском уровне решение проблемы однонаправленности обеспечивают технологии корпоративных порталов. В данном случае контент можно распространять, но все остальные ограничения остаются. Решения класса UI повышают продуктивность работы сотрудников, но не решают задач управления контентом предприятия и не учитывают нужд программных приложений, которым тоже требуется доступ к этому контенту.
Традиционные интеграционные платформы (Enterprise Application Integration, EAI) строятся на основе программных интерфейсов (Application Program Interface, API). Они служат для оркестровки бизнес-процессов и организации прозрачного двунаправленного доступа к бизнес-приложениям. Но существенным ограничением является то, что они работают со структурированными данными. Обычно платформы EAI оснащают интеграционными адаптерами IBM, SAP, Oracle или Microsoft, которые не обеспечивают доступа к репозиториям Documentum, Filenet и Hummingbird. Другими словами, они не предназначены для работы с неструктурированными данными, а потому не поддерживают корпоративный поиск, создание «иконок» изображений и еще более сложные функции, связанные с мультимедиа-данными.
Наиболее современный подход основан на принципах сервисной архитектуры (service-oriented architecture, SOA). В сущности, это возврат к VDW, но на новом уроне. Основная идея заключается в том, что контент и функции управления им распределены по репозиториям, а виртуализацию обеспечивают сервисы. «Обернув» такие репозитории в оболочку на XML, их можно сделать доступными для разных приложений. Механизм работы с ними может быть создан, например, за счет «обертывания» функций управления в SOAP и опубликования в UDDI, но это не единственный способ. Такой механизм, работающий на платформе .Net или J2EE, позволяет приложениям и бизнес-процессам получать доступ к данным в репозиториях.
SOA и метаданные
Информационные системы достигли предела сложности, и по-прежнему развивать их традиционными методами попросту нерационально. На смену жестко связанным монолитным архитектурам приходят слабо связанные. Они состоят из отдельных независимых модулей, обеспечивающих друг другу те или иные сервисы. Правда, SOA более ресурсоемка и менее эффективна с точки зрения производительности, но современный уровень быстродействия компьютеров и сетей позволяет смириться с этими издержками.
Но это — внешняя сторона. А что же внутри? Как ни странно, есть очень древняя аналогия с нынешними процессами в области архитектур корпоративных информационных систем — это перестройка библиотек в связи с изобретением печатного станка. Вплоть до XV века библиотеки, обычно находившиеся в ведении монастырей, были просто хранилищами манускриптов. Не существовало стройной системы классификации, и о том, что и где находится, знали лишь монахи-библиотекари.
В эпоху Возрождения, с появлением книгопечатания, сложился стандарт описания, в который входили имя автора и название, а в последующем появились и другие учетные параметры. В совокупности их можно считать метаданными, которые описывают данные книг. Наличие метаданных позволило создать сначала алфавитные, а затем тематические, предметные и другие каталоги. В результате «монолитную» систему хранения знаний сменила сервисная модель. Придя в современную библиотеку, вы обращаетесь к библиографу, и он оказывает вам услугу поиска нужной литературы. Потом вы обращаетесь к библиотекарю и заказываете нужные книги. Полнейшая аналогия с Web-сервисами.
Суть сервисов интеграции контента заключается в использовании метаданных для поставки данных. Одним из первых рассуждать о сервисах в этом ключе начал Мико Мацумора, известный в ИТ-сообществе как основатель нескольких компаний и один из «евангелистов» Java в Sun Microsystems. Сейчас он работает в компании Infravio и считает своей целью создание международной методологии SOA. Для определения того, что именно и как нужно хранить, Мацумора использует два понятия — registry (журнал записей, учета, реестр) и repository (хранилище).
На первый взгляд, все несложно: в репозитории хранятся данные, а в реестре — метаданные. Различия между реестром и репозиторием могут быть сведены в таблицу.
 |
| Различия между понятиями «реестр» и «репозиторий» |
Но различия между самими данными и метаданными не вполне очевидны — все зависит от точки зрения. Вернувшись к аналогии с библиотекой, можно сказать, что для библиотекаря каталог — это в большей мере данные, а для пользователя — метаданные. В информационных системах граница между данными и метаданными тоже является проницаемой. Памятуя формулировку Мацумора «в реестре хранятся ссылки на сущности, а в репозитории — сами сущности», стоит смягчить связанную с реестрами и репозиториями дихотомию. Поскольку сущности не вполне определены, то и границы между реестрами и репозиториями размыты. Смежность этих понятий имеет большое значение для развития SOA. На первых его этапах все казалось однозначным и детерминированным, но по мере созревания сервисных технологий фокус будет смещаться к интегрированным технологиям, объединяющим реестры и репозитории.
Мнению Мацуморы соответствуют и взгляды ведущих аналитиков компании Zapthink Джейсона Блумберга и Рона Шмельцера. А один из самых перспективно мыслящих аналитиков Gartner Ефим Натис утверждает следующее: «Можно с уверенностью утверждать, что в долгосрочной перспективе корпоративные архитектуры SOA будут базироваться на интегрированной композиции «реестр — репозиторий», в которой можно выполнять процедуры поиска».
При всем уважении к упомянутым авторам приходится признать их рассуждения достаточно банальными. Создается впечатление, что эти аналитики нашли нечто важное, но не увидели леса за деревьями. Действительно, благодаря использованию метаданных существенно расширились возможности архитектурных решений, причем не только архитектуры SOA. Активное распространение метаданных началось с XML, следующим этапом стали сервисные архитектуры, а теперь использование пары «данные — метаданные» распространяется на системы хранения.
Первой ласточкой были контентно-адресуемые системы хранения, затем появились системы непрерывной защиты данных, в которых метаданными является время. Новое направление — контентно- и сервисно-ориентированный подход к интеграции данных. В его рамках данные поступают в виртуальное хранилище, и после обработки специальными программными агентами из них выделяются метаданные, которые используются для доступа к данным. Близкие по смыслу примеры — разрабатываемые соответственно ассоциацией OASIS и корпорацией Microsoft форматы Open Office XML и ODF, которые содержат собственные описания, то есть метаданные.
Все эти примеры свидетельствуют о том, что в компьютерной индустрии происходит очередная смена парадигм. На смену коммуникационной модели приходит иная, еще не получившая официального названия. Пока можно говорить лишь о ее особенностях, таких как слабая связанность, ориентация на сервисы и процессы. Существенно то, что ее основой является работа не с данными, а с информацией, которую можно расценивать как данные плюс описывающие их метаданные.
