Hoe groot is big data?

Voor mij (komt van een relationele database-achtergrond), gaat Big Data niet in de eerste plaats over de gegevensgrootte (dit is het grootste deel van wat de andere antwoorden tot nu toe zijn).

Big Data en Bad Data zijn nauw verwant. Relationele databases vereisen “ongerepte gegevens”. Als de gegevens in de database staan, zijn ze nauwkeurig, schoon en 100% betrouwbaar. Relationele databases vereisen “geweldige data” en er wordt enorm veel tijd, geld en verantwoordelijkheid in gestoken om ervoor te zorgen dat de gegevens goed zijn voorbereid voordat ze in de database worden geladen. Als de gegevens in de database staan, is het “gospel”, en het definieert het systeembegrip van de werkelijkheid.

“Big Data” pakt dit probleem van de andere kant aan. De gegevens zijn slecht gedefinieerd, veel ervan kan onnauwkeurig zijn en veel ervan kan zelfs ontbreken. De structuur en lay-out van de gegevens is lineair in plaats van relationeel.

Big Data moet voldoende volume hebben zodat de hoeveelheid slechte gegevens of ontbrekende gegevens statistisch onbeduidend wordt. Wanneer de fouten in uw gegevens vaak genoeg zijn om elkaar op te heffen, wanneer de ontbrekende gegevens proportioneel klein genoeg zijn om verwaarloosbaar te zijn en wanneer uw vereisten voor gegevenstoegang en algoritmen functioneel zijn, zelfs met onvolledige en onnauwkeurige gegevens, dan heeft u “Big Data” .

“Big Data” gaat niet echt over het volume, het gaat over de kenmerken van de gegevens.

Reacties

• +1 Ik waardeer de stress die wordt uitgeoefend op big data niet over wat is de grootte , maar eerder over wat is de inhoud (kenmerken van) .
• Dat is een heel verfrissend perspectief. Ik heb dit nog nooit eerder gehoord, maar het is heel waar. Dit suggereert dat SQL- en NoSQL-technologieën niet concurrerend zijn, maar complementair.
• U ‘ praat over ongestructureerde data, niet over big data. Ongestructureerde gegevens leiden meestal tot NoSQL-oplossingen en big data in toepassingen, maar ze zijn nog steeds verschillend.
• Ik denk dat dit een goed zakelijk perspectief is van wat big data is, maar geeft geen antwoord op de specifieke vraag die nogal scherp is ” hoe groot is big data? ”

Zoals u terecht opmerkt, is “big data” tegenwoordig iets dat iedereen wil zeggen “te hebben”, wat een zekere losheid met zich meebrengt in de manier waarop mensen de term definiëren. “Ik zou zeggen dat je zeker te maken hebt met big data als de schaal zodanig is dat het niet langer haalbaar is om te beheren met meer traditionele technologieën zoals RDBMS, althans zonder ze aan te vullen met big data-technologieën zoals Hadoop.

Hoe groot uw gegevens eigenlijk moeten zijn, is omstreden. Hier is een (enigszins provocerende) blogpost die beweert dat dit niet echt het geval is voor minder dan 5 TB aan gegevens. (Voor alle duidelijkheid, het beweert niet “Minder dan 5 TB is geen” big data “, maar gewoon” Minder dan 5 TB is niet groot genoeg om Hadoop nodig te hebben “.)

Maar zelfs op kleinere datasets kunnen big data-technologieën zoals Hadoop andere voordelen hebben, waaronder goed geschikt zijn voor batchbewerkingen, goed spelen met ongestructureerde data (evenals data waarvan de structuur niet van tevoren bekend is of zou kunnen veranderen), horizontale schaalbaarheid (schalen door meer knooppunten toevoegen in plaats van uw bestaande servers te versterken), en (als een van de commentatoren op de hierboven gelinkte postnotities) de mogelijkheid om uw gegevensverwerking te integreren met externe gegevenssets (denk aan een map-reduce waar de mapper een oproep naar een andere server).Andere technologieën die verband houden met big data, zoals NoSql-databases, leggen de nadruk op snelle prestaties en consistente beschikbaarheid bij het omgaan met grote datasets, maar ook op de mogelijkheid om semi-ongestructureerde data te verwerken en horizontaal te schalen.

Natuurlijk , traditionele RDBMS hebben hun eigen voordelen, waaronder ACID-garanties (Atomiciteit, Consistentie, Isolatie, Duurzaamheid) en betere prestaties voor bepaalde bewerkingen, en zijn ook meer gestandaardiseerd, volwassener en (voor veel gebruikers) meer vertrouwd. Dus zelfs voor onbetwistbare “grote” gegevens, kan het zinvol zijn om ten minste een deel van uw gegevens in een traditionele SQL-database te laden en die te gebruiken in combinatie met big data-technologieën.

Dus een ruimere definitie zou zijn dat u over big data beschikt, zolang het maar groot genoeg is dat big data-technologieën een toegevoegde waarde voor u bieden. Maar zoals u kunt zien, kan dat niet alleen afhangen van de grootte van uw gegevens, maar ook van hoe u wilt werken ermee en wat voor soort vereisten u heeft in termen van flexibiliteit, consistentie en prestaties. Hoe u uw gegevens gebruikt, is relevanter voor de vraag dan waarvoor u ze gebruikt (bijv. datamining). Dat gezegd hebbende, is het waarschijnlijker dat toepassingen zoals datamining en machine learning nuttige resultaten opleveren als je een gegevensset hebt die groot genoeg is om mee te werken.

Opmerkingen

• Deze opmerking is bijna 5 jaar oud, en hoewel delen ervan nog steeds waar zijn, is de drempel van 5 TB van de blog die ik citeerde zeker niet t waar meer. Microsoft biedt bijvoorbeeld ” hyperscale ” SQL-databases van maximaal 100 TB: docs.microsoft.com/en-us/azure/sql-database/… Natuurlijk kan men aannemen dat veel organisaties met enorme SQL DBs ook Ik heb bijvoorbeeld een Spark-cluster om verschillende workloads te ondersteunen. Er ‘ s geen regel waarvoor u de een of de ander moet kiezen.

Totale hoeveelheid gegevens in de wereld: 2,8 zetabytes in 2012, geschat op 8 zetabytes in 2015 ( source ) en met een verdubbelingstijd van 40 maanden. Kan “niet groter worden dan dat 🙂

Als voorbeeld van een enkele grote organisatie: Facebook haalt 500 terabyte per dag binnen in een magazijn van 100 petabytes en voert er vanaf 2012 70.000 zoekopdrachten per dag op uit ( source ) Hun huidige magazijn is> 300 petabytes.

Big data is waarschijnlijk iets dat een goede fractie is van de Facebook-cijfers (1 / 100 waarschijnlijk wel, 1/10000 waarschijnlijk niet: het is een spectrum, geen enkel getal).

Naast de grootte zijn enkele van de kenmerken die het “groot” maken:

• het wordt actief geanalyseerd, niet alleen opgeslagen (citeer “Als je geen voordeel haalt uit big data, dan heb je geen big data, heb je gewoon een stapel data” Jay Parikh @ Facebook)

• het bouwen en runnen van een datawarehouse is een groot infrastructuurproject

• het groeit aanzienlijk

• het is ongestructureerd of heeft een onregelmatige structuur

Gartner-definitie: “Big data is een groot volume, hoge snelheid en / of een grote verscheidenheid aan informatie-assets die nieuwe vormen van verwerking vereisen “(The 3Vs) Dus ze denken ook dat” grootheid “niet alleen te maken heeft met de grootte van de dataset, maar ook met de snelheid en structuur en het soort tools dat nodig is. / p>

Reacties

• Als de totale hoeveelheid gegevens in de wereld elke 40 maanden verdubbelt, dan kan zeker groter worden dan dat. ; p
• Anderen beschrijven 4 V ‘ s van big data IBM of zelfs 5 V ‘ s DAVE BEULKE 2011
• De originele 3 V ‘ s zijn in 2001 opgesteld door Doug Laney 3D-gegevensbeheer: controle over gegevensvolume, snelheid en variatie .

Voor mij gaat Big Data in de eerste plaats over de tools (daar is het tenslotte mee begonnen); een “grote” dataset is er een die te groot is om met conventionele tools te worden verwerkt – in het bijzonder groot genoeg om opslag en verwerking op een cluster te eisen in plaats van op een enkele machine. Dit sluit een conventioneel RDBMS uit en vereist nieuwe technieken voor verwerking; in het bijzonder maken verschillende Hadoop-achtige frameworks het gemakkelijk om een berekening over een cluster te verdelen, ten koste van het beperken van de vorm van deze berekening. Ik “volg de verwijzing naar http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html ; Big Data-technieken zijn een laatste redmiddel voor datasets die gewoon te groot zijn om op een andere manier om te gaan. Ik zou zeggen dat elke dataset voor welk doel dan ook in aanmerking zou kunnen komen als deze groot genoeg was – maar als de vorm van het probleem zodanig is dat bestaande big data-tools niet geschikt zijn, zou het waarschijnlijk beter zijn om een nieuwe naam te bedenken.

Natuurlijk is er enige overlap; toen ik (kort) aan last.fm werkte, werkten we aan dezelfde 50TB-dataset met Hadoop en ook in een SQL-database op een redelijk belachelijke server (ik herinner me dat het 1TB RAM had, en dit is een paar jaar geleden). Wat in zekere zin betekende dat het zowel wel als geen big data was, afhankelijk van aan welke baan je werkte. Maar ik denk dat dat een nauwkeurige karakterisering is; de mensen die aan de Hadoop-banen werkten, vonden het nuttig om naar Big Data-conferenties en websites te gaan, terwijl de mensen die aan de SQL-banen werkten dat niet deden.

Gegevens worden “groot” wanneer een enkele commodity-computer niet langer de hoeveelheid gegevens kan verwerken die u heeft. Het geeft de punt waarop u moet gaan nadenken over het bouwen van supercomputers of het gebruik van clusters om uw gegevens te verwerken.

Big Data is gedefinieerd door de hoeveelheid gegevens, dat klopt, maar niet alleen. Het bijzondere van big data is dat u een lots van moet opslaan verschillende en soms ongestructureerde dingen alle keren en van een ton sensoren , meestal voor jaren of decennia .

Verder heb je iets schaalbaars nodig, zodat je er niet een half jaar de tijd om gegevens terug te vinden.

Dus hier is Big Data, waar de traditionele methode niet meer werkt. SQL is niet schaalbaar. En SQL werkt met zeer gestructureerde en gekoppelde gegevens (met alle die Primaire en externe sleutel puinhoop, innerlijke verbinding, overladen verzoek …).

In feite, omdat opslag goedkoper en goedkoper wordt en gegevens steeds waardevoller worden, vraagt een grote manager de technicus om alles op te nemen. deze tonnen nieuwe sensoren met al die mobiele, sociale netwerken, ingebedde dingen … enz. Dus aangezien klassieke methoden niet werken, moeten ze nieuwe technologieën vinden (alles opslaan in bestanden, in json-indeling, met grote index, wat we noSQL noemen).

Big Data kan dus erg groot zijn, maar kan niet zo groot zijn, maar complex, ongestructureerd of verschillende gegevens die snel en on-the-run in een onbewerkt formaat moeten worden opgeslagen. Eerst concentreren we ons en slaan we op, en dan kijken we hoe we alles aan elkaar kunnen koppelen.

Ik zal delen hoe Big Data is in genomics, in het bijzonder de-novo assembly.

Wanneer we sequencen uw genoom (bijvoorbeeld: detecteer nieuwe genen), we nemen miljarden korte reads van de volgende generatie. Kijk naar de afbeelding hieronder, waar we proberen een aantal leesbewerkingen samen te stellen.

Dit ziet er eenvoudig uit? Maar wat als je een miljard van die reads hebt? Wat als die reads sequentiefouten bevatten? Wat als uw RAM “niet genoeg geheugen heeft om de leesbewerkingen bij te houden? Hoe zit het met repetitieve DNA-gebieden, zoals het zeer algemene Alu-element ?

De-novo assembly wordt gedaan door een De-Bruijn-grafiek te construeren:

De grafiek is een slimme gegevensstructuur om overlappende metingen weer te geven. Het is niet perfect, maar het is “is beter dan het genereren van alle mogelijke overlappingen en ze in een array op te slaan.

Het assemblageproces kan dagen in beslag nemen, omdat er nogal wat paden zijn die een assembler zou moeten doorkruisen en instorten.

In genomics heb je big data wanneer:

• je niet alle combinaties bruut kunt forceren
• Je computer heeft niet genoeg fysiek geheugen om de gegevens op te slaan
• U moet de afmetingen verkleinen (bijv.: overtollige grafiekpaden ineenstorten)
• U wordt pissig omdat u “zou moeten wacht dagen om iets te doen
• U heeft een speciale gegevensstructuur nodig om de gegevens weer te geven
• U moet uw gegevensset filteren op fouten (bijvoorbeeld: sequentiefouten)

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

Er is iets speciaals aan het plotten van algoritmen, je originele vragen die dan speciaal maken, dat gaat over de mogelijkheid om de gegevens in wezen te partitioneren.

Voor sommige dingen, zoals het sorteren van getallen op een array, is het niet zo moeilijk om het probleem op de datastructuur in kleinere disjunctieve stukken te verdelen, bijv. Hier: Parallel in plaats samenvoegen sorteren

Voor grafiekalgoritmen is er echter de uitdaging dat het vinden van een optionele partitionering op een bepaalde grafische metriek bekend is $ NP-hard $ zijn.

Dus hoewel 10 GB aan te sorteren getallen een zeer goed benaderbaar probleem kan zijn op een normale pc (je kunt gewoon binnenkomen via dynamisch programmeren en een zeer goede voorspelbaarheid hebben over de programmastroom), werken met een grafiek van 10 GB datastructuur kan al door uitdagen.

Er zijn een aantal gespecialiseerde frameworks zoals GraphX die methoden en speciale rekenparadigmas gebruiken om de inherente uitdagingen van grafieken enigszins te omzeilen.

Dus om uw vraag kort te beantwoorden: zoals eerder door anderen is vermeld, als uw gegevens niet in het hoofdgeheugen op een normale pc passen, maar u alles nodig hebt om uw probleem te beantwoorden, is dit een goede hint dat uw gegevens zijn al een beetje groot. De exacte etikettering hangt echter een beetje af van de datastructuur en de gestelde vraag.

Ik denk dat big data begint op het punt waar de grootte je ervan weerhoudt te doen wat je wilt. In de meeste scenarios is er een limiet aan de looptijd die als haalbaar wordt beschouwd. In sommige gevallen is het een uur, in sommige gevallen kan het enkele weken duren. Zolang de gegevens niet groot genoeg zijn zodat alleen O (n) -algoritmen kunnen worden uitgevoerd binnen het haalbare tijdsbestek, heb je geen “big data” bereikt.

Ik vind deze definitie leuk omdat deze agnostisch is voor volume, technologieniveau en specifieke algoritmen. Het is niet agnostisch voor bronnen, dus een afgestudeerde student bereikt het punt van big data ver voor Google.

Om te kunnen kwantificeren hoe groot de gegevens zijn, wil ik houd rekening met de tijd die nodig is om er een back-up van te maken. Sinds de technologie vordert, zijn de volumes die enkele jaren geleden als groot werden beschouwd, nu gematigd. De back-uptijd verbetert naarmate de technologie verbetert, net als de looptijd van de leeralgoritmen. Ik denk dat het verstandiger is om over een dataset te praten, duurt het X uur om een back-up te maken en niet van een dataset van Y bytes.

PS.

Het is belangrijk op te merken dat zelfs als je het big data-punt bereikt en je kunt algoritmen van complexiteit niet meer dan O (n) op de ongecompliceerde manier uitvoeren, er is genoeg dat je kunt doen om nog steeds van een dergelijk algoritme te profiteren s.

Functieselectie kan bijvoorbeeld het aantal functies verminderen waarvan de looptijd van veel algoritmen afhangt. Bij veel lange staartdistributie kan het nuttig zijn om te focussen op de weinige items in het hoofd. Je kunt een sample gebruiken en daarop de langzamere algoritmen draaien.

Reacties

• Merk op dat de $ O (n) $ -barrière ook is geschonden nu in sommige domeinen van ML. Zie [ grigory.us/mpc-workshop-dimacs.html] voor de workshop over sublineaire algoritmen voor ML [1]: grigory.us/mpc-workshop-dimacs.html

Gegevens zijn “Big Data” als ze zo groot zijn dat het minder duur is om ze te analyseren op twee of meer standaardcomputers dan op één geavanceerde computer.

Dit is in wezen hoe Google “s” BigFiles “-bestandssysteem ontstond. Page en Brin konden zich geen chique Sun-server veroorloven om hun webindex op te slaan en te doorzoeken, dus sloten verschillende commodity-computers aan.

Ik ben het meestal eens met wat @Dan Levin al heeft gezegd. Omdat we uiteindelijk nuttige inzichten uit de gegevens willen halen in plaats van ze alleen op te slaan, is het “de het vermogen om algoritmen / systemen te leren die moeten bepalen wat “Big data” wordt genoemd. Naarmate ML-systemen evolueren, zal wat vandaag big data was, morgen niet langer big data zijn.

Een manier om big data te definiëren zou kunnen zijn:

• Big data : gegevens waarop u “geen ML-modellen kunt bouwen in redelijke tijd (1-2 uur) op een standaard werkstation (met zeg maar 4GB RAM)
• Niet-big data : aanvulling op bovenstaande

Ervan uitgaande dat deze definitie, zolang het geheugen dat wordt ingenomen door een individuele rij (alle variabelen voor een enkel gegevenspunt) niet groter is dan het machine-RAM, zouden we ons in de Niet-big data regime.

Opmerking: Vowpal Wabbit (verreweg het snelste ML-systeem tot nu toe) kan van elke dataset leren, zolang een individuele rij (datapunt) < RAM is (zeg 4 GB) . Het aantal rijen is geen beperking omdat het SGD op meerdere kernen gebruikt. Uit ervaring gesproken, je kunt een model trainen met 10.000 functies en 10MN rijen op een laptop per dag.

“Groot data is letterlijk gewoon veel data. Hoewel het meer een marketingterm is dan wat dan ook, is de implicatie meestal dat u over zoveel gegevens beschikt dat u niet alle gegevens tegelijk kunt analyseren, omdat de hoeveelheid geheugen (RAM) die nodig is om de gegevens op te slaan geheugen om het te verwerken en te analyseren is groter dan de hoeveelheid beschikbaar geheugen.

Dit betekent dat analyses meestal moeten worden gedaan op willekeurige gegevenssegmenten, waardoor modellen kunnen worden gebouwd om te vergelijken met andere delen van de gegevens.