пределы python в параллельной обработке файлов

Question

Я потратил неделю на обработку некоторых gnarly текстовых файлов - некоторые в сотне миллионов рядов.

Я использовал python для открытия, разбора, преобразования и вывода этих файлов. Я выполнял задания параллельно, часто 6 -8 за раз, на массивном 8-процессорном 16-ядерном блоке EC2, используя SSD.

И я бы сказал, что выход плохо на 0,001% записи, как:

Expected output: |1107|2013-01-01 00:00:00|PS|Johnson|etc. 

Actual output: |11072013-01-01 00:00:00|PS|Johnson|etc. 
       or |1107|2013-01-01 :00:00|PS|Johnson 

Почти всегда, проблема не GIGO, а то, что Python не удалось написать разделитель или часть поле даты. Таким образом, я предполагаю, что я перегружаю SSD этими заданиями или, вернее, компьютер не работает с дросселем python на основе конкуренции записи для диска.

Мой вопрос заключается в следующем: как получить самую быструю обработку из этой коробки, но не вызвать такие ошибки «писать»?

Answer 1

Вы используете модуль multiprocessing (отдельные процессы) или просто используете потоки для параллельной обработки?

Я очень сомневаюсь, что проблема с SSD. Или питон. Но, может быть, модуль csv имеет состояние гонки и не является потокобезопасным?

Также проверьте свой код. И входы. Являются ли «плохие» записи последовательными? Можете ли вы воспроизвести их? Вы упоминаете GIGO, но на самом деле не исключаете это («Почти всегда, ...»).