Развитие существующего хранилища данных: «красивое» решение против «рационального»

Александр Кондиайн, главный архитектор по хранилищам данных Департамента аналитических систем, R-Style Softlab

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

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

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

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

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

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

Технологии идут вперед. И это не дань моде, а назревшая необходимость. Если хранилище данных работает уже свыше пяти-десяти лет, то велика вероятность того, что в нем не используются технологии, которые появились в последние годы и сейчас на слуху: 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-процессы. Данные будут поступать в хранилище гораздо быстрее. Но самое главное заключается в том, что существующие отчеты и витрины потребуют минимальной переработки.

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

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

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

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

Просмотр материала на БО