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).
При обработке дельты (и поддержке историчности) в рамках кластера необходимо учитывать следующее:
- В силу 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, оперативно обрабатываются, «прикручиваются» к конкретной задаче и передаются конечному потребителю. Если непосредственное использование показало, что функционал корректен и применим в будущем, то запускается полный процесс, в рамках которого строятся целевые трансформации, подготавливаются или обогащаются портфели данных, задействуется слой витрин и строятся полноценные интерактивные отчеты или выгрузки.
Проект еще в стадии реализации, тем не менее, можно отметить ряд достижений и подвести промежуточные итоги:
- Решены классические задачи формирования регуляторной отчетности:
- Реализованы многофункциональные интерактивные отчеты и их выгрузки в различных форматах, поддерживающие требования регуляторов;
- Настроена гибкая ролевая модель с использованием LDAP авторизации;
- Достигнута требуемая скорость построения отчетности: 35 минут на загрузку из источников и построение портфелей данных в HDFS, ещё 15 минут на построение всех отчетных форм (50 шт. на момент написания статьи) в рамках одного операционного дня;
- Настроена консоль администратора для простого управления загрузкой данных без понимания деталей работы HDFS и всего «зоопарка» Big Data;
- Покрытие системы контроля качества данных расширено в том числе и на область портфелей данных (PDS) Hadoop кластера.
- Подтверждена надежность и отказоустойчивость системы за счет стандартных преимуществ распределённой файловой системы Hadoop;
- Использование open-source решений, в т.ч. Hadoop и Spark, позволило снизить затраты на оборудование (для проектов больших данных можно применять стандартные серверы среднего и начального уровня производительности, объединяя их в легко масштабируемые кластеры) и программное обеспечение. Таким образом, удалось снизить общую стоимость владения решением для работы с большими данным относительно решений на базе традиционного КХД;
- Централизация только «полезных» данных системы и вместе с тем, доступность всех остальных данных для локальных или оперативных задач также сократили затраты на подготовку и сопровождение всей системы;
- Благодаря Datagram и наличию всех данных СИ собранных воедино, у НКЦ есть возможность посредством визуального проектирования быстро строить новые ETL-процессы и вести разработку своими силами без привлечения внешних вендоров.
Автор материала — Кристина Козлова, менеджер бизнес-направления Big Data Solutions компании «Неофлекс»