2016-01-28 5 views
0

Как проверить сценарий?как валировать миллионы данных?

Сценарий 1:

Исходный файл Плоский файл, который содержит миллионы данных. Все данные из исходного файла загружаются в целевую таблицу в базе данных.

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

Примечание: мы не можем использовать xls для проверки, поскольку у нас есть миллионы записей.

+2

Вы знаете количество строк в файле, каждая строка должна стать новой записью в базе данных (в большинстве случаев). Вы знаете количество записей в таблице до и после выполнения ETL. Сравните числа, и вы узнаете, загружены ли все строки или нет. Это количественная проверка, а не качество. В качестве общего совета: Загрузите данные в отдельную таблицу, посвященную ETL, без чрезмерного преобразования записей. Используйте эту таблицу в качестве источника в последующих ETL. – Pred

+0

В качестве дополнительного примечания: Используя инструменты, предоставляемые СУБД, вы можете быть уверены, что некоторая ошибка не может произойти. Используйте ограничения (NOT NULL, CHECK и т. Д.), Чтобы сбой ETL, если данные недостаточны, ошибочны и т. Д. – Pred

ответ

0

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

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

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

+0

У меня есть требование, когда я должен проверить все данные, присутствующие в столбце Source [Flat Files], чтобы Целевая колонка [База данных]. Количество записей в исходном файле составляет 10 мил. –

0

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

  1. Загрузите файл в обычную TableA без ограничений, чтобы процесс импорта выполнялся нормально.
  2. Создайте еще TableB со всей проверкой достоверности. Тип, длина строки, FK.
  3. Создать одну процедуру магазина, чтобы переместить данные из TableA в TableB
  4. Включите ошибку поймать и вставить в другую таблицу Errors, где вы вставляете row_id и err_description
1

Есть много способов, можно проверить данные. Большая часть этого зависит от трех факторов:

  1. Сколько времени у вас есть на проверку?

  2. Каковы ваши возможности обработки?

  3. Являются ли данные на QA или производственном SQL-сервере?

Если вы в QA и имеют много вычислительной мощности, вы можете сделать основные проверки:

  • Где какие-либо предупреждения или ошибки во время загрузки данных?
  • Подсчитать общее количество элементов в базе данных против исходного файла
  • Подсчитать общее количество нулевых записей в базе данных
  • Проверьте общее количество столбцов vs.необработанный файл
  • Проверьте длину переменных. Они как и ожидалось?
  • Являются ли столбцы символов неожиданно усеченными?
  • Числовые столбцы соответствуют правильному количеству значащих цифр?
  • Являются ли даты разумными? Например, если вы ожидали даты с 2004 года, говорят ли они 1970 год?
  • Сколько дубликатов есть?
  • Проверьте, имеют ли данные в столбцах смысл. Несколько вопросов, которые вы можете задать: любые строки «сдвинуты»? Числовые переменные в числовых столбцах? Действительно ли ключевой столбец является ключом? Имеются ли названия столбцов? Ваша проверка нулевых записей должна помочь обнаружить эти вещи.
  • Можете ли вы вручную вычислить любые столбцы и сравнить свои вычисления с данными в файле?

Если вы разряжен обработка или на сервере, и не хочешь рисковать ухудшение производительности для других пользователей, вы можете сделать многие из вышеуказанных проверок с simple random sample. Возьмите, скажем, 100 000 строк за раз .; или, если необходимо, расслоить его.

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

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

Вы загружаете данные и предоставляете как можно больше разумных проверок. Если они удовлетворены результатом, и вы удовлетворены результатом, вы должны рассмотреть данные действительными.

Смежные вопросы