Kuinka iso on iso data?

Minulle (tulossa relaatiotietokannan taustasta), ”Big Data” ei koske ensisijaisesti datan kokoa (mikä on suurin osa muista vastauksista tähän mennessä).

”Big Data” ja ”Bad Data” ovat läheistä sukua. Relaatiotietokannat edellyttävät ”koskemattomia tietoja”. Jos tiedot ovat tietokannassa, ne ovat tarkkoja, puhtaita ja 100% luotettavia. Relaatiotietokannat edellyttävät ”suurta dataa” ja valtava määrä aikaa, rahaa ja vastuullisuutta käytetään varmistaaksesi, että tiedot ovat hyvin valmistautuneet ennen niiden lataamista tietokantaan. Jos data on tietokannassa, se on ”evankeliumia” ja se määrittää järjestelmän ymmärryksen todellisuudesta.

”Big Data” käsittelee tätä ongelmaa toisesta suunnasta. Tiedot on määritelty huonosti, suuri osa niistä voi olla epätarkkoja, ja suuri osa niistä voi itse asiassa puuttua. Tietojen rakenne ja asettelut ovat lineaariset toisin kuin relaatiot.

Suurilla tiedoilla on oltava riittävä määrä, jotta huonojen tai puuttuvien tietojen määrä muuttuu tilastollisesti merkityksettömäksi. Kun tietojesi virheet ovat riittävän yleisiä toistensa peruuttamiseksi, kun puuttuvat tiedot ovat suhteellisen pieniä niin, että ne ovat vähäpätöisiä ja kun tiedonsiirtovaatimuksesi ja algoritmit toimivat jopa epätäydellisten ja epätarkkojen tietojen kanssa, sinulla on ”iso data” .

”Big Data” ei koske oikeastaan määrää, vaan tietojen ominaisuuksia.

Kommentit

• +1 Arvostan melkein suurten datojen aiheuttamaa stressiä siitä, että mikä on koko , ja pikemminkin siitä, mikä on sisällön (ominaisuudet) .
• Se on erittäin virkistävä näkökulma. En ole koskaan kuullut tätä ennen, mutta se on totta. Tämä viittaa siihen, että SQL- ja NoSQL-tekniikat eivät ole kilpailevia, vaan täydentäviä.
• Puhut ’ strukturoimattomasta datasta, ei suuresta datasta. Strukturoimaton data johtaa yleensä NoSQL-ratkaisuihin ja sovellusten suuriin tietoihin, mutta ne ovat silti erilaisia.
• Mielestäni tämä on hyvä liiketoimintanäkymä big data -asiakirjoista, mutta ei vastaa tarkasti esitettyyn kysymykseen ” kuinka suuri iso data on? ”

Kuten oikein huomautat, näinä päivinä ”big data” on asia, jonka kaikki haluavat sanoa saaneensa, mikä merkitsee tiettyä löyhyyttä siitä, miten ihmiset määrittelevät termin. Yleensä kuitenkin ”Sanon, että olet varmasti tekemisissä big datan kanssa, jos mittakaava on sellainen, että sitä ei ole enää mahdollista hallita perinteisemmillä tekniikoilla, kuten RDBMS: llä, ainakaan täydentämättä niitä suurilla datatekniikoilla, kuten Hadoop.

Kuinka suuri tietojesi on todellisuudessa oltava, jotta näin voi olla, on kiistanalainen. Tässä on (hieman provosoiva) -blogiviesti , joka väittää, että näin ei ole oikeastaan alle 5 Tt: n datan kohdalla. (Selvyyden vuoksi se ei väitä, että alle 5 Tt ei ole ”suuria tietoja”, mutta vain ”Alle 5 Tt ei ole riittävän suuria, jotta tarvitset Hadoopia”.)

Mutta jopa Pienemmissä tietojoukoissa suurilla tietotekniikoilla, kuten Hadoopilla, voi olla muita etuja, mukaan lukien se, että ne soveltuvat hyvin eräoperaatioihin, pelaavat hyvin strukturoimattomilla tiedoilla (samoin kuin tiedoilla, joiden rakennetta ei tiedetä etukäteen tai jotka voisivat muuttua), horisontaalinen skaalattavuus lisäämällä uusia solmuja sen sijaan, että parannat nykyisiä palvelimiasi) ja (yhtenä ylläolevien linkkien kommentoijista) kyky integroida tietojenkäsittelysi ulkoisiin tietojoukkoihin (ajattele kartan vähennystä, missä kartoittaja tekee puhelu toiselle palvelimelle).Muut suuriin tietoihin liittyvät tekniikat, kuten NoSql-tietokannat, korostavat nopeaa suorituskykyä ja tasaista saatavuutta käsitellessään suuria tietojoukkoja sekä pystyvän käsittelemään puolirakentamattomia tietoja ja mittakaavassa vaakasuoraan.

Tietysti , perinteisillä RDBMS: llä on omat etunsa, mukaan lukien ACID-takuut (atomisuus, johdonmukaisuus, eristäminen, kestävyys) ja parempi suorituskyky tietyissä toiminnoissa sekä standardoidumpi, kypsempi ja (monille käyttäjille) tutumpi. Joten jopa kiistattomasti ”isojen” tietojen kohdalla voi olla järkevää ladata ainakin osa tiedoistasi perinteiseen SQL-tietokantaan ja käyttää sitä yhdessä big data -tekniikoiden kanssa.

Joten, antelias määrittely olisi, että sinulla on isot tiedot niin kauan kuin ne ovat riittävän suuria, jotta isot tietotekniikat tarjoavat sinulle lisäarvoa. Mutta kuten näette, se voi riippua paitsi datasi koosta myös siitä, miten haluat työskennellä sen kanssa ja millaisia vaatimuksia sinulla on joustavuuden, johdonmukaisuuden ja suorituskyvyn suhteen. Kuinka tietojasi käytetään, on merkityksellisempää kysymykseen kuin mihin sitä käytät mihin (esim. tiedonlouhinta). Tästä huolimatta sellaiset käyttötavat kuin tiedonlouhinta ja koneoppiminen tuottavat todennäköisemmin hyödyllisiä tuloksia, jos sinulla on tarpeeksi suuri tietojoukko, jota voit käyttää.

Kommentit

• Tämä kommentti on melkein 5 vuotta vanha, ja vaikka osa siitä on edelleen totta, lainaamani blogin 5 teratavun kynnys ei todellakaan ole ei ole enää totta. Esimerkiksi Microsoft tarjoaa ” hyperscale ” Enintään 100 Tt: n SQL-DB: t: docs.microsoft.com/en-us/azure/sql-database/… Tietenkin voidaan olettaa, että monet organisaatiot, joilla on valtavat SQL-tietokannat, myös Minulla on esimerkiksi Spark-klusteri tukemaan erilaisia kuormituksia. Siellä ’ ei ole sääntöä, että sinun on valittava yksi tai toinen.

Minulle Big Data koskee ensisijaisesti työkaluja (loppujen lopuksi siitä, mistä se alkoi); ”iso” tietojoukko on sellainen, joka on liian suuri käsiteltäväksi tavanomaisilla työkaluilla – etenkin tarpeeksi suuri vaatiakseen varastointia ja käsittelyä klusterissa eikä yhdellä koneella. Tämä sulkee pois tavanomaisen RDBMS: n ja vaatii uusia tekniikoita käsittelyyn; Erityisesti erilaiset Hadoopin kaltaiset kehykset tekevät laskennan jakamisesta klusterille helppoa kustannuksella, joka rajoittaisi tämän laskennan muotoa. Toistan viittauksen http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html ; Big Data -tekniikat ovat viimeinen keino yksinkertaisesti liian suurille tietojoukoille sanoisin, että mikä tahansa tietojoukko mihin tahansa tarkoitukseen voisi olla kelvollinen, jos se olisi riittävän suuri – vaikka jos ongelman muoto on sellainen, että olemassa olevat ”big data” -työkalut eivät ole sopivia, niin se olisi todennäköisesti parempi keksimään uuden nimen.

Tietysti on jonkin verran päällekkäisyyksiä; kun työskentelin (lyhyesti) last.fm, työskentelimme samalla 50 Tt: n tietojoukolla Hadoopin avulla ja myös SQL-tietokannassa melko naurettavalla palvelimella (muistan, että siinä oli 1 Tt RAM-muistia, ja tämä on muutama vuosi sitten). Mikä tavallaan tarkoitti sitä, että se oli ja ei ollut isoa dataa, riippuen siitä, mitä työtä työskentelitte. Mutta luulen, että se on tarkka kuvaus; Hadoop-töiden parissa työskentelevien ihmisten mielestä oli hyödyllistä käydä Big Data -konferensseissa ja verkkosivustoilla, kun taas SQL-työpaikoilla työskentelevät eivät tienneet.

Tiedot muuttuvat ”suuriksi”, kun yksittäinen hyödyketietokone ei enää pysty käsittelemään sinulla olevaa datamäärää. Se tarkoittaa kohta, jossa sinun on alettava ajatella supertietokoneiden rakentamista tai klustereiden käyttöä tietojen käsittelemiseksi.

Big Data on määritelty tietojen määrän mukaan, se on oikein, mutta ei vain. Suurten tietojen erityispiirre on, että sinun on tallennettava -erät / erilaisia ja joskus jäsentämättömiä stuffs aina ja tonnilta antureita , yleensä vuosien tai vuosikymmenen ajan .

Tarvitset lisäksi jotain skaalautuvaa, jotta se ei vie sinua puoli vuotta tietojen palauttamiseksi.

Joten tässä on Big Data, jossa perinteinen menetelmä ei enää toimi. SQL ei ole skaalautuva. Ja SQL toimii hyvin jäsennellyn ja linkitetyn datan kanssa (kaikkien ne ensisijaisen ja ulkomaisen avaimen sotku, sisäinen liitos, imbrikoitu pyyntö …).

Pohjimmiltaan, koska varastointi on halvempaa ja dataa arvokkaampaa, iso johtaja pyytää insinööriä tallentamaan kaiken. Lisää tämä tonnia uusia antureita, joissa on kaikki mobiili-, sosiaalinen verkosto, upotetut jutut … jne. Joten kun klassiset menetelmät eivät toimi, heidän on löydettävä uusia tekniikoita (kaiken tallentaminen tiedostoihin, json-muodossa, suurella indeksillä, jota kutsumme noSQL: ksi).

Joten Big Data voi olla hyvin iso, mutta voi olla niin iso, mutta monimutkainen strukturoimaton tai erilaisia tietoja, jotka on tallennettava nopeasti ja ajon aikana raakamuodossa. Aluksi keskitymme ja tallennamme ja sitten tarkastelemme, miten kaikki linkitetään yhteen.

Jaan millainen Big Data on genomiikassa, erityisesti de novo -kokoonpanossa.

Milloin sekvensoimme genomisi (esimerkiksi: tunnista uudet geenit), otamme miljardeja seuraavan sukupolven lyhyitä lukuja. Katso alla olevaa kuvaa, jossa yritämme koota joitain lukuja.

Tämä näyttää yksinkertaiselta? Mutta entä jos sinulla on miljardi näistä lukemista? Entä jos nämä lukut sisältävät järjestysvirheitä? Entä jos RAM-muistissasi ei ole tarpeeksi muistia lukemien säilyttämiseksi? Entä toistuvat DNA-alueet, kuten hyvin yleinen Alu-elementti ?

De-novo-kokoonpano tehdään rakentamalla De-Bruijn-kaavio :

Kaavio on fiksusti kaivettu tietorakenne, joka edustaa päällekkäisiä lukuja. Se ei ole täydellinen, mutta se ”on parempi kuin luoda kaikki mahdolliset päällekkäisyydet ja tallentaa ne matriisiin.

Kokoonpanoprosessin suorittaminen voi kestää päiviä, koska kokoonpanijan on kuluttava melko monta polkua ja romahdettava.

Genomiikassa sinulla on iso data, kun:

• Et voi yhdistää kaikkia yhdistelmiä
• Tietokoneellasi ei ole tarpeeksi fyysistä muistia tietojen tallentamiseksi
• Sinun on pienennettävä mittasuhteita (esim. redundanttien kaavion polkujen romahtaminen)
• Sinua kiusaa, koska sinun ei tarvitse odota päiviä tehdäksesi mitään
• Tarvitset erityisen tietorakenteen tietojen esittämiseksi
• Sinun on suodatettava tietojoukko virheiden (esim. sekvensointivirheiden) varalle

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

Algoritmien piirtämiseen on erityinen asia, sinä alkuperäiset kysymykset, jotka tekevät sitten erityisiksi, eli hänen kyvystään osioida tiedot olennaisesti.

Joissakin asioissa, kuten taulukon numeroiden lajittelussa, ei ole liian vaikeaa jakaa datarakenteen ongelmaa pienempiin disjunktiivisiin kappaleisiin, esim. Tässä: Rinnakkainen paikalla yhdistämisen lajittelu

Kaavioalgoritmeille on kuitenkin haaste, että valinnaisen osion löytäminen tietylle graafiselle tunnukselle tunnetaan olla $ NP-vaikea $.

Vaikka 10 Gt: n lajiteltavat numerot saattavat olla hyvin lähestyttävä ongelma normaalilla tietokoneella (voit vain päästä sisään dynaamisen ohjelmoinnin avulla ja sinulla on erittäin hyvä ennustettavuus ohjelmavirrasta), työskentely 10 Gt: n kaavion kanssa tietorakenne voi jo haastaa.

On olemassa useita erikoistuneita kehyksiä, kuten GraphX , jotka käyttävät menetelmiä ja erityisiä laskentaparadigmoita kiertääkseen kuvaajien luontaisia haasteita.

Joten vastaamaan kysymykseesi lyhyesti: Kuten muut ovat aiemmin maininneet, kun tietosi eivät mahdu normaalin tietokoneen päämuistiin, mutta tarvitset niitä kaikkia vastaamaan ongelmasi, on hyvä vihje, että data on jo jonkin verran suurta. Tarkka merkintä riippuu kuitenkin mielestäni hieman tietorakenteesta ja esitetystä kysymyksestä.

Luulen, että big data alkaa pisteestä, jossa koko estää sinua tekemästä mitä haluat. Useimmissa tilanteissa ajoajalle on asetettu raja, jota pidetään toteutettavissa. Joissakin tapauksissa se on tunti, joissakin tapauksissa se voi olla muutama viikko. Niin kauan kuin tiedot eivät ole riittävän suuria, jotta vain O (n) -algoritmit voisivat toimia toteutettavissa olevassa aikataulussa, et saavuttanut isoja tietoja.

Pidän tästä määritelmästä, koska se on agnostinen äänenvoimakkuuden suhteen, Teknologiataso ja tietyt algoritmit. Resursseille ei ole agnostista, joten grad-opiskelija saavuttaa big data -tieteen ennen Googlea.

Jotta voin mitata datan suuruutta, haluan harkitse sen varmuuskopiointiin tarvittavaa aikaa. Koska tekniikka on edennyt, vuosia sitten suuriksi pidetyt volyymit ovat nyt kohtuullisia. Varmuuskopiointiaika paranee, kun tekniikka paranee, samoin kuin oppimisalgoritmien ajoaika. Minusta on järkevämpää Jos haluat puhua tietojoukosta, varmuuskopiointi vie X tuntia eikä Y-tavujen tietojoukkoa.

PS.

On tärkeää huomata, että vaikka saavutitkin ison datapisteen etkä voi käyttää monimutkaisia algoritmeja enemmän kuin O (n) suoralla tavalla, voit tehdä paljon voidaksesi silti hyötyä tällaisesta algoritmista s.

Esimerkiksi ominaisuuksien valinta voi vähentää niiden ominaisuuksien määrää, joista useiden algoritmien ajoaika riippuu. Monissa pitkän hännän jakaumassa keskittyminen muutamaan päähän olevaan kohtaan saattaa olla hyödyllistä. Voit käyttää näytettä ja suorittaa siinä hitaammat algoritmit.

Kommentit

• Huomaa, että myös $ O (n) $ -estettä on rikottu. nyt joillakin ML: n aloilla. Katso [ grigory.us/mpc-workshop-dimacs.html] ML-tason alitasoisten algoritmien työpaja [1]:

Tiedot ovat ”suuria tietoja”, jos ne ovat niin suuria, että niiden analysointi kahdessa tai useammassa hyödyketietokoneessa on halvempaa kuin yhdessä huipputietokoneessa.

Google ”pohjimmiltaan näin” BigFiles ”-tiedostojärjestelmä on syntynyt. Sivulla ja Brinillä ei ollut varaa hienoon Sun-palvelimeen tallentaa ja hakea heidän verkkohakemistonsa, joten liitit useita hyödyketietokoneita

”Iso data ”on kirjaimellisesti vain paljon tietoa. Vaikka se onkin enemmän markkinointitermi kuin mikään muu, seurauksena on yleensä, että sinulla on niin paljon tietoa, että et voi analysoida kaikkia tietoja kerralla, koska muistin (RAM) määrä, joka tietojen pitämiseen tarvitaan muisti sen käsittelemiseksi ja analysoimiseksi on suurempi kuin käytettävissä olevan muistin määrä.

Tämä tarkoittaa, että analyysit on yleensä tehtävä satunnaisilla tietosegmenteillä, mikä mahdollistaa mallien rakentamisen vertailemaan tietoja muihin osiin.