Qual é o tamanho do big data?

Muitas pessoas usam o termo big data de maneira bastante comercial , como um meio de indicar que grandes conjuntos de dados estão envolvidos na computação e, portanto, as soluções em potencial devem ter um bom desempenho. Obviamente, o big data sempre carrega termos associados, como escalabilidade e eficiência, mas o que exatamente define um problema como um problema de big data ?

O cálculo precisa estar relacionado a algum conjunto de finalidades específicas, como mineração de dados / recuperação de informações, ou um algoritmo para problemas gerais de gráfico pode ser rotulado como big data se o conjunto de dados for grande o suficiente ? Além disso, quão grande é grande o suficiente (se é possível definir isso)?

Para mim (vindo de um fundo de banco de dados relacional), "Big Data" não se refere principalmente ao tamanho dos dados (que é a maior parte do que as outras respostas estão até agora).

"Big Data" e "Bad Data" estão intimamente relacionados. Bancos de dados relacionais requerem 'dados primitivos'. Se os dados estiverem no banco de dados, são precisos, limpos e 100% confiáveis. Os bancos de dados relacionais exigem "ótimos dados" e uma quantidade enorme de tempo, dinheiro e responsabilidade são aplicados para garantir que os dados estejam bem preparados antes de carregá-los no banco de dados. Se os dados estão no banco de dados, é 'evangelho' e define o entendimento da realidade do sistema.

O "Big Data" aborda esse problema de outra direção. Os dados são mal definidos, muitos deles podem ser imprecisos e muitos deles podem estar ausentes. A estrutura e o layout dos dados são lineares, e não relacionais.

O Big Data precisa ter volume suficiente para que a quantidade de dados incorretos ou ausentes se torne estatisticamente insignificante. Quando os erros nos seus dados são comuns o suficiente para serem cancelados, quando os dados ausentes são proporcionalmente pequenos o suficiente para serem insignificantes e quando os requisitos e algoritmos de acesso a dados estão funcionais, mesmo com dados incompletos e imprecisos, você tem "Big Data" .

"Big Data" não é realmente sobre o volume, é sobre as características dos dados.

Como você observa com razão, hoje em dia "big data" é algo que todos querem dizer que têm, o que implica uma certa folga na maneira como as pessoas definem o termo. Geralmente, porém, eu diria que você certamente está lidando com big data se a escala é tal que não é mais possível gerenciar com tecnologias mais tradicionais, como RDBMS, pelo menos sem complementá-las com tecnologias de big data, como o Hadoop.

Qual é o tamanho dos seus dados para realmente ser esse o caso é discutível. Aqui está um post (um tanto provocador) que afirma que não é realmente o caso de menos de 5 TB de dados. (Para deixar claro, ele não afirma "Menos de 5 TB não é grande volume de dados", mas apenas "Menos de 5 TB não é grande o suficiente para que você precise do Hadoop".)

Mas, mesmo em conjuntos de dados menores, as tecnologias de big data como o Hadoop podem ter outras vantagens, incluindo adequar-se a operações em lote, jogar bem com dados não estruturados (além de dados cuja estrutura não é conhecida antecipadamente ou pode mudar), escalabilidade horizontal ( escalando adicionando mais nós em vez de aumentar seus servidores existentes) e (como um dos comentadores das notas postadas acima) a capacidade de integrar seu processamento de dados a conjuntos de dados externos (pense em um mapa-reduzir onde o mapeador faz uma chamada para outro servidor). Outras tecnologias associadas ao big data, como os bancos de dados NoSql, enfatizam o desempenho rápido e a disponibilidade consistente ao lidar com grandes conjuntos de dados, além de serem capazes de lidar com dados semiestruturados e fazer a escala horizontal.

Obviamente, os RDBMS tradicionais têm suas próprias vantagens, incluindo garantias ACID (Atomicidade, Consistência, Isolamento, Durabilidade) e melhor desempenho para determinadas operações, além de serem mais padronizados, mais maduros e (para muitos usuários) mais familiares. Portanto, mesmo para dados indiscutivelmente "grandes", pode fazer sentido carregar pelo menos uma parte de seus dados em um banco de dados SQL tradicional e usá-lo em conjunto com as tecnologias de big data.

Portanto, uma definição mais generosa seria a de que você possui big data, desde que seja grande o suficiente para que as tecnologias de big data ofereçam algum valor agregado. Mas, como você pode ver, isso pode depender não apenas do tamanho dos seus dados, mas também de como você deseja trabalhar com eles e que tipo de requisitos você possui em termos de flexibilidade, consistência e desempenho. Como você está usando seus dados é mais relevante para a questão do que o que você está usando-o para (por exemplo, mineração de dados). Dito isto, usos como mineração de dados e aprendizado de máquina são mais propensos a produzir resultados úteis se você tiver um conjunto de dados grande o suficiente para trabalhar.

Quantidade total de dados no mundo: 2,8 zetabytes em 2012, estimados em 8 zetabytes até 2015 ( fonte ) e com um tempo de duplicação de 40 meses. Não pode ficar maior que isso :)

Como exemplo de uma única organização grande, o Facebook atrai 500 terabytes por dia para um armazém de 100 petabytes e executa 70 mil consultas por dia a partir de 2012 ( fonte ) O armazém atual deles é de> 300 petabytes.

O big data é provavelmente algo que é uma boa fração dos números do Facebook (1/100 provavelmente sim, 1/10000 provavelmente não: é um espectro, não um número único).

Além do tamanho, alguns dos recursos que o tornam "grande" são:

• ele é analisado ativamente, não apenas armazenado (aspas "Se você não está tirando proveito do big data, não tem big data, apenas uma pilha de dados" Jay Parikh @ Facebook)

• construir e executar um data warehouse é um grande projeto de infraestrutura

• está crescendo a uma taxa significativa

• não está estruturado ou possui estrutura irregular

Definição do Gartner: "Big data são ativos de informações de alto volume, alta velocidade e / ou alta variedade que requerem novas formas de processamento" (os 3Vs). Portanto, eles também pensam que "grandeza" não é inteiramente do tamanho do conjunto de dados, mas também sobre a velocidade e estrutura e o tipo de ferramentas necessárias.

Para mim, o Big Data é principalmente sobre as ferramentas (afinal, foi aí que começou); um conjunto de dados "grande" é grande demais para ser manipulado com ferramentas convencionais - em particular, grande o suficiente para exigir armazenamento e processamento em um cluster em vez de em uma única máquina. Isso exclui um RDBMS convencional e exige novas técnicas de processamento; em particular, várias estruturas do tipo Hadoop facilitam a distribuição de uma computação em um cluster, com o custo de restringir a forma dessa computação. Vou colocar a referência em http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html; As técnicas de big data são o último recurso para conjuntos de dados que são simplesmente grandes demais para serem manipulados de qualquer outra maneira. Eu diria que qualquer conjunto de dados para qualquer finalidade poderia se qualificar se fosse grande o suficiente - embora se a forma do problema seja tal que as ferramentas de "big data" existentes não sejam apropriadas, provavelmente seria melhor criar um novo nome.

Claro que há alguma sobreposição; quando eu (brevemente) trabalhei no last.fm, trabalhamos no mesmo conjunto de dados de 50 TB usando o Hadoop e também em um banco de dados SQL em um servidor bastante ridículo (lembro-me que ele tinha 1 TB de RAM, e isso ocorre há alguns anos). Em certo sentido, isso significava que era e não era um grande volume de dados, dependendo do trabalho em que você estava trabalhando. Mas acho que é uma caracterização precisa; as pessoas que trabalharam nos trabalhos do Hadoop acharam útil ir para conferências e sites de Big Data, enquanto as pessoas que trabalharam nos trabalhos do SQL não.

Os dados se tornam "grandes" quando um único computador comum não pode mais lidar com a quantidade de dados que você possui. Indica o ponto em que você precisa começar a pensar em construir supercomputadores ou usar clusters para processar seus dados.

Big Data é definido pelo volume de dados, isso mesmo, mas não apenas. A particularidade do big data é que você precisa armazenar muitos materiais variados e às vezes não estruturados o tempo todo e de vários sensores , geralmente por anos ou década .

Além disso, você precisa de algo escalável, para que não demore meio ano para encontrar os dados de volta.

Então aqui está o Big Data, onde o método tradicional não funciona mais. SQL não é escalável. E o SQL trabalha com dados muito estruturados e vinculados (com toda essa bagunça de chave primária e externa, junção interna, solicitação imbricada ...).

Basicamente, como o armazenamento se torna cada vez mais barato e os dados se tornam cada vez mais valiosos, o grande gerente solicita ao engenheiro que registre tudo. Adicione a essa tonelada de novos sensores todas essas redes sociais móveis, coisas incorporadas ... etc. Portanto, como os métodos clássicos não funcionam, eles precisam encontrar novas tecnologias (armazenando tudo em arquivos, no formato json, com grande índice, o que chamamos de noSQL).

Portanto, o Big Data pode ser muito grande, mas pode não ser tão grande, mas não estruturado, complexo ou vários dados que precisam ser armazenados rapidamente e em execução em um formato bruto. Nós nos concentramos e armazenamos no início, e depois analisamos como vincular tudo.

Vou compartilhar como é o Big Data na genômica, em particular na montagem de-novo.

Quando sequenciamos seu genoma (por exemplo: detectar novos genes), fazemos bilhões de leituras curtas da próxima geração. Veja a imagem abaixo, onde tentamos montar algumas leituras.

Isso parece simples? Mas e se você tiver bilhões dessas leituras? E se essas leituras contiverem erros de sequência? E se a sua RAM não tiver memória suficiente para manter as leituras? E as regiões repetitivas do DNA, como o elemento Alu, muito comum ?

A montagem de novo é feita através da construção de um gráfico de De-Bruijn :

O gráfico é uma estrutura de dados minada inteligente para representar leituras sobrepostas. Não é perfeito, mas é melhor do que gerar todas as sobreposições possíveis e armazená-las em uma matriz.

O processo de montagem pode levar dias para ser concluído, porque há vários caminhos que um montador precisaria percorrer e recolher.

Em genômica, você tem um grande volume de dados quando:

• Você não pode força bruta em todas as combinações
• Seu computador não possui memória física suficiente para armazenar os dados
• Você precisa reduzir as dimensões (por exemplo: recolhendo caminhos de gráficos redundantes)
• Você fica chateado porque você teria que esperar dias para fazer qualquer coisa
• Você precisa de uma estrutura de dados especial para representar os dados
• Você precisa filtrar seu conjunto de dados para erros (por exemplo: erros de sequência)

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

Há algo especial em representar graficamente os algoritmos, suas perguntas originais, o que torna especial, que é a capacidade de particionar os dados essencialmente.

Para algumas coisas, como classificar números em uma matriz, não é muito difícil particionar o problema na estrutura de dados em partes disjuntivas menores, por exemplo : Aqui: Parallel in place place merge

$NP-hard$

Portanto, embora 10 GB de números a serem classificados possa ser um problema muito acessível em um PC normal (você pode acessar via programação dinâmica e ter uma previsão muito boa sobre o fluxo do programa), trabalhar com uma estrutura de dados gráficos de 10 GB já pode ser um desafio.

Existem várias estruturas especializadas, como o GraphX, usando métodos e paradigmas especiais de computação para contornar um pouco os desafios inerentes aos gráficos.

Portanto, para responder brevemente à sua pergunta: Como mencionado anteriormente por outras pessoas, quando seus dados não se encaixam na memória principal de um PC normal, mas você precisa de tudo para responder ao seu problema, é uma boa dica de que seus dados já são um pouco grandes. A rotulagem exata, porém, depende, penso um pouco da estrutura de dados e da pergunta.

Eu acho que o big data começa no ponto em que o tamanho impede que você faça o que deseja. Na maioria dos cenários, há um limite no tempo de execução considerado viável. Em alguns casos, é de uma hora; em alguns casos, pode demorar algumas semanas. Desde que os dados não sejam grandes o suficiente para que apenas os algoritmos O (n) possam ser executados no período de tempo possível, você não alcançou o big data.

Eu gosto dessa definição, pois é independente de volume, nível de tecnologia e algoritmos específicos. Como não é independente de recursos, um estudante de graduação chegará ao ponto de big data muito antes do Google.

Para poder quantificar o tamanho dos dados, eu gosto de considerar o tempo necessário para fazer backup deles. Desde que a tecnologia avança, os volumes considerados grandes alguns anos atrás agora são moderados. O tempo de backup melhora, assim como a tecnologia, assim como o tempo de execução dos algoritmos de aprendizado. Eu sinto que é mais sensato falar sobre um conjunto de dados que leva X horas para fazer backup e não sobre um conjunto de dados de Y bytes.

PS.

É importante observar que, mesmo que você tenha atingido o ponto de big data e não possa executar algoritmos de complexidade mais do que O (n) de maneira direta, há muito o que fazer para se beneficiar ainda de tais algoritmos.

Por exemplo, a seleção de recursos pode reduzir o número de recursos dos quais muitos algoritmos dependem do tempo de execução. Em muitas distribuições de cauda longa, o foco nos poucos itens da cabeça pode ser benéfico. Você pode usar uma amostra e executar nela os algoritmos mais lentos.

Os dados são "big data" se forem de tal volume que é mais barato analisá-los em dois ou mais computadores comuns do que em um computador de ponta.

Foi assim que o sistema de arquivos "BigFiles" do Google se originou. Page e Brin não tinham dinheiro para comprar um servidor sofisticado da Sun para armazenar e pesquisar em seu índice da web; portanto, conectaram vários computadores comuns

Costumo concordar com o que @Dan Levin já disse. Por fim, como queremos extrair informações úteis dos dados, em vez de apenas armazená-los, é a capacidade de aprender algoritmos / sistemas que deve determinar o que é chamado de "Big data". À medida que os sistemas ML evoluem, o que era Big Data hoje não será mais Big Data amanhã.

Uma maneira de definir Big Data pode ser:

• Big data : dados nos quais você não pode criar modelos de ML em tempo razoável (1-2 horas) em uma estação de trabalho típica (digamos, 4 GB de RAM)
• Dados não grandes : complemento dos itens acima

Assumindo essa definição, desde que a memória ocupada por uma linha individual (todas as variáveis ​​para um único ponto de dados) não exceda a RAM da máquina, deveríamos estar no regime Não-big data .

Nota: O Vowpal Wabbit (de longe o sistema ML mais rápido atualmente) pode aprender sobre qualquer conjunto de dados, desde que uma linha individual (ponto de dados) seja <RAM (digamos 4GB). O número de linhas não é uma limitação, pois usa SGD em vários núcleos. Falando por experiência, você pode treinar um modelo com recursos de 10.000 e 10MN de linhas em um laptop em um dia.

"Big data" é literalmente apenas muitos dados. Embora seja mais um termo de marketing do que qualquer coisa, a implicação é geralmente que você tem tantos dados que não pode analisar todos os dados de uma só vez, porque a quantidade de memória (RAM) necessária para reter os dados na memória é processar e analisar é maior que a quantidade de memória disponível.

Isso significa que as análises geralmente precisam ser feitas em segmentos aleatórios de dados, o que permite que modelos sejam construídos para comparação com outras partes dos dados.