Comments 2
Очень доступно изложено о том, какие подводные камни надо прощупать перед проектированием DWH. Я бы добавила телеграм как способ оповещения (уже много где поддерживается).
Также стоит учитывать при выборе и проектировании, как сильно может вырасти система (горизонтальное масштабирование). Пример: в известном банке загрузка дневного регламента была реализована сначала в одном управляющем workflow (потоке) в Информатике. Т.е. отдельные процессы, конечно, были реализованы как отдельные workflow, а в управляющий встраивались "ссылки", которые вызывали загрузки в правильном порядке. Управляющий поток буквально за год так разросся, что при любых действиях с ним интерфейс Информатики зависал минут на 30-40 – и при запуске, и при открытии, и при любом изменении, даже банальном “протягивании стрелочки”. В общем, переделывать потом пришлось на несколько маленьких потоков и костылить прикручивать между ними взаимосвязи.
Также интересный вопрос, как решение будет работать с несколькими процессами над одним объектом. Например, я возьму и запущу две загрузки в одну и ту же таблицу за разные периоды (инициирующую/исправляющую и регламентную, например) - по идее, система не должна такого позволять вообще или должна выстраивать их в очередь (вторая не стартует, пока первая не добежит).
Мы у себя выбрали смешанное решение - ETL-инструмент (Datastage, да, то еще г, так уж вышло) выступает как движок, умеющий выполнять операции разного рода. А логика уже на нашей системе. Описание, если интересно, тут
Важнейшие критерии при выборе Extract – Load решения для интеграции данных в DWH