Боб Иванс (Bob Evans) из Information Week размышляет об этичности Oracle, гордо объявившей недавно о рекордной операционной прибыли в размере 51%, в самом разгаре мирового экономического кризиса. Пикантности данному событию добавляет факт, что это произошло благодаря повышению ставки платежей за тех.поддержку до 22%, ультимативно объявленной клиентам не так давно.

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

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

...В том, что касается продуктов и услуг, которые Oracle производит, а вы покупаете, цифры [продаж - прим.пер.] упали по всем трем категориям: новые лицензии за технологии - минус 10% (в USD), новые лицензии за приложения - минус 19% (в USD), профессиональные услуги - минус 16% (в USD). Это не то, что можно праздновать, но в условиях тяжелой экономической ситуации это по крайней мере понимаемо. Но это не то, что дало бы такую выдающуются операционную прибыль в размере 51% - откуда же она появилась?

Ответ: ваши ежегодные платежи за тех.поддержку. Судя по финансовому отчету Oracle за четвертый квартал, эти платежи составили $3.1млрд. или плюс 7% (в USD) ... Посмотрим на итоги года - доходы Oracle от продаж новых лицензий на софт составили $7.1млрд, в то время как доходы от ваших ежегодных платежей за тех.поддержку составили $12млрд...

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

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

1) Будет ли Oracle способна продолжать поставлять заказчикам тот уровень качества и инноваций, которую эти заказчики определят как стоящие 22% ежегодной тех.поддержки?

2) Достигли ли Oracle, SAP и, в меньшей степени Microsoft, такого доминирования на рынке корпоративного ПО, что заказчики весьма ограничены в вариантах, независимо от того, чувствуют ли они, что Oracle и остальные большие игроки рынка дают им соответствующее качество и ценность за взымаемые деньги?
...
В конце-концов, это вы должны решить, получаете ли вы честную отдачу от тех 22% платежей за тех.поддержку, которые составляют более половины доходов компании (Oracle - прим.пер.), и которые позволяют ей получать операционную прибыль в размере 51%. Если вы решите, что ответ "да", тогда вы получаете справедливый возврат на свои деньги, тогда Oracle делает все правильно и собирает ежегодные фонды для инвестиций в высокое качество тех приложений и технологий от которых вы и ваши клиенты будут потом зависеть.

Если вы решите что ответ "нет", что значит вы не получаете честную отдачу от того, что вы платите Oracle, тогда пристегивайтесь по-крепче, потому что пока вы будете заниматься выбором из огромного множества вариантов, у вас не будет ресурсов и экспертизы компании, которая убедила многие компании за многие годы, что ее продукты и услуги настолько хороши, что эти заказчики были готовы оплачивать бизнес-модель принесящую 51% операционной прибыли. И вы не достигните такой прибыльности, без того чтобы быть черезвычайно хорошим в своем деле."

Сегодня IBM анонсировала приобретение SPSS - известного производителя ПО для прогнозирования и анализа данных с помощью сложных моделей, основанных на статистических алгоритмах. Программные продукты SPSS достаточно широко известны на рынке (большую долю имеет наверное только SAS) и имеют обширную и очень лояльную базу клиентов. По сути дела, эта сделка на рынке прогнозной аналитики и data mining имеет такое же значение, какое имела покупка Cognos почти два года назад для рынка BI. И в том и в другом случае IBM приобретала одного из лидеров рынка, и в том и в другом случае приобретаемый портфолио продуктов достаточно незначительно пересекался с существующей продуктовой линейкой (чем, кстати, не могли похвастаться другие мегавендоры).

Приобретение SPSS с одной стороны является вполне логичным шагом IBM, которая продолжает выстраивать полный стек продуктов для построения аналитических управленческих систем, руководствуясь идеологией Information On Demand, недавно переозвученной как Information Agenda. С другой стороны, остается вопрос - а будет ли эффект синергии от предложения SPSS клиентам IBM вместе с другими продуктами из линейки Information Management, включающей Cognos, InfoSphere и пр.? Поясню почему:

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

Во-вторых, есть определенная мистификация и идеализация средств data mining - вокруг них (не без помощи маркетинга, конечно) создан некий ореол "чудодейственности". Многие полагают, что использование средств data mining способно сразу дать существенный эффект. В то же время, более зрелым является подход, в котором сначала создается информационная инфраструктура, которая позволяет получить очищенные и согласованные первичные данные, потом настраивается базовая коллективная работа организации с этой информацией с помощью средств BI, и уже третьим этапом идет получение дополнительных выгод с помощью высокоинтелектуальных инструментов для прогнозной аналитики и data mining. Перескочить сразу к третьему этапу, миновав предыдущие два иногда можно, но в общем случае это работает плохо.

В-третьих, мое личное мнение - время, когда считалось что статистическими моделями можно описать и предсказать любые тенденции в бизнесе, уходит. Увлечение статанализом для принятия решений в бизнесе приходится на 70-80е годы - как раз тогда и зародились сегодняшние монстры этого рынка. Однако, в конце 90х и в начале этого века все больше и больше происходит сдвиг в сторону "вебдванольности" систем поддержки решения - так как становится приоритетным не сколько замена эксперта-аналитика высоконаучным математическим алгоритмом, сколько создание удобной среды для совместной работы этих экспертов-аналитиков.

Впрочем, я несколько уклонился в лирику - вернемся же к нашим новостям. Что можно ожидать с точки зрения продуктового развития?

Очевидным первым шагом будет интеграция Cognos и SPSS - кроме единой аутентификации и портальной интеграции, вероятнее всего мы увидим использование единого слоя метаданных для Cognos и SPSS. Что кстати будет хорошим и красивым шагом - IBM Cognos силен своим единым слоем метаданных для всех BI-инструментов.

Можно также ожидать появления инструментов SPSS в составе отраслевых решений типа Banking Risk Management Cockpit. Возможно появление некоторых "заточек" под SPSS в СУБД DB2 и пакете InfoSphere Warehouse, на ней основаной. Хотя конечно же SPSS будет оставаться гетерогенным решением - Голубой гигант менее других мегавендоров был замечен в переориентации своих приобретений исключительно под свою платформу.

И напоследок, несколько фантазий о том, как же скажется эта сделка на других участниках рынка? Наверное, в самом затруднительном положении окажется SAP, который последние 1,5 года активно развивал сотрудничество с SPSS, продуктом которого стало появление BusinessObects Predictive Workbench. Возможно SAP будет переориентироваться на SAS (что, кстати, будет еще одним шагом в сторону материализации слухов о приобретении Teradata).

Oracle находится в более выигрышном положении, чем SAP, так как в свое время уже сделал ряд приобретений в области advanced analytics, и даже пытался агрессивно их маркетировать, невинно жонглируя понятиями predictive analytics, advanced analytics и business analytics. Но, по-моему, со временем интерес к этой идее был несколько утрачен.

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

Что же будет дальше - мы увидим. Как я уже упоминал выше, мое мнение - золотая пора прогнозной аналитики в бизнесе уже уходит. Так что альянс IBM и SPSS хоть и логичен, но, вполне возможно, уже не так актуален, как раньше.

Недавно, благодаря Informatica, стал доступен для всех желающих отчет Gartner по инструментам очистки данных (Data Quality Tools). Это наверняка будет познавательно для тех, для кого были актуальны вопросы поднятые в  статье Расчищаем авгиевы конюшни корпоративных данных.

На июнь 2009 года соответствующий "магический квадрант" в представлении Gartner выглядит следующим образом:

Как видно по рисунку, в числе лидеров DataFlux, IBM, Informatica, Trillium и закрывает пятерку лидеров SAP BusinessObjects. Что примечательно - в Украине более-менее доступны как раз эти 5 технологий, в то время как остальные вендоры, упомянутые в отчете Gartner, на просторах родной земли лично мною замечены не были.

В отчете отмечается дальнейшее развитие функциональности инструментов класса Data Quality и предсказывается рост рынка этих инструментов. Что в общем-то не является чем-то неожиданным, в свете продолжающегося экспоненциального роста объема корпоративных данных, модно именуемого не иначе как "информационным взрывом".

Еще один пост в этой серии посвящяется технике Changed Data Capture, или сокращенно CDC. Встречается также иногда написание Change Data Capture. Суть CDC - выделение измененных или добавленных в СУБД данных за период времени. На жаргоне такие данные еще называют "дельтой".

Выделение "дельты" в транзакционных системах - обязательная задача при создании аналитических хранилищ данных, CRM, MDM-хабов, Это также часто встречающаяся задача в проектах по миграции с одной учетной системы на другую, когда есть период паралельной эксплуатации. При традиционном подходе, "дельта" данных определяется обычными запросами типа SELECT к СУБД.

Однако в случае большого количестве новых и измененных транзакционных данных такие запросы могут выполняться часами, при этом нередко значительно влияя на производительность системы из которой извлекаются данные. Если у транзакционных систем есть явный период сниженной нагрузки (например ночью) и этого периода хватает, чтобы выгрузить "дельту" всех необходимых данных без ущерба для основной деятельности системы - то использование прямых запросов к СУБД это приемлемый вариант. А что делать, если периода сниженной нагрузки нет, или выделенного окна загрузки не хватает, чтобы полностью выгрузить всю "дельту"?

В этих случаях целесообразно попробовать использовать CDC-решения. Принцип их работы достаточно прост - выявление новых и измененных данных за период происходит непосредственно по логам СУБД, минуя движок выполнения запросов СУБД. У такого подхода есть существенные преимущества:

• Практически нулевая нагрузка на систему источник, так как CDC-агент, сканирующий логи достаточно нетребователен к аппаратным ресурсам. Это значит что выгрузка данных может проходить в любое время работы приложения.
• Возможность сканировать логи в реал-тайме. Благодаря этому отпадает необходимость иметь ночное окно выгрузки - фактически "дельта" данных будет готова сразу на момент закрытия дня.
• Полученная "дельта" данных при необходимости сразу может быть сохранена в СУБД другого типа, или же экспортирована в текстовый файл.
• Простота выявления изменений, сделанных "задним числом", что нередко представляет собой проблему при построении аналитических хранилищ данных или в проектах по миграции.

Некоторые CDC-агенты могут хорошо вписываться в сервис-ориентированную архитектуру, так как могут подсоединяться к шине обмена сообщениями (service bus) и отправлять сообщения с измененным данным в он-лайн режиме. Некоторые CDC-агенты позволяют на лету делать простенькие преобразования данных - например, сложить два поля, или выполнить конкатенацию полей.

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

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

Тема сегодняшнего поста – понятие Slowly Changing Dimensions (SCD), которое можно перевести на русский как «медленно изменяющиеся размерности» или «редко меняющиеся измерения». SCD применяют, когда необходимо корректно отразить изменение размерности анализа при построении отчетов. Для иллюстрации SCD чаще всего используют пример с неким менеджером по продажам (М), успешно работавшим в филиале А, но впоследствии переведенным в филиал В, для которого характерны меньшие объемы продаж. Соответственно, значение размерности «филиал» для менеджера М сменилось с А на В. Однако, если в модели данных не учесть правильно факт перехода М из одного филиала в другой, то при попытке оценить прирост продаж в филиалах мы получим некорректные данные. В этом случае в продажах прошлого периода филиала А не будут учтены высокие продажи менеджера М, а прирост продаж в филиале В будет неадекватно низким, так как в базу прироста (прошлый период) попадут продажи М, сделанные в филиале А. Для решения подобной задачи придумали целых 6 способов, которые бесхитростно назвали SCD0, SCD1, SCD2, SCD3, SCD4 и SCD6. Впрочем, жизнеспособными можно назвать только парочку из них. Подробное описание этих способов есть как специализированной литературе, так и в интернете, включая википедию, поэтому здесь углубляться в детали нет смысла.

Напоследок замечу, что задача правильного отражения Slowly Changing Dimensions настолько часто встречается на практике, что многие производители ETL-инструментов включили генератор SCD в стандартные библиотеки элементов преобразования, дабы облегчить жизнь разработчикам и упростить написание соответствующих ETL-процедур. В частности, IBM Information Server (DataStage) обзавелся SCD stage начиная с версии 8.0.

IBM недавно осуществила интересное приобретение. Она купила небольшую компанию Exeros, специализирующуюся на решениях по профилированию и очистке данных. Уникальность разработок Exeros в том, что они позволяют на основании анализа данных в колонках таблиц выявлять достаточно сложные трансформации, которые связывают колонки. Несколько примеров:

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

По-моему, очень интересный подход, позволяющий значительно облегчить жизнь разработчикам BI/DWH-систем и MDM-хабов. Так что Exeros логично вписывается в портфолио IBM.

Кстати сказать, СТО Exeros Алекс Горелик (Alex Gorelik) - достаточно известная личность. В свое время он был VP of Engineering and President компании Acta Technology, разработавшей ETL-продукт, известный теперь как SAP BusinessObjects Data Integrator. Он также принимал участие создании Sybase Replication Server и ядра СУБД в Amdahl.

Синди Хоусон (Cindi Howson) замечательно описала причины развития BI-платформ в сторону СУБД класса in-memory.

Идея in-memory систем управления базами данных проста, как все гениальное, - сведения, используемые для аналитических запросов, размещаются полностью в оперативной памяти. В отличие от традиционных решений, которые сохраняют данные на дисковой памяти и хранят в оперативной памяти кеш под наиболее частые запросы, in-memory СУБД держат в ОЗУ полностью всю информацию, для чего также используются алгоритмы сжатия, позволяющие достигать уровня компрессии в 5-10 раз. Расположение всех данных в ОЗУ позволяет получать практически мгновенный отклик на аналитические запросы из BI-приложений, независимо от того, какие показатели и размерности в них используются.

То, что раньше казалось фантастикой, сегодня возможно благодаря существенному удешевлению памяти - за несколько лет цена на 64 GB RAM упала с $64000 до $13000. Вторым немаловажным фактором стала популяризация 64-х-битных ОС, способных работать с большими объемами ОЗУ.

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

Вендоры уловили эту тенденцию, и на сегодняшний день есть несколько существенно различающихся взглядов на развитие in-memory систем. Так, например, компания SAP уже несколько лет развивает свой BW Accelerator - программно-аппаратное решение, позволяющее в разы сократить время обработки запросов, выполняемых на ПО SAP BW. Преимущество - готовность к работе с существующим BI-контентом, созданным на базе SAP BW без каких-либо серьезных изменений. Однако область применения ограничена BI-платформой от SAP.

Совершенно иной подход в использовании технологии in-memory применяется в IBM Cognos TM1, унаследованном от Applix продукте, одного из пионеров в рассматриваемой области. In-memory OLAP СУБД Cognos TM1 может использоваться в гетерогенных средах - т. е. источником данных может выступать практически любая реляционная СУБД - Oracle Database, IBM DB2, Microsoft SQL Server и т.д. Однако при этом потребуется создавать дополнительные процедуры загрузки данных в TM1 и соответствующим образом настраивать BI-приложение. Плюсом TM1 также является способность работать не только на чтение данных, но и на запись, что весьма полезно для анализа сценариев "на лету", востребованном в сфере финансового планирования и маркетингового анализа.

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

Хотя кто знает... возможно, дальнейшее удешевление RAM приведет к вытеснению традиционных архитектур в область high-end-экзотики?

Как известно, что сегодня имеется масса разнообразных тренингов для продавцов корпоративных систем, как хардверных, так и софтверных. Несмотря на некоторые различия, их суть в общем-то сводится к одному -- к демонстрации потенциальному заказчику того, что его бизнесу принесет предлагаемое ИТ-решение. Причем принесет не в терминах "удобнее", "легче" или, упаси Боже, "эффективнее", а в деньгах -- в понятном и ощутимом Cash Flow. Тренеры утверждают, что нет другого пути убедить клиента в необходимости потратить, скажем, $100-200 тыс., на новую технологию, кроме как показать, что ее применение принесет в обозримой среднесрочной перспективе хотя-бы $1 млн.

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

Сейчас, когда "легкие" кредитные ресурсы недоступны, рациональная составляющая в принятии решений должна была бы получить больший вес. Но научит ли этот кризис ИТ-продавцов и ИТ-покупателей четче и конкретнее отвечать на вопрос -- зачем?