Hvor stor er big data?

Til mig (kommer fra en relationel databasebaggrund) handler “Big Data” ikke primært om datastørrelsen (hvilket er hovedparten af det, de andre svar hidtil er).

“Big Data” og “Bad Data” er nært beslægtet. Relationsdatabaser kræver “uberørte data”. Hvis dataene er i databasen, er de nøjagtige, rene og 100% pålidelige. Relationsdatabaser kræver “store data”, og der lægges en enorm mængde tid, penge og ansvarlighed på for at sikre, at dataene er godt forberedt, inden de indlæses i databasen. Hvis dataene er i databasen, er det “gospel”, og det definerer systemets forståelse af virkeligheden.

“Big Data” tackler dette problem fra den anden retning. Dataene er dårligt defineret, meget af dem kan være unøjagtige, og meget af dem mangler faktisk. Datastrukturen og layoutet er lineær i modsætning til relationel.

Big Data skal have nok volumen, så mængden af dårlige data eller manglende data bliver statistisk ubetydelig. Når fejlene i dine data er almindelige nok til at annullere hinanden, når de manglende data er forholdsmæssigt små nok til at være ubetydelige, og når dine dataadgangskrav og algoritmer er funktionelle, selv med ufuldstændige og unøjagtige data, har du “Big Data” .

“Big Data” handler ikke rigtig om lydstyrken, det handler om dataens egenskaber.

Kommentarer

• +1 Jeg sætter stor pris på stresset ved, at big data ikke handler om hvad der er størrelse , og snarere om hvad der er indholdet (egenskaber ved) .
• Det er et meget forfriskende perspektiv. Jeg har aldrig hørt dette før, men det er meget sandt. Dette antyder, at SQL- og NoSQL-teknologier ikke er konkurrencedygtige, men supplerende.
• Du ‘ taler om ustrukturerede data, ikke big data. Ustrukturerede data fører normalt til NoSQL-løsninger og big data i applikationen, men de er stadig forskellige.
• Jeg synes, det er et godt forretningsperspektiv på, hvad big data er, men svarer ikke på det specifikke spørgsmål, som er ret spids ” hvor stor er big data? ”

Som du med rette bemærker, er “big data” i disse dage noget, som alle vil sige, at de har fået, hvilket indebærer en vis løshed i, hvordan folk definerer udtrykket. Generelt set “d siger du” helt sikkert beskæftiger dig med big data, hvis skalaen er sådan, at det ikke længere er muligt at administrere med mere traditionelle teknologier som RDBMS, i det mindste uden at supplere dem med big data-teknologier som Hadoop.

Hvor stor dine data faktisk skal være for at det skal være tilfældet, kan diskuteres. Her er et (noget provokerende) blogindlæg , der hævder, at det egentlig ikke er tilfældet for mindre end 5 TB data. (For at være klar, hævder det ikke “Mindre end 5 TB er ikke” store data “, men bare” Mindre end 5 TB er ikke “stort nok til, at du har brug for Hadoop”.)

Men selv på mindre datasæt kan big data-teknologier som Hadoop have andre fordele, herunder at være velegnet til batchoperationer, spille godt med ustrukturerede data (såvel som data, hvis struktur ikke er kendt på forhånd eller kunne ændre sig), vandret skalerbarhed (skalering efter tilføje flere noder i stedet for at styrke dine eksisterende servere), og (som en af kommentatorerne til de ovennævnte linkede noter) muligheden for at integrere din databehandling med eksterne datasæt (tænk på en kortreduktion, hvor kortlæggeren laver en opkald til en anden server).Andre teknologier forbundet med big data, som NoSql-databaser, understreger hurtig ydeevne og ensartet tilgængelighed, mens de beskæftiger sig med store datasæt, samt er i stand til at håndtere semi-ustrukturerede data og skalere vandret. , traditionelle RDBMS har deres egne fordele, herunder ACID-garantier (Atomicitet, Konsistens, Isolering, Holdbarhed) og bedre ydeevne til visse operationer, samt at de er mere standardiserede, mere modne og (for mange brugere) mere velkendte. Så selv for utvivlsomt “store” data kan det være fornuftigt at indlæse mindst en del af dine data i en traditionel SQL-database og bruge det i forbindelse med big data-teknologier.

Så en mere generøs definition ville være, at du har big data, så længe det er stort nok til, at big data-teknologier giver dig en merværdi. Men som du kan se, kan det ikke kun afhænge af størrelsen på dine data, men af hvordan du vil arbejde med det og hvilke slags krav du har med hensyn til fleksibilitet, konsistens og ydeevne. Hvordan du bruger dine data er mere relevant for spørgsmålet end hvad du bruger det til (f.eks. data mining). Når det er sagt, er anvendelser som data mining og machine learning mere tilbøjelige til at give nyttige resultater, hvis du har et stort nok datasæt til at arbejde med.

Kommentarer

• Denne kommentar er næsten 5 år gammel, og mens dele af den stadig er sand, er tærsklen på 5 TB fra den blog, jeg citerede, bestemt ikke ikke længere sandt. For eksempel tilbyder Microsoft ” hyperscale ” SQL-DBer på op til 100 TB: docs.microsoft.com/en-us/azure/sql-database/… Man kan selvfølgelig antage mange organisationer med enorme SQL DBer også Jeg har f.eks. en Spark-klynge, der understøtter forskellige arbejdsbelastninger. Der ‘ er ingen regel, du skal vælge den ene eller den anden.

For mig handler Big Data primært om værktøjerne (trods alt det er hvor det startede); et “stort” datasæt er en, der er for stor til at blive håndteret med konventionelle værktøjer – især stor nok til at kræve opbevaring og behandling på en klynge snarere end en enkelt maskine. Dette udelukker en konventionel RDBMS og kræver nye teknikker til behandling; især forskellige Hadoop-lignende rammer gør det let at distribuere en beregning over en klynge på bekostning af at begrænse formen til denne beregning. Jeg vil henvise til http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html ; Big Data-teknikker er en sidste udvej for datasæt, der simpelthen er for store at håndtere andre måder. Jeg vil sige, at ethvert datasæt til ethvert formål kunne kvalificeres, hvis det var stort nok – men hvis formen på problemet er sådan, at eksisterende “big data” -værktøjer ikke er passende, ville det sandsynligvis være bedre at komme med et nyt navn.

Selvfølgelig er der en vis overlapning; da jeg (kort) arbejdede på last.fm, arbejdede vi på det samme 50 TB datasæt ved hjælp af Hadoop og også i en SQL-database på en ret latterlig server (jeg kan huske, at den havde 1 TB RAM, og dette er for et par år siden). Hvilket på en måde betød, at det både var og ikke var big data, afhængigt af hvilket job du arbejdede på. Men jeg synes, det er en nøjagtig karakterisering; de mennesker, der arbejdede på Hadoop-jobbet, fandt det nyttigt at gå til Big Data-konferencer og websteder, mens de mennesker, der arbejdede på SQL-jobene, ikke gjorde det.

Data bliver “store”, når en enkelt handelscomputer ikke længere kan håndtere den mængde data, du har. Det angiver punkt, hvor du skal begynde at tænke på at opbygge supercomputere eller bruge klynger til at behandle dine data.

Big Data er defineret efter datamængden er det rigtigt, men ikke kun. Specificiteten ved store data er, at du skal gemme en partier af forskellige og undertiden ustrukturerede stuffs hele tiden og fra en tonsvis af sensorer i år eller årti .

Desuden har du brug for noget skalerbart, så det ikke tager dig et halvt år for at finde data tilbage.

Så her kommer Big Data, hvor traditionel metode ikke længere fungerer. SQL er ikke skalerbar. Og SQL fungerer med meget strukturerede og sammenkædede data (med alle disse primære og udenlandske nøgle rod, indre sammenføjning, imbriceret anmodning …).

Dybest set fordi lagring bliver billigere og billigere og data bliver mere og mere værdifuld, beder stor manager ingeniøren om at registrere alt. disse masser af nye sensorer med alle de mobile, sociale netværk, indlejrede ting … osv. Da klassiske metoder ikke fungerer, er de nødt til at finde nye teknologier (lagring af alt i filer i json-format med stort indeks, hvad vi kalder noSQL).

Så Big Data kan være meget store, men kan ikke være så stort, men kompleks ustruktureret eller forskellige data, som skal gemmes hurtigt og på farten i et råformat. Vi fokuserer og lagrer først, og så ser vi på, hvordan man forbinder alt sammen.

Jeg vil dele, hvordan Big Data er i genomik, især de-novo-samling.

Hvornår vi sekvenserer dit genom (f.eks. detekterer nye gener), vi tager milliarder af næste generations korte læsninger. Se på billedet nedenfor, hvor vi prøver at samle nogle læsninger.

Dette ser simpelt ud? Men hvad nu hvis du har milliarder af disse læsninger? Hvad hvis disse læsninger indeholder sekvensfejl? Hvad hvis din RAM ikke har nok hukommelse til at holde læsningerne? Hvad med gentagne DNA-regioner, såsom det meget almindelige Alu Element ?

De-novo-samling sker ved at konstruere en De-Bruijn-graf :

Grafen er en smart-minedatastruktur, der repræsenterer overlappende læsninger. Det er ikke perfekt, men det “bedre end at generere alle mulige overlapninger og gemme dem i en matrix.

Samlingsprocessen kan tage dage at gennemføre, fordi der er et stort antal stier, som en samler har brug for at krydse og kollapse.

I genomik har du store data, når:

• Du kan ikke tvinge alle kombinationer
• Din computer har ikke nok fysisk hukommelse at gemme dataene
• Du skal reducere dimensionerne (f.eks. kollaps af overflødige grafstier)
• Du bliver sur på grund af at du skulle ventedage for at gøre noget
• Du har brug for en speciel datastruktur til at repræsentere dataene
• Du skal filtrere dit datasæt for fejl (f.eks. sekventeringsfejl)

https://en.wikipedia.org/wiki/De_Bruijn_graph

Der er en speciel ting ved at tegne algoritmer, du originale spørgsmål, der gør det specielt, hvilket handler om evnen til i det væsentlige at opdele dataene.

For nogle ting, som at sortere numre på en matrix, er det ikke for svært at opdele problemet på datastrukturen i mindre disjunktive stykker, f.eks. Her: Parallel på plads flettsortering

For grafalgoritmer er der dog udfordringen at finde en valgfri partitionering på en given grafisk metric er kendt at være $ NP-hård $.

Så mens 10 GB numre, der skal sorteres, kan være et meget tilgængeligt problem på en normal pc (du kan bare gå ind via dynamisk programmering og have meget god forudsigelighed om programflowet), mens du arbejder med en 10 GB-graf datastruktur kan allerede ved at udfordre.

Der er en række specialiserede rammer såsom GraphX ved hjælp af metoder og specielle databehandlingsparadigmer for at omgå de iboende udfordringer ved grafer.

Så for at besvare dit spørgsmål kort: Som nævnt af andre, når dine data ikke passer ind i hovedhukommelsen på en normal pc, men du har brug for det hele for at besvare dit problem, er det et godt tip, at din data er allerede noget store. Den nøjagtige mærkning afhænger dog af, at jeg tænker lidt på datastrukturen og det stillede spørgsmål.

Jeg tror, at big data starter på det punkt, hvor størrelsen forhindrer dig i at gøre, hvad du vil. I de fleste scenarier er der en grænse for den driftstid, der anses for gennemførlig. I nogle tilfælde er det en time, i nogle tilfælde kan det være få uger. Så længe dataene ikke er store nok til, at kun O (n) algoritmer kan køre i den mulige tidsramme, nåede du ikke store data.

Jeg kan godt lide denne definition, da den er agnostisk til volumen, teknologiniveau og specifikke algoritmer. Det er ikke agnostisk for ressourcer, så en studerende vil nå punktet med big data før Google.

For at kunne kvantificere, hvor stor data er, kan jeg godt lide at overvej den nødvendige tid til at tage backup af den. Da teknologien skrider frem, er mængder, der blev betragtet som store for nogle år siden, nu moderat. Backup-tiden forbedres, efterhånden som teknologien forbedres, ligesom læringens algoritmers driftstid. Jeg føler, det er mere fornuftigt at tale om et datasæt, det tager X timer at tage backup og ikke et datasæt med Y-byte.

PS.

Det er vigtigt at bemærke, at selvom du nåede det store datapunkt og du kan ikke køre algoritmer af kompleksitet mere end O (n) ligetil, der er masser du kan gøre for stadig at drage fordel af en sådan algoritme s.

F.eks. kan funktionsvalg reducere antallet af funktioner, som mange algoritmers driftstid afhænger af. I mange lange halefordelinger, der fokuserer på de få ting i hovedet, kan det være en fordel. Du kan bruge en prøve og køre på den langsommere algoritmer.

Kommentarer

• Bemærk, at $ O (n) $ -barrieren også er blevet brudt nu i nogle ML-domæner. Se [ grigory.us/mpc-workshop-dimacs.html] for Workshop om sublinear algoritmer for ML [1]: grigory.us/mpc-workshop-dimacs.html

Data er “Big Data”, hvis de har et sådant volumen, at det er billigere at analysere dem på to eller flere handelscomputere end på en avanceret computer.

Dette er i det væsentlige, hvordan Google “s” BigFiles “-filsystemet stammer fra. Page og Brin havde ikke råd til en fancy Sun-server til at gemme og søge i deres webindeks, så de tilsluttede flere råvarecomputere

“Big data “er bogstaveligt talt bare en masse data. Selvom det er mere et markedsføringsudtryk end noget andet, betyder det normalt, at du har så meget data, at du ikke kan analysere alle dataene på én gang, fordi den mængde hukommelse (RAM), det tager at holde dataene inde i hukommelse til at behandle og analysere den er større end mængden af tilgængelig hukommelse.

Dette betyder, at analyser normalt skal udføres på tilfældige segmenter af data, hvilket gør det muligt at opbygge modeller til sammenligning med andre dele af dataene.