Jaka jest korzyść z dzielenia pliku tfrecord na odłamki?

Pracuję nad rozpoznawaniem mowy z Tensorflow i planuję trenować LSTM NN z zestawem danych masywnych fal. Ze względu na wzrost wydajności planuję używać tfrecords. Istnieje kilka przykładów w Internecie (Inception na przykład.), W których pliki tfrecords są podzielone na odłamki. Moje pytanie brzmi: jaka jest korzyść z pliku tfrecords w odłamki? Czy jest jakiś dodatkowy wzrost wydajności tego podziału?

Badając zalety dzielenia na wiele plików, jedyna rozsądna odpowiedź nadeszła od jednego z pracowników Google.

Powiedzieli, że wzrost wydajności jest znikomy, ale zgadzam się, że dzielenie plików może pomóc, zwłaszcza jeśli chcesz przenieść zestaw danych do innej lokalizacji.

Należy pamiętać, że teraz nie trzeba tasować przed zapisaniem, ponieważ (obecnie) zalecana metoda odczytu zastosowań TFRecords, tf.data.TFRecordDatasetktóra implementuje bardzo przydatną .shuffle()metodę.

Dla tych, którzy nadal się zastanawiają: możesz tasować swoje dane. Dzięki TFrecords w jednym pliku nie można losowo zmieniać kolejności. Jest to zwykle konieczne w przypadku SGD.

Jednak w przypadku odłamków można zmieniać kolejność odłamków, co pozwala przybliżać tasowanie danych tak, jakbyś miał dostęp do poszczególnych rekordów TFR. Jest to wyraźnie lepsze niż nic, a im więcej odłamków masz, tym lepsze jest to przybliżenie.

Alternatywą jest wstępne pomieszanie danych poprzez ich powielenie lub całkowite nieużywanie TFRecords.

Dzielenie plików TFRecord na odłamki pomaga tasować duże zestawy danych, które nie mieszczą się w pamięci.

Wyobraź sobie, że masz zapisane miliony przykładów szkoleń na dysku i chcesz je wielokrotnie przeprowadzać podczas procesu szkolenia. Ponadto załóżmy, że dla każdego powtórzenia danych treningowych (tj. Każdej epoki) chcesz załadować dane w całkowicie losowej kolejności.

Jednym z podejść jest posiadanie jednego pliku na przykład szkolenia i generowanie listy wszystkich nazw plików. Następnie na początku każdej epoki tasujesz listę nazw plików i ładujesz poszczególne pliki. Problem z tym podejściem polega na tym, że ładujesz miliony plików z losowych lokalizacji na dysku. Może to być powolne, szczególnie na dysku twardym. Nawet macierz RAID 0 nie pomoże w szybkości, jeśli ładujesz miliony małych plików z losowych lokalizacji. Problem staje się jeszcze poważniejszy, jeśli uzyskujesz dostęp do plików przez połączenie sieciowe.

Innym podejściem jest odczytywanie przykładów treningu w jednym dużym pliku TFRecord i tasowanie przykładów w pamięci za pomocą bufora losowego. Jednak bufor losowy zwykle nie może być większy niż pamięć DDR dostępna dla procesora. A jeśli bufor losowy jest znacznie mniejszy niż zestaw danych, może on nie przetasować danych w odpowiedni sposób. Dane mogą być tasowane „lokalnie”, ale nie tasowane „globalnie”. Oznacza to, że przykładów z początku zestawu danych nie można tasować z przykładami z końca zestawu danych.

Dobrym rozwiązaniem jest użycie zrównoważonej kombinacji powyższych dwóch podejść poprzez podzielenie zestawu danych na wiele plików TFRecord (zwanych odłamkami). Podczas każdej epoki możesz losowo zmieniać nazwy plików odłamków, aby uzyskać losowe tasowanie globalne, i użyć bufora losowego, aby uzyskać lokalne losowanie. Dobra równowaga sprawi, że odłamki będą wystarczająco duże, aby zapobiec problemom z prędkością dysku, ale utrzymają odłamki na tyle małe, aby umożliwić odpowiednie przetasowanie przez bufor losowy.

Oto dokładne kroki:

1. Losowo umieść wszystkie przykłady treningu w wielu plikach TFRecord (odłamkach).
2. Na początku każdej epoki potasuj listę nazw plików odłamków.
3. Przeczytaj przykłady szkolenia z odłamków i prześlij je przez bufor losowy. Zazwyczaj bufor losowy powinien być większy niż rozmiar fragmentu, aby zapewnić dobre tasowanie między fragmentami.
4. Przekaż tasowane przykłady do swojego procesu treningowego.

Dzielenie pliku TFRecords na wiele niezależnych fragmentów ma zasadniczo 3 zalety:

1. Łatwiejsze tasowanie . Jak zauważyli inni, ułatwia to tasowanie danych na zgrubnym poziomie (przed użyciem bufora losowego).
2. Szybszy do pobrania . Jeśli pliki są rozproszone na wielu serwerach, równoległe pobranie kilku plików z różnych serwerów zoptymalizuje wykorzystanie przepustowości (zamiast pobierania jednego pliku z jednego serwera). Może to znacznie poprawić wydajność w porównaniu do pobierania danych z jednego serwera.
3. Łatwiejsze do manipulowania . Łatwiej jest poradzić sobie z 10 000 plików po 100 MB każdy niż z jednym plikiem 1 TB. Ogromne pliki mogą być trudne w obsłudze: w szczególności transfery są znacznie bardziej nieudane. Trudniej jest również manipulować podzbiorami danych, gdy wszystkie są w jednym pliku.