co się zmienia, gdy dane wejściowe są wielkości giga/terabajt?

Question

co się zmienia, gdy dane wejściowe są wielkości giga/terabajt?

Właśnie zrobiłem dziś swój pierwszy krok do prawdziwej naukowej informatyki, kiedy pokazano mi zbiór danych, w którym najmniejszy plik to 48000 pól na 1600 rzędów (haplotypy dla kilku osób, dla chromosomu 22). A to jest uważane za małe.

Piszę Pythona, więc spędziłem ostatnie kilka godzin czytając o HDF5, Numpy i PyTable, ale nadal czuję, że nie jestem naprawdę grokking co zestaw danych wielkości terabajt faktycznie oznacza dla mnie jako programista.

Na przykład ktoś zwrócił uwagę, że w przypadku większych zbiorów danych niemożliwe staje się odczytanie całości do pamięci, nie dlatego, że maszyna ma niewystarczającą ilość pamięci RAM, ale dlatego, że architektura ma niewystarczającą przestrzeń adresową! To rozwaliło mój umysł.

Jakie inne założenia opierałem w klasie, które po prostu nie działają z tak dużym wkładem? Jakie rzeczy muszę zacząć robić lub myśleć inaczej? (To nie musi być specyficzne dla Pythona.)

21

python scientific-computing large-data-volumes

Author: Wang, 2010-06-10

Source

4 answers

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

powinieneś wiedzieć wcześniej, co prawdopodobnie wąskie gardło będzie (I / O lub CPU) i skupi się na najlepszym algorytmie i infrastrukturze żeby się tym zająć. I / O dość często jest wąskim gardłem.
Wybór i dostrojenie algorytmu często dominuje nad każdym innym dokonanym wyborem.
nawet niewielkie zmiany w algorytmach i wzorcach dostępu mogą wpłynąć na wydajność przez rzędy wielkości. Będziesz dużo mikro-optymalizacji. "Najlepsze" rozwiązaniem będzie zależne od systemu.

Bandwidth and I / O

Początkowo przepustowość i wejścia / Wyjścia często są wąskim gardłem. Aby dać ci perspektywę: przy teoretycznej granicy dla SATA 3 , odczytanie 1 TB zajmuje około 30 minut. Jeśli potrzebujesz dostęp losowy, odczyt kilka razy lub zapis, chcesz to zrobić w pamięci przez większość czasu lub potrzebujesz czegoś znacznie szybszego (np. iSCSI z InfiniBand ). Twój system powinien być w stanie wykonać równoległe wejścia / Wyjścia, aby zbliżyć się jak najbliżej teoretycznego limitu interfejsu, którego używasz. Na przykład, po prostu dostęp do różnych plików równolegle w różnych procesach lub HDF5 na szczycie MPI-2 I/O jest dość powszechny. Idealnie, można również zrobić obliczenia i I/O równolegle tak, że jeden z nich jest "za darmo".

Klastry

W zależności od przypadku wąskim gardłem może być Wejście/Wyjście lub procesor. Niezależnie od tego, który z nich to klastry, można osiągnąć ogromny wzrost wydajności, 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. Spędzanie czasu na rozwoju jest często najlepszy czas spędzony.

Algorytmy

Przy wyborze pomiędzy algorytmami Duże O algorytmu jest bardzo ważne, ale algorytmy o podobnym dużym O mogą być znacznie różne w wydajności w zależności od lokalizacji. Im mniej lokalny algorytm jest (tj. im więcej braków pamięci podręcznej i pamięci głównej), tym gorsza będzie wydajność-dostęp do pamięci jest zwykle o rząd wielkości wolniejszy niż pamięć główna. Klasyczne przykłady ulepszeń to kafelkowanie dla mnożenia macierzy lub wymiany pętli .

Komputer, Język, Narzędzia Specjalistyczne

Jeśli twoim wąskim gardłem jest Wejście/Wyjście, oznacza to, że algorytmy dla dużych zbiorów danych mogą korzystać z większej ilości pamięci głównej (np. 64-bitowy) lub języków programowania / struktur danych o mniejszym zużyciu pamięci (np. w Pythonie __slots__ może być przydatne), ponieważ więcej pamięci może oznaczać mniej 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 pozwalają korzystać ze specjalnych funkcji architektury (np. SIMD Jak SSE ) mogą zwiększyć wydajność o rząd wielkości.

Sposób znajdowania i uzyskiwania dostępu do danych oraz przechowywania meta informacji może być bardzo ważny dla wydajności. Często będziesz używać plików płaskich lub niestandardowych pakietów specyficznych dla domeny do przechowywania danych (np. db bezpośrednio), które umożliwiają bardziej efektywny dostęp do danych. Na przykład, kdb + jest wyspecjalizowaną bazą danych dla dużych szeregów czasowych, a ROOT używa TTree obiekt do efektywnego dostępu do danych. pyTables , które wymienisz, byłby kolejnym przykładem.

5

Author: stephan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-14 16:14:10

Podczas gdy niektóre języki mają naturalnie niższy narzut pamięci w swoich typach niż inne, tak naprawdę nie ma to znaczenia dla danych o tej wielkości - nie trzymasz całego zestawu danych w pamięci niezależnie od języka, którego używasz, więc "koszt" Pythona jest tutaj nieistotny. Jak zauważyłeś, po prostu nie ma wystarczającej ilości miejsca adresowego, aby nawet odwoływać się do wszystkich tych danych, nie mówiąc już o trzymaniu ich.

Zwykle oznacza to albo A) przechowywanie danych w bazie danych, albo B) dodawanie zasoby w postaci dodatkowych komputerów, zwiększając tym samym dostępną przestrzeń adresową i pamięć. Realistycznie skończysz robiąc obie te rzeczy. Jedną z kluczowych rzeczy, o których należy pamiętać podczas korzystania z bazy danych, jest to, że baza danych nie jest tylko miejscem do przechowywania danych, gdy jej nie używasz - możesz pracować w bazie danych i powinieneś spróbować to zrobić. Technologia bazodanowa, której używasz, ma duży wpływ na rodzaj pracy, którą możesz wykonać, ale na przykład baza danych SQL jest dobrze nadaje się do wykonywania wielu zestawów matematycznych i robić to skutecznie (oczywiście, oznacza to, że projekt schematu staje się bardzo ważną częścią ogólnej architektury). Nie wysysaj danych i manipuluj nimi tylko w pamięci - spróbuj wykorzystać możliwości zapytań obliczeniowych bazy danych, aby wykonać jak najwięcej pracy, zanim kiedykolwiek umieścisz dane w pamięci w swoim procesie.

1

Author: Nick Bastin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-10 07:13:01

Główne założenia dotyczą ilości cpu/pamięci podręcznej/pamięci ram/pamięci masowej/przepustowości, jaką można mieć w jednej maszynie w akceptowalnej cenie. Istnieje wiele odpowiedzi tutaj w stackoverflow nadal w oparciu o stare założenia 32-bitowej maszyny z 4G ram i o terabajt pamięci masowej i 1GB sieci. Dzięki modułom 16 GB PAMIĘCI ram DDR-3 w cenie 220 Eur, 512 GB PAMIĘCI ram, 48 rdzeni można zbudować w rozsądnych cenach. Przejście z dysków twardych na SSD to kolejna ważna zmiana.

0

Author: Stephan Eggermont,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-01 13:23:08

score 18 · Accepted Answer

Obecnie zajmuję się wysokowydajnymi obliczeniami w małym zakątku przemysłu naftowego i regularnie pracuję z zestawami danych rzędu wielkości, o które się martwisz. Oto kilka punktów do rozważenia:

Bazy danych nie mają zbyt wiele trakcji w tej domenie. Prawie wszystkie nasze dane są przechowywane w plikach, niektóre z tych plików są oparte na formatach plików taśmowych zaprojektowanych w latach 70. myślę, że część przyczyn nieużywania baz danych jest historyczna; 10, a nawet 5 lat myślę, że Oracle i jego krewni po prostu nie byli w stanie zarządzać pojedynczymi zestawami danych O (TB) nie mówiąc już o bazie danych 1000 takich zestawów danych.

Innym powodem jest niedopasowanie pojęciowe między zasadami normalizacji efektywnej analizy i projektowania baz danych a charakterem zbiorów danych naukowych.

Myślę (choć nie jestem pewien), że powody wydajności są dziś znacznie mniej przekonujące. A pojęcie-przyczyna niedopasowania jest chyba też mniej nagląca teraz, że większość spośród głównych dostępnych baz danych mogą poradzić sobie ze zbiorami danych przestrzennych, które są na ogół znacznie bliższe pojęciowemu dopasowaniu do innych zbiorów danych naukowych. Widziałem coraz większe wykorzystanie baz danych do przechowywania metadanych, z pewnym odniesieniem do plików zawierających dane z czujnika.

Jednak nadal patrzyłbym na HDF5. Ma dla mnie kilka atrakcji (a) to po prostu kolejny format plików, więc nie muszę instalować DBMS ' a i zmagać się z jego B) przy odpowiednim sprzęcie mogę równolegle odczytywać/zapisywać plik HDF5. (Tak, Wiem, że mogę również odczytywać i zapisywać bazy danych równolegle).
Co prowadzi mnie do drugiego punktu: kiedy mamy do czynienia z bardzo dużymi zbiorami danych, naprawdę trzeba myśleć o użyciu obliczeń równoległych. Pracuję głównie w Fortranie, jednym z jego atutów jest składnia tablicy, która bardzo dobrze pasuje do wielu komputerów naukowych; innym jest dobre wsparcie dla równoległości dostępny. Uważam, że Python ma również wszelkiego rodzaju wsparcie dla równoległości, więc prawdopodobnie nie jest to zły wybór dla Ciebie.

Oczywiście można dodać równoległość do systemów sekwencyjnych, ale o wiele lepiej zacząć projektowanie dla równoległości. Weźmy tylko jeden przykład: najlepszy algorytm sekwencyjny dla problemu bardzo często nie jest najlepszym kandydatem do równoległości. Może lepiej będzie użyć innego algorytmu, który lepiej skaluje się na wielu procesorach. Co prowadzi do następnego punktu.
Myślę również, że być może będziesz musiał pogodzić się z poddaniem wszelkich załączników, które masz (jeśli je masz) wielu sprytnym algorytmom i strukturom danych, które działają dobrze, gdy wszystkie Twoje dane są rezydentne w pamięci. Bardzo często próba dostosowania ich do sytuacji, w której nie można dostać danych do pamięci na raz, jest o wiele trudniejsza (i mniej wydajna) niż brute-force i traktowanie całego pliku jako jednego dużego / align = "left" /
Wydajność zaczyna mieć poważne znaczenie, zarówno wydajność wykonania programów, jak i wydajność deweloperów. To nie jest tak, że zestaw danych 1TB wymaga 10 razy więcej kodu niż zestaw danych 1GB, więc musisz pracować szybciej, to jest to, że niektóre pomysły, które trzeba będzie wdrożyć będą szalenie złożone i prawdopodobnie muszą być napisane przez specjalistów domeny, czyli naukowców, z którymi pracujesz. Tutaj specjaliści od domen piszą w Matlab.

Ale to trwa zbyt długo, lepiej wrócę do pracy