Чтобы выбрать идеальную архитектуру, вам необходимо изучить некоторые аспекты вашей системы. Несколько актуальных вопросов:
- Как часто данные источника изменяются или обновляются?
- Насколько «свежими» и в реальном времени должны быть данные в отчетах?
- Как часто вы подозреваете, что исходные системы могут измениться в будущем?
- Насколько отличаются исходные структуры данных друг от друга?
- Могут ли в будущем появиться другие потребители, кроме системы отчетности?
- Помимо схематических различий, существуют ли семантические неоднородности в данных?
- Насколько сложны схемы?
Имея это в виду, давайте рассмотрим плюсы и минусы двух подходов к агрегации данных:
Центральное хранилище данных
- Простая единая схема для системы отчетности и других потребителей.
- Топология Hub-and-Spy означает, что для каждого источника требуется только один разъем. Если источник меняется, вам нужно исправить соединение только в одном месте.
- Данные могут быть не свежими, поскольку они зависят от периодической синхронизации с конечными системами.
- Если ваша схема хранилища данных не покрывает какие-то будущие потребности, топология со ступицами и спицами означает, что вам необходимо заменить все разъемы исходной системы.
- Схема жестко определена, но для обеспечения семантики необходима обширная система валидаторов.
- У вас есть возможность выполнить очистку данных в одном месте, исправляя известные вам классы грязных данных.
двухточечные пользовательские соединители
- Как можно ближе к данным в реальном времени.
- Все разъемы изолированы друг от друга, и если источник меняется, вам нужно заменить только один разъем.
- Однородность схемы и семантики может подразумеваться в ваших соединителях, но не может быть жестко обеспечена в той степени, в которой это подразумевает общая цель базы данных.
- Изменения в вашей системе отчетности или добавление новой цели могут потребовать от вас переделки всех соединителей.
- Система отчетности должна взять на себя ответственность за любую необходимую очистку данных.
- ESB (например, Biztalk) может быть хорошим способом управления этими соединителями, если они ориентированы на сообщения. Это добавит некоторые накладные расходы и затраты, но вы получите надежность и центральный брокер, чтобы помочь вам. В зависимости от размера и ожидаемого роста этой агрегированной системы, и ESB может представлять или не представлять чистое снижение сложности.
Я думаю, что в обоих случаях конструирование соединителей можно осуществить с помощью коммерческих продуктов, продуктов с открытым исходным кодом или простого старого кода. Когда вы начинаете платить за продукты, могут возникнуть некоторые дополнительные проблемы (которые могут повысить производительность), но основными затратами будут время ваших инженеров (как кодирование, так и анализ). Я бы предложил:
- Если вы уже свободно владеете данным инструментом для разъемов (например, ETL), продолжайте и рассмотрите его. В частности, это сильно отрежет шаблон.
- Если у вас нет опыта работы с этими системами, подумайте дважды - вы маскируете код в инструментах, которые могут запутать больше, чем помощь в одноразовом проекте. Но разрезать шаблон и использовать навязанную вам конструкцию может быть хорошей идеей в долгосрочной перспективе.
- Учтите, что требования когда-нибудь изменятся. Убедитесь, что вы выбрали технологию, которую легко адаптировать и поддерживать.
Конечно, нет Единого Ответа, но, надеюсь, это поможет вам найти правильные вопросы. Я думаю, что ключи управляют сложностью и понимают, что общая сеть агрегации когда-нибудь изменится. Вопрос только в том, когда.