|
|
|||||||||||||||||||||||||||||
|
Прагматика корректирует теорию. Интервью Сергея Кузнецова с Джонотаном Эйнсвортом, директором по направлению "Бизнес-аналитика", Oracle EMEAИсточник: citcity
Потребности современных предприятий в высокотехнологичных корпоративных решениях в области бизнес-анализа особенно остры. И неслучайно бизнес-аналитика сегодня - ключевой рынок для Oracle. О мировых тенденциях и передовых решениях в этой области в интервью IT-порталу CITForum рассказал Джонотан Эйнсворт (Jonathan Ainsworth), директор по направлению "Бизнес-аналитика", Oracle EMEA.
Здравствуйте, Джон. Меня зовут Сергей Кузнецов, и я представляю здесь компанию CitForum. Спасибо за Ваше согласие дать нам интервью. Свой первый вопрос я хотел бы сформулировать следующим образом. Несколько лет назад имелись, по крайней мере, три подхода к организации OLAP: реляционный OLAP (ROLAP), многомерный OLAP (MOLAP) и гибридный OLAP (HOLAP). Насколько я помню, основной метод, использовавшийся Oracle, базировался на подходе HOLAP: хранилища данных (data warehouse) с использованием основной СУБД Oracle и витрины данных (data mart) с использованием многомерной СУБД Oracle Express Server. Теперь мы слышим только про Oracle OLAP, основанный на Oracle 10g. Значит ли это, что подход ROLAP победил в этом соревновании? На самом деле, это не так. Наш подход можно представить, как оптимизацию архитектурной схемы. Но позвольте мне приступить к ответу на Ваш вопрос с изложения моего видения всей дискуссии относительно ROLAP, MOLAP и HOLAP. После этого я расскажу о том, что мы имеем сегодня. В течение многих лет вокруг этой темы велись "религиозные войны". В обсуждениях MOLAP представлялся как подход, способствующий эффективности выполнения запросов. Это позволяло производить сложную аналитику. Реляционный OLAP представлялся как подход, поддерживающий масштабируемость обрабатываемых объемов данных. Кроме того, ROLAP основывался на SQL, что обеспечивало гибкость при выборе клиентских инструментальных средств. Однако эффективность выполнения запросов была существенно ниже, чем при использовании подхода MOLAP. Поэтому для оперативной аналитической обработки приходилось переносить данные в другую среду, такую как Express Server. Что же мы сделали для исправления этой ситуации? Мы просто перенесли Express Server и технологию MOLAP внутрь основной СУБД Oracle. Теперь СУБД Oracle - это не только реляционная, но еще и многомерная СУБД. Это позволило нам обеспечить масштабируемость структур данных MOLAP. При управлении этими структурами применяется разбиение данных на разделы, распараллеливание и т.д. Теперь можно строить очень крупные многомерные хранилища данных. Например, для одного из заказчиков в США мы создали многомерное хранилище на основе Oracle OLAP, построенное на основе данных семи миллиардов транзакций, что было абсолютно невозможно раньше. При работе с многомерными данными в базах данных Oracle можно использовать как проприетарный API, так и SQL. SQL при этом работает не с реляционными таблицами, а с многомерными структурами данных. Если говорить про общую архитектуру хранилищ данных, то мы теперь обеспечиваем наиболее оптимальное решение. Наша архитектура хранилища данных состоит из трех слоев. На первом уровне находится традиционная промежуточная область хранения, основанная на реляционной технологии. Следующий уровень корпоративного хранилища данных соответствует среде хранения очищенных транзакционных исторических данных, которые поступают из промежуточной области хранения и сохраняются навечно также в нормализованной реляционной форме. Третий уровень обеспечивает эффективный доступ к данным. Этот уровень может основываться на технологии ROLAP, и тогда в нем используются обычные реляционные схемы типа "звезда" и "снежинка". И теперь в качестве альтернативы на этом уровне можно создавать так называемые аналитические пространства, содержащие специальные многомерные структуры данных. Это обеспечивает оптимальный доступ к данным на верхнем уровне архитектуры. Так что хранилище данных теперь представляет комбинацию реляционной реализации и технологии MOLAP. На верхнем уровне хранилища данных MOLAP фактически обеспечивает реализацию витрин данных внутри хранилища данных. Таким образом, в трехуровневой архитектуре хранилища данных обеспечиваются аналитические возможности MOLAP без потребности в усложнении архитектуры. Спасибо, Ваш ответ полностью прояснил ситуацию. Следующие вопросы посвящены переменам, происходящим в области средств Business Intelligence (BI) компании Oracle. Все мы были немного удивлены, когда компания Oracle приобрела компанию Sieblel и ее набор инструментальных средств BI в дополнение к собственным средствам BI. Насколько я понимаю, основным различием между традиционными средствами Oracle BI и средствами из набора Siebel Business Analytics является то, что средства Oracle базируются на действительно интегрированных, физических отдельных, согласованных хранилищах данных, в то время как средства Siebel могут работать над данными, интегрируемыми из различных источников в оперативном режиме, "на лету" (над так называемыми "виртуальными" хранилищами данных). Прошлой осенью я спрашивал Билла Инмона о его отношении к виртуальным хранилищам данным, и он ответил, что существует только одна разновидность хранилища данных - хранилище физически интегрированных данных. Какова текущая позиция Oracle по этому вопросу? Меня совсем не удивляет это мнение, поскольку Билл Инмон и Ральф Кимболл борятся за "чистоту религии" в течение многих лет. Но на практике трудно придерживаться их ортодоксальных позиций. Моя личная точка зрения, которая вполне соответствует возможностям BI от Siebel, состоит в том, что средства BI должны применяться и к динамически синхронизуемым данным. Я думаю, что сегментированные виртуальные хранилища данных являлись только первой попыткой, возврат к которой был бы очень опасен, поскольку такие хранилища данных невозможно реализовать. С другой стороны, я думаю, что поддержка единого корпоративного хранилища данных, включающего все данные, в том числе, и те, которые поступают в реальном времени, является новой и вполне достижимой целью. И это будет не виртуальное хранилище. Вы имеете в виду необработанные (raw) данные? Да, включая необработанные данные. Все данные. Что в этом смысле дает технология Siebel? В этом случае мы можем связать средства Siebel c хранилищем данных, а можем использовать транзакционные источники данных, которые совершенно не связаны с хранилищем данных. Одной из наиболее интересных особенностей технологии Siebel является то, что средства Siebel можно применять без построения хранилища данных за счет использования уровня метаданных, описывающих данные всех информационных источников в виде единой логической модели. Это очень важно, потому что на практике многие заказчики не нуждаются в построении хранилищ данных или не желают тратить на это средства. Другим преимуществом этого подхода является то, что наш подход делает доступными для анализа все данные, в то время как виртуальные хранилища данных позволяют интегрировать только хранилища данных, но не транзакционные источники данных. Еще один вопрос, связанный с предыдущим. Как кажется, люди платят большие деньги за проекты традиционных хранилищ данных, поскольку ожидают получить в результате нечто весьма ценное для них: высококачественную аналитику. Для меня очевидно, что качество аналитики, основанной на традиционных хранилищах данных, должно быть гораздо выше качества аналитики на основе виртуальных хранилищ, поскольку чем качественнее данные, тем качественнее результат анализа. Нужно ли понимать, что, переходя на использование технологии Siebel, Oracle сознательно предлагает своим заказчикам пользоваться некачественными данными и довольствоваться некачественным анализом? Практическим достоинством нашего подхода, очень важным для компаний, является то, что с использованием средств BI Siebel в зависимости от их конфигурации вы можете запрашивать как качественные данные, хранящиеся в хранилищах данных, так и промежуточные данные транзакционных систем. Результаты анализа представляются единообразно вне зависимости от того, основываются ли они на сложных запросах, адресуемых к качественным, очищенным и согласованным историческим данным, которые сохраняются в хранилище данных, или на коротких запросах, направляемым к необработанным транзакционным данным. Это становится возможным за счет наличия унифицированного слоя метаданных, использование которых позволяет избежать физической интеграции транзакционных данных. Для традиционных средств наличие хранилища данных является абсолютно необходимым. Оно обеспечивает качество исторических данных, среду управления данными и поддержки их качества. Новые средства BI могут осуществлять информационный доступ к хранилищам данных, а также, потенциально, к федеративным хранилищам данных и к транзакционным источникам данных. Это позволяет применять единую стратегию к обработке информации. Если я правильно понимаю, то теперь мы имеем следующую общую картину. Средства BI в любом случае взаимодействуют с данными через унифицированный слой метаданных. При работе с хранилищем данных эти метаданные непосредственно соответствуют данным, а при доступе к транзакционным источникам данных производится некоторое отображение метаданных на реальные данные, хранимые в настоящее время в этих источниках. Это действительно так? Да, совершенно верно. Уровень метаданных в обязательном порядке присутствует при работе с хранилищем данных и также используется при потребности в доступе к транзакционным данным. Промежуточный сервер, который называется аналитическим сервером, или BI-сервером, отвечает за управление слоем метаданных и генерацию запросов к отдельным источникам данных. Средства BI не знают, откуда берутся запрашиваемые ими данные. По моему мнению, в этом состоит основная тенденция развития архитектуры BI. Управление данными и метаданными полностью отделяется от средств BI. Кстати, технология, которую мы получили после приобретения Siebel, была приобретена Siebel в результате поглощения компании nQuire несколько лет тому назад. Следующий мой вопрос относится к разным видам лицензирования средств BI, поддерживаемых Oracle. Насколько я понимаю, вы поддерживаете (или собираетесь поддерживать) три раздельных редакции наборов средств BI: Oracle Business Intelligence Suite Enterprise Edition, Oracle Business Intelligence Suite Standard Edition и Oracle Business Intelligence Suite Standard Edition One. Про последнюю редакцию я слышал в связи с объявлением Oracle новой стратегии поддержки малых и средних предприятий. В чем состоит смысл выделения этих редакций и следует ли понимать, что последняя из них представляет собой "BI для бедных"? Да, действительно, Oracle Business Intelligence Suite существует в трех редакциях. Oracle Business Intelligence Suite Enterprise Edition включает средства Siebel Business Analytics, позволяющие работать как с хранилищами данных, так и с транзакционными данными. При этом сегодня Oracle BI Suite Enterprise Edition состоит только из средств Siebel. Но очень скоро, в конце ноября эта редакция будет включать 70% технологии Siebel и 30% технологии Oracle. И очень быстро мы достигнем соотношения 50% на 50%. Oracle Business Intelligence Suite Standard Edition полностью состоит из традиционных средств бизнес-аналитики Oracle, а Oracle BI Suite Standard Edition One - это смесь из разных технологий Enterprise Edition и Standard Edition. Из традиционных средств в эту редакцию войдет Oracle Warehouse Builder. Standard Edition One будет также включать следующие средства из набора Siebel: BI Server, обеспечивающий доступ к разнородным источникам данных; средство выполнения нерегламентированных запросов Answers; средство построения информационных панелей Dashboard. В дополнение к этому, мы будем обеспечивать средство генерации отчетов XML Publisher. Что бы ожидаем от этой редакции? Для многих небольших компаний типичные потребности в BI ограничиваются простыми запросами и формированием отчетов над транзакционными системами и/или базами данных, основанными на технологии Oracle или других поставщиков СУБД. Но по мере роста компаний появляются потребности в более сложных возможностях BI, в частности, в специализированных базах данных, ориентированных на формирование отчетов: витрин данных, или начальных хранилищ данных. Включаемый в состав Standard Edition One Oracle Warehouse Builder позволяет строить хранилище данных на основе различных источников данных. Средство Answers позволяет формировать нерегламентированные отчеты на основе построенного хранилища данных или транзакционных источников данных. Таким образом, начав с малого, сегодняшние малые предприятия могут наращивать ИТ-системы по мере роста потребностей. Мне кажется, что это решение может быть полезно далеко не только малым и средним компаниям, а всем компаниям, которые начинают применять средства BI. Фактически, вы предлагаете им путь от простого к более сложному решению с использованием сложных компонентов только при возникновении реальных потребностей. Это не совсем так. Конечно, лицензия Standard Edition One накладывает некоторые ограничения. В Enterprise Edition присутствуют некоторые функциональные возможности, не поставляемые в Standard Edition One, но необходимые для больших компаний. В Standard Edition One мы включаем необходимый минимум возможностей, позволяющих компаниям начать использовать BI, эта редакция предназначена для решения задач малых и средних предприятий. Есть и другие существенные ограничения. Например, минимальная лицензия Standard Edition One предусматривает одновременную работу пяти пользователей, а максимальная допускает наличие 50 пользователей. При дальнейшем возрастании потребностей нужно переходить к Enterprise Edition. Стоимость лицензии составляет тысячу долларов на одного пользователя. Другое ограничение выставляется на способ использования BI-сервера: к нему можно подключить одну базу данных Oracle, одну базу данных любого другого производителя и любое число плоских файлов. Эти ограничения не мешают небольшим компаниям с пользой использовать средства BI для решения своих типичных проблем, но не устраняют интерес к переходу к Enterprise Edition при росте компании и ее потребностей. Правильно ли я понимаю, что при росте компании и появлении потребности в избавлении от этих ограничений путем перехода к Enterprise Edition не требуются никакие технические изменения? Миграция от Standard Edition One к Enterprise Edition не должна вызывать у компаний никаких проблем или даже затруднений. Меняется только вид лицензии. Мой следующий вопрос относится к технологии Data Mining. Если я правильно понял, опция Data Mining доступна только при приобретении корпоративной лицензии (Enterprise License) на Oracle 10g. Значит ли это, что вы считаете ненужной технологию Data Mining малым и средним предприятиям? Действительно, опция Data Mining обычно предоставляется только при приобретении корпоративной лицензии - это как раз одно из существенных отличий Standard Edition One от Enterprise Edition. Это связано с тем, что обычно data mining в среде хранилищ данных используется аналитиками при наличии больших объемов данных. Обычно data mining требуется для анализа и предсказания поведения заказчиков в компаниях с очень большим числом транзакционных заказчиков. Я думаю, что это ограничение не препятствует использованию технологии data mining в тех случаях, когда это действительно требуется, а в этих случаях по причине больших объемов данных и интенсивной транзакционной обработки все равно нужна корпоративная лицензия. Вот если бы ограничение касалось использования OLAP, оно было бы действительно существенным. По моему мнению, в повседневной практике небольших компаний OLAP является гораздо более востребованной технологией, чем data mining. В этом году можно отмечать десятилетний юбилей объектно-реляционной технологии баз данных. В частности, десять лет назад появилась СУБД Oracle8 с объектно-реляционными возможностями. Принесли ли какую-нибудь пользу эти расширенные возможности для технологии BI? Да, имеется очень хороший пример использования объектно-реляционных средств для поддержки OLAP. На основе объектной технологии СУБД Oracle обеспечивается доступ на языке SQL к многомерным аналитическим данным. Мы использовали эту технологию, чтобы дать возможность работать с многомерными данными так, как если бы они были реляционными. Это пример использования объектно-реляционных средств во внутренних разработках Oracle. Честно говоря, я не знаю примеров применения объектно-реляционных расширений внешними разработчиками прикладных систем. Обычно они основываются на чисто реляционных возможностях. Это вполне соответствует моим собственным наблюдениям. Почти во всех случаях объектно-реляционные средства использовались самими компаниями-производителями СУБД, а не пользователями. Я хотел бы кое-что добавить по этому поводу. Многие аналитики полагают, что скоро хранилища данных будут содержать не только реляционные или многомерные данные. В хранилищах данных будут храниться графические изображения, фотографии, документы и другие продукты совместной деятельности людей. Например, в Великобритании создается хранилище данных сети железных дорог для поддержки функционирования этой сети. Данные собираются на основе реального функционирования железных дорог с целью характеристики их качества. Специалисты используют очень сложные механизмы для распознавания различного рода неисправностей. В частности, они собирают, сохраняют и обрабатывают сотни фотографий. Подобные "мягкие" данные в ряде случаев позволяют серьезно помогать при анализе данных. В заключение я хотел бы узнать Ваше мнение по поводу будущего Oracle Business Intelligence Suite. Это очень объемный вопрос. Компания Oracle планирует в следующие несколько лет произвести значительные инвестиции в развитие рынка и технологий продуктов и приложений BI. По моему мнению, наиболее интересным и обещающим направлением являются аналитические приложения. Мы должны добиться унификации приложений BI, пришедших с компанией Siebel, с традиционными приложениями BI Oracle. Мы должны также добиться унификации приложений BI с Fusion Applications. Должна иметься возможность использования приложений BI совместно с другими приложениями Fusion Applications, чтобы повысить общий уровень интеллектуальности приложений. Я полагаю, что неявно Вы имели в виду SOA, поскольку, как мне кажется, Fusion Applications - это, в частности, путь Oracle к наполнению общей идеи сервис-ориентированной архитектуры конкретным и развитым содержанием. Безусловно. Продукты BI могут отлично использоваться в этой архитектуре. Поэтому очень интересным направлением является интеграция средств BI со средствами Oracle для поддержки SOA. Это позволит использовать средства BI и средства поддержки SOA для создания развитых интеллектуальных пользовательских приложений, основанных на сервис-ориентированной архитектуре. Большое спасибо, Джон за Ваши интересные и содержательные ответы. Надеюсь, что они помогут нашим читателям лучше понять современное состояние технологии BI и стратегию компании Oracle в этой области. Ссылки по теме
|
|