Архитектура микросервиса для ETL

Я перепроектирую небольшое монолитное программное обеспечение ETL, написанное на Python. Я нахожу микросервисную архитектуру подходящей, поскольку она даст нам гибкость при использовании различных технологий, если это необходимо (Python - не самый приятный язык для корпоративного программного обеспечения, на мой взгляд). Поэтому, если бы у нас было три микросервиса (назовем их Extract, Transform, Load), в будущем мы могли бы использовать микропроцессор Java для Transform.

Проблема в том, что здесь не представляется возможным передать результат вызова службы в ответе API (например, HTTP). Вывод из Extract будет представлять собой гигабайт данных.

Одна из идей заключается в вызове Extract и хранении результатов в базе данных (это действительно то, что делает этот модуль в монолите, поэтому его легко реализовать). В этом случае служба вернет только ответ "да/нет" (был успешный процесс или нет).

Мне было интересно, есть ли лучший способ приблизиться к этому. Что было бы лучшей архитектурой? Являюсь ли я разумным?

2
12 июля '17 в 4:48
источник поделиться
4 ответов

Это интересная проблема. Лучшим решением для этого может быть Reactive Spring Boot. Вы можете использовать сервис Extract как приложение Reactive Spring Boot, а вместо отправки данных данных, передайте данные в требуемую службу.

Теперь вам может показаться, что при потоковой передаче он может работать на рабочей нити. Ответ - нет. ИТ работает на уровне ОС. Он не задерживает поток запросов для потоковой передачи результатов. Это красота реактивной весенней загрузки.

Пройдите это и исследуйте
https://spring.io/blog/2016/07/28/reactive-programming-with-spring-5-0-m1

2
12 июля '17 в 5:04
источник

Если ваш процесс ETL работает с отдельными записями (некоторые распараллеливаемые единицы вычислений), то есть много вариантов, с которыми вы могли бы пойти, вот несколько:

Система на основе сообщений

Вы можете основывать свою обработку на системе обмена сообщениями, например Apache Kafka. Он требует тщательной настройки и конфигурации (в зависимости от долговечности, доступности и масштабируемости ваших конкретных случаев использования), но может дать вам лучшую форму, чем реляционный db.

В этом случае шаги ETL будут работать совершенно независимо и просто потребляют некоторые темы, производят некоторые другие темы. Затем эти другие темы подхватываются следующим шагом и т.д. Между шагами E/T/L не будет прямой связи (вызовов).

Это чистое и понятное решение с независимыми компонентами.

Готовые решения для обработки

Существует несколько решений OTS для обработки/вычисления и преобразования: Apache Flink, Apache Storm, Apache Spark.

Хотя эти решения, очевидно, ограничивают вас одной конкретной технологией, они могут быть лучше, чем создание подобной системы с нуля.

Нестойкий

Если фактические данные являются потоковыми/основанными на записи, и не требуется сохранять результаты между шагами, вы можете просто уйти с длинным опросом HTTP-вывода предыдущего шага.

Вы говорите, что это слишком много данных, но эти данные не нужно переходить в базу данных (если это не требуется), и вместо этого можно перейти к следующему шагу. Если данные производятся непрерывно (не все в одной партии), в той же локальной сети, я не думаю, что это будет проблемой.

Это было бы очень легко сделать, очень просто проверить и контролировать.

1
12 июля '17 в 12:34
источник

Там никто не мешает вам иметь SFTP-сервер, содержащий CSV или базу данных, хранящую результаты. Вы можете делать все, что угодно. Использование обмена сообщениями для передачи гигабайт данных или потоковой передачи через HTTP может или не может сделать чувства для вашего случая.

1
29 мая '18 в 17:13
источник

Я бы посоветовал вам взглянуть на Apache, он очень похож на большие корпоративные приложения, такие как informatica, talend и отображения этапов данных, но обрабатывает их в меньшем масштабе, но многократно. Это на самом деле помогает вам вычислять и преобразовывать вещи на лету/по мере их поступления, а затем сохранять/загружать в файл /db.

В настоящее время у нас с flink процесс закрытия 28,5 ГБ за каждые 4 часа, и это просто работает. В первые дни нам приходилось запускать нашу ежедневную партию и поток flink, чтобы гарантировать, что оба они дают последовательные результаты, и в итоге большинство потоков остались активными, а ежедневные партии были постепенно удалены. Надеюсь, это кому-нибудь поможет.

0
21 мая '19 в 19:22
источник

Посмотрите другие вопросы по меткам или Задайте вопрос