Советы по написанию надежных процессов передачи данных?

У меня есть ежедневный процесс, который основан на плоских файлах, доставляемых в каталог «Drop Box» в файловой системе, это запускает загрузку этих данных с разделителями-запятыми (из excel внешней компании и т. д.) в базу данных, частичное приложение Perl/Bash , эта база данных используется несколькими приложениями, а также редактируется напрямую с помощью некоторых инструментов с графическим интерфейсом. Затем некоторые данные реплицируются с помощью дополнительного приложения Perl в базу данных, которую я в основном использую.

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

Я планирую исправить или переписать части или весь этот процесс передачи данных.

Я просматриваю рекомендуемое чтение, прежде чем приступить к этому, веб-сайты и статьи о том, как писать надежные, отказоустойчивые и автоматически восстанавливаемые процессы ETL, или другие советы будут оценены.


database etl data-transfer perl
person Ville M    schedule 21.09.2009    source источник
comment
Брэд, я чувствую некоторый сарказм... даже если задача безнадежна, я чувствую, что стоит прочитать о том, как другие люди справились с ней, или почему они не справились, как ты намекаешь...   -  person Ville M    schedule 22.09.2009

Ответы (3)


arrow_upward
1
arrow_downward

Именно для этого предназначены менеджеры очередей сообщений. Некоторые примеры приведены здесь.

person Seun Osewa    schedule 21.09.2009
comment
Отличный момент, который, безусловно, указывает мне правильное направление в отношении переписывания этого беспорядка. +1 - person Ville M; 22.09.2009

arrow_upward
1
arrow_downward

Вы не говорите, какой у вас сервер базы данных, но в SQL Server я бы написал это как пакет SSIS. У нас есть система, предназначенная также для записи данных в базу данных метаданных, которая сообщает нам, когда файл был получен, успешно ли он обработался и почему, если нет. Он также сообщает такие вещи, как количество строк в файле (которые мы затем можем использовать, чтобы определить, является ли текущий размер строки ненормальным). Одна из прелестей SSIS заключается в том, что я могу настраивать конфигурации соединений и переменных пакетов, что упрощает перемещение пакета из среды разработки в рабочую среду (мне не нужно входить и вручную изменять соединения каждый раз, когда у меня есть конфигурация). настроить в таблице конфигурации)

В SSIS мы выполняем различные проверки, чтобы убедиться, что данные верны, или очищаем данные перед вставкой в ​​нашу базу данных. На самом деле мы делаем очень много проверок. Сомнительные записи могут быть удалены из обработки файлов и помещены в отдельное место для проверки администратором базы данных и, возможно, передачи обратно клиенту. Мы также можем проверить, соответствуют ли данные в различных столбцах (и имена столбцов, если они заданы, не во всех файлах они есть) ожидаемым. Поэтому, если в поле почтового индекса вдруг окажется 250 символов, мы знаем, что что-то не так, и можем отклонить файл перед обработкой. Таким образом, когда клиент меняет местами столбец с фамилией и столбцом с именем, не сообщая нам об этом, мы можем отклонить файл до того, как будет импортировано 100 000 новых неверных записей. В SSIS мы также можем использовать нечеткую логику, чтобы найти существующие записи для соответствия. Так что, если в записи о Джоне Смите указано, что его адрес находится на Стейт-стрит, 213. это может сопоставить нашу запись, в которой говорится, что он живет по адресу 215 State Street.

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

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

person HLGEM    schedule 22.09.2009
comment
Затем я предлагаю вам поискать инструменты Oracle ETL, чтобы узнать, что можно сделать что-то подобное. Для меня ключ действительно решить, что вам нужно проверить перед последним шагом ввода данных в производственные таблицы. Чем больше проверок, тем лучше для вас. Наличие метаданных для просмотра того, что произошло с каждым импортом, также имеет решающее значение. Наличие места для хранения записей о потенциальных проблемах до тех пор, пока кто-нибудь не очистит их, также может быть хорошей идеей в зависимости от вашей среды. Таким образом, вы можете получить 200 000 хороших записей и избежать сбоя всего импорта, потому что у одной записи есть дополнительная вкладка. - person HLGEM; 22.09.2009

arrow_upward
0
arrow_downward

Я нашел эту статью полезной для аспектов обработки ошибок при выполнении заданий cron:

person Samuel Lampa    schedule 10.09.2011