Ładowanie i analizowanie ogromnych ilości danych

Question

Tak więc w przypadku niektórych prac badawczych muszę przeanalizować masę nieprzetworzonych danych dotyczących ruchu (obecnie prawie cały gigant danych i ich wzrost) oraz wypluć informacje ilościowe i wykresy.

Napisałem większość tego przy użyciu Groovy (z JFreeChart do tworzenia wykresów) i kiedy wydajność stała się problemem, przepisałem główne części w Javie.

Problem polega na tym, że analiza i kreślenie trwa około minuty, podczas gdy ładowanie wszystkich danych zajmuje około 5-10 minut. Jak możesz sobie wyobrazić, staje się to naprawdę denerwujące, gdy chcę wprowadzić małe zmiany w działkach i zobaczyć wyniki.

Mam kilka pomysłów na ustalenie to:

1. załadowanie wszystkich danych w bazie danych SQLite.
   Zalety: Będzie szybko. Będę w stanie uruchomić SQL, aby uzyskać zbiorcze dane, jeśli zajdzie taka potrzeba.

   Minusy: Muszę napisać cały ten kod. Ponadto, dla niektórych działek potrzebuję dostępu do każdego punktu danych, więc ładując kilkaset tysięcy plików, niektóre części mogą być nadal wolne.

2. Java RMI do zwrócenia obiektu. Wszystkie dane są ładowane do jednego obiektu głównego, który w przypadku serializacji wynosi około 200 MB. Nie jestem pewien, ile czasu zajmie przeniesienie obiektu o powierzchni 200meg za pośrednictwem RMI. (ten sam klient).

   Musiałbym uruchomić serwer i załadować wszystkie dane, ale to nie jest wielka sprawa.

   major pro: powinna przyjąć najmniejszą ilość czasu, aby napisać

3. uruchomić serwer, który ładuje dane i wykonuje groovy skryptu na komendzie w VM serwera. Ogólnie rzecz biorąc, wydaje się, że najlepszym pomysłem (do czasu realizacji vs wydajności, jak również inne długofalowe korzyści)

Co chciałbym wiedzieć, że inni ludzie rozwiązać ten problem?

Analiza pointericzna (3/29/2011): Kilka miesięcy po napisaniu tego pytania, musiałem nauczyć się R, aby uruchomić pewne statystyki. Korzystanie z R było dużo łatwiejsze i szybsze do analizy danych i agregacji niż to, co robiłem.

Ostatecznie wykorzystałem Javę do uruchomienia wstępnej agregacji, a następnie uruchomiłem wszystko inne w R. R było również o wiele łatwiejsze do tworzenia pięknych wykresów niż przy użyciu JFreeChart.

Answer 1

Bazy danych są bardzo skalowalne, jeśli zamierzasz dysponować ogromnymi ilościami danych. W MS SQL obecnie grupujemy/sumujemy/filtrujemy około 30 GB danych w 4 minuty (chyba około 17 milionów rekordów).

Jeśli dane nie będą bardzo rosły, to spróbuję zastosować # 2. Możesz wykonać prostą aplikację testową, która tworzy obiekt o wielkości 200-400 MB z losowymi danymi i przetestować wydajność transferu przed podjęciem decyzji, czy chcesz iść tą drogą.

Answer 2

Jeśli twoje dane mają właściwości relacyjne, nie ma nic bardziej naturalnego niż przechowywanie ich w bazie danych SQL. Tam możesz rozwiązać swój największy problem - wydajność, kosztując "po prostu", aby napisać odpowiedni kod SQL.

Wydaje mi się to banalne.

Answer 3

Zajmę się analizą za pomocą R. Jest to język statystyczny z możliwościami graficznymi. Mogłaby cię wyprzedzić, zwłaszcza jeśli jest to rodzaj analizy, którą zamierzasz wykonać. Po co pisać cały ten kod?

Answer 4

Ah, tak: duże struktury danych w Javie. Powodzenia z tym, przetrwanie "death by garbage collection" i wszystkich. To, co java najwyraźniej najlepiej robi, to owijanie interfejsu użytkownika wokół jakiegoś innego silnika przetwarzania, chociaż za darmo kosztuje to programistów z większości zadań związanych z zarządzaniem pamięcią. Gdyby to był ja, najprawdopodobniej wykonałbym ciężkie zgniatanie w Perlu (musiałbym przekodować kilka kawałków systemu wsadowego w perlu zamiast java w poprzedniej pracy ze względu na wydajność), a następnie wypluć wyniki z powrotem do istniejącego kodu graficznego .

Jednak biorąc pod uwagę sugerowane przez ciebie opcje, prawdopodobnie powinieneś wybrać trasę SQL DB. Po prostu upewnij się, że naprawdę jest szybszy w przypadku kilku przykładowych zapytań, oglądaj dane z planu kwerend i wszystko (zakładając, że twój system będzie rejestrował lub interaktywnie pokazuje takie szczegóły).

Edycja, (do Jim Ferrans) re: java big -N szybszy niż perl (komentarz poniżej): benchmarki, do których się odwołujesz, są głównie małymi "arytmetycznymi" pętlami, a nie czymś, co robi kilkaset MB IO i zapisuje je w mapie /% hash/Dictionary/associative-array na później ponowna wizyta. Java I/O może się polepszyć, ale podejrzewam, że cała abstrakcyjność sprawia, że ​​jest porównywalnie powolna i wiem, że GC jest zabójcą. Nie sprawdzałem tego ostatnio, nie przetwarzam plików danych o wielu GB codziennie w mojej obecnej pracy, tak jak kiedyś.

Karmienie trolli (12/21): I measured Perl to be faster than Java for doing a bunch of sequential string processing. W rzeczywistości, w zależności od używanej maszyny, Perl był między 3 a 25 razy szybszy niż Java dla tego rodzaju z pracy (partia + ciąg). Oczywiście, specjalny test thrashowy, który zestawiłem, nie zawierał żadnej pracy numerycznej, co do którego podejrzewam, że Java zrobiłaby coś lepszego, ani nie wymagała buforowania dużej ilości danych w mapie/haszy, co podejrzewam, że Perl miałby zrobione trochę lepiej. Zauważ, że Java znacznie lepiej wykorzystała dużą liczbę wątków.

Answer 5

Polecam uruchomienie profilera, aby zobaczyć, która część procesu ładowania zabiera najwięcej czasu i czy istnieje możliwość optymalizacji szybkiego wygrywania. Możesz pobrać licencję próbną na JProfiler lub YourKit.

Answer 6

Przed podjęciem decyzji prawdopodobnie warto zrozumieć, co dzieje się z maszyną JVM, a także z zasobami systemu fizycznego.

Istnieje kilka czynników, które mogą być co grają:

• rozmiar JVM sterty
algorytmy zbierania
• śmieci
• ile pamięci fizycznej masz
• jak załadować danych - czy to z pliku podzielonego na cały dysk?
• ty nawet trzeba załadować wszystkie dane na raz - można to zrobić to dozuje
• jeśli robisz to w partiach można zmieniać wielkość wsadu i zobaczyć co się dzieje
• jeśli system ma wiele rdzenie być może mógłbyś spojrzeć na użycie więcej niż jednego wątku na raz do przetwarzania/ładowania danych
• jeśli używasz wielu rdzeni już i we/wy dysku jest wąskim gardłem, być może mógłbyś spróbować ładować z różnych dysków w tym samym czasie

Powinieneś także spojrzeć na http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp, jeśli nie znasz e ustawienia dla VM.