top of page

Интеграция информационных систем. Борьба с неконсистентными данными.

Обновлено: 10 апр. 2021 г.

Коллеги, привет! Меня зовут Бравин Илья, и сегодня я хочу поделиться с вами своим опытом использования Open Source решения Apache Zeppelin для упрощения и ускорения процесса выявления неконсистентных данных в интегрированных системах с различными базами данных.

Также расскажу, как мы выстроили процесс работы с неконсистентными данными.


О чем будет статья

  1. Кратко о себе и компании, в которой работаю.

  2. О неконсистентных данных в энтерпрайз системах простым языком.

  3. 4 причины появления неконсистентных данных.

  4. Первый случай выявления неконсистентности.

  5. Как мы находили неконсистентность, что нас не устраивало и к чему пришли.

  6. Вы узнаете, почему мы выбрали именно Apache Zeppelin как решение для частичной автоматизации процесса поиска неконсистентности.

  7. Покажу реальный пример работы с Apache Zeppelin.

  8. Расскажу про кейсы, когда данный инструмент может быть полезен вам.

  9. Дам список ссылок на полезную литературу по работе и установке Apache Zeppelin.


Кому будет полезен материал?

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

а) Все системы/модули/сервисы интегрированы между собой через синхронизацию данных

б) Данные в системах хранятся в различных БД (например, MySQL и PostgreSQL или Oracle Database, Elasticsearch)



Вводная часть


Для начала, хотел бы немного рассказать о себе и о компании. На данный момент у меня более 6 лет опыта аналитической и консалтинговой работы.


На прошлом месте я в составе консалтинговой команды в течение четырех лет внедрял систему управления активами предприятия от IBM на 10 теплоэлектростанциях в различных регионах России, а на данный момент я на протяжении 2,5 лет являюсь системным аналитиком в логистической компании СДЭК в блоке CRM (отвечаю за модули Контрагент, Договор, Отчет менеджера продаж во внутренней ERP).


Я, как и многие коллеги, работающие в компаниях, существующих более 10 лет, помогаю переводить функциональность и данные из старой монолитной системы в новую микросервисную.


Для понимания масштабов компании приведу несколько метрик:

  1. 300 тыс. заказов в день

  2. 15 млн контрагентов

  3. 750 тыс. Договоров

  4. 25 тыс. сотрудников

  5. 3000 ПВЗ в 20 странах

  6. Отдел IT - 350 человек


В дальнейшем для термина "неконсистентные данные" я буду применять сокращение - "НКД".


Проблематика


Как показывает опыт общения с коллегами, во многих проектах данные могут стекаться из разных источников, храниться в разных базах, кто-то может пользоваться дополнительно сторонними сервисами аналитики. Соответственно, перед аналитиками порой встают задачи “подружить” такой зверинец между собой.


В данной статье мы рассмотрим ситуацию, когда причиной, по которой необходимо “подружить” зоопарк систем в разрезе данных, является выявленная или пока потенциальная НКД между связанными системами.

Для наглядности, представьте, что у вас есть две системы “А” (монолит) и “Б” (микросервисы).


Большая часть пользователей работает в новой системе, а меньшая - в старой. Часть работает и там, и там.

Часть модулей имеют уже только одностороннюю миграцию ( из новой системы в старую), но большая часть - двустороннюю.

В новой системе отсутствует часть модулей, которые есть в старой ( например, Финансы) - они в процессе “переезда”.


Неконсистентные данные


Консистентность данных — согласованность данных друг с другом, целостность данных.


Если сказать простыми словами, то неконсистентность в данных - это различие в данных между системами в разрезе конкретного объекта или атрибута.


Как вы думаете, чем вообще грозит неконсистентность между двумя и более связанными Энтерпрайз системами?


Представьте, что у вас 50 тыс. договоров в старой системе имеют верный номер договора, а в новой системе - отличающийся.


Тогда все взаиморасчеты с клиентами по данным договорам могут “встать”, когда другие модули, которым для работы нужен номер Договора, начнут брать данные из новой системы. Причем с учетом массовости проблемы, это может просто остановить бизнес в целом на какое-то время!


Или, например, адреса доставки возвратов разные для 1% заказов (что для нас около 3 тыс. заказов) или телефон у клиента разный в разных системах, а на него приходят все уведомления и смс - насколько велики будут потери в деньгах и репутации?



4 причины возникновения НКД


Проработав более 6 месяцев по задачам связанным с НКД, мы выявили следующие причины их возникновения:


1. Ошибки в маппинге между моделями данных в любом из направлений миграции

Пример: статусы или любые другие списочные данные конвертируются неверно при миграции сущностей из одной БД в другую ( особенно, если статусные модели разные или списки давно не актуализировались в одной из систем).


2. Различаются обязательные атрибуты между системами (из-за этого сущности могут зависать в миграторе, не переходя в другую систему).

Пример: в старой системе есть необязательное поле “Адрес”, а в новой оно обязательное. Тогда миграция сущности, у которой оно не заполнено, из старой в новую систему не произойдет, а зависнет с ошибкой. Потенциально это может привести к НКД уже в разрезе сущностей, а не атрибутов.


3. Отсутствует событие на миграцию в другую систему (потерялось или вообще не создавалось)

Пример: событие на миграцию из старой системы в новую создавалось только при стандартном сохранении объекта через пользовательский интерфейс.

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

4. Массовые ручные обновления боевых данных в БД

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