Есть много способов, можно проверить данные. Большая часть этого зависит от трех факторов:
Сколько времени у вас есть на проверку?
Каковы ваши возможности обработки?
Являются ли данные на QA или производственном SQL-сервере?
Если вы в QA и имеют много вычислительной мощности, вы можете сделать основные проверки:
- Где какие-либо предупреждения или ошибки во время загрузки данных?
- Подсчитать общее количество элементов в базе данных против исходного файла
- Подсчитать общее количество нулевых записей в базе данных
- Проверьте общее количество столбцов vs.необработанный файл
- Проверьте длину переменных. Они как и ожидалось?
- Являются ли столбцы символов неожиданно усеченными?
- Числовые столбцы соответствуют правильному количеству значащих цифр?
- Являются ли даты разумными? Например, если вы ожидали даты с 2004 года, говорят ли они 1970 год?
- Сколько дубликатов есть?
- Проверьте, имеют ли данные в столбцах смысл. Несколько вопросов, которые вы можете задать: любые строки «сдвинуты»? Числовые переменные в числовых столбцах? Действительно ли ключевой столбец является ключом? Имеются ли названия столбцов? Ваша проверка нулевых записей должна помочь обнаружить эти вещи.
- Можете ли вы вручную вычислить любые столбцы и сравнить свои вычисления с данными в файле?
Если вы разряжен обработка или на сервере, и не хочешь рисковать ухудшение производительности для других пользователей, вы можете сделать многие из вышеуказанных проверок с simple random sample. Возьмите, скажем, 100 000 строк за раз .; или, если необходимо, расслоить его.
Это всего лишь несколько проверок, которые вы можете сделать. Чем больше сравнений и проверок здравомыслия, тем лучше.
Самое главное, сообщить эти данные и что-нибудь, что кажется странным для владельца файла. Они должны быть в состоянии дать вам дополнительную информацию о правильности загрузки данных или если они даже дали вам нужный файл в первую очередь.
Вы загружаете данные и предоставляете как можно больше разумных проверок. Если они удовлетворены результатом, и вы удовлетворены результатом, вы должны рассмотреть данные действительными.
Вы знаете количество строк в файле, каждая строка должна стать новой записью в базе данных (в большинстве случаев). Вы знаете количество записей в таблице до и после выполнения ETL. Сравните числа, и вы узнаете, загружены ли все строки или нет. Это количественная проверка, а не качество. В качестве общего совета: Загрузите данные в отдельную таблицу, посвященную ETL, без чрезмерного преобразования записей. Используйте эту таблицу в качестве источника в последующих ETL. – Pred
В качестве дополнительного примечания: Используя инструменты, предоставляемые СУБД, вы можете быть уверены, что некоторая ошибка не может произойти. Используйте ограничения (NOT NULL, CHECK и т. Д.), Чтобы сбой ETL, если данные недостаточны, ошибочны и т. Д. – Pred