Как ETL (база данных к базе данных) вписывается в SOA?

Ответ 1

Все эти ответы являются хорошими и полезными.

Как я теперь понимаю, SOA - это не реализация приложения, а архитектура ( "A" ), в основном корпоративная архитектура. Основным методом управления предприятием является делегирование ответственности за услуги ( "S" ).

Итак, если в структуре предприятия есть две разные бизнес-функции с двумя разными ответственными учетными записями, мы должны разделить ее на две разные службы с четко определенными контрактами (интерфейсами), политикой и методами аудита - вот основная цель SOA.

Но если это атомная функция с одним ответственным человеком, в SOA нет необходимости, и мы должны использовать простые технологии и реализовывать простое и быстрое надежное сервисное приложение.

Как и в моем первоначальном вопросе, это отсутствие информации о контексте задачи. Теперь я понимаю, что ссылки на базы данных не должны реализовываться между службами, и это плохой дизайн, поскольку он не совместим с управлением предприятием. Но в рамках сервиса это может быть простое решение.

Спасибо всем.

Ответ 2

В SOA вы можете адаптировать Biztalk или данные SAP BusinessObjects Интегратор способ обработки. В принципе, это служба задания/окна планировщика или что-то подобное. Вы предоставляете две точки обслуживания, 1 для планировщика для извлечения данных, а другое для планировщика для отправки данных. Ответственность диспетчера заключается в том, чтобы просто периодически запускать и преобразовывать данные.

Итак, основными шагами будут:

Шаг 1: Запуск планировщика и получение данных из службы A

Scheduler --get--> Service A
Service A --data--> Scheduler

Шаг 2: планировщик, выполняющий преобразование данных

[ Conversion --> Conversion --> Conversion --> Conversion ]

Шаг 3: планировщик отправляет данные в другую службу

Scheduler --data--> Service B

В BizTalk и SAP BusinessObject Data Integrator этапы настраиваются (они могут извлекаться из любой службы и могут преобразовывать данные сценариев), поэтому она более гибкая.

Тем не менее, все еще существуют обычные проблемы, которые могут возникнуть при обработке ETL. Например: данные слишком велики, влияние производительности сети, RTO, дублированные данные и т.д. Таким образом, лучшие практики ETL все еще требуют здесь (использование промежуточной таблицы, ведения журнала и т.д.).

Но являются ли ухудшение производительности и дополнительные моменты отказа стоит того?

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

Стоит ли это того? Это зависит. Если вы работаете в той же среде (той же базе данных), то это спорно. Если вы работаете в разных средах (например, в двух разных системах: от Asp.Net до SAP или от другого экземпляра базы данных), то эта архитектура лучше всего подходит для обработки ETL.

Ответ 3

ETL в целом подходит для SOA - например, Службы SOA могут выполнять операции ETL между собой.

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

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

Связь между базой данных и базой данных по-прежнему вписывается в SOA, когда только одна база данных является постоянством для службы SOA. Другой может рассматриваться как переход на другой ресурс или простая репликация, не связанная напрямую с SOA. В этом случае привязка базы данных к базе данных просто становится связанной с данными проблемой, которую вам разрешено иметь и решать.

Ответ 4

Для меня есть несколько точек, отсутствующих в настройках db-to-db и Rest-based: Исключения в процессе etl:

Когда происходит преобразование данных, считающихся действительными?
Как результат неудачной трансформации?
Простое отбрасывание данных в большинстве случаев не является вариантом.
Сбой системы/восстановление
Что делать, если одна/обе системы не работают некоторое время? Как обрабатывается синхронизация? Когда произошел сбой etl и где его нужно перезапустить?

Таким образом, вместо того, чтобы иметь базы данных или службы отдыха - обмениваться данными друг с другом imho, это больше связано с использованием технологий миграции, таких как Apache Camel или с помощью ESB, которые могут обрабатывать преобразования, разделять данные, обрабатывать их асинхронно, возвращать их вместе, иметь надлежащий мониторинг, восстановление, баланс нагрузки для оптимизации производительности. Это не обязательно ускорит "E" в etl, а не "L" (хотя это может и в обоих), но, конечно, ускорит "T" и имеет положительные результаты для целостности данных.
И, конечно же, ESB - это технологии, связанные с SOA. Apache Camel для меня на самом деле не является, хотя считается, что это эталонная реализация шаблонов интеграции предприятия.


В основном идея заключается в том, что etl - это проблемы, основанные на контенте, а не на основе структуры.

Итак, что вы можете сделать с этими методами, это что-то вроде:
DB < - DataExtractor - Validator
 - ContentLengthBasedRouter - Splitter
       (Ansynch)        - Трансформатор1,
       - Трансформатор 2..
             - Агрегатор -
 - ContentBasedRouter - Transformer3 -
- DataInserter
- Монитор
и многое другое, но это не укладывается в текстовое описание.