из набора импортёра конкретные типы, которые забирают данные из разных endpoint-ов.
Я добавляю ETL в этот процесс и пишу данные в промежуточную БД, которую буду потом трансформировать, как мне буде удобно.
Мне нужно знать, какие таблицы в БД к каким импортёрам относятся. Как лучше построить эту связь?
А обязательно таблицы?
Уточните вопрос, пожалуйста
> Мне нужно знать, какие таблицы в БД к каким импортёрам относятся Вы хотите именно в таблицах хранить сущности или это не принципиально?
А в чем вопрос? Как лучше - хз, в условиях нет инфы что бы оценить
вообще БД для ETL это тупо временная карманная база на sqlite. Ми забираем данные из datasource-ов (их может быть несколько), трансформируем в тот формат, которые будет удобен нашей системе и потом сливаем все данные в основную систему. Для бизнес логики нужно отображать клиенту инфу, про то, какие таблицы находятся в импортёре. Я пока что не знаю, где лучше эту инфу держать, как формировать эти связи и ТД.
А почему не на лету создавать таблицы, которые содержат имя импортера или ид импортера? endpoint_1_{import_name} и т.д Соответственно если импортер состоит из разного количества эндпоинтов создать и каждый эндпоинт имеет разные данные, то по имени можно спокойно найти к какому эндпоинту отнести таблицу и какому импортеру и после обработки, просто грохнуть временную таблицу.
Окей, был такой вариант Но есть вероятность, что таблицы могут быть персистентными (например, при повторном импорте будем забирать часть данных от конкретной даты)
Ну тогда относительно различных эндпоинтов, применяйте разные стратегии. Если не нужно рубить/удалять, то кладите в одну таблицу для эндпоинта и добавляйте ссылку на импортера. После обработки данных, к примеру, можно оставлять условно последнюю запись для загрузки в дальнейшем только от определенной даты. Вам нужно определиться с эндпоинтами, как вы в них ходите, где что "дешевле" по получению данных, что можно не кешировать, где эндпоинты залить себе, потому как для всех импортёров будут одни и те же данные и т.д.
Спасибо Приму во внимание)
может вам пересмотреть модель и сделать как в прометее? т е самим ходить за данными из aggregation mechanism в каждый дата сорс
Не выйдет, к сожалению - механизм агрегации базируется полностью на sql. Интерфейсы получения из datasource могут быть разными (БД, файл, API)
А как это у вас механизм агрегации на SQL, а датасорс по API? Вы условный json ложите в реляционку в raw формате?
Если коротко, то да: почти все API возвращают нам плоскую структуру (некоторые в формате json, некоторые xml)
Как тогда это противоречит идее выше где предлагается ходить самому? Общение по API у вас, судя по всему, уже есть, и судя по всему вы же и собираете эти данные
Тогда я, скорее всего, неправильно понял идею
Обсуждают сегодня