Всем привет!
Меня зовут Алексей, я старший аналитик команды «Цифровая карта магазина». Сегодня я хочу рассказать про различные варианты интеграции с внешними системами, какие подходы и технологии мы использовали при их реализации и что из этого вышло.
О продукте «Цифровая карта магазина»
Наш продукт – это цифровой двойник розничного магазина, предназначенный для визуализации и управления расстановкой торгового оборудования, презентационными поверхностями на торговом оборудовании, размещения различных товарных объектов на презентационных поверхностях. Также система обеспечивает возможности для планирования и контроля презентации товара, отображает схемы расстановки торгового оборудования и зонирования, выполнение регламентных операций в торговом зале и упрощает учет комплектующих товарного оборудования и элементов управления.
Недавно в системе была реализована возможность редактирования презентационных товаров до конкретных цветомоделей и отображения этой презентации в 3D-режиме торгового зала магазина.
Смежные системы и виды интеграций
Для поддержания работы определенных бизнес-процессов в цифровой карте используются данные из различных сторонних систем компаний. Например, это могут быть справочные данные из системы управления мастер-данными, учетные записи и права доступа из системы управления учетными данными, плановые параметры сезонных зонирований из системы планирования площадей зон магазина, остатки из системы сбора и хранения операций магазина и многие другие данные.
Я бы хотел сконцентрироваться на интеграциях в рамках ETL-процесса и его особенностях, а также рассказать, почему не всегда данные из чужой базы нужно переносить в вашу.
На слайде выделена зелеными рамками система «Поставщики», интеграция с которой происходит в рамках ETL-процесса.
Расскажу немного подробнее про то, что же такое ETL-процесс.
ETL-процесс: определение и особенности
ETL – это аббревиатура от Extract, Transform and Load, обозначающая совокупность процессов, которые выполняют извлечение данных из внешних источников, например, объекты базы данных или файлов, преобразование и очистка данных согласно бизнес-потребностям, загрузка обработанной информации в базу данных. Прикладное назначение ETL состоит в том, чтобы организовать определенную структуру и набор данных с помощью интеграции различных информационных систем.
Если говорить об особенностях этого процесса, извлечение данных может быть как полным, так и частичным, или инкрементальным. Частичное извлечение может поддерживаться благодаря системе-поставщику данных, которая может указать, какие записи были добавлены, изменены либо удалены в тех или иных источниках. Например, в системе управления мастер-данными существует возможность добавления вашей системы в качестве подписчика на инкремент, а с помощью определенной функции можно получить только те строки, которые были изменены с момента прошлой итерации извлечения данных.
После извлечения данные, которые мы собрали, могут не подходить для дальнейшего использования в нашей системе. Поэтому на этапе преобразования могут происходить следующие действия:
очистка данных. Задача этого преобразования создать более полезный набор данных, готовый к использованию в целевой базе данных. Например, удаление дубликатов, замена или удаление нулевых значений, поиск и исправление ошибок;
разделение. Помогает разделить данные, чтобы облегчить с ними дальнейшую работу. Например, преобразование адреса клиента в три поля: улица, номер дома, квартира;
извлечение. Позволяет достать отдельную информацию из поля данных, например, месяц заказа из формата месяц, день и год;
объединение. Можно сразу же объединять релевантные данные из разных источников в один. Например, собрать в один файл всю информацию о клиентах из офисов продаж разных регионов.
Для этапа загрузки тоже можно выделить определенные особенности:
полное обновление посредством удаления содержимого таблицы и заполнения ее свежим набором данных;
инкрементальная загрузка, подразумевающая обработку на интеграционном слое вашей базы данных, наличие новых записей и изменения в существующем. В случае обнаружения новых записей будет происходить добавление, а в случае совпадения – обновление.
Если говорить о применимости этих особенностей процесса, то я бы советовал использовать по возможности инкрементальное извлечение и загрузку данных. Например, для справочников, которые вы дублируете у себя в системе, либо данных, которые появляются в источнике с определенной периодичностью. В случае Цифровой карты это, к примеру, данные по кластерам «Категории», которые рассчитываются на будущий сезон.
Полное обновление можно использовать в случае отсутствия зависимости в конечных таблицах и в целях экономии времени на разработку интеграции. Но при этом нужно понимать, что при большом объеме извлекаемых данных будет тратиться больше ресурсов на преобразование и загрузку.
Рассказав немного об особенностях этапов процесса, я бы хотел перейти к практике применения данного процесса в рамках разных технологий систем-поставщиков, с которыми интегрируется Цифровая карта.
Интеграция Oracle -> Oracle
B случае, если поставщик данных имеет у себя Oracle базу данных, мы просим его создать для нас представление, структуру которого обговариваем заранее.
Далее по dblink подключаемся к этому представлению и извлекаем из него данные.
В случае, если у поставщика есть возможность инкрементального извлечения данных, то вместо представления обычно используется табличная функция.
На схеме видно, что этап преобразования может быть как на стороне поставщика данных, так и на стороне потребителя, а иногда и там, и там. Обычно все зависит от структуры, типов данных и, например, наличия зависимости от других систем загружаемых данных. Загрузка же в конечной таблице в нашей системе проходит через хранимые процедуры, разрабатываемые на интеграционном слое нашей базы данных.
Интеграция MS SQL -> Oracle
Однако не все системы в нашей компании имеют в распоряжении Oracle базу данных. Например, одной из таких систем, с которой мы интегрируемся, является Агеа Planning Management, или система планирования площадей.
В данном случае решением (в том числе рекомендованным Департаментом систем клиент-сервер) было использовать веб-сервис, т.к. вариант dblink из Oracle в NSSQL не гарантировал стабильную и оптимизированную работу.
В нашем случае это сервис, который вызывается по расписанию, выполняет запрос к поставщику данных, а после извлечения преобразовывает это в числовой формат и отдает в хранимую процедуру на интеграционном контуре.
Real-time интеграция
Помимо интеграции через ETL-процесс в некоторых функциях системы мы используем real-time интеграции.
Например, для первых трех пунктов на картинке слева мы используем RESTful API. А вот для получения текущих остатков мы обращаемся уже напрямую к представлению, которое расположено на сервере системы сбора и хранения операций магазина, и используем это хранилище в качестве источника данных при работе системы.
Текущие остатки – это один из примеров данных, которые лучше не переносить с одного сервера на другой, а запрашивать при необходимости, т.к. из-за большого количества записей и их изменений (даже за небольшой промежуток времени) скорость анализа и загрузки этих изменений (не говоря уже о полном обновлении) в большинстве случаев будет меньше, чем появление новой порции изменений.
Ручная интеграция
В некоторых случаях, когда, например, смежная команда еще не подготовила источники для интеграции, а у вас уже все готово и вы хотите начать тестировать ваш функционал, можно воспользоваться так называемой ручной интеграцией как реальных данных, так и просто их созданием.
И ещё немного о способах загрузки
Поделюсь еще одним способом загрузки. В случае, если у вас есть данные в табличном виде, с помощью Excel вы добавляете столбец и простой формулой генерируете Insert-запросы в нужную вам таблицу. Либо вы можете сохранить этот Excel в виде плоского файла с разделителем и воспользоваться инструментом Text Importer в PL/SQL Developer. Этот инструмент позволяет загрузить данные из вашего файла в таблицу и в случае необходимости может предварительно ее очистить. При этом он не строг к расположению столбцов в файле и позволяет преобразовывать данные перед загрузкой. Он также умеет избавляться от дублей, но, по моему личному опыту, может переусердствовать, поэтому лучше загружать файл, предварительно выбрав пункт Ignore Duplicates.
Подводя итоги
В заключение хотел бы сказать, что даже при наличии различных особенностей и упрощений в процессе миграции данных с одного сервера на другой, это решение не всегда является панацеей для всех бизнес-процессов вашей системы.
Однако же, как процесс выстраивания определенной структуры внутри вашей базы данных без бесконечных обращений в сторонние системы за ответом, может облегчить вам жизнь при проектировании системы и добавить чуть большую отказоустойчивость.