granice Pythona w przetwarzaniu plików równoległych

Question

Spędziłem tydzień przetwarzając niektóre gnarly pliki tekstowe - niektóre w zakresie rzędu stu milionów wierszy.

Użyłem Pythona do otwierania, analizowania, przekształcania i wyprowadzania tych plików. Pracowałem równolegle, często 6 -8 na raz, na ogromnej, 8-procesorowej, 16-rdzeniowej jednostce EC2, używając SSD.

I chciałbym powiedzieć, że wyjście jest złe na 0,001% z zapisów, jak:

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 

prawie zawsze, problemem nie jest GIGO, ale raczej, że Python nie udało się napisać separatora lub części pole daty. Zakładam więc, że przeciążam dysk SSD tymi zadaniami, a raczej, że komputer nie jest w stanie dławić pythona w oparciu o rywalizację zapisu na dysku.

Moje pytanie brzmi: jak uzyskać najszybsze przetwarzanie z tego pola, ale nie wywołać tego typu "zapisu"?

Answer 1

Czy używasz modułu multiprocessing (oddzielne procesy) lub po prostu używasz wątków do przetwarzania równoległego?

Wątpię, aby dysk SSD był problemem. Lub python. Ale może moduł csv ma stan wyścigowy i nie jest bezpieczny dla wątków?

Sprawdź również kod. I dane wejściowe. Czy "złe" zapisy są spójne? Czy możesz je odtworzyć? Wspomniałeś GIGO, ale tak naprawdę nie wykluczaj tego ("Prawie zawsze, ...").