Najpierw oszacowanie, potem sprzęt
„Potrzebujemy serwera" nie jest jeszcze wymaganiem. Pipeline może być ograniczony czasem procesora, pamięcią RAM, odczytem z dysku, transferem sieciowym albo pojemnością — a wąskie gardło bywa inne, niż się wydaje. Dobór infrastruktury zaczyna się od małego uruchomienia i pomiaru: ile danych wchodzi, jaki jest szczyt RAM, jak długo pracuje każdy krok i które pliki trzeba zachować. Ten artykuł pokazuje cztery zasoby, realne środowiska (stacja / HPC / chmura) i warstwy przechowywania — z konkretnymi technologiami.
Cztery zasoby
CPU wykonuje większość klasycznych zadań: kompresję, mapowanie, zliczanie i statystykę. Więcej rdzeni pomaga tylko wtedy, gdy program umie je wykorzystać (wątki, -t/--threads), a dysk nadąża z dostarczaniem danych.
RAM przechowuje indeksy i obiekty robocze. Złożenie genomu (SPAdes, hifiasm), indeks STAR czy analiza dużej macierzy single-cell w scanpy/Seurat mogą mieć wysokie szczyty pamięci — przekroczenie RAM kończy zadanie albo spycha dane do wolnego swapu. Mierz maksimum, nie średnią.
GPU przyspiesza część uczenia maszynowego, obrazowania i wybranych narzędzi. Realne przykłady z bioinformatyki: AlphaFold i ESMFold (predykcja struktur), NVIDIA Parabricks (przyspieszony GATK/DeepVariant), Dorado (basecalling nanopore), duże modele językowe. Karta musi być zgodna (zwykle NVIDIA + CUDA), a pamięć GPU (np. 40–80 GB w A100/H100) bywa realnym ograniczeniem. GPU nie przyspieszy automatycznie programu napisanego dla CPU.
Wejście/wyjście (I/O) bywa ukrytym wąskim gardłem. Dziesiątki procesów czytających ten sam duży plik z sieciowego systemu plików mogą zwolnić bardziej niż pojedynczy proces. Pomagają lokalny scratch (szybki dysk węzła), indeksowanie, kompresja dopasowana do wzorca dostępu (bgzip+tabix) i ograniczenie zbędnych plików pośrednich.
Wiele zadań genomicznych jest „wstydliwie równoległych" (embarrassingly parallel): każdą próbkę można policzyć niezależnie, więc dodanie węzłów naprawdę skraca czas. Inaczej z krokami, które muszą biec po kolei — tam o łącznym czasie decyduje część nierównoległa (intuicja prawa Amdahla). Dlatego przed „kupnem większej maszyny" sprawdza się, czy zadanie w ogóle potrafi skorzystać z równoległości.
W sekwencjonowaniu nanoporowym komputer bywa także częścią toru przyrządu. Czytnik przenośny korzysta z hosta podłączonego przez USB-C, a systemy wielostanowiskowe i wysokoprzepustowe integrują zasoby dla kilku aktywnych flow cells. Nie warto utrwalać jednej listy CPU/GPU: należy przetestować akwizycję, basecalling, zapis surowego sygnału i transfer dla najcięższej planowanej konfiguracji.
Stacja robocza, klaster czy chmura
- Stacja robocza — dobra do eksploracji i małych projektów, gdy dane mieszczą się lokalnie; pełna kontrola, brak kolejki. Linux + Docker, szybki dysk NVMe, ewentualnie jedna karta GPU.
- Klaster HPC — współdzieli kolejkę, szybkie systemy plików i wiele węzłów. Pracuje się przez scheduler (najczęściej SLURM:
sbatch,srun,squeue,sacct), deklarując zasoby (rdzenie, RAM, czas). Oprogramowanie ładują moduły środowiskowe (Lmod), dane leżą na wydajnych systemach plików (Lustre, GPFS/Spectrum Scale), a kontenery uruchamia Apptainer/Singularity (Docker na współdzielonym HPC zwykle jest niedostępny ze względów bezpieczeństwa). - Chmura — pozwala szybko wynająć różne maszyny i liczyć blisko publicznych danych. Realne usługi: AWS (EC2, S3, Batch), Google Cloud, Azure; tanie instancje spot/preemptible dla zadań odpornych na przerwanie; GPU w chmurze (A100/H100). Uwaga na koszty: transfer wychodzący (egress), pozostawione dyski i niekontrolowane zadania potrafią zaskoczyć rachunkiem — pomaga monitoring kosztów i automatyczne wyłączanie.
Do przenoszenia dużych danych służą Globus (niezawodny transfer między ośrodkami), Aspera (ascp) i rsync. Menedżery workflow (Nextflow, Snakemake) pozwalają uruchomić ten sam pipeline na każdym z tych środowisk, zmieniając tylko profil wykonania — to argument za pisaniem przenośnych potoków (patrz Workflow i kontrola jakości danych).
Ile miejsca naprawdę potrzeba
Policz osobno: (1) surowe dane, których nie wolno utracić; (2) referencje i indeksy współdzielone; (3) wyniki pośrednie możliwe do odtworzenia; (4) rezultaty końcowe i dokumentację; (5) kopie zapasowe i zapas na wzrost. Jeśli 1 TB wejścia tworzy 2 TB pośrednich BAM i dwie kopie, projekt nie potrzebuje „około terabajta". Warto uruchomić 1–5% danych i ekstrapolować osobno dla każdego etapu. CRAM zmniejsza koszt uliniowień, ale zwiększa zależność od dokładnej referencji. Współdzielone genomy i indeksy warto trzymać raz, w jednym miejscu, i wersjonować (pomagają refgenie i iGenomes), zamiast kopiować do każdego projektu.
Warstwy przechowywania: gorące, ciepłe, zimne
Pamięć układa się w warstwy według częstości dostępu: dane gorące (pliki robocze biegnącego zadania) trzyma się na najszybszym, najdroższym scratchu (NVMe/Lustre), czyszczonym okresowo; dane ciepłe aktywnego projektu — na dyskach sieciowych/obiektowych (S3 „standard", NAS); dane zimne (surowe odczyty, których nie wolno utracić, a rzadko ruszamy) — w tanim, wolnym archiwum (AWS S3 Glacier, taśma LTO). Osobną kategorią są pliki do skasowania: odtwarzalne wyniki pośrednie (BAM) można świadomie usuwać, zamiast płacić za ich wieczne przechowywanie.
Kopia zapasowa nie jest archiwum
Kopia zapasowa służy odtworzeniu po awarii lub przypadkowym usunięciu; archiwum zachowuje wybrany, opisany stan projektu na długo. Synchronizacja nie jest kopią, jeśli skasowanie pliku natychmiast replikuje się na drugi system. Praktyczną regułą jest 3-2-1: co najmniej trzy kopie, na dwóch rodzajach nośnika, z czego jedna poza główną lokalizacją — plus okresowe testy odtwarzania i sumy kontrolne. Trzeba ustalić właściciela danych, czas retencji i procedurę usuwania. Zasady FAIR podkreślają identyfikowalność, metadane i możliwość ponownego użycia — samo przechowanie bitów nie wystarcza.1
Dane ludzkie: bezpieczeństwo ważniejsze niż cena rdzenia
Przy danych ludzkich szyfrowanie, kontrola dostępu, rejestrowanie operacji i lokalizacja przechowywania bywają ważniejsze niż cena obliczeń. Coraz częściej analizę takich danych prowadzi się w Trusted Research Environment (TRE) / Secure Data Environment — bezpiecznym środowisku, do którego badacz przychodzi z kodem do danych, zamiast pobierać dane do siebie (analiza „w miejscu"). Wymogi te wynikają z warunków dostępu (dbGaP/EGA, RODO) opisanych w artykule Bazy danych dla biologa. Amerykańska NIH Data Management and Sharing Policy wymaga zaplanowania zarządzania i udostępniania danych już na etapie projektu, z uwzględnieniem ograniczeń etycznych i prawnych.2
Mały profil zasobów
Dla każdego procesu zapisz rozmiar wejścia, czas, rdzenie, szczyt RAM, ilość I/O i kod zakończenia (na SLURM pomaga sacct/seff). Po kilku uruchomieniach ustaw realistyczne żądania w schedulerze. Dwukrotny zapas ma sens na niestabilnym etapie; stałe rezerwowanie dziesięciokrotnie większego RAM wydłuża kolejki i marnuje zasoby. Najlepsza infrastruktura to taka, która daje odtwarzalny wynik w akceptowalnym czasie, koszcie i reżimie bezpieczeństwa. Kolejny artykuł pokazuje, dlaczego podobnie trzeba mierzyć obietnice AI w biologii bez skrótów.