Data Platform для целей формирования регуляторной отчетности

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

Совокупность этих факторов привела к изменению процессов управления данными. Data Platform – подход, который предлагает переосмысление традиционной концепции классического хранилища данных (КХД) с использованием технологий Big Data и новых подходов, применяемых при построении Data Lake платформ. Data Platform позволяет качественно учесть такие важные факторы, как рост количества пользователей, требования к time2customer (обеспечить возможность высокой скорости выполнения изменений), а также стоимость получаемого решения, в том числе, с учётом его дальнейшего масштабирования и развития.

В частности, предлагаем рассмотреть опыт автоматизации отчетности по РСБУ, налоговой отчетности и отчетности в Росфинмониторинг в Национальном Клиринговом Центре (далее – НКЦ).
Выбор архитектуры, позволяющей реализовать решение с учётом нижеизложенных требований, проходил крайне тщательно. В конкурсе участвовали как классические решения, так и несколько «бигдатных» – на Hortonworks и Oracle Appliance.

Предъявлялись основные требованиями к решению:

• Автоматизировать построение регуляторной отчётности;
• В разы увеличить скорость сбора и обработки данных, построения конечных отчетов (прямые требования на время построения всей отчетности за день);
• Разгрузить АБС за счет вывода процессов подготовки отчетности за пределы Главной книги;
• Выбрать оптимальное решение с ценовой точки зрения;
• Предоставить пользователям комфортное, гибкое, настраиваемое решение с точки зрения формирования отчетности;
• Получить масштабируемую отказоустойчивую систему, совместимую с технологическим стеком группы компаний МБ.

Было принято решение в пользу внедрения продукта Neoflex Reporting Big Data Edition на основе open-source платформы Hadoop Hortonworks.



СУБД систем источников является Oracle, также источниками являются плоские файлы различных форматов и изображения (для целей налогового мониторинга), загрузка отдельной информации производится посредством REST API. Таким образом, появляется задача работы как со структурированными, так и с неструктурированными данными.

Рассмотрим подробнее области хранения данных Hadoop кластера:

Operation Data Store (ODS) – данные хранятся «as is» системы источника, в той же форме и формате, которые определены системой-источником. Для хранения истории по ряду необходимых сущностей реализован дополнительный архивный слой данных (ADS).

CDC (Change Data Capture) – почему отказались от захвата дельты

Отдельного журнала аудита, пригодного для извлечения дельты, на стороне систем источников нет. При таких исходных условиях оптимальным выглядит отбор всех записей или выделение дельты на стороне Hadoop кластера.

При обработке дельты (и поддержке историчности) в рамках кластера необходимо учитывать следующее:

• В силу append-only режима хранения данных, варианты историчности, требующие обновления уже существующих данных, неприменимы, либо требуют сложной логики;
• Для сущностей, для которых в исходной системе уже поддерживается историчность данных, необходимо хранить полный срез историчности, т.к. возможны изменения в прошлых датах, и нужно учитывать полное состояние истории на дату расчета;
• Работа с историчностью с одной датой актуальности требует либо отбора только актуальных записей в рамках первичного ключа, либо создания промежуточных «кэширующих» витрин;
• При отсутствии промышленного CDC-средства загрузка данных из источника «срезами» будет быстрее, чем выделение «дельты» на уровне загрузки и затем прогрузка только выделенной «дельты».

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

• Реализован слой ODS, хранящий данные СИ в виде AS IS. Таким образом, никакой нагрузки на СИ, помимо однократных чтений для загрузки в Hadoop кластер, нет;
• В ODS историчность на уровне нетранзакционных данных СИ организована посредством архивного слоя данных, транзакционные данные единоразово загружаются на ежедневной основе (партицированно);
• Данные в PDS выстраиваются на основании историчных и неисторичных данных СИ в виде «1 срез актуальных данных на 1 дату» в разрезе каждой из сущностей PDS.

Portfolio Data Store (PDS) – область, в которой подготавливаются и хранятся в унифицированном централизованном формате критичные данные, к которым предъявляются повышенные требования по качеству не только данных, но и структуры синтаксиса и семантики. Например, к данным относятся реестры клиентов, сделок, баланс и т.п.

Разработка ETL-процессов ведется на Spark SQL с помощью Datagram. Он относится к классу решений — «акселераторов», и позволяет упростить процесс разработки посредством визуального проектирования и описания преобразований данных с помощью привычного синтаксиса SQL – а в свою очередь, код самих джобов на языке Scala генерируется автоматически. Таким образом, уровень сложности разработки эквивалентен разработке ETL на более традиционных и привычных инструментах таких, как Informatica и IBM InfoSphere DataStage. Следовательно, это не требует дополнительного обучения специалистов или привлечения экспертов со специальными знаниями технологий и языков Big Data.

На следующем этапе рассчитываются отчетные формы. Результаты расчетов помещаются в витрины СУБД Oracle, где на базе Oracle Apex строятся интерактивные отчеты. На первый взгляд может показаться нелогичным использование коммерческого Oracle наряду с open-source технологиями Big Data. Исходя из следующих факторов, было принято решение использовать именно Oracle и Apex:

• Отсутствие альтернативного BI-решения, совместимого со свободно-распространяемой СУБД и отвечающего при этом требованиям Бизнеса НКЦ в части построения экранных/печатных форм регуляторной отчетности;
• Использование Oracle для DWH, задействованных в качестве систем-источников данных Hadoop кластера;
• Наличие гибкой платформы Neoflex Reporting на Oracle, обладающей большинством регуляторных отчетов и легко интегрируемой со стеком технологий Big Data.

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

Поэтому, в случае необходимости расширения под новый класс задач, КХД зачастую сталкивается с фактически новым проектом внедрения с соответствующим T2C, в то время как в Data Platform все данные уже есть в системе и могут быть задействованы в любой момент времени без предварительной подготовки. Например, данные собираются из ODS, оперативно обрабатываются, «прикручиваются» к конкретной задаче и передаются конечному потребителю. Если непосредственное использование показало, что функционал корректен и применим в будущем, то запускается полный процесс, в рамках которого строятся целевые трансформации, подготавливаются или обогащаются портфели данных, задействуется слой витрин и строятся полноценные интерактивные отчеты или выгрузки.

Проект еще в стадии реализации, тем не менее, можно отметить ряд достижений и подвести промежуточные итоги:

1. Решены классические задачи формирования регуляторной отчетности:
   
   
   • Реализованы многофункциональные интерактивные отчеты и их выгрузки в различных форматах, поддерживающие требования регуляторов;
   • Настроена гибкая ролевая модель с использованием LDAP авторизации;
   • Достигнута требуемая скорость построения отчетности: 35 минут на загрузку из источников и построение портфелей данных в HDFS, ещё 15 минут на построение всех отчетных форм (50 шт. на момент написания статьи) в рамках одного операционного дня;
   • Настроена консоль администратора для простого управления загрузкой данных без понимания деталей работы HDFS и всего «зоопарка» Big Data;
   • Покрытие системы контроля качества данных расширено в том числе и на область портфелей данных (PDS) Hadoop кластера.
2. Подтверждена надежность и отказоустойчивость системы за счет стандартных преимуществ распределённой файловой системы Hadoop;
3. Использование open-source решений, в т.ч. Hadoop и Spark, позволило снизить затраты на оборудование (для проектов больших данных можно применять стандартные серверы среднего и начального уровня производительности, объединяя их в легко масштабируемые кластеры) и программное обеспечение. Таким образом, удалось снизить общую стоимость владения решением для работы с большими данным относительно решений на базе традиционного КХД;
4. Централизация только «полезных» данных системы и вместе с тем, доступность всех остальных данных для локальных или оперативных задач также сократили затраты на подготовку и сопровождение всей системы;
5. Благодаря Datagram и наличию всех данных СИ собранных воедино, у НКЦ есть возможность посредством визуального проектирования быстро строить новые ETL-процессы и вести разработку своими силами без привлечения внешних вендоров.

Автор материала — Кристина Козлова, менеджер бизнес-направления Big Data Solutions компании «Неофлекс»