BigData 2012. Время выполнять обещания?

Удивительное единодушие проявили вендоры на конференции BigData 2012. IBM, Oracle, Microsoft, Informatica, в общем все, говорили одно и тоже слово. И это слово – Hadoop. Одни говорили о том, как развернуть hadoop на своем оборудовании, другие намекали, что портируют hadoop в свою операционку, третьи рассказывали как «прислонить» их продукты к hadoop сбоку, сверху, снизу, в общем со всех сторон.

Другое, в чем были единодушны практически все ораторы, так это в том, что hadoop нужен для анализа социальных сетей. Робкие упоминания о том, что BigData это не только facebook и twitter вряд ли кто-то расслышал. Мое мнение на этот счет заключается в том, что анализ социальных сетей это, конечно, хорошо. Еще лучше будет, если маркетологи, заинтересованные в анализе социальных сетей, заплатят за очередную технологическую революцию, вызванную появлением понятие bigdata и соответствующими технологиями. Уверен, если это случится, то наши корпоративные ИТ-архитектуры ожидают серьезные изменения. Потому что линейно масштабируемые приложения для хранения и обработки данных нужны не только для анализа социальных сетей.

Предыдущая технологическая революция в архитектуре корпоративных информационных систем произошла лет двадцать назад. Вызвана она была появлением баз данных в архитектуре «клиент-сервер». До этого в компаниях господствовали персональные компьютеры и локальные сети. Очень немногие организации могли позволить себе мэйнфреймы. Базы данных существовали в локальных сетях. Имели они архитектуру «файл-сервер» и представляли из себя набор файлов, развернутых на файловом сервере под управлением Novel Netware. В принципе, этого было вполне достаточно для небольших организаций, но являлось проблемой для более крупных, многофилиальных компаний. Например, базы данных клиентов банка велись локально в каждом филиале. Естественно, снять деньги со счета можно было только в том филиале, где вы обслуживались. (В некоторых банках с этим до сих пор проблема, но вызвана она совсем не технологическими ограничениями. Пусть это останется на совести банка. ) И вдруг, появляется оборудование, операционные системы и СУБД, способные хранить и обрабатывать на одном сервере всю клиентскую базу крупного многофилиального банка. Чуть позже, каналы связи стали позволять работать с такой базой данных из большинства удаленных офисов. Это стало настоящим прорывом. Такие решения стоили больших денег, но это того стоило.

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

В связи с этим в обиходе ИТ аналитиков стали появляться слова, начинающиеся со слова Enterprise (ERP, ECM, ESB). Наверное, самыми популярными из них стали корпоративное хранилище данных и корпоративный портал.  Все они обещали очень простую вещь — обеспечить единый подход к определенной задаче в масштабах всей компании. Единое хранилище контента, единый склад данных для аналитики и отчетности, единое рабочее место и т.д.  К сожалению, мало что из этих обещаний было, действительно, реализовано. Такие системы  не имели технической  возможности распространится в масштабах всего Enterprise, т.к реализованы они в архитектуре с ограниченной  масштабируемостью. Их просто не хватало на всю компанию. Обещания были выполнены лишь частично. Например, корпоративное хранилище данных существует во многих организациях. Но обычно, туда попадает только самая важная информация, влияющая на финансовые результаты компании. Цикл работы такой системы выглядит следующим образом. Сначала мы собираем данные со множества источников. Потом загружаем их в единое хранилище (загружаем долго, так как данных немало). Далее запускаем процедуры обработки загруженных данных; строим отчеты. К концу текущего  месяца  мы выводим на корпоративный портал данные за предыдущий месяц. И только в этот момент люди начинают с ними работать, обсуждают, что-то корректируют. Безусловно, речь не идет о том, чтоб выстраивать над таким хранилищем информационные системы организации, т.к. данные в нем довольно старые. Тема хранилища, доступного для других систем, так называемого Operational Data Store последние несколько лет, вообще, не звучит.

С появлением распределенных, линейно-масштабируемых архитектур это ограничение, похоже, снимается. Можно собирать аналитику намного быстрее. От последовательности «собираем->загружаем->обрабатываем->отображаем» мы можем перейти к процессу «снимаем->сортируем по получателям->показываем». Это очень похоже на та, что принято называть воронкой событий. Пользователь подписывается на те события, которые ему интересно выделять из общего потока и задает алгоритм их обработки. Приложения «просеивают» поток, выделяя и обрабатывая именно то, что нужно. Примерно такую идею в свое время реализовала TIBCO см.  Интранет, интеграционная среда или корпоративный портал? в продукте tibbr. События из разных источников сортируются по темам и попадают в общую информационную ленту организации.

Интересно, будет ли теперь кто-либо выполнять свои обещания относительно унификации информационных систем в масштабе всей организации? Впрочем, вопрос риторический 😉

Реклама

2 Comments

  1. Только не Online Data Store, а Operational Data Store.

    > От последовательности “собираем->загружаем->обрабатываем->отображаем” мы
    > можем перейти к процессу “снимаем->сортируем по получателям->показываем”.

    Только ведь Hadoop не решает проблему съема информации из различных корпоративных систем, а дописывать их так, чтобы они сами через шину данных отсылали данные никто не станет.

    Ответить

    1. Конечно, operational, спасибо, поправил.

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

      Ответить

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s