С годами компания обычно доходит до того, что множество справочников по одной и той же теме (например, «Хобби» или «Гендер») хранятся в совершенно невообразимых форматах в нескольких системах, что препятствует эффективной интеграции и совместному использованию данных.
Традиционный подход к решению этой проблемы рекомендует создать единую версию каталога «Хобби» и настроить потоки обмена в него (и из него) для всех информационных систем.
Мы решили пойти другим путем и создать децентрализованную платформу для исследования данных с открытым исходным кодом — Recoder. Хотите точно знать, что мы сделали и какую роль Lucene и Apache CXF играют в нашем продукте?
Как обычно решается проблема хранения каталогов?
ИТ-директор решает прекратить разнообразие каталогов, и компания начинает создавать единый каталог.Он будет призван объединить все возможные типы корпоративных данных и, наконец, положить конец «лоскутной автоматизации» и «историческому наследию».
Если мы собираемся решить проблему, то сразу за все, верно? Но нет. Об ужасающих недостатках централизации не будет написано в презентациях крупных западных компаний, которые действительно хотят продать вам многомиллионное программное обеспечение, и не будет упомянуто в пресс-релизах.
Но если вы начнете такой проект, вы увязнете в долгой и утомительной реализации, которая займет годы.
Потому что сущности, которых вы приведёте к одному стандарту, имеют разную природу.
И это делает бессмысленным объединение их в рамках единой системы.
Если не верите, посмотрите сами в таблицу с типами данных, которые обычно встречаются в компании:
| Что они описывают | Стол, машина и т. д. | Физические, юридические лица, частные предприниматели/индивидуальные предприниматели.
|
Атрибуты сущности: образование, профессия и т. д. |
| Атрибут Критерий истинности | Цель (есть реальная машина, на которую можно посмотреть) | Цель (есть реальный человек или компания, у которой можно все спросить) | Субъективное (мнение эксперта, которое может быть не совсем правым, или системы) |
| Размер | Средний (десятки тысяч единиц) | Средний или большой (сотни тысяч и миллионы записей) | Малые (тысячи единиц) |
| Количество атрибутов | Среднее (атрибуты инвентаря) | Среднее (атрибуты клиента) | Маленький (в большинстве случаев структура типа id — имя) |
| Как существующие объекты меняются со временем? | Редко | Постоянно меняется (смена адреса, семейного положения, пола.
) |
Изменяются непредсказуемо в зависимости от потребностей информационной системы или бизнес-процесса.
|
Для товарно-материальных ценностей обычно реализуется Управление информацией о товарах (PIM), для контрагентов — Интеграция данных клиентов (CDI), но с классификаторами происходит нечто интересное: для них зачастую отдельно реализуются основные данные (MDM) и единая версия истины.
сформирован.
Правильно ли внедрить справочные данные и создать единую версию классификаторов? Или эту проблему можно решить по-другому?
Хорошо ли иметь единую версию истины для классификаторов?
При приведении классификаторов к единому виду обычно происходит один из следующих сценариев:- Создается каталог-монстр, учитывающий все комбинации в исходных системах.
Этот сложный каталог сложно изменить, он требует длительных согласований, и со временем все постепенно его игнорируют.
- Создается единый справочник, содержащий урезанную версию истины, устраивающую всех.
Любой, кто работал в крупной компании, знает, что поиск «истины, которая устраивает лебедя, рака и щуку» редко заканчивается успешно, а если и заканчивается, то требует многих и многих часов жарких встреч.
Кроме того, при использовании единого стандарта всегда возникает проблема «серой зоны».
В этом разница между ценностями в исходных системах и ценностями вожделенной единой версии истины, которую лично подтвердил специально назначенный эксперт. Наличие «серой зоны» и необходимость работы с ней приводит к появлению многочисленных рабочих потоков и альтернативных потоков, которые составляют значительную часть функциональности (стоимости чтения) мастер-данных.
Более того, бизнес не всегда готов годами ждать многочисленных согласований.
Поэтому в результате данные начинают передаваться «под таблицу», с помощью «временных» перекодировок (что это такое, поясним ниже).
Можно ли не создать единую версию истины?
Возникает закономерный вопрос: если единая версия истины стоит так дорого, можно ли обойтись без нее? Возможно – есть организации, не внедрившие справочные данные.Если внимательно поискать, то в этих организациях вы найдете множество небольших таблиц соответствия между справочниками «Пол», «Образование» и т. д. в разных системах.
Они будут храниться либо в Oracle, либо на шине, либо даже прямо в коде загрузки/выгрузки и экспорта/импорта.
Потому что таблицы поиска — это наиболее естественный способ решения проблемы, когда один и тот же домен обозначается по-разному для разных людей или систем.
Другими словами, можно заставить всех людей на земле говорить на эсперанто (создать единую версию истины), а можно пригласить китайско-немецкого медицинского переводчика на переговоры между китайскими и немецкими врачами (сделать таблицу соответствия).
Поэтому мы решили сделать синхронный переводчик, который понимает язык любой системы и позволяет согласовывать одни и те же концепции в рамках бизнес-процесса.
Таблицы соответствия мы назвали перекодировками, а саму систему — Рекодером.
Основное назначение Рекодера — хранение копий каталогов исходных систем и преобразований между ними.
Как все это работает
- В начале своей работы Рекодер считывает каталоги из баз данных исходных систем и сохраняет их копии в свою базу данных для последующей автоматической синхронизации.
Мы работаем с Sybase, MariaDB, Vertica, MS SQL Server, MySQL, Oracle, PostgreSQL.
выборка - В интерфейсе Транскодера оператор настраивает таблицы соответствия записей справочника.
Например, если в одной системе мужской пол введён как «М», а в другой — как «1», то оператор сопоставляет эти два значения, создавая перекодировку.
- Теперь любая система в процессе обмена информацией с другой системой может запросить Транскодер через интерфейс SOAP или REST перевести значение из своего классификатора на язык целевой системы или перевести полученные данные на свой диалект.
Перекодировка из справочника «Тип документа» определенной банковской системы (АБС) в справочник «Тип DUL» для CRM. Заграничный паспорт соответствует общему заграничному паспорту, водительское удостоверение соответствует другим документам.АБС и CRM не нужно интегрировать с мастер-каталогом, все довольны.
- Транскодер изначально был рассчитан на нагрузку до тысячи транскодирований в секунду, чтобы удовлетворить всех участников обмена информацией: шину, ETL-скрипты, обслуживающие процедуры реального времени, макросы в Xcel, космическую станцию и т. д.
Что вы можете сделать с помощью Recoder
Вы можете и должны:- Управляйте каталогами, группами каталогов и конверсиями (создавайте, редактируйте и удаляйте).
- Настройте периодическую синхронизацию каталогов Транскодера с исходными системами.
- Выполняйте онлайн-преобразования и получайте значения исходных каталогов через интерфейсы SOAP и REST.
- Получайте автоматические уведомления об изменениях в исходных каталогах.
Если вдруг появится значение, для которого нет преобразования, SOAP/REST вернет ошибку и оповестит об этом всех заинтересованных сторон.
Классификатор «Программа обслуживания клиентов», в котором атрибуты почему-то названы нерусскими словами «Описание» и «Полное описание».
Что под капотом?
Система разделена на модули для изоляции API, бизнес-логики и хранилища друг от друга.Spring Framework служит связующим контейнером IoC между компонентами.
Технологическую схему потоков данных можно представить следующим образом: 
Как видите, сервисы вообще не взаимодействуют напрямую с базой данных.
Вместо этого вся работа (чтение/запись) выполняется с индексом Lucene, а результаты операций записи дополнительно записываются в базу данных.
Почему это делается? Все просто: основная задача системы — как можно быстрее найти перекодировку (соответствие между записями в паре каталогов), и такая архитектура наиболее эффективно с этим справляется на больших объемах данных.
Плюс мы получаем полнотекстовый поиск по всем данным «из коробки».
Конечно, можно было бы использовать решения более высокого уровня, такие как Elasticsearch или Solr, но у них есть свои недостатки, бороться с которыми дороже, чем писать собственный код. В целях обеспечения целостности информации модификация данных выполняется за одну транзакцию в поисковом индексе и в базе данных.
Причём интерфейсы спроектированы так, что бизнес-логика приложения знает только об индексе, а СУБД можно заменить другим решением с минимальными доработками.
По сути, вам нужно реализовать пару классов и добавить их в путь к классам — все остальное сделает Spring и фабрики компиляции классов на лету (компиляция кода во время выполнения).
Фреймворком для интерфейсов SOAP и RESTfull является Apache CXF, который позволяет легко настроить версионирование API (если вдруг понадобится его изменить) и вклиниться в любой этап обработки входящего/исходящего сообщения.
Источник
github.com/hflabs/recoderИспытательный стенд
rcd.hflabs.ru/rcd/admin/login Логин: admin Пароль: демоДокументация
confluence.hflabs.ru/x/RICSCgЧто дальше
Мы начали внедрение Recoder для нескольких клиентов.Будем рады вашим комментариям по функционалу: что нравится, что нет, что непонятно.
Что ж, если этот продукт вам полезен, то мы не зря потратили время на написание этой статьи ;) Теги: #open source #open source project #Справочные данные #mdm #справочники #классификаторы #транскодер #открытый код #Анализ и проектирование систем
-
Написание Контента, Вызывающего Доверие
19 Oct, 24 -
Mysqlgame
19 Oct, 24 -
Все Уже Успокоились, Я Вам Скажу.
19 Oct, 24
