Cât de mare este Big Data?

Pentru mine (vine dintr-o bază de date relațională), „Big Data” nu se referă în primul rând la dimensiunea datelor (care reprezintă cea mai mare parte a celorlalte răspunsuri de până acum).

„Big Data” și „Bad Data” sunt strans legate. Bazele de date relaționale necesită „date curate”. Dacă datele se află în baza de date, acestea sunt corecte, curate și 100% fiabile. Bazele de date relaționale necesită „date minunate” și o cantitate imensă de timp, bani și responsabilitate este asigurată pentru a vă asigura că datele sunt bine pregătite înainte de a le încărca în baza de date. Dacă datele sunt în baza de date, acestea sunt „evanghelie” și definește înțelegerea realității de către sistem.

„Big Data” abordează această problemă din cealaltă direcție. Datele sunt slab definite, o mare parte din acestea pot fi inexacte și multe din ele pot lipsi. Structura și aspectul datelor sunt liniare, spre deosebire de relaționale.

Big Data trebuie să aibă suficient volum, astfel încât cantitatea de date rele sau datele lipsă să devină nesemnificative statistic. Când erorile din datele dvs. sunt destul de comune pentru a se anula reciproc, când datele lipsă sunt proporțional suficient de mici pentru a fi neglijabile și când cerințele și algoritmii de acces la date sunt funcționale chiar și cu date incomplete și inexacte, atunci aveți „Big Data” .

„Big Data” nu ține de volum, ci de caracteristicile datelor.

Comentarii

• +1 Apreciez destul de mult stresul cauzat de datele mari, nu referitor la care este dimensiunea și mai degrabă la care este conținutul (caracteristicile) .
• Aceasta este o perspectivă foarte răcoritoare. Nu am mai auzit acest lucru până acum, dar este foarte adevărat. Acest lucru sugerează că tehnologiile SQL și NoSQL nu sunt competitive, ci complementare.
• Vor ‘ vorbiți despre date nestructurate, nu despre date mari. Datele nestructurate conduc de obicei la soluții NoSQL și date mari în aplicație, dar acestea sunt încă diferite.
• Cred că aceasta este o perspectivă de afaceri bună despre ceea ce este Big Data, dar nu răspunde la întrebarea specifică, care este destul de accentuată ” cât de mare este big data? ”

După cum ați observat pe bună dreptate, în zilele noastre „big data” este ceva ce toată lumea vrea să spună că „are”, ceea ce implică o anumită relaxare în modul în care oamenii definesc termenul. În general, totuși, eu „Aș spune că aveți cu siguranță de-a face cu big data dacă scara este de așa natură încât nu mai este fezabilă gestionarea cu tehnologii mai tradiționale precum RDBMS, cel puțin fără a le completa cu tehnologii de big data, cum ar fi Hadoop.

Cât de mari trebuie să fie datele dvs. pentru ca acesta să fie cazul este discutabil. Aici este o (oarecum provocatoare) postare de blog care susține că nu este chiar cazul pentru mai puțin de 5 TB de date. (Pentru a fi clar, nu pretinde „Mai puțin de 5 TB nu sunt” date mari „, ci doar” Mai puțin de 5 TB nu este suficient de mare încât să aveți nevoie de Hadoop „.)

Dar chiar pe seturi de date mai mici, tehnologiile de date mari, cum ar fi Hadoop, pot avea alte avantaje, inclusiv faptul că sunt foarte potrivite pentru operațiile de lot, se joacă bine cu date nestructurate (precum și date a căror structură nu este cunoscută în prealabil sau s-ar putea modifica), scalabilitate orizontală (scalare de adăugarea mai multor noduri în loc de îmbunătățirea serverelor existente) și (ca unul dintre comentatorii la notele postate mai sus-conectate) capacitatea de a vă integra procesarea datelor cu seturi de date externe (gândiți-vă la o reducere a hărții în care mapatorul face o apel la alt server).Alte tehnologii asociate cu datele mari, cum ar fi bazele de date NoSql, subliniază performanța rapidă și disponibilitatea consecventă în timp ce se ocupă de seturi mari de date, precum și posibilitatea de a gestiona date semi-nestructurate și de a scala pe orizontală.

Desigur , RDBMS tradiționale au propriile avantaje, inclusiv garanții ACID (atomicitate, consistență, izolare, durabilitate) și performanțe mai bune pentru anumite operațiuni, precum și mai standardizate, mai mature și (pentru mulți utilizatori) mai familiare. Deci, chiar și pentru datele incontestabil „mari”, ar putea avea sens să încărcați cel puțin o parte din datele dvs. într-o bază de date SQL tradițională și să o utilizați împreună cu tehnologiile de date mari.

Deci, o definiție mai generoasă ar fi că aveți date mari atât timp cât este suficient de mare încât tehnologiile de date mari să vă ofere o valoare adăugată. Dar, după cum puteți vedea, acest lucru poate depinde nu doar de dimensiunea datelor dvs., ci de modul în care doriți să lucrați cu el și ce fel de cerințe aveți în ceea ce privește flexibilitatea, consistența și performanța. Cum vă folosiți datele este mai relevant pentru întrebare decât pentru ce îl utilizați pentru (de exemplu, extragerea datelor). Acestea fiind spuse, utilizările precum extragerea datelor și învățarea automată au mai multe șanse să dea rezultate utile dacă aveți un set de date suficient de mare pentru a lucra.

Comentarii

• Acest comentariu are aproape 5 ani și, deși părți din el sunt încă adevărate, pragul de 5 TB de pe blogul pe care l-am citat nu este cu siguranță nu mai este adevărat. De exemplu, Microsoft oferă ” hiperscale ” DB SQL de până la 100 TB: docs.microsoft.com/en-us/azure/sql-database/… Desigur, se pot presupune multe organizații cu DB-uri SQL uriașe și Am, să zicem, un cluster Spark pentru a susține diferite sarcini de lucru. ‘ nu există nicio regulă pe care trebuie să o alegeți una sau alta.

Pentru mine Big Data este în primul rând despre instrumente (la urma urmei, de unde a început); un set de date „mare” este una care este prea mare pentru a putea fi manipulată cu scule convenționale – în special, suficient de mare pentru a solicita stocarea și procesarea pe un cluster, mai degrabă decât pe o singură mașină. Aceasta exclude un RDBMS convențional și necesită noi tehnici de procesare; în special, diferite cadre de tip Hadoop facilitează distribuirea unui calcul pe un cluster, cu costul restricționării formei acestui calcul. Voi secunda trimiterea la http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html ; tehnicile Big Data sunt o ultimă soluție pentru seturile de date care sunt pur și simplu prea mari pentru a gestiona orice alt mod. Aș spune că orice set de date pentru orice scop s-ar putea califica dacă ar fi suficient de mare – deși dacă forma problemei este de așa natură încât instrumentele de „date mari” existente nu sunt adecvate, atunci ar fi probabil mai bine pentru a veni cu un nume nou.

Desigur, există unele suprapuneri; când am lucrat (pe scurt) la last.fm, am lucrat la același set de date de 50TB folosind Hadoop și, de asemenea, într-o bază de date SQL pe un server destul de ridicol (îmi amintesc că avea 1TB RAM, și asta este acum câțiva ani). Ceea ce, într-un anumit sens, a însemnat și nu a fost și nu a fost o mare informație, în funcție de jobul la care lucrați. Dar cred că este o caracterizare exactă; persoanele care au lucrat la joburile Hadoop au găsit util să meargă la conferințe și site-uri web Big Data, în timp ce persoanele care au lucrat la joburile SQL nu au făcut-o.

Datele devin „mari” atunci când un singur computer de marfă nu mai poate gestiona cantitatea de date pe care o aveți. moment în care trebuie să începeți să vă gândiți la construirea de supercalculatoare sau la utilizarea clusterelor pentru a vă procesa datele.

Big Data este definită după volumul de date, este corect, dar nu numai. Particularitatea datelor mari este că trebuie să stocați un loturi din diverse și uneori nestructurate elemente de fiecare dată și dintr-o tone de senzori , de obicei de ani sau decenii .

În plus, aveți nevoie de ceva scalabil, astfel încât să nu vă ia jumătate de an pentru a găsi date înapoi.

Deci, aici vin Big Data, unde metoda tradițională nu mai funcționează. SQL nu este scalabil. Și SQL funcționează cu date foarte structurate și legate (cu toate acele mizerie cheie primară și străină, interioară, cerere imbricată …).

Practic, deoarece stocarea devine din ce în ce mai ieftină și datele devin din ce în ce mai valoroase, managerul mare cere inginerului să înregistreze totul. o mulțime de senzori noi cu toate acele mobile, rețele sociale, lucruri încorporate … etc. Deci, deoarece metodele clasice nu funcționează, trebuie să găsească noi tehnologii (stocarea totul în fișiere, în format json, cu index mare, ceea ce numim noSQL).

Deci Big Data poate fi foarte mare, dar nu pot fi atât de mari, dar complexe, nestructurate sau diverse date, care trebuie stocate rapid și pe fugă într-un format brut. Ne concentrăm și stocăm la început, apoi ne uităm la cum să legăm totul împreună.

Voi împărtăși cum este Big Data în genomică, în special asamblarea de-novo.

Când îți secvenționăm genomul (de exemplu: detectăm gene noi), luăm miliarde de lecturi scurte de generația următoare. Uită-te la imaginea de mai jos, unde încercăm să asamblăm câteva citiri.

Arată simplu? Dar dacă aveți miliarde de citiri? Ce se întâmplă dacă aceste citiri conțin erori de secvență? Ce se întâmplă dacă memoria RAM nu are suficientă memorie pentru a păstra citirile? Dar regiunile ADN repetitive, cum ar fi elementul Alu foarte frecvent?

Asamblarea de-novo se realizează prin construirea unui grafic De-Bruijn :

Graficul este o structură de date minată inteligent pentru a reprezenta citiri suprapuse. Nu este perfect, dar este „Este mai bine decât să generați toate suprapunerile posibile și să le stocați într-o matrice.

Procesul de asamblare ar putea dura câteva zile pentru a fi finalizat, deoarece există un număr destul de mare de căi pe care un asamblor ar trebui să le parcurgă și să le prăbușească.

În genomică, aveți date mari când:

• Nu puteți „forța brută toate combinațiile
• Computerul dvs. nu are suficientă memorie fizică pentru a stoca datele
• Trebuie să reduceți dimensiunile (de exemplu: colapsarea căilor grafice redundante)
• Vă supărați pentru că ar trebui să așteptați zile pentru a face ceva
• Aveți nevoie de o structură de date specială pentru a reprezenta datele
• Trebuie să filtrați setul de date pentru erori (de exemplu: erori de secvențiere)

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

Există un lucru special pentru a grafica algoritmii, întrebări originale, ceea ce face atunci special, care este despre capacitatea de a partiționa datele în esență.

Pentru unele lucruri, cum ar fi sortarea numerelor pe o matrice, nu este prea dificil să partiționăm problema structurii de date în bucăți disjunctive mai mici, de ex. Aici: Sortare paralelă la locul de îmbinare

Pentru algoritmi grafici, totuși, există provocarea că este cunoscută găsirea unei partiționări opționale pe o metrică grafică dată a fi $ NP-hard $.

Deci, în timp ce 10 GB de numere de sortat ar putea fi o problemă foarte accesibilă pe un computer normal (puteți doar să intrați prin programare dinamică și să aveți o predictibilitate foarte bună despre fluxul de programe), lucrând cu un grafic de 10 GB structura datelor poate deja prin provocare.

Există o serie de cadre specializate, cum ar fi GraphX care utilizează metode și paradigme de calcul speciale pentru a ocoli oarecum provocările inerente ale graficelor.

Așadar, pentru a răspunde la întrebarea dvs. pe scurt: așa cum am menționat anterior alții, când datele dvs. nu se încadrează în memoria principală de pe un PC normal, dar aveți nevoie de toate acestea pentru a răspunde la problema dvs., este un bun indiciu că datele sunt deja oarecum mari. Etichetarea exactă, deși depinde, cred un pic de structura datelor și întrebarea pusă.

Cred că datele mari încep din punctul în care dimensiunea vă împiedică să faceți ceea ce doriți. În majoritatea scenariilor, există o limită a timpului de funcționare care este considerată fezabilă. În unele cazuri este o oră, în unele cazuri ar putea dura câteva săptămâni. Atâta timp cât datele nu sunt suficient de mari încât numai algoritmii O (n) să poată rula în intervalul de timp fezabil, nu ați ajuns la date mari.

Îmi place această definiție, deoarece este agnostică la volum, nivel tehnologic și algoritmi specifici. Nu este agnostic pentru resurse, așa că un student absolvent va ajunge la punctul de big data înaintea Google.

Pentru a putea cuantifica cât de mari sunt datele, îmi place să luați în considerare timpul necesar pentru a o copia de rezervă. Deoarece tehnologia avansează, volumele considerate mari acum câțiva ani sunt acum moderate. Timpul de rezervă se îmbunătățește, pe măsură ce tehnologia se îmbunătățește, la fel ca și timpul de funcționare al algoritmilor de învățare. Cred că este mai sensibil pentru a vorbi despre un set de date este nevoie de X ore pentru a face backup și nu de un set de date de Y octeți.

PS.

Este important să rețineți că, chiar dacă ați atins punctul mare de date și nu puteți rula algoritmi de complexitate mai mult de O (n) în mod direct, există multe lucruri pe care le puteți face pentru a beneficia în continuare de un astfel de algoritm s.

De exemplu, selectarea funcției poate reduce numărul de caracteristici de care depinde timpul de funcționare al multor algoritmi. În multe distribuții de coadă lungă, concentrarea în puținele articole din cap ar putea fi de folos. Puteți utiliza un eșantion și puteți rula algoritmii mai încet.

Comentarii

• Rețineți că bariera $ O (n) $ a fost de asemenea încălcată acum în unele domenii ale ML. Consultați [ grigory.us/mpc-workshop-dimacs.html] pentru Workshop-ul despre algoritmi subliniari pentru ML [1]: grigory.us/mpc-workshop-dimacs.html

Datele sunt „Big Data” dacă sunt atât de volum, încât este mai puțin costisitoare să le analizăm pe două sau mai multe computere de marfă, decât pe un computer de ultimă generație.

Acesta este în esență modul în care Google „s” Sistemul de fișiere BigFiles a apărut. Page și Brin nu și-au putut permite un server Sun de lux să-și stocheze și să caute în indexul web, așa că au conectat mai multe computere de marfă

„Big date „este literalmente doar o mulțime de date. Deși este mai mult un termen de marketing decât orice altceva, implicația este de obicei că aveți atât de multe date încât nu puteți analiza toate datele simultan, deoarece cantitatea de memorie (RAM) necesară pentru a păstra datele în memoria pentru ao procesa și analiza este mai mare decât cantitatea de memorie disponibilă.

Aceasta înseamnă că, de obicei, analizele trebuie făcute pe segmente aleatorii de date, ceea ce permite construirea de modele pentru a fi comparate cu alte părți ale datelor.