Принято считать, что информационные технологии в государственных ведомствах приживаются тяжелее, и для этого мнения есть ряд объективных причин. Однако, как говорил Альф: «Вы не любите котов? Значит, вы не умеете их готовить!». И сегодня мы хотим поговорить о том, как отличаются проекты в госкомпаниях с точки зрения бизнес-IT интегратора, и для каких целей госы создают большие хранилища для аналитических проектов.

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



Однако при всем этом отношение к ИТ в госкомпаниях за последние годы радикально изменилось. Под действием программы «Электронного правительства» госорганы осознали, что применение информационных систем – как минимум, неизбежно. А смена поколений, в рамках которого на руководящие должности приходят относительно молодые управленцы, которые готовы развиваться, создает очень важный прецедент — у госорганов появляются люди, которые могут войти в проект со стороны заказчика, чтобы обеспечивать его поддержку и развитие.

Что нужно госам?

Если бизнес четко знает, что ему нужно и к какому числу, то государственные структуры не могут похвастаться таким знанием. При этом потребности ведомств, как правило, оказываются куда шире, чем ожидалось изначально. Например, как показала практика, при переходе на систему межведомственного взаимодействия третьей версии (СМЭВ 3.х), заказчикам потребовалось куда больше, чем просто внедрение новых модулей – нужны были конверторы форматов, обеспечивающие обратную совместимость со СМЭВ 2.х, а также ряд дополнительных решений. Подобные вещи происходят на любых проектах в госкомпаниях, что требует от интегратора комплексного подхода и готовности ко всему.

Несмотря на то, что в государственных организациях повсеместно используются решения от гигантов отрасли, таких как SAP или Oracle, в последнее время приоритеты смещаются, несмотря на стабильность этих платформ. Все важнее становится стоимость поддержки, а также продолжает набирать обороты курс на импортозамещение. Например, если раньше мы планировали использовать для крупных аналитических проектов OLAP-движки IBM Cognos TM1 и Oracle Hyperion EssBase, то сегодня из-за изменения курсов валют подобные решения перестали входить в предусмотренные бюджеты. В результате были найдены достойные отечественные решения, такие как продукт компании «Полиматика». Эта система размещает данные OLAP-куба в оперативной памяти, благодаря чему анализ происходит с максимальной скоростью, и на стандартном сервере можно обрабатывать несколько миллиардов записей, используя ядра центрального и графического процессора.

Однако российских продуктов нужного уровня на рынке очень мало, и далеко не для каждой сферы применения удается найти достойную замену. Поэтому госструктуры позитивно относятся к заказной разработке на базе платформ с открытым исходным кодом, а также к гарантированному сопровождению систем от зарубежных поставщиков. Конечно, полной автономности тут не добиться, и вместо зависимости от вендора возникает зависимость от разработчика. Заказчика начинает интересовать, кто будет поддерживать и развивать систему? Поэтому подрядчиками для государственных заказчиков чаще всего выступают одни и те же компании: заслуженное доверие является одним из главных аргументов при запуске нового проекта.

Учитывая все сказанное выше, информационные системы в госструктурах похожи на пазл, сборка которого требует применения коробочных и заказных продуктов, открытых платформ и коммерческих решений. При наличии качественной интеграции подобный подход позволяет избежать замыкания на каких-то определенных продуктах, оставляя возможности для добавления новых «деталей» и замены пазликов, если их развитие или поддержка оказываются под вопросом.

Потребности в госструктурах

Формирование в госструктурах комплексного информационного пространства, которое охватывает не одно ведомство, а сразу несколько, создало предпосылки для использования аналитических решений нового поколения. Например, в состав СМЭВ третьей версии также входит аналитический модуль, который собирает статистику по количеству и качеству оказания государственных услуг в электронном виде и межведомственному взаимодействию. На фоне постоянно растущего числа пользователей СМЭВ, в число которых теперь входят и региональные МФЦ, и финансовые организации, объемы взаимодействия растут в геометрической прогрессии. Большое количество данных открывает все возможности для внедрения дополнительных инструментов, которые смогли бы их использовать. Огромные массивы данных открывают возможности для аналитики, и использование новых ИТ-инструментов диктуется реальными потребностями госов. В отличие от коммерческих организаций, где все направлено на получение прибыли и сокращение издержек, в государственных структурах стоят несколько иные задачи, и вот основные из них:

• Формирование регламентированной отчетности – в каждом государственном ведомстве предусмотрена отчетность по строго определенной форме. В ручном режиме подготовка таких отчетов парализует работу отделов на несколько дней, и аналитические системы позволяют решить этот вопрос максимально четко и быстро. Например, автоматизированная система ПФР готовит более 300 различных отчетов.
• Ведение реестров – большинству ведомств за последние годы было поручено ведение того или иного реестра. Так, «Роскомандзор» ведет реестр запрещенных сайтов и обнаруживает их клоны, ПФР ведет реестр страховщиков и страхователей. Слежение за актуальностью такого реестра – практически идеальная задача для BI-системы.
• Мобильная аналитика – руководителям отделов различных организаций оказывается удобно работать с оперативными показателями, которые можно найти на своем планшете. В случае с госструктурами кроме отслеживания общего процесса, данная возможность также дает менеджеру необходимый уровень личной защиты, ведь «на ковре» у начальства можно дать оперативный ответ на любой вопрос.

Данные федерального масштаба

Для решения этих задач необходимо использовать особые технологии, такие как БОЛЬШИЕ хранилища данных и специальные инструменты для работы с ними. В федеральных ведомствах используются базы данных, содержащие до 50 Тб и более. Например, аналитическое хранилище данных ИАП АИС-2 в ПФР отличается следующими характеристиками:

• Расчетная емкость до 200 Тб.
• Более 1500 пользователей с перспективой подключения до 6000.
• 17 источников данных с разной типологией, некоторые из которых – территориально-распределенные.
• Более 2000 сущностей (таблиц).
• Порядка 10 000 атрибутов сущностей.
• Около 300 показателей и 500 измерений модели данных.
• Более 15 000 атрибутов модели данных.

Чтобы обеспечить работу подобных систем в распределенном варианте (ведь данные хранятся в разных регионах, то есть многие источники работают на территориально-распределенных платформах), мы использовали классический подход создания хранилищ данных по Ральфу Кимбаллу и Биллу Инмону.

Было создано три слоя хранения, которые дополняются одним слоем BI

1. Слой подготовки данных состоит из двух уровней: SRC, где хранятся исходные данные, и Staging, на котором мы применяем алгоритмы объединения и очистки данных. Это необходимо потому, что в распределенных государственных системах нормативно-справочная информация не всегда оказывается однородной. Конкретный пример: справочники в каждом из 85 регионов хоть немного, да отличаются.

2. Слой детальных данных непосредственно обеспечивает хранение данных. К нему нет прямого доступа, но именно в нем постоянно актуализируется информация, важная для заказчика. Детальный слой представляет собой полную картину предметной деятельности организации с точки зрения информации. Приведем пример: в системе персонифицированного учета (СПУ), хранится информация по всем застрахованным лицам, а в системе Администрирования страховых взносов (АСВ) имеются данные платежах от страхователей. Более того, когда застрахованное лицо выходит на пенсию, его данные вносят в Федеральную базу данных пенсионеров (ФБДП). Интеграция всех этих данных по каждому объекту производится именно в слое детальных данных. Для этого происходит серьезная модификация и трансформация данных, построение связей между разными системами.

3. Витрины данных обеспечивают выдачу информации по запросам. Это достаточно сложный слой, так как каждая отдельно взятая витрина может предоставлять информацию, полученную из разных участков детального слоя. Фактически именно витрины данных обеспечивают представление различных показателей или выборок данных. Уже через витрины создается подключение к слою бизнес-логики (BI). Например, когда пользователь хочет узнать значение какого-то показателя и нажимает на кнопку в графическом интерфейсе системы BI, данные моментально поступают из витрины, так как они уже подготовлены для запроса. Если информация о людях, вышедших на пенсию в текущем году, была собрана по всему региону, в витринах уже будут представления по районам, либо по размеру пенсии – по любому заранее заданному критерию.

Особенности эксплуатации

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

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

Ну и, наконец, самая любопытная черта организационно-экономических систем и их хранилищ заключается в поддержке историчности данных. Ни для кого не секрет, что в случае исправления ошибок или возобновления канала связи, который не работал, данные могут меняться задним числом. Но для построения отчетов могут потребоваться как актуализированные данные, так и информация «на определенную дату». Как показала практика, поддержка такого функционала требует выделения дополнительных ресурсов хранилища и внесения корректировок в проектирование его топологии. Задумайтесь, кроме хранения разных версий, ко всем полям необходимо привязывать метки времени и периода действия данных, которые также должны учитываться при запросах от BI-системы.

Параллельная обработка запросов

Чтобы получить достаточно высокую производительность и справиться с различными проблемами распределенного хранилища сложной топологии, мы в своей практике используем асинхронные массово-параллельные многопроцессорные MPP-системы, например, IBM Netezza. В этом случае огромные объемы данных размещаются по узлам территориально-распределенного кластера, и каждый аналитический запрос может быть обработан параллельно на целом ряде серверных узлов. Об архитектуре MPP и особенностях ее работы мы расскажем в следующем посте.