Это краткое описание того, что мы делаем. Сначала у нас есть промежуточные таблицы для всех наших импортов, которые включают в себя rowid. У нас есть два из них, один с необработанными данными и один с очищенными данными. Затем у нас есть таблица исключений, в которой записано имя файла, который мы обрабатываем, данные, идентификатор строки, отправленной в файл исключений, причина возникновения исключения и сгенерированный клиентом идентификатор для записи, если таковой имеется. (мы обычно требуем один, но это может не быть правдой для вас). Ваши потребности могут варьироваться в зависимости от того, что положить в таблицу. Первый поток данных - это тот, который передает все данные в таблицу обработки после выполнения всех этапов очистки.
Теперь, после каждого шага, который может иметь исключения, мы помещаем следующее в путь сбоя (красная стрелка и зеленая стрелка выходят из задачи)), производную задачу столбца, чтобы получить информацию, которую мы хотим получить имя файла и исключение, причина и данные, а затем целевое соединение с таблицей исключений для фактической вставки данных.
Наконец, у нас есть задача SQl выполнить после потока данных, чтобы определить, было ли слишком много исключений или исключений, которые должны уничтожать весь процесс. Только после того, как этот шаг пройден, мы делаем еще один поток данных для вставки в таблицы prod.
Теперь, что дает вам вся эта сложность? Во-первых, вы можете легко увидеть различия между очищенными и исходными данными, если после загрузки возникает проблема с данными. Это говорит нам о том, что отправленные данные были неверными (99% времени это так, но мы должны доказать это клиенту) или то, как мы их очистили, было неверным. Затем мы точно знаем, какие вещи не прошли обработку, и мы можем легко сгенерировать для нашего поставщика данных список неверных данных, которые они должны исправить. Наконец, нам почти никогда не приходится откатывать нагрузку на prod, потому что мы сделали все исправления, прежде чем перейти к prod. И фактическая загрузка в prod быстрее (наш prod находится на другом сервере, чем наш сервер обработки данных), потому что он не должен выполнять этапы очистки на этом этапе. Да, общий импорт может занять больше времени, но та часть, которая действительно может повлиять на наших клиентов, занимает меньше времени.
У нас также есть контроль над тем, что мы делаем, когда что-то не получается. По большей части (за исключением одного конкретного типа импорта) мы используем процент (согласованный с заказчиком) неудачных записей, чтобы определить, произошел ли сбой процесса. Таким образом, 4 плохих записи в файле с миллионами записей не остановят процесс, а 100 000 - остановят. И у нас есть несколько вещей, которые показывают, что даже одна плохая запись является причиной, чтобы остановить процесс. Это дает нам свободу определять в каждом конкретном случае, что мы хотим использовать, чтобы остановить процесс.