Mekkora a nagy adat?

Nekem (jön relációs adatbázis háttérből), a “Big Data” nem elsősorban az adatméretről szól (ami a többi válasz eddigi legnagyobb része).

A “Big Data” és a “Bad Data” szorosan kapcsolódó. A relációs adatbázisok “érintetlen adatokat” igényelnek. Ha az adatok az adatbázisban vannak, akkor azok pontosak, tiszták és 100% -ban megbízhatóak. A relációs adatbázisok “nagy adatokra” igényelnek, és rengeteg időt, pénzt és elszámoltathatóságot fordítanak arra, hogy megbizonyosodjanak arról, hogy az adatok megfelelően felkészültek-e az adatbázisba történő betöltése előtt. Ha az adatok az adatbázisban vannak, akkor az “evangélium”, és meghatározza a rendszer rendszerszerű megértését.

A “Big Data” a másik irányból kezeli ezt a problémát. Az adatok nincsenek pontosan definiálva, nagy részük lehet pontatlan, és nagy részük valóban hiányozhat. Az adatok felépítése és elrendezése lineáris, szemben a relációs kapcsolatokkal.

A Big Data-nak elegendő mennyiségűnek kell lennie ahhoz, hogy a rossz vagy hiányzó adatok statisztikailag jelentéktelenné váljanak. Ha az adataiban előforduló hibák elég gyakoriak egymás törléséhez, amikor a hiányzó adatok arányosan elég kicsiek ahhoz, hogy elhanyagolhatóak legyenek, és amikor az adatokhoz való hozzáférési követelmények és algoritmusok működnek még hiányos és pontatlan adatok esetén is, akkor „Big Data” .

A “Big Data” nem igazán a mennyiségről szól, hanem az adatok jellemzőiről.

Megjegyzések

• +1 Nagyjából értékelem, hogy a nagy adatok miatt a stressz nem arról szól, hogy mekkora a méret , hanem inkább arról, hogy mi a tartalma (jellemzői) .
• Ez nagyon üdítő perspektíva. Ezt még soha nem hallottam, de nagyon igaz. Ez arra utal, hogy az SQL és a NoSQL technológiák nem versengőek, hanem kiegészítik egymást.
• Ön ‘ strukturálatlan adatokról beszél, nem pedig nagy adatokról. A strukturálatlan adatok általában NoSQL megoldásokhoz és big data-hoz vezetnek az alkalmazásban, de ezek még mindig különböznek egymástól.
• Úgy gondolom, hogy ez jó üzleti perspektíva a big data jelentésének, de nem válaszol a konkrét kérdésre, amely eléggé hangsúlyos ” mekkora a nagy adat? ”

Amint helyesen megjegyzed, manapság a “nagy adat” olyan dolog, amit mindenki mondani akar, ami megvan, ami bizonyos lazasággal jár abban, ahogyan az emberek meghatározzák a kifejezést. “azt mondhatjuk, hogy bizonyosan foglalkozik a big data-val, ha a méret olyan, hogy már nem lehet kezelni olyan hagyományosabb technológiákkal, mint például az RDBMS, legalábbis anélkül, hogy azokat kiegészítenénk olyan big data technológiákkal, mint a Hadoop.

Vitatható, hogy mekkora adatoknak kell lenniük ahhoz, hogy ez így legyen. Itt van egy (kissé provokatív) blogbejegyzés , amely azt állítja, hogy valójában nem ez az 5 TB-nál kevesebb adat. (Az egyértelműség kedvéért nem állítja, hogy kevesebb mint 5 TB nem “nagy adat”, de csak “kevesebb, mint 5 TB nem elég nagy ahhoz, hogy Hadoopra van szüksége”.)

De még kisebb adatkészleteknél a big data technológiák, mint például a Hadoop, más előnyökkel is járhatnak, többek között jól használhatók kötegelt műveletekhez, jól játszhatók strukturálatlan adatokkal (valamint olyan adatokkal, amelyek struktúrája nem ismert előre vagy változhat), horizontális méretezhetőséggel további csomópontok hozzáadása a meglévő szerverek megerősítése helyett), és (mint a fent hivatkozott bejegyzések egyik kommentelője) az adatfeldolgozás külső adatkészletekkel történő integrálásának képessége (gondoljon egy térképcsökkentésre, ahol a leképező egy hívjon egy másik szerverre).A nagy adatokhoz kapcsolódó egyéb technológiák, mint például a NoSql adatbázisok, a gyors teljesítményt és az állandó rendelkezésre állást hangsúlyozzák, miközben nagy adathalmazokkal foglalkoznak, valamint képesek kezelni a félig strukturálatlan adatokat és vízszintesen méretezni.

Természetesen , a hagyományos RDBMS-nek megvannak a maga előnyei, beleértve az ACID-garanciákat (atomosság, konzisztencia, izolálás, tartósság) és bizonyos műveletek jobb teljesítményét, valamint szabványosabbak, érettebbek és (sok felhasználó számára) jobban megismerhetők. Tehát még a vitathatatlanul “nagy” adatok esetében is van értelme betölteni az adatok legalább egy részét egy hagyományos SQL adatbázisba, és ezt a big data technológiákkal együtt használni.

Tehát, egy bőkezűbb meghatározás az lenne, hogy van nagy adata, amíg elég nagy ahhoz, hogy a nagy adattechnológiák bizonyos hozzáadott értéket biztosítsanak az Ön számára. De mint láthatja, ez nem csak az adatok méretétől, hanem attól is, hogy hogyan akar dolgozni, függhet. és milyen követelményei vannak a rugalmasság, a következetesség és a teljesítmény szempontjából. Az adatok felhasználásának módja a kérdés szempontjából relevánsabb, mint az, hogy mire használja őket (pl. adatbányászat). Ennek ellenére az olyan felhasználások, mint az adatbányászat és a gépi tanulás, nagyobb valószínűséggel hoznak hasznos eredményeket, ha elég nagy adatkészlet áll rendelkezésedre.

Megjegyzések

• Ez a megjegyzés csaknem 5 éves, és bár egyes részei még mindig igazak, az általam idézett blog 5 TB-os küszöbértéke bizonyosan nem t már nem igaz. Például a Microsoft ” hiperskála ” legfeljebb 100 TB méretű SQL DB-ket kínál: docs.microsoft.com/en-us/azure/sql-database/… Természetesen sok szervezetet feltételezhetünk hatalmas SQL DB-kkel is mondjuk van egy Spark-fürtje a különböző terhelések támogatására. ‘ nincs szabály, amelyet választania kell, egyiket vagy másikat.

Számomra a Big Data elsősorban az eszközökről szól (végül is ott kezdődött); egy “nagy” adatkészletről olyan, amely túl nagy ahhoz, hogy hagyományos eszközökkel kezelhető legyen – különösen elég nagy ahhoz, hogy egyetlen gép helyett fürtön tárolást és feldolgozást igényeljen. Ez kizárja a hagyományos RDBMS-t, és új technikákat követel meg a feldolgozáshoz; Különösen a Hadoop-szerű különféle keretrendszerek megkönnyítik a számítás szétosztását egy fürtön, ennek a számításnak a korlátozásával. Másodszor utalom a http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html hivatkozást; A Big Data technikák az utolsó megoldás az egyszerűen túl nagy adatkészletek számára bármilyen más módon kezelni. Azt mondanám, hogy bármilyen célú adatkészlet megfelelő lehet, ha elég nagy – bár ha a probléma formája olyan, hogy a meglévő “big data” eszközök nem megfelelőek, akkor valószínűleg jobb lenne hogy új nevet találjon ki.

Természetesen van némi átfedés; amikor (röviden) dolgoztam a last.fm-n, ugyanazon az 50 TB-os adatkészleten dolgoztunk a Hadoop segítségével, és egy SQL-adatbázisban is egy meglehetősen nevetséges szerveren (úgy emlékszem, 1 TB RAM-mal rendelkezett, és ez néhány évvel ezelőtt történt). Ami bizonyos értelemben azt jelentette, hogy mindkettő volt, és nem volt nagy adat, attól függően, hogy melyik munkakörön dolgozik. De azt hiszem, ez pontos jellemzés; azok az emberek, akik a Hadoop munkáin dolgoztak, hasznosnak találták a Big Data konferenciákra és webhelyekre való felkeresést, míg az SQL munkákon dolgozó emberek nem.

Az adatok akkor lesznek “nagyok”, ha egyetlen árucikk számítógép már nem tudja kezelni a rendelkezésére álló adatmennyiséget. amikor el kell kezdenie gondolkodni szuperszámítógépek építésén vagy fürtök használatán az adatok feldolgozásán.

A Big Data meghatározva az adatok mennyisége szerint ez igaz, de nem csak. A nagy adatok sajátossága, hogy tételeket tárolnia kell a különféle és néha strukturálatlan töm minden alkalommal és egy tonna érzékelőtől , általában évekre vagy évtizedekre .

Ezenkívül szükség van valami skálázhatóra, hogy ne vigyen el fél év az adatok visszakeresésére.

Tehát itt van a Big Data, ahol a hagyományos módszer már nem működik. Az SQL nem skálázható. És az SQL nagyon strukturált és összekapcsolt adatokkal működik (minden azokat az elsődleges és külföldi kulcsos rendetlenségeket, belső csatlakozásokat, beépített kéréseket …).

Alapvetően, mivel a tárolás olcsóbbá és olcsóbbá válik, az adatok pedig egyre értékesebbé válnak, a nagy menedzser felkéri a mérnököket, hogy mindent rögzítsenek. ez a rengeteg új érzékelő mindazokkal a mobil, közösségi hálózatokkal, beágyazott dolgokkal … stb. Tehát, mivel a klasszikus módszerek nem működnek, új technológiákat kell találniuk (mindent fájlokban, json formátumban, nagy indexű tárolással, amit noSQL-nek hívunk).

Tehát a Big Data nagyon nagy lehet, de lehet nem olyan nagy, de összetett strukturálatlan vagy különféle adatok, amelyeket gyorsan és futás közben kell tárolni nyers formátumban. Először összpontosítunk és tárolunk, majd megvizsgáljuk, hogyan lehet mindent összekapcsolni.

Megosztom, milyen a Big Data a genomikában, különös tekintettel a de novo összeállításra.

Mikor szekvenáljuk genomját (pl .: új gének kimutatása), a következő generáció rövid milliárdjait vesszük figyelembe. Nézze meg az alábbi képet, ahol megpróbálunk összeolvasni néhány olvasmányt.

Ez egyszerűnek tűnik? De mi van, ha milliárd ilyen olvasata van? Mi van, ha ezek az olvasások hibákat tartalmaznak? Mi van, ha a RAM-jának nincs elég memóriája az olvasás megőrzéséhez? Mi a helyzet az ismétlődő DNS-régiókkal, például a nagyon gyakori Alu Elemmel ?

De-novo összeállítás egy De-Bruijn-gráf felépítésével történik:

A grafikon ügyesen bányászott adatstruktúra, amely az átfedéseket tartalmazó olvasatokat ábrázolja. Nem tökéletes, de mégis “jobb, mint az összes lehetséges átfedést előállítani, és egy tömbben tárolni.

Az összeállítási folyamat napokig tarthat, mert sok olyan út van, amelyen az összeszerelőnek meg kell haladnia és összecsukódnia.

A genomikában nagy adatokkal rendelkezik, amikor:

• Nem lehet minden kombinációt durván erőltetni
• A számítógépének nincs elég fizikai memóriája az adatok tárolásához
• Csökkentenie kell a dimenziókat (pl .: redundáns gráfutak összecsukása)
• Piszkálódik, mert nem kell várjon napokat, hogy bármit megtehessen
• Az adatok ábrázolásához speciális adatstruktúrára van szükség
• Szűrnie kell az adatkészletet hibákra (pl .: szekvenálási hibák)

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

Különleges dolog az algoritmusok ábrázolása, Ön eredeti kérdéseket tesz, amelyek aztán különlegessé válnak, ami arról szól, hogy képes az adatok lényegében particionálni.

Bizonyos dolgok, például a tömbben lévő számok rendezése, nem túl nehéz az adatszerkezet problémáját kisebb disszjunktív darabokra felosztani, pl. Itt: Párhuzamos a helyeken egyesítés rendezése

A gráf algoritmusok esetében azonban az a kihívás, hogy egy opcionális particionálás megtalálása egy adott grafikus metrikán ismert hogy $ NP-kemény $.

Tehát míg a rendezni kívánt 10 GB-os szám nagyon jól megközelíthető probléma lehet egy normál számítógépen (dinamikus programozással csak be lehet lépni, és nagyon jól kiszámítható a program folyamata), egy 10 GB-os gráffal dolgozunk adatstruktúra már kihívással.

Számos speciális keretrendszer létezik, például a GraphX módszerekkel és speciális számítási paradigmákkal, amelyek némileg megkerülik a grafikonok eredendő kihívásait.

Tehát, hogy röviden válaszoljon a kérdésére: Amint azt mások már említették, amikor az adatai nem férnek el egy normál számítógép fő memóriájában, de minderre szükségünk van a probléma megválaszolásához, jó tipp arra, az adatok már kissé nagyok. A pontos címkézés azonban attól függ, hogy kicsit gondolkodom az adatszerkezeten és a feltett kérdésen.

Úgy gondolom, hogy a nagy adat ott kezdődik, hogy a méret megakadályozza abban, hogy azt csináld, amit szeretnél. A legtöbb esetben a futási időnek van egy korlátja, amelyet megvalósíthatónak tartanak. Bizonyos esetekben ez egy óra, egyes esetekben néhány hét lehet. Amíg az adatok nem elég nagyok ahhoz, hogy csak az O (n) algoritmusok fussanak a megvalósítható időkeretben, addig nem értek el nagy adatokat.

Tetszik ez a meghatározás, mivel agnosztikus a kötetre, technológiai szint és specifikus algoritmusok. Az erőforrások szempontjából nem agnosztikus, így egy évfolyamos hallgató eléri a big data módját a Google előtt.

Annak érdekében, hogy számszerűsíteni tudjam, mekkora az adat, szeretem vegye figyelembe a mentéshez szükséges időt. Mivel a technológia fejlődik, a néhány évvel ezelőtt nagynak tekintett kötetek már mérsékeltek. A mentési idő javul, ahogy a technológia javul, ahogyan a tanulási algoritmusok futási ideje is. Úgy érzem, hogy ésszerűbb Ha egy adatkészletről beszélünk, a mentéshez X óra szükséges, nem pedig az Y bájtokból.

PS.

Fontos megjegyezni, hogy még akkor is, ha elérte a nagy adatpontot és az O (n) -nél nagyobb komplexitású algoritmusokat nem lehet egyenesen futtatni, rengeteg mindent megtehet annak érdekében, hogy még mindig élvezhesse az ilyen algoritmus előnyeit s.

Például a Funkcióválasztás csökkentheti azoknak a szolgáltatásoknak a számát, amelyektől sok algoritmus futási ideje függ. Sok hosszú farok eloszlásban előnyös lehet a fej néhány elemének összpontosítása. Használhat egy mintát, és futtathatja rajta a lassabb algoritmusokat.

Megjegyzések

• Vegye figyelembe, hogy a $ O (n) $ korlátot is megsértették most az ML egyes területein. Lásd a [ grigory.us/mpc-workshop-dimacs.html] című részt az ML szublináris algoritmusainak műhelyéről [1]:

Az adatok “nagy adatok”, ha olyan volumenűek, hogy olcsóbb két vagy több árucikk-számítógépen elemezni, mint egy csúcskategóriás számítógépen.

A Google lényegében így “s” BigFiles “fájlrendszer keletkezett. Page és Brin nem engedhette meg maguknak, hogy egy divatos Sun szerver tárolja és keresgéljen webes indexükben, ezért több árucikk számítógépet csatlakoztatott

Hajlamos vagyok egyetérteni azzal, amit @Dan Levin már elmondott. Végül, mivel hasznos betekintést szeretnénk meríteni az adatokból, nem csak tárolni, ezért a algoritmusok / rendszerek tanulási képessége amelynek meg kell határoznia az úgynevezett “nagy adatot”. Ahogy az ML rendszerek fejlődnek, a mai nagy adat ma már nem lesz nagy adat.

A Big Data meghatározásának egyik módja lehet:

• Nagy adatok : Olyan adatok, amelyekre nem lehet ML modelleket felépíteni ésszerű idő (1-2 óra) alatt egy tipikus munkaállomáson (mondjuk 4 GB RAM-mal)
• Nem nagy adat : a fentiek kiegészítése

Feltételezve ezt a meghatározást, mindaddig, amíg az egyes sorok által elfoglalt memória (egyetlen adatpont összes változója) nem haladja meg a gép RAM-ját, a Nem nagy adatok rezsim.

Megjegyzés: Vowpal A Wabbit (a mai napig messze a leggyorsabb ML rendszer) képes bármilyen adatsorozatról tanulni, amennyiben egy adott sor (adatpont) < RAM (mondjuk 4 GB) . A sorok száma nem korlátozás mert több magon használja az SGD-t. Tapasztalatból elmondható, hogy egy laptopon 10k funkciókkal és 10MN sorokkal rendelkező modellt képezhet ki egy nap alatt.

“Nagy adatok “szó szerint csak sok adat. Bár ez inkább egy marketing kifejezés, mint bármi más, ennek általában az a következménye, hogy annyi adata van, hogy nem tudja egyszerre elemezni az összes adatot, mert a memória (RAM) mennyisége az adatok tárolásához szükséges feldolgozásához és elemzéséhez szükséges memória nagyobb, mint a rendelkezésre álló memória mennyisége.

Ez azt jelenti, hogy az elemzéseket általában véletlenszerű adatszegmenseken kell elvégezni, ami lehetővé teszi a modellek felépítését az adatok más részeivel való összehasonlításhoz.