Извлечение по медленной или дорогой WAN-ссылке
Я думаю, то, что вы описываете, звучит уместно. Для медленного или дорогого канала WAN вы хотели бы уменьшить объем передаваемых данных. Некоторые подходы к этому:
- Изменен сбор данных.
- Сжатие.
Если вы можете легко идентифицировать новые транзакции или измененные данные в источнике, вы можете уменьшить объемы данных, только отправляя изменения. Если у вас есть ресурсы в источнике, но вы не можете легко идентифицировать измененные данные, вы можете сделать что-то вроде этого (для этого создайте общую структуру для этого):
- Выписка из источника
- Рассчитать значение хеш-функции, используя алгоритм с низкой вероятностью присоединения к дню рождения (например, MD5, SHA-1)
- Ведение базы данных или файла со значениями хеш-функции в форме (системный ключ источника, значение хеш-функции всех неключевых атрибутов)
- Объедините все что угодно с непревзойденным значением хеш-функции и отправьте его по глобальной сети.
- Обновление базы данных хэшей.
Надежная распределенная экстракция
Существует много режимов отказа для распределенной системы, подобной этой, поэтому вам потребуется реализовать достаточно надежный механизм обработки ошибок для этого. Примеры режимов отказа могут быть:
- Одна из исходных систем или сетевых подключений отключается, возможно, по расписанию.
- Один из пакетов данных опаздывает
- Данные как-то повреждены.
- Временные нагрузки или другие проблемы вызывают тайм-ауты, поэтому передача должна быть разбита на фрагменты.
В зависимости от требований к складской системе может потребоваться допустить сбой отдельных каналов. Для этого вам необходимо разработать надежную стратегию обработки ошибок.
Слияние на экстракт против слияния на преобразование
Если системы идентичны (например, POS-системы в сети розничных магазинов), вы, вероятно, получите более простую архитектуру, объединив данные до этапа преобразования. Это означает, что промежуточная область должна быть осведомлена об источнике данных, по крайней мере, для целей аудита.
Если у вас небольшое количество систем или несколько разнородных источников, объединение данных должно происходить в процессе преобразования. В этой ситуации ваш ETL, вероятно, будет иметь отдельные подпрограммы для каждой из исходных систем, по крайней мере, для части процесса.
Нужны ли нам ОРВ?
Одна из великих религиозных войн в хранилищах данных заключается в том, нужно ли иметь ОРВ. Я делал системы со структурами ODS и без них, и в отдельных случаях были причины для проектных решений. Я полагаю, что с обеих сторон этого решения нет универсального убедительного аргумента, который, во-первых, является обычной причиной существования религиозных войн.
Я считаю, что при взгляде на 50 000 футов, чем больше исходных систем и чем более однородны данные, тем сильнее аргумент в пользу ODS. Для этого можно нарисовать квадрант в стиле gartner:
High+--------------------------+--------------------------+
| | |
| Kimball Model (low/high) | Enterprise Data Warehouse|
H | Unified ODS model hard | (high/high) |
e | to meaningfully design. | ODS both difficult and |
t | Flat star schemas easier | probably necessary to |
e | to fit disparate | make a manageable system |
r | data into. | Better to separate trans-|
g | | formation ahd history. |
e +--------------------------+--------------------------+
n | | |
e | | Consolidated Reporting |
a | Data Mart (low/low) | (high/low) |
i | | ODS easy to implement |
t | ODS probably of | and will simplify the |
y | little benefit | overall system |
| | architecture |
| | |
Low +--------------------------+--------------------------+
Low Number of data sources High