Problem z Big Data
Ilość dużych ilości danych rośnie wykładniczo. Zjawisko to ma miejsce od lat, ale jego tempo znacznie przyspieszyło od 2012 r. Zapoznaj się z blogiem CSC zatytułowanym Big Data Just Beginning to Explode, aby poznać podobny punkt widzenia na temat pojawiania się dużych zbiorów danych i związanych z nimi wyzwań.
IRI jest świadoma tego trendu od momentu założenia firmy pod koniec lat 70-tych. Jego flagowy pakiet CoSort jest przeznaczony do obsługi rosnących ilości danych dzięki wydajności algorytmów oprogramowania i projektowania, technikom eksploatacji „przenośnego” sprzętu oraz konsolidacji zadań (np. sort-join-aggregate-encrypt-report). Pytanie, jakie stawia ten artykuł, dotyczy podejścia, biorąc pod uwagę „wzrost maszyn”.
Ograniczenia sprzętowe w rozwiązywaniu tego problemu
Z pewnością od dziesięcioleci wydajność komputerów rośnie pod każdym względem. A dla wielu rzucanie sprzętu na problem dużych zbiorów danych jest tylko drugą naturą. Jednak problem może być większy. Rozważmy prawo Moore'a, zgodnie z którym moc procesora tylko podwaja się w najlepszym przypadku co 18 miesięcy oraz nieodłączne starzenie się, problemy z konserwacją i czyste koszty strategii skoncentrowanej na sprzęcie.
Nowością do rozważenia jest również oczekiwanie, że ten paradygmat wydajności dla dużych zbiorów danych może się skończyć. Według Gery Menegaza jego założenie jest takie, że koniec Prawa Moore'a jest bliski. Time Magazine opublikował podobną historię w maju 2012 roku zatytułowaną Upadek prawa Moore'a:Fizyk mówi, że już się dzieje. Zgodnie z artykułem Time,
Biorąc to pod uwagę, Kaku mówi, że kiedy prawo Moore’a w końcu upadnie pod koniec następnej dekady, „po prostu trochę go dostosujemy za pomocą komputerów podobnych do chipów w trzech wymiarach”. Poza tym mówi:„być może będziemy musieli przejść do komputerów molekularnych i być może pod koniec XXI wieku komputerów kwantowych”.
Jednak w przypadku większości użytkowników ich sprzęt jest kupowany w celu obsługi i do pewnego stopnia skalowania, aby sprostać wyzwaniom związanym z przetwarzaniem dużych zbiorów danych, z którymi się borykają lub przewidują. Ale im mniej wydajnie działa oprogramowanie na nim działające, tym więcej zasobów sprzętowych trzeba wydać na pokonanie nieefektywności. Przykładem w naszym świecie może być zakup IBM p595 do uruchamiania /bin/sort, gdy maszyna o jedną trzecią tego rozmiaru i kosztująca z CoSort zamiast tego dałaby ten sam wynik.
Tymczasem urządzenia DB i ELT, takie jak Exadata i Netezza, oparte na sprzęcie, wymagają już inwestycji w wysokości 6-7 cyfr. I chociaż można je skalować, aby przejąć większe obciążenia, zwykle istnieje limit tego, jak bardzo mogą skalować (z pewnością nie wykładniczo), ile pieniędzy można wydać na próbę utrzymania skalowania i jak chętni ludzie mogą polegać na jednego dostawcy dla każdego krytycznego aspektu ich obciążeń. I czy dobrym pomysłem jest narzucenie kosztów transformacji dużych zbiorów danych w bazach danych, które zostały zaprojektowane do optymalizacji przechowywania i wyszukiwania (zapytań)?
Nawet jeśli na wszystkie te pytania można było znaleźć proste odpowiedzi, jak rozwiązywane są problemy obliczeniowe (z nawet tylko liniowym skalowaniem wzrostu danych big data), które wymagają wykładniczo większego zużycia zasobów (takich jak sortowanie)? W jakiś sposób odpowiedź nie wydaje się leżeć w oczekiwaniu na niedrogie obliczenia kwantowe…
Rola oprogramowania
Jak wiedzą architekci Hadoop i hurtowni danych, sortowanie — oraz operacje łączenia, agregowania i ładowania w ETL, które opierają się na sortowaniu — jest sercem wyzwania związanego z przetwarzaniem dużych zbiorów danych i wykładniczym konsumentem zasoby obliczeniowe. Ponieważ duże zbiory danych podwajają się, wymagania dotyczące zasobów do ich sortowania mogą się potroić. Dlatego algorytmy, techniki eksploatacji sprzętu i schematy przetwarzania związane z wieloplatformowym, wielordzeniowym oprogramowaniem do sortowania są kluczami do zarządzania tym problemem w skalowalny, niedrogi i wydajny sposób.
Wkład CoSort
Wydajność CoSort skaluje się liniowo w objętości, bardziej zgodnie z prawem Amdahla. Podczas gdy CoSort może przetworzyć setki gigabajtów dużych zbiorów danych w ciągu kilku minut za pomocą kilkudziesięciu rdzeni, inne narzędzia mogą zająć ponad dwa razy więcej czasu, nie skalują się tak dobrze i/lub zużywają więcej pamięci i I/O w tym procesie. Co być może ważniejsze, CoSort integruje sortowanie bezpośrednio z powiązanymi aplikacjami i wykonuje wszystkie swoje ciężkie prace poza warstwą DB i BI, gdzie dane pomostowe byłyby mniej wydajne.
Architektura współprogramowa CoSort przenosi rekordy między sorterem a programami, takimi jak SortCL (narzędzie do transformacji, filtrowania, wyszukiwania, raportowania, migracji i ochrony danych CoSort) interaktywnie przez pamięć. Gdy tylko następny posortowany rekord będzie dostępny, może przejść do aplikacji, wczytać itp. Aplikacja wygląda na to, że odczytuje plik wejściowy, ale w rzeczywistości tylny koniec źródła nie został jeszcze utworzony. I nie, nie wyprzedzisz sortującego.
Pod koniec 2015 r. CoSort stał się również motorem nowoczesnej platformy IRI do zarządzania i manipulacji dużymi danymi, Vorality. Voracity bezproblemowo wykorzystuje zarówno silniki CoSort, jak i Hadoop.
Podsumowanie
Sam fizycznych zasobów obliczeniowych nie można liczyć na skalowanie problemu przetwarzania dużych zbiorów danych. Środowisko oprogramowania CoSort to takie, w którym wymagana transformacja dużych zbiorów danych i powiązane zadania nie działają jako samodzielne procesy, ale równolegle podczas tego samego przebiegu we/wy.
Tak więc, jeśli potrzebujesz szybkiego sortowania w innym celu niż tylko posortowanie, powinieneś pomyśleć o tym, co dzieje się za sortowaniem i o najlepszych sposobach łączenia takich procesów. A po ustaleniu najlepszego paradygmatu środowiska wykonawczego, czy można połączyć wysokowydajny sprzęt z takim oprogramowaniem, aby zoptymalizować wydajność? Czy można na przykład umieścić dane DW za pomocą CoSort po stronie serwera bazy danych Exadata? A może bardziej sensowne byłoby pozostawienie IBM p595 i dodanie CoSort do trzykrotnej przepustowości? A jeśli zamierzasz używać Hadoop, rozważ użycie tego samego prostego 4GL CoSort lub intuicyjnych mapowań ETL Vorcity, aby kierować zadaniami MapReduce 2, Spark, Storm lub Tez.
Niech budżet i wyobraźnia będą Twoimi przewodnikami w walce ze wzrostem ilości danych.
