?

Log in

No account? Create an account

serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Система сбора корпоративной отчетности: онтологии + Big data
serge_gorshkov
На прошлой неделе сдали в промышленную эксплуатацию еще один проект - систему сбора корпоративной отчетности одной из крупнейших госкомпаний. Функционал системы состоит в сборе с дочерних зависимых обществ информации, нужной для построения отчетов для внешних и внутренних потребителей (всего отчетов - несколько сотен). Если совсем по-простому, то раньше в компании собирали непосредственно те данные, которые в эти отчеты попадают, то есть итоговые цифры; в нашей реализации собираются исходные данные, а затем на их основании рассчитываются значения для формализованных отчетов. Это позволяет повторно использовать собираемые данные и верифицировать их.

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

Главный технологический интерес в этом решении представляет связка HBase (база данных в составе стека Hadoop) и графовой СУБД. Графовая база нужна для хранения сложной и изменчивой структуры информации (отчетные формы постоянно изменяются), а кластер HBase - для того, чтобы разместить огромный объем фактических данных.

Для использования в качестве "обычной" СУБД HBase не очень-то пригоден: он довольно медленный, функционал запросов не богат, возможности тюнинга минимальны (даже индексов, как таковых, нет - можно только создать синтетический ключ для каждой записи и использовать его для ограничения диапазона поиска). Зато он специально предназначен для распределенного хранения данных и выполнения вычислений на них, без чего в нашем проекте никак не обойтись.

Конечно, структура хранения в HBase у нас полностью определяется онтологией. Можно создавать и удалять классы объектов, атрибуты для них - структура данных в HBase автоматически следует этой эволюции.

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

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

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

То есть для того, чтобы "быстро менять структуру генерируемой отчетности по мере выхода новых нормативных и организационно-распорядительных документов" нужно обеспечить сбор достоверной и (пока) никому не нужной информации на все случаи жизни.
Насколько это удается в реальных внедрениях?


Edited at 2017-05-11 12:15 pm (UTC)

Хороший вопрос.
Аналитическая часть работы состояла как раз в том, чтобы посмотреть на существующую отчетность и понять, на каких исходных данных она строится. Затем посмотреть на полученный набор данных и детализировать его до разумного уровня. Здесь легко перестараться, так как детализацию в принципе можно взять очень глубокую. Глубокая детализация снижает риск того, что в какой-то момент не хватит той или иной информации для построения отчетов, но создает дополнительную нагрузку по ее сбору.

В итоге мы пришли к выводу, что слишком глубоко закапываться не стоит, а стоит сделать механизм, который позволяет менять уровень детализации по ходу работы системы. Например, некий показатель N сначала вводился как базовый, т.е. его значения забивались руками. Затем в какой-то момент его решили декомпозировать - например потому, что на основе этих декомпозированных данных можно вычислить и другие показатели. Соответственно, ввели в модели новые показатели более низкого уровня, создали алгоритм расчета для показателя N и других показателей. Получилось, что до некоторого момента t1 у нас показатель N хранился как готовое число, а после этого момента стал вычисляемым, и система должна такую ситуацию корректно обрабатывать. Так и реализовали.


  • 1