Hvor stor er big data? (Norsk)

For meg (kommer fra en relasjonell databasebakgrunn) handler «Big Data» ikke først og fremst om datastørrelsen (som er mesteparten av det de andre svarene er så langt).

«Big Data» og «Bad Data» er nært beslektet. Relasjonsdatabaser krever «uberørte data». Hvis dataene er i databasen, er de nøyaktige, rene og 100% pålitelige. Relasjonsdatabaser krever «store data» og det blir lagt ned enorme mengder tid, penger og ansvar for å sikre at dataene er godt forberedt før de lastes inn i databasen. Hvis dataene er i databasen, er det «gospel», og det definerer systemforståelsen av virkeligheten.

«Big Data» takler dette problemet fra den andre retningen. Dataene er dårlig definert, mye av dem kan være unøyaktige, og mye av det kan faktisk mangle. Strukturen og utformingen av dataene er lineære i motsetning til relasjonelle.

Big Data må ha nok volum slik at mengden dårlige data eller manglende data blir statistisk ubetydelig. Når feilene i dataene dine er vanlige nok til å avbryte hverandre, når de manglende dataene er forholdsmessig små nok til å være ubetydelige, og når dine datatilgangskrav og algoritmer er funksjonelle selv med ufullstendige og unøyaktige data, har du «Big Data» .

«Big Data» handler egentlig ikke om volumet, det handler om dataenes egenskaper.

Kommentarer

• +1 Jeg setter ganske stor pris på stresset på at big data ikke handler om hva som er størrelsen , og heller om hva som er innholdet (egenskapene til) .
• Det er et veldig forfriskende perspektiv. Jeg har aldri hørt dette før, men det er veldig sant. Dette antyder at SQL- og NoSQL-teknologier ikke er konkurransedyktige, men komplementære.
• Du ‘ snakker om ustrukturerte data, ikke big data. Ustrukturerte data fører vanligvis til NoSQL-løsninger og big data i applikasjonen, men de er fremdeles forskjellige.
• Jeg synes dette er et godt forretningsperspektiv på hva big data er, men svarer ikke på det spesifikke spørsmålet som er ganske spiss. » hvor stor er big data? »

Som du med rette bemerker, er «big data» i disse dager noe alle vil si at de har, noe som medfører en viss løshet i hvordan folk definerer begrepet. Generelt sett skjønner jeg «d say you» har helt sikkert å gjøre med store data hvis skalaen er slik at det ikke lenger er mulig å klare seg med mer tradisjonelle teknologier som RDBMS, i det minste uten å utfylle dem med big data-teknologier som Hadoop.

Hvor stor dataene dine faktisk må være for at det skal være tilfelle, kan diskuteres. Her er et (litt provoserende) blogginnlegg som hevder at det egentlig ikke er tilfelle for mindre enn 5 TB med data. (For å være klar, krever det ikke «Mindre enn 5 TB er ikke» store data «, men bare» Mindre enn 5 TB er ikke stort nok til at du trenger Hadoop «.)

Men til og med på mindre datasett kan big data-teknologier som Hadoop ha andre fordeler, inkludert å være godt egnet til batchoperasjoner, spille godt med ustrukturerte data (samt data hvis struktur ikke er kjent på forhånd eller kan endres), horisontal skalerbarhet (skalering etter legge til flere noder i stedet for å forbedre dine eksisterende servere), og (som en av kommentatorene til de ovennevnte koblede innleggsnotatene) muligheten til å integrere databehandlingen din med eksterne datasett (tenk på en kartreduksjon der kartleggeren lager en ring til en annen server).Andre teknologier knyttet til big data, som NoSql-databaser, understreker rask ytelse og konsistent tilgjengelighet mens de håndterer store datasett, i tillegg til å kunne håndtere semi-ustrukturerte data og skalere horisontalt.

, tradisjonelle RDBMS har sine egne fordeler, inkludert ACID-garantier (Atomicitet, Konsistens, Isolasjon, Holdbarhet) og bedre ytelse for visse operasjoner, samt å være mer standardiserte, mer modne og (for mange brukere) mer kjent. Så selv for utvilsomt «store» data, kan det være fornuftig å laste minst en del av dataene dine inn i en tradisjonell SQL-database og bruke den i forbindelse med big data-teknologier.

Så, en mer sjenerøs definisjon ville være at du har store data så lenge det er stort nok til at store datateknologier gir noe merverdi for deg. Men som du kan se, kan det ikke bare avhenge av størrelsen på dataene dine, men også hvordan du vil jobbe med det og hva slags krav du har når det gjelder fleksibilitet, konsistens og ytelse. Hvordan du bruker dataene dine er mer relevant for spørsmålet enn hva du bruker det for (f.eks. data mining). Når det er sagt, er det mer sannsynlig at bruk som data mining og maskinlæring gir nyttige resultater hvis du har et stort nok datasett å jobbe med.

Kommentarer

• Denne kommentaren er nesten 5 år gammel, og mens deler av den fremdeles er sanne, er 5 TB-terskelen fra bloggen jeg siterte absolutt ikke ikke sant lenger. For eksempel tilbyr Microsoft » hyperscale » SQL DB-er på opptil 100 TB: docs.microsoft.com/en-us/azure/sql-database/… Selvfølgelig kan man anta mange organisasjoner med store SQL-DB også Jeg har, si, en Spark-klynge for å støtte forskjellige arbeidsbelastninger. Det er ‘ ingen regel du trenger å velge den ene eller den andre.

For meg handler Big Data først og fremst om verktøyene (det er tross alt det det startet); et «stort» datasett er en som er for stor til å håndteres med konvensjonelle verktøy – spesielt stor nok til å kreve lagring og behandling i en klynge i stedet for på en enkelt maskin. Dette utelukker en konvensjonell RDBMS, og krever nye teknikker for behandling; spesielt gjør forskjellige Hadoop-lignende rammer det enkelt å distribuere en beregning over en klynge, på bekostning av å begrense formen til denne beregningen. Jeg kommer til å referere til http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html ; Big Data-teknikker er en siste utvei for datasett som rett og slett er for store å håndtere andre måter. Jeg vil si at ethvert datasett for ethvert formål kan kvalifisere hvis det var stort nok – men hvis formen på problemet er slik at eksisterende «big data» -verktøy ikke er passende, ville det sannsynligvis være bedre å komme med et nytt navn.

Selvfølgelig er det noe overlapping; da jeg (kort) jobbet på last.fm, jobbet vi med det samme 50 TB datasettet ved hjelp av Hadoop og også i en SQL-database på en ganske latterlig server (jeg husker den hadde 1 TB RAM, og dette er for noen år siden). Som på en måte betydde at det både var og ikke var store data, avhengig av hvilken jobb du jobbet med. Men jeg tror det er en nøyaktig karakterisering; menneskene som jobbet med Hadoop-jobbene, syntes det var nyttig å gå til Big Data-konferanser og nettsteder, mens de som jobbet med SQL-jobbene ikke gjorde det.

Data blir «store» når en enkelt råvarecomputer ikke lenger kan håndtere datamengden du har. Den betegner punktet der du må begynne å tenke på å bygge superdatamaskiner eller bruke klynger til å behandle dataene dine.

Big Data er definert etter datamengden er det riktig, men ikke bare. Spesialiteten til store data er at du må lagre partier av forskjellige og noen ganger ustrukturerte ting alle tidene og fra en tonnevis av sensorer i flere år eller tiår .

Videre trenger du noe skalerbart, slik at det ikke tar deg et halvt år for å finne data tilbake.

Så her kommer Big Data, der tradisjonell metode ikke vil fungere lenger. SQL er ikke skalerbar. Og SQL fungerer med veldig strukturerte og koblede data (med alle disse primære og utenlandske nøkkelen, innerjoin, imbricated forespørsel …).

I utgangspunktet, fordi lagring blir billigere og billigere og data blir mer og mer verdifull, ber stor leder ingeniøren om å registrere alt. dette tonnevis av nye sensorer med alle de mobile, sosiale nettverk, innebygde ting … osv. Så da klassiske metoder ikke fungerer, må de finne nye teknologier (lagring av alt i filer, i json-format, med stor indeks, det vi kaller noSQL).

Så Big Data kan være veldig stort, men kan ikke være så stort, men kompleks ustrukturert eller forskjellige data som må lagres raskt og på farten i et råformat. Vi fokuserer og lagrer først, og så ser vi på hvordan vi kan koble alt sammen.

Jeg vil dele hvordan Big Data er i genomikk, spesielt de-novo-samling.

Når vi sekvenserer genomet ditt (f.eks. oppdager nye gener), vi tar milliarder neste generasjons kortlesninger. Se på bildet nedenfor, hvor vi prøver å sette sammen noen lesninger.

Dette ser enkelt ut? Men hva om du har milliarder av disse lesningene? Hva om disse lesningene inneholder sekvensfeil? Hva om RAM-en din ikke har nok minne til å holde lesene? Hva med repeterende DNA-regioner, for eksempel det veldig vanlige Alu Element ?

De-novo-montering gjøres ved å konstruere en De-Bruijn-graf :

Grafen er en smart utvunnet datastruktur som representerer overlappende lesninger. Det er ikke perfekt, men det «er bedre enn å generere alle mulige overlapp og lagre dem i en matrise.

Monteringsprosessen kan ta dager å fullføre, fordi det er ganske mange baner som en montør trenger for å krysse og kollapse.

I genomikk har du store data når:

• Du kan ikke tøffe alle kombinasjoner
• Datamaskinen din har ikke nok fysisk minne for å lagre dataene
• Du må redusere dimensjonene (f.eks. kollaps av overflødige grafbaner)
• Du blir forbanna fordi du må vent dager for å gjøre hva som helst
• Du trenger en spesiell datastruktur for å representere dataene
• Du må filtrere datasettet ditt for feil (f.eks. sekvenseringsfeil)

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

Det er spesielle med grafalgoritmer, du originale spørsmål som gjør det spesielt, som handler om muligheten til å partisjonere dataene i det vesentlige.

For noen ting, som å sortere tall på en matrise, er det ikke for vanskelig å dele problemet på datastrukturen i mindre disjunktive biter, f.eks. Her: Parallell in place merge sort

For grafalgoritmer er det imidlertid utfordringen å finne en valgfri partisjonering på en gitt grafisk beregning. å være $ NP-hard $.

Så selv om 10 GB tall å sortere kan være et veldig godt problem på en vanlig PC (du kan bare gå inn via dynamisk programmering og har veldig god forutsigbarhet om programflyten), arbeider du med en 10 GB graf datastruktur kan allerede ved å utfordre.

Det finnes en rekke spesialiserte rammer som GraphX ved hjelp av metoder og spesielle databehandlingsparadigmer for å omgå de iboende utfordringene ved grafer.

Så for å svare på spørsmålet ditt kort: Som nevnt før av andre, når dataene dine ikke passer inn i hovedminnet på en vanlig PC, men du trenger alt for å svare på problemet ditt, er det et godt hint om at data er allerede noe store. Den nøyaktige merkingen avhenger skjønt, jeg tenker litt på datastrukturen og spørsmålet.

Jeg tror at big data starter på det punktet hvor størrelsen hindrer deg i å gjøre det du vil. I de fleste scenarier er det en begrensning på kjøretiden som anses mulig. I noen tilfeller er det en time, i noen tilfeller kan det være noen uker. Så lenge dataene ikke er store nok til at bare O (n) -algoritmer kan kjøres i den mulige tidsrammen, nådde du ikke store data.

Jeg liker denne definisjonen siden den er agnostisk til volum, teknologinivå og spesifikke algoritmer. Det er ikke agnostisk for ressurser, så en gradstudent vil nå punktet med big data før Google.

For å kunne kvantifisere hvor stor data er, liker jeg å vurder tiden som er nødvendig for å sikkerhetskopiere den. Siden teknologien utvikler seg, er volumene som ble ansett som store for noen år siden moderat. Sikkerhetskopieringstiden forbedres, ettersom teknologien forbedres, akkurat som løpetiden til læringsalgoritmene. å snakke om et datasett det tar X timer å sikkerhetskopiere og ikke et datasett med Y-byte.

PS.

Det er viktig å merke seg at selv om du nådde big data-punktet og du kan ikke kjøre algoritmer av kompleksitet mer enn O (n) på en rett frem måte, det er mye du kan gjøre for fortsatt å ha nytte av en slik algoritme s.

For eksempel kan funksjonsvalg redusere antall funksjoner som mange algoritmer kjører avhengig av. I mange distribusjoner med lang hale kan det være fordelaktig å fokusere på noen få ting i hodet. Du kan bruke et utvalg og kjøre på de langsommere algoritmene.

Kommentarer

• Merk at $ O (n) $ -barrieren også er brutt. nå på noen domener i ML. Se [ grigory.us/mpc-workshop-dimacs.html] for Workshop on Sublinear Algorithms for ML [1]: grigory.us/mpc-workshop-dimacs.html

Data er «Big Data» hvis de har et slikt volum at det er billigere å analysere dem på to eller flere råvaredatamaskiner enn på en avansert datamaskin.

Dette er egentlig Googles «s» BigFiles «filsystem stammer fra. Page og Brin hadde ikke råd til en fancy Sun-server for å lagre og søke i webindeksen deres, så koblet til flere råvaredatamaskiner

«Stor data «er bokstavelig talt bare mye data. Mens det er mer et markedsføringsuttrykk enn noe annet, er det vanligvis at du har så mye data at du ikke kan analysere alle dataene på en gang fordi mengden minne (RAM) det tar å holde dataene inne. minne for å behandle og analysere det er større enn mengden tilgjengelig minne.

Dette betyr at analyser vanligvis må gjøres på tilfeldige datasegmenter, noe som gjør at modeller kan bygges for å sammenligne med andre deler av dataene.