co się zmienia, gdy dane wejściowe mają rozmiar giga/terabajt?

Question

Właśnie zrobiłem pierwszy krok dla dzieci dzisiaj do prawdziwego obliczenia naukowego dzisiaj, kiedy pokazano mi zestaw danych, w którym najmniejszy plik to 48000 pól po 1600 wierszy (haplotypy dla kilku osób, dla chromosomu 22). I to jest uważane za małe.

Piszę Pythona, więc ostatnie kilka godzin spędziłem na czytaniu o HDF5, Numpy i PyTable, ale wciąż mam wrażenie, że nie mam pojęcia, co tak naprawdę oznacza zestaw danych o wielkości terabajtów. programista.

Na przykład ktoś zwrócił uwagę, że w przypadku większych zestawów danych niemożliwe jest odczytanie całej zawartości pamięci, nie dlatego, że komputer ma niewystarczającą ilość pamięci RAM, ale dlatego, że architektura ma niewystarczającą przestrzeń adresową! Rozwaliło mój umysł.

Jakie inne założenia byłem opierając się na zajęciach, które po prostu nie działają z wejściem tego wielkiego? Jakiego rodzaju rzeczy muszę zacząć robić lub myśleć inaczej? (To nie musi być specyficzne dla Pythona.)

Answer 1

Jestem obecnie zaangażowany w informatyce wysokiej wydajności w małym kącie przemysłu naftowego i regularnie pracować z zestawów danych z rzędów wielkości jesteś zaniepokojony. Oto kilka punktów do rozważenia:

1. Bazy danych nie mają wiele trakcji w tej dziedzinie. Niemal wszystkie nasze dane są przechowywane w plikach, niektóre z tych plików oparte są na formatach plików taśm zaprojektowanych w latach 70-tych. Uważam, że część przyczyn nieużywania baz danych ma charakter historyczny; 10, nawet 5 lat temu uważam, że Oracle i jego krewni nie byli w stanie zarządzać pojedynczymi zestawami danych O (TB), nie mówiąc już o bazie danych takich zestawów danych.

   Innym powodem jest koncepcyjnym niedopasowanie pomiędzy zasadami normalizacji skutecznej analizy i projektowania baz danych i charakter zbiorów danych naukowych.

   myślę (chociaż nie jestem pewien), że powód (y) wydajność jest znacznie mniej przekonujące dzisiaj. A przyczyna niedopasowania koncepcji jest prawdopodobnie również mniej paląca, ponieważ większość dostępnych baz danych może poradzić sobie z zestawami danych przestrzennych, które są ogólnie o wiele bliższe konceptualnemu dopasowaniu do innych zbiorów danych naukowych. Widziałem coraz częstsze korzystanie z baz danych do przechowywania metadanych, z pewnym odniesieniem do plików zawierających dane z czujników.

   Nadal jednak patrzę na HDF5.Ma dla mnie kilka atrakcji (a) to tylko kolejny format plików, więc nie muszę instalować DBMS i zmagać się z jego złożonością, i (b) przy odpowiednim sprzęcie mogę równolegle czytać/zapisywać plik HDF5 . (Tak, wiem, że potrafię równolegle czytać i pisać bazy danych).

2. Co prowadzi mnie do drugiego punktu: kiedy mamy do czynienia z bardzo dużymi zestawami danych, naprawdę trzeba myśleć o używaniu obliczeń równoległych. Pracuję głównie w Fortranie, jedną z jego mocnych stron jest składnia tablicowa, która pasuje bardzo dobrze do wielu naukowych obliczeń; innym jest dobre wsparcie dla równoległości. Wierzę, że Python ma również wiele różnych narzędzi do obsługi równoległej, więc prawdopodobnie nie jest to dla ciebie zły wybór.

   Oczywiście można dodać równoległość do systemów sekwencyjnych, ale o wiele lepiej jest rozpocząć projektowanie równoległości. Aby wziąć tylko jeden przykład: najlepszy algorytm sekwencyjny dla problemu bardzo często nie jest najlepszym kandydatem do równoległości. Lepiej możesz użyć innego algorytmu, który lepiej skaluje się na wielu procesorach. Który prowadzi schludnie do następnego punktu.

3. Myślę również, że być może trzeba będzie pogodzić się z poddania żadnych załączników masz (jeśli je masz) do wielu sprytnych algorytmów i struktur danych, które pracują dobrze, gdy wszystkie dane ma siedzibę w pamięci. Bardzo często starają się dostosować je do sytuacji, w której nie można uzyskać danych do pamięci za jednym razem, jest znacznie trudniejsze (i mniej wydajne) niż brute-force i dotyczące całego pliku jako jedną dużą tablicę.

4. Wydajność zaczyna mieć znaczenie w poważny sposób, zarówno wydajność wykonania programów, jak i wydajność programisty. Nie chodzi o to, że zbiór danych 1 TB wymaga 10 razy więcej kodu niż 1 GB danych, więc musisz pracować szybciej, ponieważ niektóre pomysły, które będziesz musiał wdrożyć, będą szalenie skomplikowane i prawdopodobnie muszą być napisane przez specjalistów z domeny, tj. naukowcy, z którymi pracujesz. Tutaj specjaliści domeny piszą w Matlabie.

Ale to dzieje się zbyt długo, bym lepiej wrócić do pracy

Answer 2

Podczas gdy niektóre języki mają naturalnie niższe obciążenie pamięci w swoich typach niż inne, to tak naprawdę nie ma znaczenia dla danych tej wielkości - nie przechowujesz całego zestawu danych w pamięci niezależnie od języka, którego używasz, więc "wydatek" Pythona jest tutaj nieistotny. Jak zauważyłeś, po prostu nie ma wystarczającej ilości miejsca na adres, aby odnieść się do wszystkich tych danych, nie mówiąc już o tym.

Co to oznacza zwykle jest albo a) przechowywania danych w bazie danych, lub b) dodanie środków w postaci dodatkowych komputerów, zatem dodanie do dostępnej przestrzeni adresowej i pamięci. Realistycznie skończysz robić obie te rzeczy. Kluczową rzeczą, o której należy pamiętać podczas korzystania z bazy danych, jest to, że baza danych to nie tylko miejsce, w którym można umieścić dane, gdy jej nie używasz - można wykonać WORK w bazie danych i należy spróbować to zrobić. Technologia baz danych, z której korzystasz, ma duży wpływ na rodzaj pracy, jaką możesz wykonać, ale baza danych SQL na przykład dobrze nadaje się do wykonywania wielu zadań matematycznych i robienia tego sprawnie (oczywiście oznacza to, że projekt schematu staje się bardzo ważna część twojej ogólnej architektury). Nie wysysaj danych i nie manipuluj nimi tylko w pamięci - spróbuj wykorzystać możliwości kwerend obliczeniowych bazy danych, aby wykonać jak najwięcej pracy, zanim kiedykolwiek umieścisz dane w pamięci w procesie.

Answer 3

w skrócie, główne różnice IMO:

1. Powinieneś wiedzieć wcześniej, co się prawdopodobny wąskim gardłem będzie (I/O lub CPU) i skupi się na najlepszym algorytmie i infrastrukturze , aby rozwiązać ten problem. I/O dość często jest wąskim gardłem.
2. Wybór i dostrajanie algorytmu często dominuje nad każdym innym dokonanym wyborem.
3. Nawet niewielkie zmiany algorytmów i wzorców dostępu mogą wpływać na wydajność rzędu rzędów wielkości. Bardzo dużo zoptymalizujesz. "Najlepsze" rozwiązanie będzie zależne od systemu.
4. Porozmawiaj ze swoimi kolegami i innymi naukowcami, aby czerpać korzyści z ich doświadczeń z tymi zestawami danych . W podręcznikach nie można znaleźć wielu sztuczek.
5. Wstępne przetwarzanie i przechowywanie może być bardzo skuteczne.

pasma I/O

Początkowo pasma I/O często stanowi wąskie gardło. Aby dać ci perspektywę: przy teoretycznym limicie SATA 3, odczyt 1 TB zajmuje około 30 minut. Jeśli potrzebujesz dostępu losowego, przeczytaj kilka razy lub napisz, chcesz to zrobić w pamięci przez większość czasu lub potrzebujesz czegoś znacznie szybciej (np.iSCSI z InfiniBand). Twój system powinien być w stanie zrobić to najlepiej, aby maksymalnie zbliżyć się do teoretycznego limitu dowolnego interfejsu, z którego korzystasz. Na przykład zwykłe uzyskiwanie dostępu do różnych plików równolegle w różnych procesach lub HDF5 na szczycie MPI-2 I/O jest dość powszechne. W idealnej sytuacji wykonuje się równolegle obliczenia i operacje we/wy, aby jeden z nich był "bezpłatny".

Klastry

W zależności od przypadku, albo I/O lub moc procesora niż być wąskim gardłem. Niezależnie od tego, który z nich jest, zwiększanie wydajności można uzyskać dzięki klastrom, jeśli można skutecznie dystrybuować swoje zadania (przykład: MapReduce). Może to wymagać zupełnie innych algorytmów niż typowe przykłady podręczników. Poświęcanie czasu na rozwój to często najlepszy czas.

Algorytmy

w wyborze pomiędzy algorytmami, big O algorytmu jest bardzo ważne, ale algorytmy o podobnym Big O może być znacznie różni się w zależności od wydajności miejscowości. Im mniej lokalny jest algorytm (tj. Im więcej brakuje pamięci podręcznej i brakuje pamięci głównej), tym gorsza wydajność - dostęp do pamięci jest zwykle o rząd wielkości wolniejszy niż pamięć główna. Klasycznymi przykładami ulepszeń będzie tiling dla multiplikacji macierzy lub loop interchange.

komputerowe, językowe, Narzędzia specjalistyczne

Jeśli gardłem jest I/O, oznacza to, że algorytmy dla dużych zbiorów danych mogą korzystać z większej pamięci głównej (na przykład 64-bitowy) lub języków programowania/struktur danych z mniejsze zużycie pamięci (np. w Pythonie __slots__ może być przydatne), ponieważ większa pamięć może oznaczać mniej operacji we/wy na czas procesora. BTW, systemy z TBs pamięci głównej nie są niespotykane (np. HP Superdomes). Podobnie, jeśli wąskim gardłem jest procesor, szybsze maszyny, języki i kompilatory, które umożliwiają korzystanie ze specjalnych funkcji architektury (np. SIMD, takich jak SSE), mogą zwiększyć wydajność o rząd wielkości.

Sposób wyszukiwania i uzyskiwania dostępu do danych oraz przechowywania informacji meta może być bardzo ważny dla wydajności. Często używasz plików płaskich lub niestandardowych pakietów specyficznych dla domeny do przechowywania danych (np. Nie jako relacyjnej bazy danych bezpośrednio), które umożliwiają bardziej efektywny dostęp do danych. Na przykład: kdb+ jest specjalistyczną bazą danych dla dużych serii czasowych, a ROOT używa obiektu TTree do wydajnego dostępu do danych. Wspomniany przykład to kolejny przykład.

Answer 4

Główne założenia dotyczą liczby procesorów/pamięci podręcznej/pamięci RAM/pamięci masowej/przepustowości, które można mieć na jednej maszynie w przystępnej cenie. Istnieje wiele odpowiedzi na stackoverflow w oparciu o stare założenia maszyny 32-bitowej z 4G RAM i około terabajta pamięci i sieci 1Gb. Z 16GB modułami RAM DDR-3 w cenie 220 EUR, pamięć RAM 512 GB, 48 rdzeniowych maszyn może być zbudowanych w rozsądnych cenach. Przejście z dysków twardych na SSD to kolejna ważna zmiana.