Os impactos do Big Data sobre o armazenamento, em termos práticos

A sua implementação “pode” exigir que você opte por federalizar o dado, utilizar armazenamento em memória, incluir processamento analítico dimensionável, etc

O Big Data, como a Nuvem, não se refere a uma tecnologia em particular, nem a um conjunto de tecnologias. O Big Data define uma classe de problemas de gerenciamento de informações que são difíceis ou até impossíveis de se resolver de modo eficiente utilizando ferramentas e técnicas convencionais de gerenciamento de dados.

O Big Data é caracterizado comumente pelos cinco Vs: volume, velocidade, variedade, veracidade e valor. Os três primeiros Vs são certamente comuns, enquanto os últimos dois estão ficando cada vez mais evidentes no vernáculo do Big Data. Existe uma boa chance de que os pontos a seguir caracterizem os tipos de desafios que os cinco Vs podem estar causando na sua organização.

 O VOLUME das informações que você está acumulando sobrecarrega as pessoas, os processos e as capacidades técnicas do seu grupo de Gerenciamento de Informações Empresariais. Provavelmente, você vai precisar encontrar um conjunto de ferramentas e técnicas distintualmente (eu sei, essa palavra não existe, mas devia) diferentes para resolver este problema.

A VELOCIDADE cada vez maior com a qual as pessoas esperam que você analise e processe os dados já está excedendo as habilidades do seu pessoal e da sua infraestrutura.

Você bem que gostaria que o escopo da análise fosse limitado a um conjunto pequeno de armazéns de dados, mas a realidade sugere que esse escopo inclui uma VARIEDADE de tipos de dados, incluindo gravações de chamadas, documentos de texto, logs de sensores, tweets, curtidas, vídeos de segurança de estabelecimentos comerciais etc.

Algumas partes da sua organização têm dúvidas sobre a VERACIDADEdo reconhecimento facial nos dados dos vídeos de segurança. Armazenar arquivos de vídeo é fácil; identificar com precisão um rosto em um quadro único de um vídeo é tudo menos fácil.

Frases como “os dados são nossa maior fonte de VALOR não aproveitado” são escutadas todos os dias em sua organização. As pessoas que produzem essas frases, quando pressionadas a quantificar ou justificar o valor dos dados, ficam marcadamente silenciosas.

Ainda está lendo? Que bom.

Eu não ficaria surpreso se descobrisse que o MIS, a Inteligência de Negócios e a Analítica de Negócios estão no topo da atenção das organizações. Também não ficaria chocado ao saber que as empresas ainda gastam copiosas quantias de dinheiro em tecnologia, tanto em soluções quanto na integração a sistemas fonte em BI e sistemas relacionados. Eu arriscaria dizer que, em um nível bastante geral, as arquitetura de armazenamento de dados são da seguinte maneira:

As implementações “provavelmente” incluem vários sistemas fonte (que, naturalmente, precisam ser arquivados / protegidos / ter o back up feito), áreas de preparação para uma variedade de transformações e operações de aumento de qualidade, um EDW para servir de recipiente de ativos estruturados de informação, e muitos data marts para serem utilizados em tarefas específicas de análise. É claro que essa complexidade toda é perfeitamente automatizada e totalmente documentada. Ainda existem operações de TI que não são totalmente automatizadas e documentadas?

Estaria tudo ótimo se as organizações NÃO tivessem um problema de Big Data. A arquitetura descrita acima funciona muito bem quando as empresas possuem conjuntos de dados de fontes homogêneas e relativamente pequenos. Entretanto, digamos que o negócio está tentando introduzir um valor novo na organização, que “mexe” com o tipo de informação que a TI terá que passar a “conduzir”. Um novo aplicativo móvel que talvez seja implantado para milhões de clientes, que precisam ter impactos em TEMPO REAL nos negócios da organização. Talvez a tendência geral das conversas sociais precise ser analisada ao lado de ou contra a tendência de milhares de interações de centros de atendimento gravadas. Bem, neste caso, a TI terá preocupações a mais no seu design. Vejamos:

1 – Volume: Cada repositório adicional de dados, desde o sistema fonte até o data mart, nessa arquitetura pode vir a precisar armazenar petabytes de dados em vez de terabytes.

É impraticável manter backups operacionais e offsite para conjuntos de dados múltiplos e massivos.

Fazer streaming de dados do armazenamento à máquina de processamento (por exemplo, RDBMS) leva a um tempo de resposta a consultas inaceitável na escala do big data.

2 – Velocidade: O ETL pode significar um espaço enorme entre os eventos geradores de dados e a entrega aos consumidores de negócios.

A orientação “schema on write” requer um design e análise iniciais extensivos, atrasando ainda mais a derivação de valor a partir dos dados.

A tradicional arquitetura baseada em SAN tem dificuldades para crescer rápido o suficiente para atender às demandas.

Uma arquitetura orientada ao batch não é capaz de fornecer insight em tempo real.

3 – Variedade: A arquitetura EDW é otimizada para dados relacionais gerados por aplicativos de negócios.

Dados não estruturados ou semiestruturados estão se tornando tão importantes quanto dados estruturados para a analítica.

Custos de design e análise inicial exacerbados pela variedade em fontes de dados-fonte.

Veracidade: A falta de confiança implícita nas fontes de dados requer um ambiente que seja mais condutível à descoberta e exploração ágeis. Todavia, o alto custo do design e da infraestrutura inibe a agilidade, criando assim o paradoxo da “análise para investir, investimento para analisar”.

4 – Valor: As organizações frequentemente encontram dificuldades para encontrar valor em seus dados. Sem uma consideração cuidadosa, o big data somente tornará o valor mais difícil de se encontrar.

Com alguma esperança, você não estará chegando à conclusão de que o investimento da sua organização é uma enorme perda de tempo, dinheiro e esforços (por acaso você percebe um tsunami de Big Data vindo na sua direção…). Claramente, você está resolvendo problemas REAIS de negócios agora mesmo, e vai precisar CONTINUAR a resolver esses problemas no futuro. A sua arquitetura atual não vai desaparecer, mas você precisará explorar e se aproveitar de novas ferramentas e técnicas para garantir a derivação eficiente de valor nos negócios a partir dessa nova enxurrada de exigências.

A arquitetura “data lake” emergiu como uma resposta aos desafios colocados pelo big data à arquitetura de gerenciamento de dados. Note que o data lake complementa a arquitetura convencional de BI e analítica. Sugerir uma substituição total, dados os investimentos substanciais feitos por organizações em todo o mundo em BI, seria loucura.

Um data lake (ou como eu a chamo, a lagoa dos sete mares) ajuda em virtude de: armazenar os dados na condição em que se encontram, processar in loco, eliminar backups operacionais, otimizar a colocação e o armazenamento de dados, dimensionar de forma simples e barata, facilitar a exploração e a análise e trabalhar em uma escala de petabytes.

A sua implementação “pode” exigir que você “federalize” a sua informação fonte, em vez de centralizá-la (o que você, em última análise, não pode controlar ou prever); incluir streaming ou processamento complexo de eventos utilizando armazenamento em memória para gerenciar milhões de novas transações por segundo; incluir um modo de empacotar meta dados de informação não estruturada e armazenar em formato de objeto para o uso em ferramentas analíticas; incluir processamento analítico dimensionável em clusters Hadoop para criar valores de negócios combinados a partir de todas as fontes de informação.

Matéria completa: http://cio.com.br/

Os comentários estão fechados.