Интеграция информационных систем. Борьба с неконсистентными данными.
Обновлено: 10 апр. 2021 г.
Коллеги, привет! Меня зовут Бравин Илья, и сегодня я хочу поделиться с вами своим опытом использования Open Source решения Apache Zeppelin для упрощения и ускорения процесса выявления неконсистентных данных в интегрированных системах с различными базами данных.
Также расскажу, как мы выстроили процесс работы с неконсистентными данными.
О чем будет статья
Кратко о себе и компании, в которой работаю.
О неконсистентных данных в энтерпрайз системах простым языком.
4 причины появления неконсистентных данных.
Первый случай выявления неконсистентности.
Как мы находили неконсистентность, что нас не устраивало и к чему пришли.
Вы узнаете, почему мы выбрали именно Apache Zeppelin как решение для частичной автоматизации процесса поиска неконсистентности.
Покажу реальный пример работы с Apache Zeppelin.
Расскажу про кейсы, когда данный инструмент может быть полезен вам.
Дам список ссылок на полезную литературу по работе и установке Apache Zeppelin.
Кому будет полезен материал?
В первую очередь бизнес-аналитикам и системным аналитикам из IT-индустрии, работающими с Энтерпрайз системами в разрезе данных там, где присутствует одно или сразу оба условия одновременно:
а) Все системы/модули/сервисы интегрированы между собой через синхронизацию данных
б) Данные в системах хранятся в различных БД (например, MySQL и PostgreSQL или Oracle Database, Elasticsearch)
Вводная часть
Для начала, хотел бы немного рассказать о себе и о компании. На данный момент у меня более 6 лет опыта аналитической и консалтинговой работы.
На прошлом месте я в составе консалтинговой команды в течение четырех лет внедрял систему управления активами предприятия от IBM на 10 теплоэлектростанциях в различных регионах России, а на данный момент я на протяжении 2,5 лет являюсь системным аналитиком в логистической компании СДЭК в блоке CRM (отвечаю за модули Контрагент, Договор, Отчет менеджера продаж во внутренней ERP).
Я, как и многие коллеги, работающие в компаниях, существующих более 10 лет, помогаю переводить функциональность и данные из старой монолитной системы в новую микросервисную.
Для понимания масштабов компании приведу несколько метрик:
300 тыс. заказов в день
15 млн контрагентов
750 тыс. Договоров
25 тыс. сотрудников
3000 ПВЗ в 20 странах
Отдел IT - 350 человек
В дальнейшем для термина "неконсистентные данные" я буду применять сокращение - "НКД".
Проблематика
Как показывает опыт общения с коллегами, во многих проектах данные могут стекаться из разных источников, храниться в разных базах, кто-то может пользоваться дополнительно сторонними сервисами аналитики. Соответственно, перед аналитиками порой встают задачи “подружить” такой зверинец между собой.
В данной статье мы рассмотрим ситуацию, когда причиной, по которой необходимо “подружить” зоопарк систем в разрезе данных, является выявленная или пока потенциальная НКД между связанными системами.
Для наглядности, представьте, что у вас есть две системы “А” (монолит) и “Б” (микросервисы).
Большая часть пользователей работает в новой системе, а меньшая - в старой. Часть работает и там, и там.
Часть модулей имеют уже только одностороннюю миграцию ( из новой системы в старую), но большая часть - двустороннюю.
В новой системе отсутствует часть модулей, которые есть в старой ( например, Финансы) - они в процессе “переезда”.
Неконсистентные данные
Консистентность данных — согласованность данных друг с другом, целостность данных.
Если сказать простыми словами, то неконсистентность в данных - это различие в данных между системами в разрезе конкретного объекта или атрибута.
Как вы думаете, чем вообще грозит неконсистентность между двумя и более связанными Энтерпрайз системами?
Представьте, что у вас 50 тыс. договоров в старой системе имеют верный номер договора, а в новой системе - отличающийся.
Тогда все взаиморасчеты с клиентами по данным договорам могут “встать”, когда другие модули, которым для работы нужен номер Договора, начнут брать данные из новой системы. Причем с учетом массовости проблемы, это может просто остановить бизнес в целом на какое-то время!
Или, например, адреса доставки возвратов разные для 1% заказов (что для нас около 3 тыс. заказов) или телефон у клиента разный в разных системах, а на него приходят все уведомления и смс - насколько велики будут потери в деньгах и репутации?
4 причины возникновения НКД
Проработав более 6 месяцев по задачам связанным с НКД, мы выявили следующие причины их возникновения:
1. Ошибки в маппинге между моделями данных в любом из направлений миграции
Пример: статусы или любые другие списочные данные конвертируются неверно при миграции сущностей из одной БД в другую ( особенно, если статусные модели разные или списки давно не актуализировались в одной из систем).
2. Различаются обязательные атрибуты между системами (из-за этого сущности могут зависать в миграторе, не переходя в другую систему).
Пример: в старой системе есть необязательное поле “Адрес”, а в новой оно обязательное. Тогда миграция сущности, у которой оно не заполнено, из старой в новую систему не произойдет, а зависнет с ошибкой. Потенциально это может привести к НКД уже в разрезе сущностей, а не атрибутов.
3. Отсутствует событие на миграцию в другую систему (потерялось или вообще не создавалось)
Пример: событие на миграцию из старой системы в новую создавалось только при стандартном сохранении объекта через пользовательский интерфейс.
Т.е. изначально не заложили, что при изменении какого-то атрибута объекта не через пользовательский интерфейс (например, триггер или техподдержка делает запись напрямую в БД) создавалось событие на миграцию в новую систему.
4. Массовые ручные обновления боевых данных в БД
Пример: такие обновления часто нужно выполнять сразу во всех связанных системах, что при ручном исполнении приводит к постепенному росту неконсистентности данных из-за человеческого фактора.