Quelle est la taille des données volumineuses?

Beaucoup de gens utilisent le terme mégadonnées de manière plutôt commerciale pour indiquer que de grands ensembles de données sont impliqués dans le calcul et que, par conséquent, les solutions potentielles doivent être performantes. Bien entendu, le big data contient toujours des termes associés, tels que scalabilité et efficacité, mais qu'est-ce qui définit exactement un problème comme un problème de big data ?

Le calcul doit-il être lié à un ensemble d'objectifs spécifiques, tels que l'exploration de données / la récupération d'informations, ou un algorithme pour les problèmes de graphes généraux peut-il être qualifié de « big data» si le jeu de données est suffisamment volumineux ? Aussi, quelle taille est assez grande (si cela est possible de définir)?

Pour moi (provenant d'un arrière-plan de base de données relationnelle), le "Big Data" ne concerne pas principalement la taille des données (qui constitue l'essentiel des réponses précédentes).

"Big Data" et "Bad Data" sont étroitement liés. Les bases de données relationnelles requièrent des «données parfaites». Si les données sont dans la base de données, elles sont précises, propres et fiables à 100%. Les bases de données relationnelles requièrent des "données de grande qualité", ainsi que beaucoup de temps, d’argent et de responsabilité afin de s’assurer que les données sont bien préparées avant de les charger dans la base de données. Si les données sont dans la base de données, il s'agit d'un «évangile», qui définit la compréhension de la réalité par le système.

"Big Data" aborde ce problème dans l'autre sens. Les données sont mal définies, une grande partie peut être inexacte et une grande partie peut en fait être manquante. La structure et la présentation des données sont linéaires et non relationnelles.

Les données volumineuses doivent avoir un volume suffisant pour que la quantité de données incorrectes, ou les données manquantes, deviennent statistiquement non significatives. Lorsque les erreurs dans vos données sont suffisamment communes pour s’annuler, lorsque les données manquantes sont suffisamment petites pour être négligeables et que vos exigences en matière d’accès aux données et vos algorithmes sont fonctionnels, même avec des données incomplètes et inexactes, vous obtenez le "Big Data". .

Le "Big Data" ne concerne pas vraiment le volume, mais les caractéristiques des données.

Comme vous le constatez à juste titre, de nos jours, le "big data" est une chose que tout le monde veut dire, ce qui implique une certaine souplesse dans la définition du terme. En règle générale, cependant, je dirais que vous avez certainement affaire à du big data si l'échelle est telle qu'il n'est plus possible de gérer avec des technologies plus traditionnelles telles que le SGBDR, du moins sans les compléter avec des technologies de big data telles que Hadoop.

La taille de vos données doit être réellement discutable. Voici un article de blog (quelque peu provocant) qui affirme que ce n'est pas vraiment le cas pour moins de 5 To de données. (Pour être clair, il ne dit pas "Moins de 5 To, ce n'est pas du Big Data", mais juste "Moins de 5 To n'est pas assez gros pour que vous ayez besoin de Hadoop".)

Mais même sur des ensembles de données plus petits, les technologies Big Data telles que Hadoop peuvent présenter d’autres avantages, notamment être bien adaptées aux opérations par lots, jouer avec des données non structurées (ainsi que des données dont la structure n’est pas connue à l’avance ou qui pourrait changer), mise à l'échelle en ajoutant plus de nœuds au lieu de renforcer vos serveurs existants), et (en tant que commentateur sur les notes de publication liées ci-dessus), la possibilité d'intégrer votre traitement de données avec des ensembles de données externes (pensez à une carte-réduire où le mappeur appelle un autre serveur). D'autres technologies associées aux mégadonnées, telles que les bases de données NoSql, mettent l'accent sur la rapidité des performances et la disponibilité constante tout en traitant de grands ensembles de données. Elles permettent également de gérer des données semi-non structurées et d'évoluer horizontalement.

Bien entendu, les SGBDR traditionnels ont leurs propres avantages, notamment des garanties ACID (atomicité, cohérence, isolement, durabilité) et de meilleures performances pour certaines opérations, tout en étant plus normalisés, plus matures et (pour beaucoup d'utilisateurs) plus familiers. Ainsi, même pour des données incontestablement "volumineuses", il peut être judicieux de charger au moins une partie de vos données dans une base de données SQL traditionnelle et de l’utiliser en conjonction avec les technologies Big Data.

Donc, une définition plus généreuse serait que vous avez le big data, à condition que sa taille soit suffisante pour que les technologies du big data vous apportent une valeur ajoutée. Mais comme vous pouvez le constater, cela dépend non seulement de la taille de vos données, mais également de la manière dont vous souhaitez les utiliser et des exigences que vous avez en termes de flexibilité, de cohérence et de performances. Comment vous utilisez vos données est plus pertinente à la question que ce que vous l' utilisez pour (par exemple , l' exploration de données). Cela dit, les utilisations telles que l'exploration de données et l'apprentissage automatique ont plus de chances de produire des résultats utiles si vous disposez d'un ensemble de données suffisamment important.

Quantité totale de données dans le monde: 2,8 zetabytes en 2012, estimée à 8 zetabytes d'ici à 2015 ( source ) et avec un délai de doublement de 40 mois. Ne peut pas devenir plus gros que ça :)

En tant qu'exemple d'une grande entreprise, Facebook collecte 500 téraoctets par jour dans un entrepôt de 100 pétaoctets et effectue 70 000 requêtes par jour à partir de 2012 ( source ). Son entrepôt actuel est supérieur à 300 pétaoctets.

Les données volumineuses représentent probablement une bonne fraction des chiffres de Facebook (1/100 probablement, oui, 1/10000 probablement pas: c'est un spectre et non un nombre).

En plus de la taille, certaines des caractéristiques qui la rendent "grande" sont:

• il est activement analysé, pas seulement stocké (citation "Si vous ne tirez pas parti du big data, alors vous n'avez pas de big data, vous avez juste une pile de données" Jay Parikh @ Facebook)

• la construction et l'exploitation d'un entrepôt de données est un projet d'infrastructure majeur

• il se développe à un rythme important

• il est non structuré ou a une structure irrégulière

Définition de Gartner: "Les données volumineuses sont des actifs d’information de grande taille, de grande vélocité et / ou très variés qui nécessitent de nouvelles formes de traitement" (The 3Vs). également sur la vitesse et la structure et le type d'outils nécessaires.

Pour moi, le Big Data concerne principalement les outils (après tout, c'est là que tout a commencé); un "gros" jeu de données est un ensemble trop volumineux pour être traité avec des outils conventionnels, en particulier suffisamment volumineux pour exiger le stockage et le traitement sur un cluster plutôt que sur une seule machine. Cela exclut un SGBDR classique et exige de nouvelles techniques de traitement; En particulier, divers frameworks de type Hadoop facilitent la répartition d'un calcul sur un cluster, au prix d'une restriction de la forme de ce calcul. J'appuierai la référence à http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html; Les techniques Big Data constituent un dernier recours pour les ensembles de données trop volumineux pour être gérés autrement. Je dirais que n'importe quel jeu de données, quelle que soit sa destination, pourrait être qualifié s'il était suffisamment volumineux. Toutefois, si le problème est tel que les outils de "Big Data" existants ne sont pas appropriés, il serait probablement préférable de proposer un nouvel outil. Nom.

Bien sûr, il y a un certain chevauchement; quand j'ai (brièvement) travaillé chez last.fm, nous avons travaillé sur le même jeu de données de 50 To en utilisant Hadoop ainsi que dans une base de données SQL sur un serveur assez ridicule (je me souviens qu'il avait 1 To de RAM, il y a quelques années déjà). Dans un sens, cela signifiait que les deux étaient et n'étaient pas des données volumineuses, en fonction du travail sur lequel vous travailliez. Mais je pense que c'est une caractérisation précise; Les personnes qui ont travaillé sur les emplois Hadoop ont jugé utile d’aller dans des conférences et des sites Web Big Data, contrairement à celles qui ont travaillé sur les emplois SQL.

Les données deviennent "volumineuses" lorsqu'un seul ordinateur ne peut plus gérer la quantité de données dont vous disposez. Il indique le moment où vous devez commencer à penser à la construction de superordinateurs ou à l’utilisation de clusters pour traiter vos données.

Le Big Data est défini par le volume de données, c'est vrai, mais pas seulement. La particularité de données est grande que vous devez stocker un bon nombre de différentes et parfois non structurées étoffes tous les temps et de un tonnes de capteurs , généralement pendant des années ou dix ans .

De plus, vous avez besoin de quelque chose d'évolutif, de sorte qu'il ne vous faut pas six mois pour retrouver une donnée.

Voici donc le Big Data, où la méthode traditionnelle ne fonctionnera plus. SQL n'est pas évolutif. Et SQL fonctionne avec des données très structurées et liées (avec tous ces désordres de clé primaire et étrangère, de joint interne, de requête imbriquée ...).

Fondamentalement, parce que le stockage devient de moins en moins cher et que les données deviennent de plus en plus précieuses, un grand responsable demande à l’ingénieur de tout enregistrer. Ajoutez à cela des tonnes de nouveaux capteurs avec tous ces réseaux mobiles, réseaux sociaux, intégrés, etc. Donc, comme les méthodes classiques ne fonctionnent pas, ils doivent trouver de nouvelles technologies (tout stocker dans des fichiers, au format json, avec un gros index, ce que nous appelons noSQL).

Ainsi, les données volumineuses peuvent être très volumineuses, mais pas très grandes, mais complexes, non structurées ou diverses, qui doivent être stockées rapidement et stockées dans un format brut. Nous nous concentrons et stockons dans un premier temps, puis nous examinons comment relier tout.

Je partagerai ce qu'est le Big Data en génomique, en particulier en assemblage de novo.

Lorsque nous séquençons votre génome (par exemple, nous détectons de nouveaux gènes), nous prenons des milliards de lectures courtes de nouvelle génération. Regardez l'image ci-dessous, où nous essayons d'assembler des lectures.

Cela a l'air simple? Mais si vous avez des milliards de ces lectures? Que se passe-t-il si ces lectures contiennent des erreurs de séquence? Que faire si votre RAM n'a pas assez de mémoire pour conserver les lectures? Qu'en est-il des régions d'ADN répétitives, telles que le très commun élément Alu ?

L’assemblage de novo est réalisé en construisant un graphe de De-Bruijn :

Le graphique est une structure de données astucieuse pour représenter les lectures qui se chevauchent. Ce n'est pas parfait mais c'est mieux que de générer tous les chevauchements possibles et de les stocker dans un tableau.

Le processus d'assemblage peut prendre plusieurs jours, car il existe un grand nombre de chemins qu'un assembleur devrait parcourir et réduire.

En génomique, vous avez un big data quand:

• Vous ne pouvez pas forcer toutes les combinaisons
• Votre ordinateur ne dispose pas de suffisamment de mémoire physique pour stocker les données
• Vous devez réduire les dimensions (par exemple: réduire les chemins des graphes redondants)
• Vous êtes énervé parce que vous devez attendre des jours pour faire quoi que ce soit
• Vous avez besoin d'une structure de données spéciale pour représenter les données
• Vous devez filtrer votre ensemble de données pour les erreurs (par exemple: erreurs de séquençage)

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

Il y a une particularité de tracer des algorithmes graphiques, vous posez des questions originales qui rendent ensuite spécial, ce qui concerne sa capacité à partitionner les données essentiellement.

Pour certaines choses, comme le tri des nombres sur un tableau, il n’est pas trop difficile de scinder le problème de la structure de données en morceaux plus petits, tels que Here: Tri par fusion sur place

Pour les algorithmes de graphes, il est toutefois difficile de trouver trouver un partitionnement facultatif sur une métrique graphique donnée .$NP-hard$

Ainsi, alors que 10 Go de nombres à trier pourraient être un problème très accessible sur un PC normal (vous pouvez entrer via une programmation dynamique et avoir une très bonne prévisibilité sur le déroulement du programme), travailler avec une structure de données de graphe de 10 Go peut déjà poser problème.

Il existe un certain nombre de cadres spécialisés tels que GraphX utilisant des méthodes et des paradigmes informatiques spéciaux pour contourner quelque peu les défis inhérents aux graphiques.

Donc, pour répondre brièvement à votre question: comme d’autres l’ont déjà mentionné, lorsque vos données ne rentrent pas dans la mémoire principale d’un PC normal, mais que vous avez besoin de tout cela pour répondre à votre problème, cela indique que vos données sont déjà un peu volumineuses. L'étiquetage exact dépend cependant un peu de la structure de données et de la question posée.

Je pense que le Big Data commence au point où la taille vous empêche de faire ce que vous voulez. Dans la plupart des scénarios, le temps d'exécution considéré est limité. Dans certains cas, il s'agit d'une heure, dans d'autres, de quelques semaines. Tant que les données ne sont pas assez volumineuses pour que seuls les algorithmes O (n) puissent s'exécuter dans les délais impartis, vous n'atteignez pas les données volumineuses.

J'aime cette définition car elle est agnostique par rapport au volume, au niveau technologique et à des algorithmes spécifiques. Ce n'est pas agnostique aux ressources afin qu'un étudiant diplômé atteigne le point de façon big data avant Google.

Afin de pouvoir quantifier la taille des données, j'aime bien considérer le temps nécessaire pour les sauvegarder. Depuis que la technologie a progressé, les volumes considérés comme importants il y a quelques années sont maintenant modérés. Le temps de sauvegarde s'améliore au fur et à mesure que la technologie progresse, tout comme le temps d'exécution des algorithmes d'apprentissage. Je pense qu'il est plus judicieux de parler d'un ensemble de données, il faut X heures pour la sauvegarde et non d'un ensemble de données de Y octets.

PS

Il est important de noter que même si vous atteignez le point de données volumineuses et que vous ne pouvez pas exécuter des algorithmes de complexité supérieure à O (n) de manière simple, il y a beaucoup de choses que vous pouvez faire pour continuer à bénéficier de ces algorithmes.

Par exemple, la sélection des fonctionnalités peut réduire le nombre de fonctionnalités dont dépend le temps d'exécution de plusieurs algorithmes. Dans de nombreux cas, la distribution à longue queue se concentrant sur les quelques éléments de la tête pourrait être bénéfique. Vous pouvez utiliser un exemple et exécuter sur celui-ci les algorithmes plus lents.

Les données sont dites «Big Data» si leur volume est tel qu'il est moins coûteux de les analyser sur deux ordinateurs de base ou plus que sur un seul ordinateur haut de gamme.

C’est essentiellement ainsi que le système de fichiers "BigFiles" de Google est né. Page et Brin ne pouvaient pas se permettre un serveur Sun sophistiqué pour stocker et rechercher leur index Web, donc branché plusieurs ordinateurs de base

J'ai tendance à être d'accord avec ce que @Dan Levin a déjà dit. En fin de compte, puisque nous voulons tirer des informations utiles des données plutôt que de simplement les stocker, c’est la capacité d’apprentissage des algorithmes / systèmes qui devrait déterminer ce que l’on appelle les «données volumineuses». À mesure que les systèmes ML évoluent, ce qui était Big Data aujourd'hui ne sera plus demain.

Une façon de définir le Big data pourrait être:

• Big data : données sur lesquelles vous ne pouvez pas créer de modèles ML en un temps raisonnable (1-2 heures) sur un poste de travail typique (avec par exemple 4 Go de RAM)
• Non Big Data : complément de ce qui précède

En supposant cette définition, tant que la mémoire occupée par une ligne individuelle (toutes les variables pour un seul point de données) ne dépasse pas la mémoire vive de la machine, nous devrions être dans le régime non big data .

Remarque: Vowpal Wabbit (de loin le système ML le plus rapide d’aujourd’hui) peut apprendre tout jeu de données, à condition qu’une rangée individuelle (point de données) représente <RAM (4 Go, par exemple). Le nombre de lignes n'est pas une limitation car il utilise SGD sur plusieurs cœurs. Par expérience, vous pouvez former un modèle en un jour avec des fonctionnalités de 10 000 fonctions et des rangées de 10 millions de dollars.

"Big Data" est littéralement juste beaucoup de données. Bien qu'il s'agisse plus d'un terme marketing qu'autre chose, cela implique généralement que vous avez une quantité de données telle que vous ne pouvez pas analyser toutes les données à la fois, car la quantité de mémoire vive (RAM) qu'il faudrait pour les conserver en mémoire traiter et analyser est supérieur à la quantité de mémoire disponible.

Cela signifie que des analyses doivent généralement être effectuées sur des segments de données aléatoires, ce qui permet de construire des modèles pour les comparer à d'autres parties des données.