Советы о том, как написать надежные процессы передачи данных? - PullRequest
2 голосов
/ 22 сентября 2009

У меня есть ежедневный процесс, который основывается на плоских файлах, доставляемых в каталог «drop box» в файловой системе, который запускает загрузку этих данных, разделенных запятыми (из Excel внешней компании и т. Д.), В базу данных, фрагментарный Perl Приложение / Bash, эта база данных используется несколькими приложениями, а также редактируется напрямую с помощью некоторых инструментов GUI. Некоторые данные затем копируются с дополнительным приложением Perl в базу данных, которую я в основном использую.

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

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

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

Ответы [ 3 ]

1 голос
/ 22 сентября 2009

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

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

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

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

1 голос
/ 22 сентября 2009

Это именно то, для чего предназначены Менеджеры очереди сообщений . Вот некоторые примеры: здесь .

0 голосов
/ 10 сентября 2011

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

...