Hur stor är big data?

Till mig (kommer från en relationsdatabasbakgrund), ”Big Data” handlar inte främst om datastorleken (vilket är huvuddelen av vad de andra svaren hittills är).

”Big Data” och ”Bad Data” är nära släkt. Relationsdatabaser kräver ”orörda data”. Om uppgifterna finns i databasen är de korrekta, rena och 100% pålitliga. Relationella databaser kräver ”stora data” och mycket tid, pengar och ansvarsskyldighet läggs på för att se till att uppgifterna är väl förberedda innan de laddas in i databasen. Om data finns i databasen är det ”gospel” och det definierar systemförståelsen för verkligheten.

”Big Data” hanterar detta problem från andra hållet. Uppgifterna är dåligt definierade, mycket av det kan vara felaktigt och mycket av det kan faktiskt saknas. Datastrukturen och layouten är linjär i motsats till relation.

Big Data måste ha tillräckligt med volym så att mängden dåliga data eller saknade data blir statistiskt obetydliga. När felen i dina data är tillräckligt vanliga för att avbryta varandra, när den saknade informationen är proportionellt liten för att vara försumbar och när dina dataåtkomstkrav och algoritmer fungerar även med ofullständiga och felaktiga data, har du ”Big Data” .

”Big Data” handlar inte riktigt om volymen, det handlar om dataens egenskaper.

Kommentarer

• +1 Jag uppskattar ganska mycket stress på att stora data inte handlar om vad som är storleken , utan snarare om vad som är innehållet (egenskaperna hos) .
• Det är ett mycket uppfriskande perspektiv. Jag har aldrig hört detta förut, men det är väldigt sant. Detta tyder på att SQL- och NoSQL-teknik inte är konkurrenskraftiga utan kompletterande.
• Du ’ talar om ostrukturerad data, inte big data. Ostrukturerad data leder vanligtvis till NoSQL-lösningar och big data i applikationen, men de är fortfarande annorlunda.
• Jag tycker att detta är ett bra affärsperspektiv på vad big data är men svarar inte på den specifika frågan som är ganska spetsig ” hur stor är big data? ”

Som du med rätta konstaterar är ”big data” idag något som alla vill säga att de har fått, vilket innebär en viss löshet i hur människor definierar begreppet. ”d säger att du verkligen har att göra med big data om skalan är sådan att det inte längre är möjligt att hantera med mer traditionell teknik som RDBMS, åtminstone utan att komplettera dem med big data-teknik som Hadoop.

Hur stor din data faktiskt måste vara för att så ska vara fallet kan diskuteras. Här är ett (något provocerande) blogginlägg som hävdar att det egentligen inte är fallet för mindre än 5 TB data. (För att vara tydlig hävdar det inte ”Mindre än 5 TB är inte” stora data ”, men bara” Mindre än 5 TB är inte tillräckligt stort för att du behöver Hadoop ”.)

Men även på mindre datamängder kan big data-teknik som Hadoop ha andra fördelar, inklusive att vara väl lämpade för batchoperationer, spela bra med ostrukturerad data (liksom data vars struktur inte är känd i förväg eller kan förändras), horisontell skalbarhet (skalning med lägga till fler noder istället för att förstärka dina befintliga servrar) och (som en av kommentarerna till ovanstående länkade anteckningar) möjligheten att integrera din databehandling med externa datamängder (tänk på en kartreducering där kartläggaren gör en samtal till en annan server).Andra tekniker associerade med big data, som NoSql-databaser, betonar snabb prestanda och konsekvent tillgänglighet samtidigt som de hanterar stora datauppsättningar, liksom också att kunna hantera halvstrukturerad data och att skala horisontellt.

Naturligtvis , traditionella RDBMS har sina egna fördelar, inklusive ACID-garantier (Atomicitet, Konsistens, Isolering, Hållbarhet) och bättre prestanda för vissa operationer, samt att de är mer standardiserade, mer mogna och (för många användare) mer bekanta. Så även för obestridligt ”stora” data kan det vara vettigt att ladda åtminstone en del av dina data till en traditionell SQL-databas och använda den i kombination med big data-teknik.

Så, en mer generös definition skulle vara att du har stora data så länge det är tillräckligt stort för att stora datateknologier ger ett mervärde åt dig. Men som du kan se kan det inte bara bero på storleken på dina data utan på hur du vill arbeta med det och vilken typ av krav du har när det gäller flexibilitet, konsekvens och prestanda. Hur du använder dina data är mer relevant för frågan än vad du använder den för (t.ex. data mining). Som sagt, användningar som data mining och maskininlärning är mer benägna att ge användbara resultat om du har tillräckligt stora datamängder att arbeta med.

Kommentarer

• Den här kommentaren är nästan 5 år gammal, och medan delar av den fortfarande är sanna är 5 TB-tröskeln från bloggen jag citerade verkligen inte är inte sant längre. Till exempel erbjuder Microsoft ” hyperscale ” SQL DB-filer på upp till 100 TB: docs.microsoft.com/en-us/azure/sql-database/… Naturligtvis kan man anta många organisationer med stora SQL-DB också Jag har, säg, ett Spark-kluster för att stödja olika arbetsbelastningar. Det finns ’ ingen regel du behöver välja den ena eller den andra.

För mig handlar Big Data främst om verktygen (det är ju det där det började); en ”stor” dataset är en som är för stor för att hanteras med konventionella verktyg – i synnerhet tillräckligt stor för att kräva lagring och bearbetning på ett kluster snarare än en enda maskin. Detta utesluter en konventionell RDBMS och kräver nya tekniker för bearbetning; i synnerhet gör olika Hadoop-liknande ramar det enkelt att distribuera en beräkning över ett kluster, på bekostnad av att begränsa formen för denna beräkning. Jag kommer att hänvisa till http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html ; Big Data-tekniker är en sista utväg för datamängder som helt enkelt är för stora för att hantera något annat sätt. Jag skulle säga att alla datauppsättningar för vilket ändamål som helst skulle kunna kvalificera sig om de var tillräckligt stora – men om problemets form är sådan att befintliga ”big data” -verktyg inte är lämpliga, skulle det troligen vara bättre att komma med ett nytt namn.

Naturligtvis finns det viss överlappning; när jag (kort) arbetade på last.fm, arbetade vi på samma 50TB-dataset med Hadoop och även i en SQL-databas på en ganska löjlig server (jag kommer ihåg att den hade 1TB RAM, och det här är för några år sedan). Vilket på sätt och vis innebar att det både var och inte var stort data, beroende på vilket jobb du arbetade med. Men jag tror att det är en korrekt karaktärisering; de som arbetade med Hadoop-jobben tyckte att det var bra att gå till Big Data-konferenser och webbplatser, medan de som arbetade med SQL-jobben inte gjorde det.

Data blir ”stora” när en enda råvarudator inte längre kan hantera mängden data du har. Det anger punkt där du måste börja tänka på att bygga superdatorer eller använda kluster för att bearbeta dina data.

Big Data definieras av datamängden är det rätt, men inte bara. Det speciella med big data är att du måste lagra partier olika och ibland ostrukturerad saker alla gånger och från en massor av sensorer , vanligtvis i åratal eller årtionde .

Dessutom behöver du något skalbart, så att det inte tar dig ett halvår för att hitta en data tillbaka.

Så här kommer Big Data, där traditionell metod inte fungerar längre. SQL är inte skalbar. Och SQL fungerar med mycket strukturerade och länkade data (med alla dessa primära och främmande nyckelröra, innerjoin, imbricated begäran …).

I grund och botten, eftersom lagring blir billigare och billigare och data blir mer och mer värdefull, ber stor chef ingenjör att registrera allt. Lägg till detta massor av nya sensorer med alla de mobila, sociala nätverk, inbäddade grejer … etc. Så eftersom klassiska metoder inte fungerar, måste de hitta ny teknik (lagra allt i filer, i json-format, med stort index, vad vi kallar noSQL).

Så Big Data kan vara väldigt stort men kan inte vara så stor utan komplex strukturerad eller olika data som måste lagras snabbt och köras i ett råformat. Vi fokuserar och lagrar först, och sedan tittar vi på hur man länkar allt.

Jag kommer att dela hur Big Data är i genomik, särskilt de-novo-montering.

När vi sekvenserar ditt genom (t.ex.: upptäcker nya gener), vi tar miljarder nästa generations korta läsningar. Titta på bilden nedan, där vi försöker sätta ihop några läsningar.

Detta ser enkelt ut? Men tänk om du har miljarder av dessa läsningar? Vad händer om dessa läsningar innehåller sekvensfel? Vad händer om ditt RAM-minne inte har tillräckligt med minne för att hålla läsningarna? Vad sägs om repetitiva DNA-regioner, till exempel det mycket vanliga Alu Element ?

De-novo-montering görs genom att konstruera en De-Bruijn-graf :

Grafen är en smart utvunnen datastruktur som representerar överlappande läsningar. Det är inte perfekt men det ”bättre än att generera alla möjliga överlappningar och lagra dem i en matris.

Monteringsprocessen kan ta dagar att slutföra, eftersom det finns ett stort antal banor som en samlare skulle behöva gå igenom och kollapsa.

I genomik har du stora data när:

• Du kan inte tvinga alla kombinationer
• Datorn har inte tillräckligt med fysiskt minne för att lagra data
• Du måste minska dimensionerna (t.ex.: kollapsa överflödiga grafvägar)
• Du blir förbannad eftersom du måste vänta dagar för att göra vad som helst
• Du behöver en speciell datastruktur för att representera data
• Du måste filtrera din datamängd för fel (t.ex. sekvenseringsfel)

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

Det finns en speciell sak med grafalgoritmer, du ursprungliga frågor som gör det speciellt, vilket handlar om förmågan att partitionera data i huvudsak.

För vissa saker, som att sortera nummer i en matris, är det inte så svårt att dela upp problemet i datastrukturen i mindre disjunktiva bitar, t.ex. Här: Parallell på plats sammanfoga sortering

För grafalgoritmer finns dock utmaningen att hitta en valfri partitionering på en given grafisk statistik att vara $ NP-hård $.

Så medan 10 GB siffror att sortera kan vara ett mycket bra problem på en vanlig dator (du kan bara komma in via dynamisk programmering och har mycket god förutsägbarhet om programflödet), men arbetar med en 10 GB-graf datastruktur kan redan genom att utmana.

Det finns ett antal specialiserade ramar som GraphX med metoder och speciella dataparadigmer för att kringgå de inneboende utmaningarna i grafer något.

Så för att svara kort på din fråga: Som tidigare nämnts av andra, när dina data inte passar in i huvudminnet på en vanlig dator men du behöver allt för att svara på ditt problem, är det ett bra tips att din uppgifterna är redan något stora. Den exakta märkningen beror dock på att jag tänker lite på datastrukturen och frågan.

Jag tror att big data börjar vid den punkt där storleken hindrar dig från att göra vad du vill. I de flesta scenarier finns det en begränsning på körtiden som anses genomförbar. I vissa fall är det en timme, i vissa fall kan det ta några veckor. Så länge data inte är tillräckligt stor för att bara O (n) -algoritmer kan köras inom den möjliga tidsramen, nådde du inte stora data.

Jag gillar den här definitionen eftersom den är agnostisk till volym, teknologinivå och specifika algoritmer. Det är inte agnostiskt för resurser så en elever kommer att nå punkten med big data långt före Google.

För att kunna kvantifiera hur stor data är vill jag gärna överväga den tid som behövs för att säkerhetskopiera den. Eftersom tekniken utvecklas är volymerna som ansågs stora för några år sedan måttliga. Backuptiden förbättras, eftersom tekniken förbättras, precis som inlärningsalgoritmernas körtid. Jag tycker att det är mer förnuftigt att prata om en dataset det tar X timmar att säkerhetskopiera och inte en dataset med Y-byte.

PS.

Det är viktigt att notera att även om du nådde big data-punkten och du kan inte köra algoritmer av komplexitet mer än O (n) på ett enkelt sätt, det finns mycket du kan göra för att fortfarande kunna dra nytta av sådan algoritm s.

Till exempel kan funktionsval minska antalet funktioner som många algoritmer är beroende av. I många långa svansfördelningar kan fokusering på de få föremålen i huvudet vara till nytta. Du kan använda ett exempel och köra på de långsammare algoritmerna.

Kommentarer

• Observera att $ O (n) $ -barriären också har brutits nu på vissa ML-domäner. Se [ grigory.us/mpc-workshop-dimacs.html] för Workshop om sublinjära algoritmer för ML [1]: grigory.us/mpc-workshop-dimacs.html

Data är ”Big Data” om den har en sådan volym att det är billigare att analysera dem på två eller flera råvarudatorer än på en avancerad dator.

Så här är Googles ” BigFiles ”filsystem har sitt ursprung. Page och Brin hade inte råd med en snygg Sun-server för att lagra och söka i deras webbindex, så anslutna flera råvarudatorer

”Big data ”är bokstavligen bara mycket data. Även om det är mer en marknadsföringsperiod än någonting, är det vanligtvis att du har så mycket data att du inte kan analysera alla data på en gång eftersom mängden minne (RAM) som krävs för att hålla data i minne för att bearbeta och analysera det är större än mängden tillgängligt minne.

Detta innebär att analyser vanligtvis måste göras på slumpmässiga datasegment, vilket gör att modeller kan byggas för att jämföra med andra delar av data.