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

Каждому — по хранилищу

Хранилище данных является неотъемлемой частью IT-инфраструктуры современного банка. Особенно верно это для крупных кредитных организаций, у которых число информационных систем составляет десятки, а то и сотни. И хранилище данных не одно, а несколько: бывают ситуации, когда разные хранилища обслуживают разные подразделения; а бывает, что внедрено новое хранилище (или даже  два-три), но старое по разным причинам продолжает использоваться. Такими причинами могут служить частичное наполнение нового хранилища, нехватка ресурсов для перевода всего функционала в новое хранилище или простое нежелание пользователей отказаться от ставших привычными за годы эксплуатации интерфейсов. В результате кредитно-финансовому учреждению приходится сопровождать не одно, а несколько хранилищ данных со всеми сопутствующими действиями: выгрузкой, загрузкой, обогащением данных, разбором ошибок и так далее. И это — далеко не полный список возникающих сложностей. 

Хранилище только частично покрывает потребности

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

Технологии меняют мир

Технологии идут вперед, и это не дань моде, а назревшая необходимость. Если хранилище данных работает свыше пяти — десяти лет, то велика вероятность того, что в нем не используются технологии, которые появились в последние годы и сейчас «на слуху»: Data Lake, Big Data, NoSQL, CDC processing и многие другие. А ведь именно они должны обеспечить эффективную обработку больших объемов данных, рост которых (причем нелинейный) в перспективе не собирается останавливаться.

Каковы возможные решения?

Красиво. Затратно. Долго

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

Вариант красивый, но долгий — порой пользователи могут ждать годы, когда их отчеты будут переведены на новое хранилище и отлажены. 

Рационально. Экономно. Быстро

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

• Если необходимо более оперативно получать детальные данные, то следует внедрить ODS и Data Lake на основе CDC, пересмотреть алгоритмы загрузки, адаптировать структуры DDS под них.
• Если необходимо подключить системы с большим объемом данных, с которым плохо справляется текущая реализация выгрузки-загрузки, то нужно добавить к упомянутым выше ODS и Data Lake систему на основе Hadoop и получить преимущества горизонтального масштабирования.
• Если есть проблемы в реализации расчетов или в длительности получения конечных витрин, то решением будет пересмотр их состава и распределения данных, проверка базовых и прикладных витрин.
• Если у пользователей есть усталость от legacy-интерфейсов, установите внешний BI, которых сейчас на рынке множество.
• Главным преимуществом второго метода является быстрое получение существенного эффекта от проекта. В самом деле, если область DDS в основном преимущественно сохраняет семантику (набор таблиц, набор значимых полей в них), то это значит следующее:
• существующие отчеты легко адаптируются;
• аналитики сразу могут сразу использовать свои наработки, не тратя время на изучения модели;
• ETL-процессы уже существуют и требуют не создания, а адаптации;
• контроль качества данных уже реализован и налажен;
• пользователи получают относительно бесшовный переход на использование нового хранилища. 

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

Мы наблюдаем тенденцию: как правило, необходимость в обновлении существующего хранилища данных возрастает у тех заказчиков, у которых это хранилище данных работает на протяжении многих лет. В компании R-Style Softlab есть достаточная экспертиза, чтобы выполнять подобные проекты. Логическая модель остается без существенных изменений, как и физическая. Добавляются элементы из методологии Data Vault с учетом их достоинств и недостатков. Создается ODS с онлайн-захватом данных из систем-источников, дорабатываются ETL-процессы. Данные будут поступать в хранилище гораздо быстрее. Но главное — существующие отчеты и витрины потребуют минимальной переработки.

Cо временем команда внутреннего подрядчика может уйти, и экспертиза будет потеряна. В случае внешнего подрядчика вероятность этого меньше, так как он связан гарантийными и финансовыми обязательствами по поддержке продукта

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

Однако со временем команда внутреннего подрядчика может уйти, и экспертиза будет потеряна. В случае внешнего подрядчика вероятность этого меньше, поскольку он связан гарантийными и финансовыми обязательствами по поддержке продукта. Таким образом, в долгосрочной перспективе более надежно доверить работу внешнему подрядчику.

В идеале должен быть некий «коктейль», содержащий правильное соотношение тех, кто продвигает (и главное — умеет реализовывать на практике!) новые идеи, и тех, кто досконально знает существующие подходы и ограничения текущего решения, потому что, как известно, «дьявол кроется в деталях».

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