PYTANIA :
Jak duże są duże zbiory danych?
Wiele osób używa terminu big data w raczej komercyjny sposób, aby wskazać, że w obliczeniach zaangażowane są duże zbiory danych, a zatem potencjalne rozwiązania muszą mieć dobrą wydajność. Oczywiście duże zbiory danych zawsze mają powiązane terminy, takie jak skalowalność i wydajność, ale co dokładnie definiuje problem jako problem dużych zbiorów danych? Czy obliczenia muszą być związane z jakimś zestawem konkretnych celów, takich jak eksploracja danych / wyszukiwanie informacji, czy też algorytm ogólnych problemów z grafami można nazwać dużymi danymi, jeśli zestaw danych byłby wystarczająco duży? Poza tym, jak duże jest wystarczająco duże (jeśli można to określić)?
Dla mnie (wywodzę się z relacyjnej bazy danych), „Big Data” nie dotyczy przede wszystkim rozmiaru danych (czyli większości tego, co dotychczas dotyczyło innych odpowiedzi). „Big Data” i „Bad Data” są ze sobą ściśle powiązane. Relacyjne bazy danych wymagają „nieskazitelnych danych”. Jeśli dane znajdują się w bazie danych, są dokładne, czyste i w 100% wiarygodne. Relacyjne bazy danych wymagają „świetnych danych” oraz poświęcenia ogromnej ilości czasu, pieniędzy i odpowiedzialności, aby upewnić się, że dane są dobrze przygotowane przed załadowaniem ich do bazy danych. Jeśli dane znajdują się w bazie danych, są to „ewangelie”, które definiują systemowe rozumienie rzeczywistości. „Big Data” rozwiązuje ten problem z innej strony. Dane są słabo zdefiniowane, wiele z nich może być niedokładnych, a wielu może faktycznie brakować. Struktura i układ danych są liniowe, a nie relacyjne. Big Data musi mieć wystarczającą ilość, aby ilość złych lub brakujących danych stała się statystycznie nieistotna. Kiedy błędy w danych są na tyle powszechne, że wykluczają się wzajemnie, a brakujące dane są proporcjonalnie na tyle małe, że można je pominąć. Kiedy Twoje wymagania i algorytmy dostępu do danych działają nawet przy niekompletnych i niedokładnych danych, masz „Big Data”. W „Big Data” tak naprawdę nie chodzi o ilość, chodzi o charakterystykę danych.
Jak słusznie zauważyłeś, w dzisiejszych czasach „duże zbiory danych” to coś, co każdy chce powiedzieć, że ma, co pociąga za sobą pewną luźność w definiowaniu tego terminu. Ogólnie rzecz biorąc, powiedziałbym, że z pewnością masz do czynienia z dużymi zbiorami danych, jeśli skala jest taka, że nie jest już możliwe aby radzić sobie z bardziej tradycyjnymi technologiami, takimi jak RDBMS, przynajmniej bez uzupełniania ich technologiami Big Data, takimi jak Hadoop. Jak duże muszą być Twoje dane, aby tak się stało, jest dyskusyjne. Oto (nieco prowokacyjny) post na blogu, w którym stwierdzono, że tak naprawdę nie jest w przypadku mniej niż 5 TB danych. (Żeby było jasne, nie stwierdza się, że „mniej niż 5 TB to nie duże zbiory danych”, ale po prostu „mniej niż 5 TB to za mało, abyś potrzebował Hadoop”). Ale nawet w przypadku mniejszych zbiorów danych technologie Big Data podobnie jak Hadoop, może mieć inne zalety, w tym być dobrze przystosowanym do operacji wsadowych, dobrze bawić się danymi nieustrukturyzowanymi (a także danymi, których struktura nie jest znana z góry lub może się zmienić), skalowalność poziomą (skalowanie poprzez dodawanie większej liczby węzłów zamiast wzmacniania Twoje istniejące serwery) i (jako jeden z komentujących w notatkach do postów, do których prowadzi powyższy link) możliwość integracji przetwarzania danych z zewnętrznymi zbiorami danych (pomyśl o map-reduku, w którym mapper wykonuje wywołanie innego serwera). Inne technologie związane z dużymi zbiorami danych, takie jak bazy danych NoSql, kładą nacisk na szybką wydajność i stałą dostępność podczas obsługi dużych zbiorów danych, a także możliwość obsługi danych częściowo nieustrukturyzowanych i skalowania w poziomie. Oczywiście tradycyjne RDBMS mają swoje zalety, w tym gwarancje ACID (atomowość, spójność, izolacja, trwałość) i lepszą wydajność dla niektórych operacji, a także są bardziej znormalizowane, bardziej dojrzałe i (dla wielu użytkowników) bardziej znane. Dlatego nawet w przypadku bezsprzecznie „dużych” danych sensowne może być załadowanie przynajmniej części danych do tradycyjnej bazy danych SQL i wykorzystanie ich w połączeniu z technologiami dużych zbiorów danych. Tak więc, bardziej hojna byłaby definicja, że masz duże zbiory danych, o ile są one na tyle duże, że technologie dużych zbiorów danych zapewniają pewną wartość dodaną. Ale jak widać, może to zależeć nie tylko od rozmiaru danych, ale także od tego, jak chcesz z nimi pracować i jakie masz wymagania w zakresie elastyczności, spójności i wydajności. To, w jaki sposób wykorzystujesz swoje dane, jest bardziej istotne dla pytania niż do czego ich używasz (np. Eksploracja danych). To powiedziawszy, zastosowania takie jak eksploracja danych i uczenie maszynowe z większym prawdopodobieństwem przyniosą użyteczne wyniki, jeśli masz wystarczająco duży zestaw danych do pracy.
Całkowita ilość danych na świecie: 2,8 zetabajtów w 2012 r., Szacowana na 8 zetabajtów do 2015 r., z czasem podwojenia wynoszącym 40 miesięcy. Nie może być większe 🙂 Jako przykład pojedynczej dużej organizacji, Facebook pobiera 500 terabajtów dziennie do magazynu o wielkości 100 petabajtów i wykonuje 70 tys. zapytań dziennie od 2012 r. Ich obecny magazyn to > 300 petabajtów. Big data to prawdopodobnie dobry ułamek liczb na Facebooku (1/100 prawdopodobnie tak, 1/10000 prawdopodobnie nie: to widmo, a nie pojedyncza liczba). Oprócz rozmiaru, niektóre z funkcji, które sprawiają, że jest duży, to:
* jest aktywnie analizowany, a nie tylko przechowywany (cytat „Jeśli nie korzystasz z dużych zbiorów danych, to nie masz dużych zbiorów danych, masz tylko stos danych”
* budowa i prowadzenie hurtowni danych to duży projekt infrastrukturalny
* rośnie w znacznym tempie
* nie ma struktury lub ma nieregularną strukturę
Definicja firmy Gartner: „Duże zbiory danych to duże ilości danych, szybkie i / lub różnorodne zasoby informacyjne, które wymagają nowych form przetwarzania” (3V). Dlatego też uważają, że „ogrom” nie dotyczy wyłącznie rozmiaru zbioru danych, ale także o prędkości i strukturze oraz rodzaju potrzebnych narzędzi.
Czy język R jest odpowiedni dla Big Data
R ma wiele bibliotek, które są przeznaczone do analizy danych (np. JAGS, BUGS, ARULES itp.) I jest wymieniany w popularnych podręcznikach. Widziałem wytyczne dotyczące 5 TB dla zbioru danych, który można uznać za Big Data. Moje pytanie brzmi: czy R jest odpowiedni dla ilości danych typowych dla problemów związanych z Big Data? Czy istnieją strategie, które należy zastosować podczas korzystania z języka R z zestawem danych o takim rozmiarze?
Właściwie to się zbliża. Jest kilka obejść, które należy wykonać, ponieważ R wykonuje całą swoją pracę w pamięci, więc zasadniczo ogranicza się ilość pamięci RAM, którą masz do dyspozycji. Dojrzały projekt dla R i Hadoop to RHadoop RHadoop został podzielony na kilka podprojektów, rhdfs, rhbase, rmr2, plyrmr i quickcheck (wiki).
Głównym problemem związanym z używaniem języka R dla dużych zestawów danych jest ograniczenie pamięci RAM. Powodem przechowywania wszystkich danych w pamięci RAM jest to, że zapewnia znacznie szybszy dostęp i przetwarzanie danych niż przechowywanie na dyskach twardych. Jeśli chcesz poprawić wydajność, to tak, praca z dużymi zbiorami danych w języku R jest dość praktyczna.
Pakiet RODBC: umożliwia połączenie z zewnętrzną bazą danych z R w celu pobierania i obsługi danych. W związku z tym manipulowane dane są ograniczone do pamięci RAM. Ogólny zestaw danych może być znacznie większy. Pakiet ff umożliwia korzystanie z zestawów danych większych niż pamięć RAM, wykorzystując strony mapowane w pamięci.
BigLM: buduje uogólnione modele liniowe w oparciu o duże zbiory danych. Ładuje dane do pamięci w fragmentach.
bigmemory: pakiet R, który umożliwia wydajne i wydajne pod względem pamięci równoległe analizy i eksplorację ogromnych zestawów danych. Umożliwia przechowywanie dużych obiektów (matryc itp.) W pamięci (w pamięci RAM) przy użyciu zewnętrznych obiektów wskaźnikowych w celu odniesienia się do nich.
R doskonale nadaje się do „dużych zbiorów danych”! Potrzebujesz jednak przepływu pracy, ponieważ R jest ograniczony (z pewnym uproszczeniem) przez ilość pamięci RAM w systemie operacyjnym. Podejście, które stosuję, polega na interakcji z relacyjną bazą danych (zobacz pakiet RSQLite do tworzenia i interakcji z bazą danych SQLite), uruchamianiu zapytań w stylu SQL w celu zrozumienia struktury danych, a następnie wyodrębnianiu poszczególnych podzbiorów danych do celów obliczeniowych- intensywna analiza statystyczna. To tylko jedno podejście: istnieją pakiety, które umożliwiają interakcję z innymi bazami danych (np. Monet) lub uruchamianie analiz w języku R z mniejszymi ograniczeniami pamięci (np. Patrz pbdR).
Kiedy wartości p są mylące?
Na jakie warunki dotyczące danych powinniśmy uważać, gdzie wartości p mogą nie być najlepszym sposobem decydowania o istotności statystycznej? Czy istnieją określone typy problemów, które należą do tej kategorii?
Pytasz o pogłębianie danych, co dzieje się podczas testowania bardzo dużej liczby hipotez w zestawie danych lub testowania hipotez w odniesieniu do zestawu danych, które zostały zasugerowane przez te same dane. W szczególności sprawdź hazard z wieloma hipotezami i testowanie hipotez sugerowanych przez dane. Rozwiązaniem jest użycie pewnego rodzaju korekty współczynnika fałszywych odkryć lub współczynnika błędów Familywise, na przykład metody Scheffégo lub (bardzo starej) poprawki Bonferroniego. W nieco mniej rygorystyczny sposób może pomóc filtrowanie odkryć według przedziału ufności dla ilorazu szans (OR) dla każdego wyniku statystycznego. Jeśli 99-procentowy przedział ufności dla ilorazu szans wynosi 10-12, to OR jest <= 1 z bardzo małym prawdopodobieństwem, zwłaszcza jeśli wielkość próby jest również duża. Jeśli znajdziesz coś takiego, prawdopodobnie jest to silny efekt, nawet jeśli wyszedł z testu milionów hipotez.
Nie powinieneś rozważać wartości p poza kontekstem. Jedną raczej podstawową kwestią (jak ilustruje xkcd) jest to, że musisz rozważyć, ile testów, które faktycznie przeprowadzasz. Oczywiście nie należy być zszokowanym, widząc p <0,05 dla jednego na 20 testów, nawet jeśli hipoteza zerowa za każdym razem jest prawdziwa. Bardziej subtelny przykład tego występuje w fizyce wysokich energii i jest znany jako efekt patrzenia gdzie indziej. Im większą przestrzeń parametrów szukasz sygnału, który może reprezentować nową cząstkę, tym większe jest prawdopodobieństwo, że zobaczysz pozorny sygnał, który w rzeczywistości jest wynikiem przypadkowych fluktuacji.
Jedną rzeczą, o której powinieneś wiedzieć, jest wielkość próbki, której używasz. Bardzo duże próbki, takie jak ekonomiści korzystający z danych ze spisu powszechnego, doprowadzą do deflowanych wartości p.
Który stos technologii Big Data najlepiej nadaje się do przetwarzania tweetów, wyodrębnianie / rozwijanie adresów URL i wysyłanie (tylko) nowych linków do systemu innej firmy?
Uważam, że rozumiem ogólny cel pytania, w wyniku czego prawdopodobnie będę w stanie odpowiedzieć na wszelkie pytania, które mogą pop-up.) Który stos technologii Big Data najlepiej nadaje się do przetwarzania tweetów, wyodrębniania / rozszerzania adresów URL i wysyłania (tylko) nowych linków do systemu innej firmy? Proponuję Apache Kafka jako magazyn wiadomości i dowolne wybrane rozwiązanie do przetwarzania strumieni, takie jak Apache Camel lub Twitter Storm
W jaki sposób zapytanie do ogromnej bazy danych powraca z pomijalnym wynikiem czasu oczekiwania?
Na przykład podczas wyszukiwania czegoś w Google wyniki zwracają się niemal natychmiast. Rozumiem, że Google sortuje i indeksuje strony za pomocą algorytmów itp., Ale wyobrażam sobie, że nie jest możliwe indeksowanie wyników każdego możliwego zapytania (a wyniki są spersonalizowane, co czyni to jeszcze bardziej niewykonalnym)? Co więcej, czy opóźnienie sprzętowe w sprzęcie Google nie byłoby ogromne? Nawet jeśli dane w Google wszystkie były przechowywane na dyskach SSD TB / s, wyobrażam sobie, że opóźnienie sprzętowe jest ogromne, biorąc pod uwagę samą ilość danych do przetworzenia.
Czy MapReduce pomaga rozwiązać ten problem?
EDYCJA: OK, więc rozumiem, że popularne wyszukiwania można przechowywać w pamięci. Ale co z niepopularnymi wyszukiwaniami? Nawet w przypadku najbardziej niejasnego wyszukiwania, jakie przeprowadziłem, nie sądzę, aby było ono kiedykolwiek zgłaszane jako dłuższe niż 5 sekund. Jak to jest możliwe?
MapReduce nie ma nic wspólnego z działaniem w czasie rzeczywistym. Jest to platforma przetwarzania zorientowana na partię, odpowiednia dla niektórych zadań offline, takich jak ETL i tworzenie indeksów. Google wycofał się z MapReduce w większości zadań, a nawet ekosystem Hadoop robi to podobnie. Odpowiedzią na małe opóźnienie jest zazwyczaj przechowywanie w pamięci wstępnie obliczonych wskaźników. Wszystko, co dotyka dysku, jest trudne do wykonania szybko i na dużą skalę. W ten sposób silniki SQL nowej generacji oparte na Hadoop, takie jak Impala, uzyskują tak dużą prędkość w porównaniu do opartych na MapReduce na przykład infrastruktura, taka jak Hive. Infrastruktura wyszukiwania nie może buforować wyników każdego zapytania. Ale z pewnością może buforować wyniki pośrednie lub bardziej kompletne wyniki dla najpopularniejszych zapytań. Przy odrobinie buforowania możesz podawać wyniki dla znacznej mniejszości wszystkich zapytań. Wyszukiwanie jest również podzielone na serwery. Tak więc jedna maszyna może delegować do 100, aby uzyskać część wyniku, a następnie połączyć je. Możesz także uciec z pewnym stopniem przybliżenia. Google nie tworzy dosłownie tysiąca stron wyników wyszukiwania; wystarczy, że pierwsza strona będzie prawidłowa. Pamiętaj, że Google ma miliony komputerów na całym świecie. Twoje zapytania trafiają do centrum danych, które znajduje się w pobliżu Ciebie i obsługuje tylko Twoją lokalizację. Eliminuje to większość opóźnień, które są związane z siecią, a nie czasem przetwarzania w centrum danych.
MapReduce nie jest używane do wyszukiwania. Został użyty dawno temu do budowy indeksu; ale jest to platforma przetwarzania wsadowego, a większość sieci nie zmienia się cały czas, więc nowsze architektury mają charakter przyrostowy, a nie wsadowy. Wyszukiwanie w Google będzie w dużej mierze działać tak samo, jak w Lucene i Elastic Search, z wyjątkiem wielu precyzyjnie dostrojonych dodatkowych obciążeń i optymalizacji. Ale w głębi serca użyją jakiejś formy odwróconego indeksu. Innymi słowy, nie przeszukują kilku terabajtów po wpisaniu zapytania wyszukiwania (nawet jeśli nie jest ono zapisane w pamięci podręcznej). Prawdopodobnie w ogóle nie patrzą na rzeczywiste dokumenty. Ale używają tabeli odnośników, która zawiera listę dokumentów pasujących do zapytania (z preprocesorami, błędami pisowni, synonimami itp.). Prawdopodobnie pobierają listę 10000 najpopularniejszych dokumentów dla każdego słowa (10 tys. Liczb całkowitych – tylko kilka kb!) I obliczają na jej podstawie najlepsze dopasowania. Tylko jeśli na tych listach nie ma dobrych dopasowań, rozwijają się one do następnych takich bloków itp. Zapytania dotyczące typowych słów można łatwo przechowywać w pamięci podręcznej; dzięki wstępnemu przetwarzaniu możesz zbudować listę 10k najlepszych wyników, a następnie uporządkować je zgodnie z profilem użytkownika. Nie ma też nic do zyskania obliczając „dokładną” odpowiedź. Spojrzenie na pierwszych 10 000 wyników jest prawdopodobnie wystarczające; nie ma poprawnej odpowiedzi; a jeśli lepszy wynik gdzieś na pozycji 10001 zostanie pominięty, nikt nie będzie wiedział ani nie zauważył (ani nie przejmował się). Prawdopodobnie został już w rankingu niżej w przetwarzaniu wstępnym i nie znalazłby się w pierwszej 10, która jest prezentowana użytkownikowi na końcu (lub w pierwszej trójce, na którą faktycznie patrzy użytkownik). Z drugiej strony rzadkie terminy nie są zbyt popularne wyzwanie – jedna z list zawiera tylko kilka pasujących dokumentów, a wszystkie pozostałe możesz od razu odrzucić.
Gdy relacyjna baza danych ma lepszą wydajność niż nie relacyjne
Kiedy relacyjna baza danych, taka jak mySQL, ma lepszą wydajność niż nierelacyjna, taka jak mongo? Widziałem kiedyś pytanie na Quorze, dlaczego Quora nadal używa mySQL jako swojego zaplecza. I jak ich wydajność jest nadal dobra.
To zależy od Twoich danych i tego, co z nimi robisz. Na przykład, jeśli przetwarzanie, które musisz wykonać, wymaga synchronizacji transakcji między węzłami, prawdopodobnie szybsze będzie użycie transakcji zaimplementowanych w RDBMS niż samodzielne implementowanie ich na bazach danych NoSQL, które nie obsługują go natywnie.
Dlaczego trudno jest zapewnić wydajność podczas korzystania z bibliotek?
Każde przetwarzanie małej bazy danych może być łatwo rozwiązane przez skrypty Python / Perl /…, które używają bibliotek i / lub nawet narzędzi z samego języka. Jednak jeśli chodzi o wydajność, ludzie zwykle sięgają po języki C / C ++ / niskiego poziomu. Możliwość dostosowania kodu do potrzeb wydaje się być tym, co czyni te języki tak atrakcyjnymi dla BigData – czy to w odniesieniu do zarządzania pamięcią, równoległości, dostępu do dysku, czy nawet optymalizacji niskiego poziomu (poprzez konstrukcje asemblacyjne na poziomie C / C ++). Oczywiście taki zestaw korzyści nie obywałby się bez kosztów: pisanie kodu, a czasem nawet wymyślanie na nowo koła, może być dość drogie / męczące. Chociaż dostępnych jest wiele bibliotek, ludzie mają skłonność do samodzielnego pisania kodu, gdy tylko potrzebują wydajności. Co uniemożliwia asercjom wydajności korzystanie z bibliotek podczas przetwarzania dużych baz danych? Na przykład rozważmy przedsiębiorstwo, które nieustannie przeszukuje strony internetowe i analizuje zebrane dane. Dla każdego przesuwanego okna na wyodrębnionych danych są uruchamiane różne algorytmy eksploracji danych. Dlaczego programiści mieliby zrezygnować z korzystania z dostępnych bibliotek / frameworków (czy to do indeksowania, przetwarzania tekstu i eksploracji danych)? Korzystanie z już zaimplementowanych rzeczy nie tylko zmniejszyłoby ciężar kodowania całego procesu, ale także zaoszczędziłoby dużo czasu.
W jednym ujęciu:
* co sprawia, że samodzielne napisanie kodu jest gwarancją wykonania?
* dlaczego poleganie na frameworkach / bibliotekach jest ryzykowne, skoro musisz zapewnić wysoką wydajność?
Nie sądzę, żeby wszyscy sięgali po C/C++, gdy problemem była wydajność. Zaletą pisania kodu niskiego poziomu jest użycie mniejszej liczby cykli procesora lub czasami mniej pamięci. Ale chciałbym zauważyć, że języki wyższego poziomu mogą odwoływać się do języków niższego poziomu i robią to, aby uzyskać część tej wartości. Języki Python i JVM mogą to zrobić. Naukowiec zajmujący się danymi, korzystający na przykład ze scikit-learn na swoim komputerze, już wywołuje mocno zoptymalizowane natywne procedury, aby wykonać obliczenia. Nie ma sensu pisać nowego kodu szybkości. W kontekście rozproszonych „dużych zbiorów danych” częściej stanowisz wąskie gardło w przenoszeniu danych:
transfer sieciowy i I / O. Kod natywny nie pomaga. Pomaga nie pisanie tego samego kodu, aby działał szybciej, ale pisanie mądrzejszego kodu. Języki wyższego poziomu pozwolą Ci zaimplementować bardziej wyrafinowane rozproszone algorytmy w danym czasie programisty niż C / C ++. Na dużą skalę inteligentniejszy algorytm zapewniający lepszy przepływ danych pokona głupi kod natywny. Zwykle jest też prawdą, że czas programisty i błędy kosztują dużo więcej niż nowy sprzęt. Rok starszego programisty może być w pełni obciążony 200 000 USD; ponad rok, który również wynajmuje setki serwerów na czas obliczeniowy. W większości przypadków po prostu nie ma sensu zawracać sobie głowy optymalizacją, zamiast rzucać więcej sprzętu. Nie rozumiem dalszych informacji na temat „przyznania”, „wyłączenia” i „potwierdzenia”?
Jak wszyscy wiemy, w świecie cyfrowym jest wiele sposobów na wykonanie tej samej pracy / uzyskanie oczekiwanych rezultatów. A odpowiedzialność / ryzyko wynikające z kodu spoczywa na barkach programistów. Jest to małe, ale myślę, że bardzo przydatny przykład z Świat .NET .. Tak wielu programistów .NET używa wbudowanego BinaryReader – BinaryWriter do serializacji danych w celu uzyskania wydajności / uzyskania kontroli nad procesem. To jest kod źródłowy CSharp wbudowanej w FrameWork klasy BinaryWriter.
przeciążone metody zapisu:
// Zapisuje wartość logiczną do tego strumienia. W strumieniu zapisywany jest pojedynczy bajt
// z wartością 0 reprezentującą fałsz lub wartością 1 reprezentującą prawdę.
//
public virtual void Write (wartość bool)
{
// Bufor _ to tablica bajtów zadeklarowana w kodach ctor / init klasy
_buffer = ((bajt) (wartość? 1: 0));
// OutStream to instancja strumienia, do której BinaryWriter zapisuje wartości.
OutStream.WriteByte (_buffer [0]);
}
Jak widać, ta metoda mogłaby zostać napisana bez dodatkowego przypisywania do zmiennej _buffer:
public virtual void Write (wartość bool)
{
OutStream.WriteByte ((bajt) (wartość? 1: 0));
}
Bez przypisywania moglibyśmy zyskać kilka milisekund… Te kilka milisekund można zaakceptować jako „prawie nic”, ale co, jeśli jest wiele tysięcy zapisów (tj. W procesie serwera)? Załóżmy, że „kilka” to 2 (milisekundy), a wiele tysięcy wystąpień to tylko 2 000 .. Oznacza to 4 sekundy więcej czasu przetwarzania..4 sekundy później powrót .. Jeśli nadal będziemy tematować z .NET i czy możesz sprawdzić kody źródłowe BCL – .NET Base Class Library – z MSDN widać wiele strat wydajności ze strony dewelopera.
Dowolny punkt ze źródła BCL To normalne, że programista zdecydował się na użycie pętli while() lub foreach(), które mogłyby zaimplementować szybszą pętlę for() w swoim kodzie. Te małe zyski dają nam całkowitą wydajność .. A jeśli wrócimy do metody BinaryWriter.Write() .. W rzeczywistości dodatkowe przypisanie do implementacji _buffer nie jest błędem nadrzędnym… To jest właśnie decyzja o „pozostaniu w bezpiecznym miejscu”! Załóżmy, że zdecydowaliśmy się nie używać _buffer i zdecydowaliśmy się zaimplementować drugą metodę. Jeśli spróbujemy wysłać wiele tysięcy bajtów przez przewód (tj. Załadować / pobrać dane BLOB lub CLOB) drugą metodą, może się to nie udać, ponieważ utraty połączenia, ponieważ staramy się przesyłać wszystkie dane bez żadnych sprawdzeń i mechanizmów kontrolnych. W przypadku utraty połączenia, zarówno serwer, jak i Klient nigdy nie wiedzą, czy wysłane dane są kompletne, czy nie. Jeśli deweloper zdecyduje się „pozostać bezpiecznym”, zwykle oznacza to, że koszty wydajności zależą od zaimplementowanego mechanizmu (ów) „pozostań bezpieczny”. Ale jeśli programista zdecyduje się „podejść ryzykownie, zwiększyć wydajność”, to również nie jest wada… Do czasu, gdy pojawiają się dyskusje na temat „ryzykownego” kodowania. Mała uwaga: deweloperzy bibliotek komercyjnych zawsze starają się zachować bezpieczeństwo, ponieważ nie wiedzą, gdzie ich kod będzie używany.
Z punktu widzenia programistów frameworki rzadko traktują wydajność jako najwyższy priorytet. Jeśli Twoja biblioteka będzie szeroko wykorzystywana, ludzie będą prawdopodobnie najbardziej cenić łatwość użytkowania, elastyczność i niezawodność. Wydajność jest generalnie ceniona w drugorzędnych konkurencyjnych bibliotekach. „Biblioteka X jest lepsza, ponieważ jest szybsza”. Nawet wtedy bardzo często te biblioteki będą wymieniać najbardziej optymalne rozwiązanie na takie, które można szeroko wykorzystać. Korzystając z dowolnego frameworka, nieodłącznie ryzykujesz, że istnieje szybsze rozwiązanie. Mógłbym nawet powiedzieć, że prawie zawsze istnieje szybsze rozwiązanie. Samo napisanie czegoś nie jest gwarancją wydajności, ale jeśli wiesz, co robisz i masz dość ograniczony zestaw wymagań, może to pomóc. Przykładem może być analiza JSON. Istnieją setki bibliotek dla różnych języków, które zmienią JSON w obiekt, do którego można się odwoływać i na odwrót. Znam jedną implementację, która robi to wszystko w rejestrach procesora. Jest wymiernie szybszy niż wszystkie inne parsery, ale jest też bardzo ograniczony, a to ograniczenie będzie się różnić w zależności od tego, z jakim procesorem pracujesz. Czy zadanie tworzenia wysokowydajnego parsera JSON specyficznego dla środowiska to dobry pomysł? Wykorzystałbym szanowaną bibliotekę 99 razy na 100. W tym jednym oddzielnym przypadku kilka dodatkowych cykli procesora pomnożonych przez milion iteracji sprawiłoby, że czas rozwoju byłby tego wart.
Kompromisy między Storm a Hadoop (MapReduce)
Czy ktoś uprzejmie może mi powiedzieć o kompromisach związanych z wyborem między Storm a MapReduce w Hadoop Cluster do przetwarzania danych? Oczywiście, pomijając oczywiste, że Hadoop (przetwarzanie przez MapReduce w klastrze Hadoop) jest systemem przetwarzania wsadowego, a Storm jest systemem przetwarzania w czasie rzeczywistym.
Pracowałem trochę z Hadoop Eco System, ale nie pracowałem z Storm. Po przejrzeniu wielu prezentacji i artykułów nadal nie udało mi się znaleźć satysfakcjonującej i wyczerpującej odpowiedzi. Uwaga: tutaj termin „kompromis” nie ma na celu porównania z podobnymi rzeczami. Ma przedstawiać konsekwencje uzyskiwania wyników w czasie rzeczywistym, których nie ma w systemie przetwarzania wsadowego.
MapReduce: odporna na błędy rozproszona struktura obliczeniowa. MapReduce pozwala na operowanie na ogromnych ilościach danych – z dużym nakładem pracy, aby zapobiec awariom spowodowanym sprzętem. MapReduce to kiepski wybór do obliczania wyników w locie, ponieważ jest wolny. (Typowe zadanie MapReduce zajmuje kilka minut lub godzin, a nie mikrosekund). Zadanie MapReduce pobiera plik (lub jakiś magazyn danych) jako dane wejściowe i zapisuje plik wyników. Jeśli chcesz, aby te wyniki były dostępne dla aplikacji, Twoim obowiązkiem jest umieszczenie tych danych w dostępnym miejscu. Jest to prawdopodobnie powolne i będzie występować opóźnienie między wartościami, które można wyświetlić, a wartościami reprezentującymi system w jego bieżącym stanie. Ważnym rozróżnieniem, które należy rozróżnić, rozważając użycie MapReduce w budowaniu systemów czasu rzeczywistego, jest szkolenie modelu i zastosowanie modelu. Jeśli uważasz, że parametry modelu nie zmieniają się szybko, możesz dopasować je za pomocą MapReduce, a następnie mieć mechanizm dostępu do tych wstępnie dopasowanych parametrów, gdy chcesz zastosować model. Storm: system obliczeniowy do przesyłania strumieniowego w czasie rzeczywistym. Storm to framework online, w tym sensie usługa, która współdziała z uruchomioną aplikacją. W przeciwieństwie do MapReduce, otrzymuje małe fragmenty danych (nie cały plik), gdy są one przetwarzane w aplikacji. Definiujesz DAG operacji do wykonania na danych. Typowym i prostym przypadkiem użycia Storm jest śledzenie liczników i wykorzystywanie tych informacji do wypełniania pulpitu nawigacyjnego w czasie rzeczywistym. Storm nie ma (koniecznie) nic wspólnego z utrwalaniem danych. W tym przypadku przesyłanie strumieniowe to kolejny sposób na zatrzymanie informacji, na których Ci zależy, i wyrzucenie reszty.
W rzeczywistości prawdopodobnie masz w aplikacji warstwę trwałości, która już zarejestrowała dane, a więc jest to dobre i uzasadnione rozdzielenie obaw. Jeśli chcesz wiedzieć więcej… Jeśli chcesz dowiedzieć się więcej o systemach czasu rzeczywistego, które pasują do parametrów z MR i stosują modele w inny sposób, oto slajdy do wykładu, który wygłosiłem na temat tworzenia silników rekomendacji w czasie rzeczywistym na HBase. Doskonałym dokumentem, który w interesujący sposób łączy liczenie w czasie rzeczywistym i wytrwałość, jest Personalizacja Google News: skalowalne, oparte na współpracy filtrowanie online Kolejnym interesującym połączeniem MR i Storm jest SummingBird. Summingbird umożliwia zdefiniowanie operacji analizy danych, które można zastosować za pośrednictwem Storm lub MR.
To trochę tak, jakby pytać o kompromisy między patelnią a szufladą ze sztućcami. Tak naprawdę to nie są dwie rzeczy, które można porównać. Możesz ich używać razem w ramach większego projektu. Sam Hadoop to nie jedno, ale nazwa federacji usług, takich jak HDFS, Hive, HBase, MapReduce itp. Storm to coś, czego używasz w przypadku niektórych z tych usług, takich jak HDFS lub HBase. Jest to struktura przetwarzania strumieniowego. W rozszerzonym ekosystemie Hadoop są inne, takie jak Spark Streaming. Kiedy wybrałbyś platformę przetwarzania strumieniowego? kiedy musisz reagować na nowe dane w czasie zbliżonym do rzeczywistego. Jeśli potrzebujesz tego rodzaju narzędzia, wdrażasz również takie narzędzie.
Kaskadowy błąd w Apache Storm
Przeglądając prezentację i materiały Summingbird na Twitterze, jednym z powodów, o których wspomina się przy jednoczesnym używaniu klastrów Storm i Hadoop w Summingbird, jest to, że przetwarzanie za pośrednictwem Storm powoduje kaskadowanie błędów. Aby uniknąć kaskadowania błędów i ich akumulacji, klaster Hadoop jest używany do przetwarzania wsadowego danych i odrzucania wyników Storm po przetworzeniu tych samych danych przez Hadoop. Jakie są przyczyny generowania tej kumulacji błędów? i dlaczego nie ma go w Hadoop? Ponieważ nie pracowałem ze Stormem, nie znam powodów. Czy to dlatego, że Storm używa przybliżonego algorytmu do przetwarzania danych w celu przetwarzania ich w czasie rzeczywistym? czy może przyczyna jest inna?
Twitter używa Storm do przetwarzania danych w czasie rzeczywistym. Mogą wystąpić problemy z danymi w czasie rzeczywistym. Systemy mogą ulec awarii. Dane mogą zostać nieumyślnie przetworzone dwukrotnie. Połączenia sieciowe mogą zostać utracone. W systemie czasu rzeczywistego może się wiele wydarzyć. Używają hadoopa do niezawodnego przetwarzania danych historycznych. Nie znam szczegółów, ale na przykład uzyskanie solidnych informacji z zagregowanych dzienników jest prawdopodobnie bardziej niezawodne niż dołączenie do strumienia. Gdyby po prostu polegali na Storm we wszystkim – Storm miałby problemy ze względu na charakter dostarczania informacji w czasie rzeczywistym na dużą skalę. Jeśli we wszystkim polegali na hadoopie, wiąże się to z dużym opóźnieniem. Połączenie tych dwóch z Summingbird to kolejny logiczny krok.
Czy muszę się uczyć Hadoop, aby zostać naukowcem danych?
Aspirujący naukowiec danych. Nie wiem nic o Hadoopie, ale czytając o Data Science i Big Data, wiele mówi się o Hadoop. Czy jest absolutnie konieczne, aby nauczyć się Hadoop, aby zostać naukowcem danych?
Różni ludzie używają różnych narzędzi do różnych celów. Terminy takie jak nauka o danych są ogólne z jakiegoś powodu. Analityk danych może spędzić całą karierę bez konieczności uczenia się konkretnego narzędzia, takiego jak hadoop. Hadoop jest szeroko stosowany, ale nie jest jedyną platformą, która jest w stanie zarządzać danymi, nawet tymi na dużą skalę, i nimi manipulować. Powiedziałbym, że naukowiec zajmujący się danymi powinien znać pojęcia takie jak MapReduce, systemy rozproszone, rozproszone systemy plików i tym podobne, ale nie oceniałbym kogoś za brak wiedzy o takich rzeczach.
To duże pole. Jest morze wiedzy i większość ludzi jest w stanie nauczyć się i być ekspertem w jednej kropli. Kluczem do bycia naukowcem jest chęć uczenia się i motywacja do poznania tego, czego jeszcze nie wiesz. Na przykład: mógłbym przekazać właściwej osobie sto ustrukturyzowanych plików CSV zawierających informacje o wynikach w jednej klasie w ciągu dziesięciu lat. Naukowiec zajmujący się danymi mógłby spędzić rok na zbieraniu informacji z danych bez konieczności rozłożenia obliczeń na wiele maszyn. Można zastosować algorytmy uczenia maszynowego, analizować je za pomocą wizualizacji, łączyć z zewnętrznymi danymi o regionie, składzie etnicznym, zmianach środowiska w czasie, informacjami politycznymi, wzorcami pogodowymi itp. Wszystko to byłoby według mnie „nauką o danych”. . Potrzeba czegoś w rodzaju hadoopa, aby przetestować i zastosować wszystko, czego się nauczyłeś, do danych obejmujących cały kraj uczniów, a nie tylko salę lekcyjną, ale ten ostatni krok niekoniecznie czyni kogoś badaczem danych. A niepodjęcie tego ostatniego kroku niekoniecznie dyskwalifikuje kogoś z bycia naukowcem danych.
Jako były inżynier Hadoop nie jest to potrzebne, ale pomaga. Hadoop to tylko jeden system – najpopularniejszy system oparty na Javie i ekosystem produktów, które stosują określoną technikę „Mapuj / Zmniejsz”, aby uzyskać wyniki w odpowiednim czasie. Hadoop nie jest używane w Google, chociaż zapewniam, że używają analityki dużych zbiorów danych. Google korzysta z własnych systemów, opracowanych w C ++. W rzeczywistości Hadoop powstał w wyniku opublikowania przez Google ich białych ksiąg Map / Reduce i BigTable (HBase in Hadoop). Naukowcy zajmujący się danymi będą współpracować z inżynierami hadoopów, chociaż w mniejszych miejscach może być wymagane noszenie obu czapek. Jeśli jesteś ściśle analitykiem danych, to wszystko, czego używasz do analizy, R, Excel, Tableau itp., Będzie działać tylko na niewielkim podzbiorze, a następnie będzie musiało zostać przekonwertowane, aby działało z pełnym zestawem danych obejmującym hadoop.
Najpierw musisz wyjaśnić, co masz na myśli, mówiąc „naucz się Hadoop”. Jeśli masz na myśli używanie Hadoop, na przykład naukę programowania w MapReduce, to najprawdopodobniej jest to dobry pomysł. Jednak wiedza podstawowa (baza danych, uczenie maszynowe, statystyka) może odgrywać większą rolę w miarę upływu czasu.
Filtrowanie spamu z pobranych danych
Słyszałem kiedyś, że filtrowanie spamu za pomocą czarnych list nie jest dobrym podejściem, ponieważ niektórzy użytkownicy szukający wpisów w Twoim zbiorze danych mogą szukać określonych informacji z zablokowanych źródeł. Ponadto ciągłe sprawdzanie aktualnego stanu każdego zablokowanego spamera, sprawdzanie, czy witryna / domena nadal rozpowszechnia dane o spamie, stałoby się ciężarem. Biorąc pod uwagę, że każde podejście musi być wydajne i skalowalne, aby obsługiwać filtrowanie na bardzo dużych zbiorach danych, jakie są dostępne strategie pozbycia się spamu w sposób nieobiektywny?
Edycja: jeśli to możliwe, każdy przykład strategii, nawet jeśli tylko intuicja za nim stoi, byłby bardzo mile widziany wraz z odpowiedzią.
Sieci neuronowe zrewolucjonizowały filtrowanie spamu, zwłaszcza w wiadomościach e-mail.
EDYCJA: Podstawową intuicją stojącą za używaniem sieci neuronowej do pomocy w filtrowaniu spamu jest przypisywanie wagi terminom na podstawie tego, jak często są one powiązane ze spamem. Najszybciej sieci neuronowe można trenować w nadzorowanym – jawnie podajesz klasyfikację zdania w zbiorze uczącym – środowisko. Bez wchodzenia do nitty gritty podstawową ideę można zilustrować tymi zdaniami:
Tekst = „Jak utrata patentu Viagry wpłynie na firmę Pfizer”, Spam = false Text = „Tania Viagra Kup teraz”, Spam = true Text = „Apteka internetowa Viagra Cialis Lipitor”, Spam = true
W przypadku dwuetapowej sieci neuronowej pierwszy etap obliczy prawdopodobieństwo spamu na podstawie tego, czy słowo istnieje w zdaniu. A więc z naszego przykładu: viagra => 66% kup => 100% Pfizer => 0% itd. Następnie w drugim etapie wyniki z pierwszego etapu są używane jako zmienne w drugim etapie: viagra & buy => 100% Pfizer & viagra => 0%. Ta podstawowa idea jest stosowana dla wielu permutacji wszystkich słów w danych treningowych. Po wytrenowaniu wyników końcowych chodzi w zasadzie tylko o równanie, które na podstawie kontekstu słów w zdaniu może określić prawdopodobieństwo spamu. Ustaw próg spamowania i odfiltruj wszelkie dane powyżej wspomnianego progu.
Czy FPGrowth nadal często jest uważane za „najnowocześniejsze” górnictwo?
Z tego, co wiem o rozwoju algorytmów do rozwiązania problemu FPM (Frequent Pattern Mining), droga ulepszeń ma kilka głównych punktów kontrolnych. Po pierwsze, algorytm Apriori został zaproponowany w 1993 roku przez Agrawala i wspólnikóe. , wraz z formalizacją problemu. Algorytm był w stanie usunąć niektóre zestawy z zestawów 2 ^ n – 1 (poweret) przy użyciu kraty do utrzymania danych. Wadą tego podejścia była konieczność ponownego odczytu bazy danych w celu obliczenia częstotliwości każdego rozszerzanego zestawu. Później, w 1997 roku, Zaki i wspólnicy. Zaproponował algorytm Eclat, który wstawiał wynikową częstotliwość każdego zestawu do wnętrza sieci. Dokonano tego poprzez dodanie, w każdym węźle sieci, zestawu identyfikatorów transakcji, które zawierały elementy od korzenia do węzła, do którego się odnosi. Główny wkład polega na tym, że nie trzeba ponownie czytać całego zbioru danych, aby poznać częstotliwość każdego zestawu, ale pamięć wymagana do utrzymania takiej struktury danych może przekroczyć rozmiar samego zbioru danych. W 2000 roku Han i wsp. zaproponowali algorytm o nazwie FPGrowth wraz z przedrostkową strukturą danych w postaci drzewa o nazwie FPTree. Algorytm był w stanie zapewnić znaczną kompresję danych, jednocześnie zapewniając, że zostaną uzyskane tylko częste zestawy elementów (bez generowania zestawu elementów kandydatów). Odbyło się to głównie poprzez sortowanie pozycji każdej transakcji w kolejności malejącej, tak aby pozycje najczęściej występowały w przypadku najmniej powtórzeń w strukturze danych drzewa. Ponieważ częstotliwość spada tylko podczas dogłębnego przemierzania drzewa, algorytm jest w stanie usunąć rzadkie zestawy elementów. Czy algorytm FPGrowth jest nadal uważany za „najnowocześniejszy” w częstym eksploracji wzorców? Jeśli nie, jakie algorytmy mogą skuteczniej wyodrębniać częste zestawy pozycji z dużych zbiorów danych?
Stan techniki: zastosowany w praktyce czy opracowany w teorii?
APRIORI jest używane wszędzie, z wyjątkiem opracowywania nowych algorytmów częstego zestawiania przedmiotów. Jest łatwy do wdrożenia i ponownego wykorzystania w bardzo różnych dziedzinach. Znajdziesz setki wdrożeń APRIORI o różnej jakości. W rzeczywistości łatwo jest pomylić APRIORI.
FPgrowth jest znacznie trudniejszy do zaimplementowania, ale także znacznie bardziej interesujący. Z akademickiego punktu widzenia każdy stara się poprawić wzrost FP – uzyskanie pracy w oparciu o zaakceptowane APRIORI będzie teraz bardzo trudne. Jeśli masz dobrą implementację, każdy algorytm jest dobry i moim zdaniem są to złe sytuacje. Dobra implementacja APRIORI będzie wymagała jedynie przeszukania bazy danych k razy, aby znaleźć wszystkie częste zestawy elementów o długości k. W szczególności, jeśli dane mieszczą się w pamięci głównej, jest to tanie. To, co może zabić APRIORI, to zbyt wiele częstych zestawów 2 elementów (zwłaszcza gdy nie używasz Trie i podobnych technik przyspieszania itp.). Działa najlepiej w przypadku dużych danych z małą liczbą częstych zestawów elementów. Eclat działa na kolumnach; ale musi czytać każdą kolumnę znacznie częściej. Trwają prace nad mechanizmami różnicowymi, aby zmniejszyć tę pracę. Jeśli twoje dane nie mieszczą się w pamięci głównej, Eclat cierpi prawdopodobnie bardziej niż Apriori. Przechodząc najpierw w głąb, będzie w stanie zwrócić pierwszy interesujący wynik znacznie wcześniej niż Apriori i możesz użyć tych wyników do dostosowania parametrów; więc potrzebujesz mniej iteracji, aby znaleźć dobre parametry. Ale z założenia nie może wykorzystywać przycinania tak starannie, jak zrobił to Apriori. FPGrowth kompresuje zestaw danych do drzewa. Działa to najlepiej, gdy masz dużo zduplikowanych rekordów. Prawdopodobnie możesz odnieść spore korzyści także dla Apriori i Eclat, jeśli możesz wstępnie posortować swoje dane i scalić duplikaty w ważone wektory. FPGrowth robi to na ekstremalnym poziomie. Wadą jest to, że implementacja jest znacznie trudniejsza; a kiedy to drzewo nie mieści się już w pamięci, robi się bałagan do zaimplementowania. Jeśli chodzi o wyniki wydajności i testy porównawcze – nie ufaj im. Jest tak wiele rzeczy do nieprawidłowego wdrożenia. Wypróbuj 10 różnych implementacji, a uzyskasz 10 bardzo różnych wyników wydajności. W szczególności w przypadku APRIORI mam wrażenie, że większość implementacji jest zepsuta w tym sensie, że brakuje niektórych głównych elementów APRIORI… a wśród tych, które mają te części prawidłowo, jakość optymalizacji jest bardzo różna.
Większość ostatnich podejść do częstych wzorców, które widziałem w literaturze, opiera się na optymalizacji FPGrowth. Muszę przyznać, że od wielu lat nie widziałem wielu zmian w literaturze dotyczącej FPM.
Czy Python jest odpowiedni dla dużych zbiorów danych?
W tym poście przeczytałem, że język R jest odpowiedni dla Big Data, że duże zbiory danych stanowią 5 TB i chociaż dobrze radzą sobie z dostarczaniem informacji o możliwości pracy z tego typu danymi w R, to dostarczają bardzo mało informacji o Pythonie. Zastanawiałem się, czy Python może również pracować z taką ilością danych. Aby wyjaśnić, czuję, że oryginalne odniesienia do pytań przez OP prawdopodobnie nie są najlepsze dla formatu typu SO, ale z pewnością będę reprezentował Pythona w tym konkretnym przypadku. Zacznę od tego, że niezależnie od rozmiaru danych, Python nie powinien być czynnikiem ograniczającym. W rzeczywistości jest tylko kilka głównych problemów, które napotkasz w przypadku dużych zbiorów danych:
* Wczytywanie danych do pamięci – jest to zdecydowanie najczęstszy problem w świecie dużych zbiorów danych. Zasadniczo nie możesz wczytać więcej danych, niż masz w pamięci (RAM). Najlepszym sposobem rozwiązania tego problemu jest wykonanie niepodzielnych operacji na danych zamiast próby wczytania wszystkiego naraz.
* Przechowywanie danych – w rzeczywistości jest to tylko kolejna forma wcześniejszego wydania, zanim osiągniesz około 1 TB, zaczniesz szukać gdzie indziej miejsca do przechowywania. AWS S3 jest najpopularniejszym zasobem, a python ma fantastyczną bibliotekę boto, która ułatwia prowadzenie z dużymi fragmentami danych.
* Opóźnienie sieci – Twoim wąskim gardłem będzie przenoszenie danych między różnymi usługami. Nie możesz zrobić wiele, aby to naprawić, poza próbą wybrania zasobów w kolokacji i podłączeniem do ściany.
Jest kilka rzeczy, które musisz zrozumieć, mając do czynienia z Big Data –
Co to jest Big Data?
Być może znasz słynne V Big Data – Volume, Velocity, Variety… Więc Python może nie być odpowiedni dla wszystkich. I to pasuje do wszystkich dostępnych narzędzi do analizy danych. Musisz wiedzieć, które narzędzie jest dobre do jakiego celu. W przypadku dużej ilości danych:
Pig / Hive / Shark – czyszczenie danych i prace ETL
Hadoop / Spark – rozproszone przetwarzanie równoległe
Mahout / ML-Lib – uczenie maszynowe
Teraz możesz używać R / Python na etapach pośrednich, ale zdasz sobie sprawę, że stają się wąskim gardłem w całym procesie. Jeśli masz do czynienia z prędkością danych:
Kafka / Storm – system o dużej przepustowości
Ludzie próbują tutaj R / Python, ale znowu zależy to od rodzaju paralelizmu, który chcesz i złożoności modelu. Jeśli model wymaga, aby najpierw wszystkie dane zostały przeniesione do pamięci, model nie powinien być złożony, ponieważ jeśli dane pośrednie są duże, kod ulegnie awarii. A jeśli myślisz o zapisaniu go na dysku, napotkasz dodatkowe opóźnienie, ponieważ odczyt / zapis dysku jest wolny w porównaniu z pamięcią RAM.
Wniosek
Zdecydowanie możesz używać Pythona w przestrzeni Big Data (zdecydowanie, ponieważ ludzie próbują z R, dlaczego nie Python), ale najpierw poznaj swoje dane i wymagania biznesowe. Mogą być dostępne lepsze narzędzia do tego samego i zawsze pamiętaj: Twoje narzędzia nie powinny określać, jak odpowiadasz na pytania. Twoje pytania powinny określić, jakich narzędzi używasz.
Python ma kilka bardzo dobrych narzędzi do pracy z dużymi zbiorami danych:
numpy
Tablice mapowane w pamięci Numpy umożliwiają dostęp do pliku zapisanego na dysku tak, jakby był to tablica. Tylko części tablicy, z którymi aktywnie pracujesz, muszą zostać załadowane do pamięci. Można go używać prawie tak samo, jak zwykłej tablicy.
h5py i pytables
Te dwie biblioteki zapewniają dostęp do plików HDF5. Pliki te umożliwiają dostęp tylko do części danych. Ponadto, dzięki bazowym bibliotekom używanym do uzyskiwania dostępu do danych, wiele operacji matematycznych i innych manipulacji danymi można wykonać bez ładowania ich do struktury danych Pythona. Możliwe są ogromne pliki o wysokiej strukturze, znacznie większe niż 5 TB. Umożliwia również płynną, bezstratną kompresję.
bazy danych
Istnieją różne typy baz danych, które umożliwiają przechowywanie dużych zbiorów danych i ładowanie tylko potrzebnych części. Wiele baz danych umożliwia wykonywanie manipulacji bez ładowania danych do struktury danych Pythona.
pandas
Umożliwia to wyższy poziom dostępu do różnych typów danych, w tym danych HDF5, plików csv, baz danych, a nawet stron internetowych. W przypadku dużych zbiorów danych zapewnia otoki wokół dostępu do plików HDF5, które ułatwiają analizę zbiorów dużych zbiorów danych.
mpi4py
Jest to narzędzie do uruchamiania kodu Pythona w sposób rozproszony na wielu procesorach lub nawet na wielu komputerach. Pozwala to na jednoczesną pracę nad częściami danych.
dask
Dostarcza wersję normalnej tablicy numpy, która obsługuje wiele normalnych operacji numpy w sposób wielordzeniowy, który może pracować na danych zbyt dużych, aby zmieściły się w pamięci.
blaze
Narzędzie zaprojektowane specjalnie dla dużych zbiorów danych. Jest to w zasadzie opakowanie wokół powyższych bibliotek, zapewniające spójne interfejsy dla różnych metod przechowywania dużych ilości danych (takich jak HDF5 lub bazy danych) oraz narzędzia ułatwiające manipulowanie, wykonywanie operacji matematycznych i analizowanie danych, które jest zbyt duży, aby zmieścić się w pamięci.