Возможно ли создать универсальное решение для процесса синхронизации данных от разных поставщиков?

Question

[tiveli3655]

Есть проект в котором нужно "синхронизировать" данные присылаемые в (.csv/.xlsx и.т.д файлах) от разных поставщиков. Загвоздка в том, что процесс не удаётся структуризовать в виду постоянных сюрпризов от заказчиков, вот несколько таких:

- Заголовки у каждого поставщика отличаются в зависимости от используемой ими сторонней системы или могут отсутствовать вовсе
- Некоторые поставщики шлют статус изделия (одна запись для изделия в файле), а некоторые его историю (много записей для одного изделия в файле)
- Ещё могут быть всякие приколы, например поставщик ведёт учёт изделий в 2 системах, одна присылает данные точные, а другая нет, но содержит данные которых нет в первой, в результате бизнес-процесс требует мёржа двух присылаемых файлов
и уже потом синхронизации с базой и это только для этого поставщика, у другого например нужно делать запрос по API для получения недостающей инфы и.т.д
- Каждая компания использует свою уникальную систему кодов по которой нужно определять характеристики изделия
- У некоторых поставщиков данных об изделиях в файлах "мусорные" и для каждого поставщика присылаемые файлы нужно фильтровать по своему

Можно ли как-то попытаться структуризовать всё это/придумать другое решение? Или придётся и дальше для каждого поставщика отдельный обработчик писать?

Comments

[Илья]

оооо, у нас такая же боль.
Куча поставщиков, у всех разный формат данных, бывает несколько файлов, причём товар один, а sku немного отличается в разных файлах (видимо поставщик заполняет вручную и не парится).

У нас на каждого поставщика отдельный обработчик.

Но всё же бОльшая часть поставщиков адекватные, и дают нормальный формат, который можно хоть как-то подогнать под общую гребёнку, дав возможность менеджерам самим настраивать что-то (например в какой колонке в xlsx лежит sku, цена, остаток и тп.)

Поэтому в планах сделать какое-то более менее универсальное решение, но там, где поставщик совсем неадекват формат даёт - оставить возможность делать кастомный обработчик (уже силами программиста).

Answer 1

[mayton2019]

Если кратко - то да. Можно.

Если более подробно - то это долго. Мучительно. И где то в конце вы создадите свой собственный
язык (DSL) который будет описывать все бизнес-преобразования данных.

Общая идея такая. Вы пишете одинаковый софт на Python для всех поставщиков данных а различия
реализуете как часть конфигураций. Пример (совершенно выдуманный):

datasources:
  - datasource: Bitcoin
    format: xls
    header: on
  - datasource: Market
    format: csv
    header: off

transformations:
  - name : Bitcoin
    filter: "WHERE payload is not null"

sink:
  - name : Bitcoin
    dest: jdbc:thin:oracle@....

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

В качестве основы для DSL не обязательно нужен Yaml. Это можно делать на Python, Lua, Lisp
и вообще даже на основном языке. Главное чтобы конфигурационная часть была декларативной
и не содержала циклов и проверок условий.

Comments

[tiveli3655]

Спасибо за ход ваших мыслей. Я сопоставил ваш ответ, свой мысли и ответ моих коллег, и мы все пришли к плюс минус одинаковому рассуждению. Уверен, что отказ от частных решений в пользу универсального будет правильным.

Answer 2

[Slavik KENNY]

Такая-же боль на работе имеется: куча приборов химического анализа от кучи разных производителей - практически у каждого свой формат вывода.
И таки да - под каждый прибор свой метод разбора результатов: у одного можно напрямую к БД подключиться, у другого разбирать файлы с сетевой папки куда несколько однотипных приборов скидывают результаты, у третьего экселевские таблицы ковырять и т.д.
Итого у меня все это происходит в два этапа-
1 - получить в промежуточную таблицу данные с прибора (часть уникальная для каждого прибора, или каждого производителя), эта таблица содержит все возможные поля для данных, которые могу вообще поспать с любых приборов.
2 - универсальная часть, которая уже из промежуточной таблицы, по имеющимся данным раскидает их в рабочую базу ЛИМСа.

Как и сказал mayton2019 практически написался свой язык для парсинга результатов с приборов, так как никогда не угадаешь, какой прибор купят завтра и какие извраты с экспортом результатов в нем будут использоваться :)

Comments

[mayton2019]

Да. Это типичная постановка для BigData/ETL. Хуже всего то что твой DSL все равно не покрывает
все потенциально возможно новые инпуты. Поэтому такая задача будет почти всегда в стадии бета-версии.
Бизнес растет и меняется и под него надо постоянно подстраивать DSL. И очередная подстройка
уже может потребовать еще одного слоя абстракций например.

Answer 3

[Vindicar]

Разные форматы/особенности данных - разные обработчики.
Максимум, можешь использовать полиморфизм и оформить обработчики под каждого поставщика как классы с общим предком/интерфейсом и использовать паттерн "Цепочка ответственности".

Comments

[tiveli3655]

Общие интерфейсы можно выделить возведя всё до самых высоких уровней абстракции. "Загрузить", "Отфильтровать", "Отсортировать", "Обработать". Но в целом это мало чем помогает в плане "чистоты", т.к внутри всё равно много уникальных кейсов которые не возвести до общих интерфейсов. Единственная мысля которая мне пока приходит в голову это написать ETL под всё это, а дальше менеджеры пусть сами настраивают через графический редактор.

Answer 4

[Vamp]

Попробуйте какой-нибудь готовый ETL фреймворк: Airflow, Luigi, Airbyte и другие.

Answer 5

[Артем Воронов]

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

Что попробовали, но работает не очень:
- собственный DSL. Слишком дорого в поддержке, онбоардинг разработчиков превращается в ад.
- Использование шаблонов и маппингов специфичных для каждого истончика с помощью специфичного софта типа Xceptor. Опять таки дорого в поддержке и недостаточно гибко.

Что работает хорошо:
- Разделение процесса на этапы, все по классике Data Science: очистка данных от мусора, стандартизация форматов и т.п. Это позволяет не дублировать одну и ту же логику в отдельном обработчике для каждого источника, а консолидировать правила в одном месте.
- Elastic для перевода, синонимов и обработки опечаток
- Кросс проверки с дополнительными источниками данных, где это возможно