Управление сколь-нибудь сложной системой требует получения информации от нее с последующим анализом для выработки управляющего решения. Эти задачи в современном мире решаются с помощью информационно-аналитических систем (ИАС). Чем управляемый объект сложнее и масштабнее, тем больше и сложнее оказывается обслуживающая его ИАС. Одна из таких систем — информационно-аналитическая подсистема автоматизированной-информационной системы нового поколения Пенсионного фонда России (ИАП АИС ПФР-2, далее просто ИАП). Предметом статьи являются вопросы построения больших ИАС, больших аналитических хранилищ данных, особенности создания таких систем, их архитектура, необходимая функциональность, проблемы с которыми сталкивается интегратор при построении систем такого масштаба будут рассмотрены на примере ИАП. Но сначала необходимо определить, какие системы можно считать большими и что их отличает от остальных.
Отличительные особенности больших аналитических систем
Большие аналитические информационные системы характеризуются несколькими параметрами. Основной критерий — объём хранилища данных, ядра ИАС. Мы в компании считаем большими системами те, у которых объём хранилища не менее 20 Тб (в ИАП АИС ПФР-2 объём хранилища составляет 50 Тб, целевое значение — 200 Тб). Эту метрику мы используем даже при подборе сотрудников — архитекторов систем, чтобы оценить опыт будущего архитектора, задавая вопрос — хранилища какого объёма он до сих пор проектировал и внедрял.
Второй критерий — количество пользователей, которые регулярно подключаются к системе — это значение должно быть порядка нескольких сотен или тысяч человек. Целевое количество пользователей ИАП — 6000, в настоящий момент их 1500. Это сотрудники, которые регулярно подключаются, строят отчёты и анализируют большой объём данных.
Следующий показатель большой аналитической системы — количество преднастроенных отчётов. Большая система должна предоставлять пользователям несколько сотен различных отчётов. В ИАПе сейчас около 300 отчётов.
Еще одна характеристика большой системы — количество предметных областей. Что это такое? Предметная область — это совокупность процессов и объектов, имеющих близкое функциональное назначение. Например, в банковском деле есть такие предметные области как кредиты, депозиты, взыскания задолженности и т.п. Если предметная область одна или две, то такая система не может считаться большой, а просто узкоспециализированной. В ИАПе сейчас подключено и реализовано двенадцать предметных областей. Они все разнородные и разнообразные, в том числе и по типам назначения. Есть области чисто для отчётности, например, отчётность департамента администрирования страховых взносов или отчётность департамента персонифицированного учета. В этих модулях есть регламентированные отчёты и инструмент их построения, и пользователи используют их на регулярной основе. Таких модулей большинство, есть модуль отчётности департамента организации выплаты и назначения пенсий, есть модуль отчётности департамента организации и контроля инвестиционных процессов, а есть модуль типа ВИР (ведомственные информационные ресурсы). Этот модуль строит различные реестры государственного или ведомственного назначения (реестр застрахованных лиц, реестр страхователей и т.п.) и в соответствии с программой «Электронного межведомственного взаимодействия» на базе этих реестров работают электронные сервисы, которые функционируют на портале ПФР и в СМЭВ, обслуживая десятки запросов в минуту. Например, на их основе реализована проверка СНИЛС или запрос периодов работы застрахованного лица. В данном случае информационная система используется нашим заказчиком не только для анализа, а как информационный ресурс для оказания электронных услуг.
Третий вид предметной области — модуль АППУР (аналитическая поддержка принятия управленческих решений). Из его названия понятно, что модуль предназначен для анализа и его целевая аудитория — руководство Пенсионного фонда, и он ориентирован не на регламентные отчёты, а на информационные панели, которые показывают выполнение ключевых показателей, исполнение бюджета, сбор страховых взносов по регионам, и связь финансовых показателей и показателей из оперативных данных.
Еще один важный показатель большой аналитической системы — количество источников данных. Любая аналитическая система, любое хранилище работает на базе источников. Большая аналитическая система имеет не один-два источника, а больше десятка. В ИАП сейчас подключено 17 источников. Типология источников может быть разной: разные типы, разные платформы. Источником может быть база данных или сервис. Они могут быть территориально распределены. Источник данных подсистемы Администрирования страховых взносов (АСВ) находится в 85 регионах (85 региональных баз).
Есть и связанные характеристики больших хранилищ данных — количество таблиц или сущностей, и их атрибутов. В ИАП АИС ПФР-2 около двух тысяч сущностей и порядка десяти тысяч атрибутов сущностей.
Ещё один из показателей большой системы — размерность модели. Мы выделяем три метрики: количество показателей, количество измерений и количество атрибутов. Для большой системы эти значения измеряются сотнями. В ИАП около трехсот показателей и около пятисот измерений. Количество атрибутов в данной модели — около 15 тысяч.
И еще одна характеристика — структура большинства источников меняется со временем. Это связано с тем, что АИС ПФР-2 — развивающаяся система. Меняется структура баз данных источников, меняется бизнес-логика. Заказчик не может ждать, когда ему внедрят оперативные системы, а затем создадут аналитику. Он хочет и требует, чтобы внедрение оперативных систем шло параллельно с внедрением информационно-аналитической системы.
Архитектура больших хранилищ данных и BI-систем
Из масштаба системы, её сложности, разнородности и разноплановости её компонент, изменчивости источников данных, возникает потребность в определенных технологиях и подходах к созданию такой системы.
Поговорим об архитектуре и о том, как строить хранилища такого масштаба.
Для небольших систем (до сотен гигабайт) можно строить хранилище просто на табличках. Для большой системы требуется определенная архитектура. Мы использовали подходы, развиваемые классиками-теоретиками построения хранилищ данных Ральфом Кимбаллом и Биллом Инмоном. Эти подходы предполагают следующее: три слоя хранилища данных плюс слой BI. Первый слой, который мы называем слоем подготовки данных, делится у нас на два уровня: уровень SRC, в который мы собираем исходные данные, и уровень Staging, где происходит группировка и объединение данных по определенным алгоритмам. Интеграция не всегда формальна. Несмотря на теоретически одинаковые справочники, используемые в 85 регионах, практически они оказываются разными. Поэтому помимо слияния идёт процесс интеграции данных, разрозненных с точки зрения нормативно-справочной информации. На этом подготовка данных завершается, и они перетекают в следующий слой — слой детальных данных.
Это фундаментальный слой, он предназначен для хранения данных. Пользователи к нему напрямую не обращаются. В нём хранятся все данные по всем предметным областям, которые интересуют заказчика, интегрированные с точки зрения объектной функциональности. Что это такое? Вернемся к источникам. В системе персонифицированного учета (СПУ), хранится информация по всем застрахованным лицам, а в АСВ есть привязка платежей, которые поступили по застрахованному лицу от его страхователя. Когда застрахованное лицо выходит на пенсию, по нему появляется запись в Федеральной базе данных пенсионеров (ФБДП). Если в СПУ хранятся данные по всем застрахованным лицам, то в других системах — какие-то их выборки. И интеграцию данных функционально разного назначения по одним и тем же информационным объектам мы проводим в этом детальном слое, который и предназначен для глобальной интеграции и хранения данных. В нём происходят очень серьёзные преобразования данных при движении от источника данных. Там создаётся объектная модель данных по каждой функциональной области со связями во все предметные области. Таким образом, детальный слой обеспечивает полную информационную картину всей предметной деятельности организации. Но наверх он ничего не выдает, выдача происходит через следующий слой — слой витрин данных.
Витрины предназначены для выдачи информации конкретным пользователям. Они имеют собственное функциональное назначение, каждая витрина может интегрировать информацию из разных мест детального слоя. В них производится необходимый предрасчет и расчет показателей. К готовым и предрасчитанным витринам подключается и внешний, по отношению к хранилищу, слой BI, включающий в себя бизнес-логику, бизнес-названия всех объектов и физический слой, обеспечивающий доставку данных из витрин. Когда пользователь в BI-интерфейсе выбирает мышкой какой-то показатель, строя отчёт, то система уже знает, откуда взять данные. Таким образом, витрина, это не просто база данных, а данные, подготовленные для анализа. Они денормализованы, и если требуется показатель по разным измерениям, например, застрахованные лица по регионам, по стажу, по видам назначенных пенсий, то эти показатели предрасчитаны и могут быть быстро получены. Они лежат в витрине и через слой BI идут к пользователю.
Теперь остановимся на функциональности большого хранилища данных. Во-первых, это возможность и полной, и инкрементальной загрузки данных. Когда внедряется какой-либо модуль, то должна быть произведена полная загрузка данных, а дальнейшее обновление хранилища осуществляется при помощи инкрементальной загрузки данных. Без данных витрина и BI никому не нужны. В маленьком хранилище можно обойтись полной перезагрузкой данных, так как она не займёт много времени.
Следующая черта присуща большинству хранилищ, связанных с организационно-экономическим и контрольным направлением — это историчность данных. Бывает так, что данные меняются задним числом, если не работал канал данных или страхователь не сдал вовремя отчёт. Но заказчику нужно получать состояние на определенную дату. Эта вещь на первый взгляд простая и невинная, но если задуматься, то оказывается, что это требует серьёзных ресурсов хранилища и, соответственно, особого подхода к его проектированию. Везде ко всем полям привязываются метки времени и периода действия, а также во всех запросах должны задаваться соответствующие параметры.
Технологии
Большие объёмы, и особенности архитектуры требует применения особых технологий, т.е. тех движков, которые заставят это всё работать. Основной элемент системы, её ядро—это хранилище. На нём должен стоять самый мощный движок. Эксперты RedSys считают, что самым прогрессивным движком для аналитических хранилищ данных является движок класса MPP (Massive Parallel Processing). Это технология даёт впечатляющие результаты с точки зрения быстродействия обработки данных. В ИАПе используется IBM Netezza. С точки зрения пользователя, программиста и аналитика — это просто сервер базы данных на PostgreSQL, на самом деле — это кластер серверов, каждый из которых содержит много ядер. В ИАПе используется средняя по масштабам поставщика система с 298 процессорами и 298 дисками. Система устроена так, что на каждый диск приходится по процессору и расстояние между местом, где хранятся данные и местом, где они обрабатываются минимально. Все такие ячейки организованы особым образом, данные «размазываются» по всем дискам. При поступлении запроса на получение данных при таком подходе выигрыш получается в десятки раз. Мы сравнивали производительность с вариантом одного из модулей системы, первоначально реализованного на AS-400. Там продолжительность вычислений для подготовки одного отчёта составляла более месяца, когда один цикл отчётности завершался, то сразу надо было начинать новый. При переходе на MPP среднее время вычислений для одного удалось свести к нескольким часам. Выигрыш в MPP — огромный и никакими другими ухищрениями такого быстродействия не достигнуть.
Следующая технология связана с забором данных из источников. В ИАП основным инструментом для этого является CDC (Change Data Capture). Эта современная технология реплицирует сведения о всех событиях, связанных с данными, в режиме реального времени, не влияя на производительность системы (не нагружая источник). На сервер источника данных ставится агент CDC, между источником и хранилищем ставится сервер CDC. Агентов может быть много. Они передают на сервер CDC все журналы изменения данных (запросы INSERT, DELETE и UPDATE), сервер CDC фиксирует также время взаимодействия и исполняет этот журнал, получая, то изменение данных, которое произошло. После чего он передает, полученные данные в хранилище. Такой механизм полезно применять на самых больших источниках данных.
Ещё две технологии касаются анализа данных. Одна из них — это классический инструмент OLAP. Пользователь вертит многомерный куб, чтобы получить требуемый срез данных. Разворот куба должен проходить не более чем за 5 сек. Мы ее используем в модификации ROLAP (реляционный OLAP). Полноценного MOLAP нет, но BI-инструмент в сочетании с Netezza позволяет достаточно быстро крутить реляционную модель.
Ещё одна передовая технология, появившаяся сравнительно недавно, In-memory BI. Память дешевеет и становится выгодным помещать все необходимые для анализа данные в оперативную память.
СПЕЦПРОЕКТ КОМПАНИИ REDSYS
