Os 3 Vs do Big Data

Muita gente se confunde se são 3 ou 5 Vs do Big Data e, por este motivo, resolvi explicar neste post que existem 3Vs principais e 2Vs complementares, que iremos abordar à partir de agora.

O conceito mais usado para definir os fundamentos de Big Data é baseado em 3Vs. Não ignore ou questione os 3Vs neste momento, pois requer uma análise mais aprofundada para entendermos algumas questões importantes.

Existem 3Vs principais e 2Vs complementaresVolume é um conceito relativo, o que é Big Data hoje pode não ser Big Data amanhã. Portanto, precisamos entender essa questão-chave sobre o principal fundamento de Big Data.

Volume

Vamos definir um cenário inicial para identificar qual volume é considerado um Big Data e, nessa definição, utilizaremos o volume em petabytes (que equivale a 1.000 terabytes).

Obs.: Assim como 1 TB, alguns anos atrás, era considerado um grande volume, e havia poucos bancos de dados com essa capacidade, o petabyte será comum para a maioria das organizações, em pouco tempo.

• 10 TB é Big Data?

• 100 TB é Big Data?

• 1 PB é Big Data?

A melhor maneira de responder a essas questões é analisando as tecnologias tradicionais, e para isso, proponho fazermos a seguinte pergunta:

A solução tradicional (cliente-servidor), seja ela um database, uma aplicação ou um hardware, está preparada para atender este volume?

Então, pense sobre:

• Custo ($)

• Capacidade (por exemplo: Armazenamento, Processamento, I/O)

• Arquitetura (por exemplo: Geograficamente Distribuída)

Caso sua resposta seja não, temos aqui a principal motivação para quebrar os paradigmas tradicionais da segunda geração e buscar novas soluções que se enquadrem melhor nas suas necessidades computacionais da terceira geração.

Um database tradicional definitivamente não foi concebido para trabalhar com vários terabytes, sua estrutura foi estressada ao longo da evolução para se adaptar ao crescimento de volumes cada vez maiores. Porém, a partir da nova era da informação, a explosão de dados causou um colapso nas arquiteturas de dados tradicionais e chegamos ao seu limite técnico-financeiro, para a maioria das empresas que operam volumes de dados em petabytes.

Portanto, o V de volume para definição de Big Data está ligado a capacidades que excedem as tecnologias tradicionais.

Velocidade

Como vimos nos fundamentos da computação baseada em nuvem, a TI não atende o time-to-market. A velocidade de negócios é imediatista e de caráter emergencial, enquanto a velocidade de TI requer muitos processos vagarosos.

Vamos analisar o modelo clássico da arquitetura analítica.

Podemos mencionar dois principais aspectos relativos à velocidade, que são:

• Throughput: a velocidade necessária para processar um grande volume de informações.

• Latência: a velocidade para análise de informações, ou seja, para chegarmos ao relatório final (D-1 => Data-In-Motion).

O fluxo de dados da arquitetura tradicional acima limita a análise com delta de 1 dia para a tomada de decisão. As transações que alimentam os bancos de dados operacionais são acumuladas ao longo do dia e estão fragmentadas em várias bases, criando silos de informações com visões diferentes. Através de processos ETL (Extract Transform Load – Extração, Transformação e Carga), as informações são extraídas dos bancos de dados operacionais, passam por um processo de transformação e são carregadas diariamente para o Data Warehouse (em um cenário otimista, esse processo funciona diariamente e não ultrapassa o delta de 1 dia), consolidando um modelo de dados dimensional que centraliza os dados com uma visão integrada e consistente na linha do tempo.

Agora vamos analisar um modelo do Google, considerando as necessidades das empresas da era digital.

Para contextualizar, o Google, sem dúvida, é o maior motor de inovação para Big Data, e seu primeiro grande desafio surgiu há mais de uma década, quando encontrou as primeiras barreiras para a evolução do seu algoritmo de PageRank.

O Google faz uso do PageRank e de outros algoritmos com o objetivo de computar (indexar) e otimizar as buscas na web.

Para um exemplo hipotético, considere o cenário abaixo, com o volume de 200 TB e a capacidade de processamento de 50 MB/s (megabytes por segundo).

• Qual é o tempo estimado para a análise dos 200 TB de dados?

• O que deverá ser realizado para otimizar a latência de 46 dias (tempo de processamento)?

O uso de computação distribuída com capacidades de processamento e armazenamento massivo de dados é o caminho para soluções de Big Data.

As arquiteturas tradicionais terão dificuldades para escalar velocidade, assim como, seria humanamente impossível ler o livro de 1.000 páginas com baixa latência.

Considere a possibilidade de distribuir as páginas do livro para um grupo de dez pessoas, e ao invés de uma pessoa ler o livro sozinha, teremos dez pessoas lendo o livro em paralelo, considerando porções de cem páginas por pessoa. Este é um exemplo clássico de dividir para conquistar e a solução para reduzir a latência e aumentar o throughput do todo.

Variedade

A variedade dos dados está ligada principalmente à maneira como podemos trabalhar a identificação de sua estrutura.

Imagine uma farmácia com diversos medicamentos sem identificação de rótulos nas embalagens e sem etiquetas nas prateleiras. Considere que cada medicamento tem um código único (chave) de identificação que o associa a uma lista com as descrições detalhadas sobre sua composição, processo de fabricação, qualidade e regulamentações de saúde, desde a origem dos laboratórios até as prateleiras das farmácias. Por meio desse novo modo de identificar as propriedades dos medicamentos, podemos consultá-los considerando um número muito maior de atributos.

Dados estruturados (menor parte)	São provenientes de sistemas estruturados tradicionais.
Dados não estruturados (imensa maioria dos dados que temos à nossa disposição)	Gerados por e-mails, mídias sociais (Facebook, Twitter, YouTube, entre outros), documentos eletrônicos, vídeos e imagens, sensores, RFIDs. Estima-se que mais de 80% dos dados gerados atualmente são não
Dados semiestruturados	Normalmente registros de sensores, máquinas ou logs.

Conforme vimos anteriormente, a Web 2.0 foi um grande milestone (marco) para avançarmos com a computação de terceira geração. Novas semânticas de dados foram criadas com o objetivo de aproximar a linguagem humana da linguagem da máquina. Os conceitos de colaboração e interoperabilidade dos dados já são pensados há mais de uma década com esse propósito; e com o auxílio da web semântica, conseguimos evoluir adotando padrões que ajudam a integrar aplicações com o objetivo de compartilhar informações com ampla facilidade.

Para facilitar essa definição conceitual de variedade, vamos considerar que os dados estruturados são aqueles submetidos a processos de modelagens com o objetivo de normalizar e/ou definir um esquema (tabelas, colunas, data type, constraints) mais rígido, basicamente os dados que armazenamos em um SGBDR (Sistema Gerenciador de Banco de Dados Relacional). De maneira simples, todo o restante são dados não estruturados.

Big Data não tem o objetivo de tratar apenas os dados não estruturados, muito pelo contrário, sempre haverá uma necessidade de implementar algum tipo de estrutura para evoluir os metadados e facilitar o acesso aos dados. Alguns componentes de soluções Big Data são inclusive projetados para suportar SQL (Structured Query Language), por exemplo, um pouco longe dos conceitos de relacionamento, porém com base na sua estrutura tabular.

Mas um dos grandes diferenciais em relação ao padrão tradicional é a capacidade de manipular os dados não estruturados, considerando que as plataformas de segunda geração da computação (cliente-servidor) não foram projetadas para isso.

Veracidade

O significado de veracidade está intimamente ligado a tudo o que diz respeito à verdade.

Trabalhando com os dados estruturados ou não estruturados, é importante garantir que os dados são autênticos e fazem sentido, para evitar tomada de decisões com base na análise de dados incertos e imprecisos.

Pode ser prudente atribuir uma pontuação (score) de veracidade dos dados e classificação de conjuntos específicos de dados para garantir a qualidade da informação.

Quando analisamos dados de redes sociais, considerando análises de textos, por exemplo, corremos sérios riscos de concluirmos a análise com dados não verídicos, tais como as fake news. O que acontece com uma mentira reproduzida milhares de vezes na internet? Torna-se verdade, não é mesmo? Se não criarmos um processo de mitigação de cenários como estes, podemos tomar decisões imprecisas e pouco confiáveis.

Sempre foi importante tratar a veracidade dos dados, porém diferentemente dos modelos analíticos baseados em BI (Business Intelligence) tradicional, em que podemos confiar de “olhos vendados” nas fontes de dados comuns (ERP, CRM, Aplicações Corporativas); Big Data deve se preocupar muito mais com a veracidade, considerando as várias fontes de dados e a velocidade que precisamos impor para a análise.

Valor

Informações são comercializadas há muito tempo, em jornais, revistas, filmes, livros etc. Fontes de dados financeiros são produtos valiosos, e empresas como a Serasa Experian e Boa Vista Serviços lucram vendendo informações para o mercado, que depende delas, seja para crédito, seguros, antifraude ou alavancagem de clientes.

Quando trabalhamos com Big Data, os valores que buscamos dos dados devem ser definidos com clareza. Este é o maior motivador para direcionar um use case de Big Data.

Não é relevante armazenar um grande volume com possíveis variedades e requisitos de velocidade sem considerar um objetivo claro de extrair valor dos dados.

A necessidade de gerar valor é o principal objetivo de Big Data. Esse valor pode ocorrer pela agilização da tomada de decisão, aumento da precisão da análise com mais dados sendo correlacionados, redução dos riscos, criação de oportunidades. E assim justificamos um projeto de Big Data.

O valor pode ser muito mais do que uma forma de rentabilizar a receita para a corporação, considere os avanços nas pesquisas contra o câncer e doenças graves, a evolução nos controles do uso sustentável da água potável, maior transparência na gestão de contas públicas, e assim estamos sendo induzidos naturalmente a usar os dados para resolver problemas e evoluir com mais precisão nas análises complexas, até pouco tempo atrás inviáveis.

Monetização dos dados

O objetivo de monetizar os dados está relacionado à geração de receitas financeiras a partir de fonte de dados disponíveis ou em tempo real. Em resumo, tratar os dados efetivamente como um produto.

Algumas empresas de software especializadas em dados (com domínio de Big Data) estão criando soluções baseadas em modelos de negócios que propõem um compartilhamento de receita (revenue share), e usam o ativo dados das empresas como matéria-prima para alavancar receitas.

Considere o potencial de uma empresa de telecom com enormes volumes de dados e possibilidades de reduzir o custo de campanhas de marketing com propostas mais precisas. Por exemplo, no Brasil, as operadoras têm milhões de clientes, e as campanhas direcionadas para todos eles são pouco precisas e custam um valor altíssimo. Uma empresa fornecedora de soluções de análises baseadas em revenue share poderia propor uma abordagem mais precisa para a campanha, usando técnicas de real time analytics e reduzindo os custos de uma campanha de marketing com a proposta de atingir o público-alvo, segmentando com grupos de clientes ou até mesmo direcionado a cada cliente com base em eventos específicos.

Ou uma empresa financeira que pretende baixar os índices de fraudes de 0,1% (que representam milhões de reais mensais) para 0,01%. A empresa fornecedora da solução de análise de dados pode propor 30% do compartilhamento da receita (alguns milhões de reais) em caso de sucesso, referente ao retorno financeiro previsto. A empresa financeira não deverá pagar nada além do resultado comprometido, inclusive considerando a possibilidade de não obter sucesso, a empresa fornecedora da solução não receberá sobre o trabalho. Será um ótimo negócio para ambos, e dessa forma, muitas empresas e consultorias especializadas em monetizar os dados emergirão.

Podemos criar grandes ativos de dados fazendo uso de estratégias baseadas em API (Application Programming Interface), um conceito bastante difundido no desenvolvimento de software na era da computação em nuvem e importante para os novos modelos de arquitetura de TI.

A API propõe alguns mecanismos de interfaces para que possamos monetizar bases de dados. Por exemplo: o Google possui uma base de geolocalização com o serviço do Google Maps, porém algumas aplicações podem demandar um número de requisições diárias acima do limite considerado free e deverão pagar para usar o serviço. Esse modelo já foi implementado por grande parte dos gigantes da internet e deve ser referência para as empresas que estão buscando oportunidades neste mundo de negócios, cada vez mais baseado em dados.

Básico	1.000 requisições/dia = R$ 100,00/mês
Dados não estruturados	10.000 requisições/dia - R$ 250,00/mês
Dados semiestruturados	Ilimitado = R$ 500,00/mês