Duże dane są najczęściej kojarzone z logami serwerów lub strumieniami danych z portali społecznościach.
Ale duże wolumeny danych są generowane też przez wysokoprzepustowe metody pomiarowe np. w biologii molekularnej.
Miałem ostatnio taki problem.
Kurierem dojechał dysk, na którym było 2 TB spakowanych danych genetycznych, wygenerowany przez metodę RNAseq. W skrócie te dane to duuuużo krótkich (~75 znaków) napisów złożonych z literek TCGA. Pierwszym krokiem analiz jest tzw. mapowanie, czyli określenie gdzie na genomie człowieka (taki długi napis o długości ponad 3 000 000 000 znaków) znajdują się te krótkie napisy (z ewentualnie drobnymi różnicami). Robi się to po to by określić, które geny są aktywne i jak bardzo. Taką informację można następnie przetwarzać bardziej klasycznymi technikami dla danych ilościowych, duże pole do popisu.
Ale aby móc się popisywać trzeba najpierw te dane mapować, a samo mapowanie potrafi być czasochłonne. Dla tych 2 TB danych, wstępne szacunki wykazały, że mapowanie całych danych wejściowych na jednym rdzeniu potrwałoby ponad 9 lat i 4 miesiące!!!
Około 80 tys. godzin obliczeniowych!!!
A ja chciałbym rozpocząć analizy po weekendzie.
I co teraz?
Można, albo szukać lepszego algorytmu mapowania, albo podzielić obliczenia na więcej komputerów.
Obecnie używane algorytmy do mapowania są już bardzo wyrafinowane i stosują rozmaite kruczki by mapowanie było możliwie wydajne. Pozostaje podział obliczeń na więcej komputerów.
I tutaj dochodzimy do PLGridu.
Co to jest?
Projekt w ramach którego naukowcy (ale nie tylko, też np. studenci) mogą wykorzystać nieodpłatnie moc obliczeniową superkomputerów z centrów superkomputerowych w Warszawie (ICM), Krakowie (Cyfronet), Poznaniu (PCSS), Wrocławiu (WCSS) czy TASK.
Można rezerwować maszyny z dużą ilością RAM (do 512 GB) lub wieloma procesorami (do 192 rdzeni).
Wystarczy zarezerwować 120 maszyn po 12 rdzeni każda, by te 80 tys. godzin przeliczyły się w dwa dni. Co więcej można to zrobić pisząc prosty skrypt w R który będzie tworzył i zgłaszał nowe zadania obliczeniowe na kolejne maszyny.
Krótka prezentacja jak obsługiwać system kolejkowy, oraz zgłaszać zadania obliczeniowe napisane w R znajduje się tutaj.
Opis zasobów poszczególnych środków superkomputerowych znajduje się tutaj.
Opis systemów kolejkowych do zgłaszania zadań znajduje się tutaj.
Więcej o projekcie PLGrid znajduje się tutaj.
Może się przydać osobom, potrzebującym sporadycznie dużej maszyny lub wielu maszyn na raz.
Jeżeli mamy dużo danych, to często szybciej wepchniemy jest w infrastrukturę PLGrid niż wkopiujemy np. na AWS czy inną chmurę.
W jaki sposób przekopiowujesz takie dane na PL-GRID?
W tym przypadku dysk był wpinany do komputera w sieci akademickiej,
a tam transfer do maszyn PCSS czy ICM jest bardzo przyzwoity,
przekopiowanie tych danych trwało mniej więcej 2-3 dni.
Masz jakieś porównanie z AWS? Tj. np. jak prosto postawić engine fo obliczeń (np. Sparka) i ile takie maszynki by kosztowały na AWS?
Opis z PLGrid jest bardzo pod projekt unijny, mało pod użytkownika. Próbuję się przeklikać, i jeśli dobrze zrozumiałem – ma się na starcie trochę darmowych godzin, potem – można ubiegać się o grant.
PLGrid udostępnia duże węzły (albo dużo RAM albo dużo procesorów) a te na AWS już trochę kosztują.
O ile pamiętam spark na AWS potrzebuje node’ów przynajmniej XL, na darmowych mnie się nie udało go uruchomić.
Na AWS dostajesz maszyny na których możesz instalować co chcesz, na PLGridzie masz gotowy system Scientific Linux i możesz pod niego instalować różne dodatkowe programy.
2TB danych wepchnie się na PLGrid w kilka dni, na AWS nie wiem czy nie trzeba za taki transfer dodatkowo płacić.
AWS to produkt dosyć dopracowany z komercyjnymi licencjami, jest więc z pewnością większe wsparcie dla klienta.
Na zajęciach z R i Big Data jedno spotkanie poświęciliśmy PLGridowi i później studenci sugerowali by te zajęcia zrobić nawet wcześniej bo im się PLGrid przydaje do różnych projektów.
Co wybrać? zależy co chcesz zrobić i jakie masz środki.
Przemek, próbowałeś do mapowania użyć http://bowtie-bio.sourceforge.net/index.shtml? Powinno być szybkie.
Dzięki, korzystałem z bowtie2 z tej samej stajni (jak się opisują 'ultrafast and memory-efficient tool’ http://bowtie-bio.sourceforge.net/bowtie2/index.shtml).
Ale tych wyszukiwań było wystarczająco wiele by podgrzewać temperaturę tysiącem rdzeni przez dwa dni (proszę tylko nie wiązać tego z falą upałów).