Muito se fala hoje em dia sobre Big Data, Data Mining e outros conceitos relacionados aos dados, coisa que todos nós estamos expostos a todo o momento, seja no trabalho, em casa, no lazer ou nas ruas.
Ano passado, quando participei do TDC (The Delevopers Conference - 2013), ouvi uma boa definição sobre Big Data. Dizia a respeito de quando os dados com quais são necessários lidar passam a ser um problema para você ou sua organização.
Algumas pesquisas estimam que a quantidade de dados no mundo dobre a cada dois anos (EMC, 2014). Outras, estimam que 90% de todos os dados disponíveis hoje foram criados nos últimos dois anos (SIENCE DAILY, 2013). De qualquer forma, a previsão do crescimento exponencial de dados é assustadora.
O público do Viva o
Linux é majoritariamente composto por sysadmins, developers, product managers, team leaders ou mesmo entusiastas da tecnologia.
O que os dados e um pouco de contexto que coloquei acima pode significar para você? É isso que a série de artigos, começando com este, propõe-se a fazer: situar o significado da era de Big Data que estamos vivendo e trabalhar em cima de uma das abordagens do tema, que é a busca de dados. Embora existam outras, como estratégias de armazenamento e modelagem de dados.
É importante lembrar que a preocupação com a busca de informações relevantes não é algo novo. O
Babbo classificou o sistema de busca corporativa como "Mina de Ouro", em 2008.
Aqui no próprio Viva O Linux, Alessandro de Oliveira Faria (o Cabelo) fez um excelente
artigo (só pra variar, né?!) sobre um sistema de busca corporativa chamada IBM OMNI Find Yahoo.
Conceito
Quando se fala de Big Data, existem muitas definições a respeito do tema. SEMANTIX (2014) publicou um post com definições fornecidas por referências na indústria de TI. Profissionais de renome que trabalham todos os dias com o desafio de lidar com Big Data.
A parte das definições fornecidas, quando se trata de Big Data estamos nos referindo às três características fundamentais deste novo desafio da gestão de dados, mais conhecidos como os "três Vs" de Big Data:
- Volume :: trata-se da quantidade total de dados coletados e armazenados. Não faz muito tempo que o grande problema era lidar com grandes volumes de dados da ordem de gigabytes. Hoje, falamos da realidade de lidar com ordens de PetaBytes, números tão grandes que são inconcebíveis naturalmente para a mente humana. O tamanho dos dados é comumente visto como o primeiro grande desafio de Big Data;
- Variedade :: trata-se da origem e tipos de dados coletados. Além do volume, precisamos lidar com dados de diversas fontes (banco de dados, arquivos de texto, planilhas, arquivos de mídia, redes sociais, ERPs, sensores, IoT, etc) e de diversos tipos (dados estruturados e não estruturados, sendo o último aquele que frequentemente demanda maior esforço). O objetivo é coletar dados com estas características e organiza-los de forma coesa e que façam sentido para aplicações e pessoas que as usem;
- Velocidade :: trata-se do tempo de espera para ter acesso aos dados. Como os volumes de dados tendem a ser cada vez maiores, encontrar informações relevantes, precisas e rápidas torna-se um desafio sem precedentes. O objetivo é encontrar recursos, tecnologias e métodos para responder a este desafio.
Um caso real
No continente europeu existe uma empresa chamada GEFCO. Ela é subsidiária da Peugeot e é responsável pela logística de veículos e peças novas das fábricas para centros automotivos.
Segundo DEVMEDIA (2013), a GEFCO trabalha com aproximadamente 100.000 eventos diários, referentes a 600.000 veículos em 80 países. Na prática, isso significa 5 terabytes de informações, que são disponibilizadas para clientes via portal WEB, com disponibilidade 24x7 e com latência de atualização de dados da ordem de 15 minutos.
A situação é bem diferente da anterior, onde a disponibilidade do sistema mal superava sete horas por dia e a latência de atualização de dados era de 24 horas, além de os clientes terem que esperar inaceitáveis 30 segundos para ter acesso aos dados solicitados.
O que a GEFCO fez, na verdade, foi substituir o sistema antigo de buscas, baseado em banco de dados Oracle, por outro baseado no paradigma de motor de busca corporativo (Enterprise Engine Search). Mas a Oracle é conhecida por ter um sistema de banco de dados muito robusto e altamente performático.
Todos estes atributos são verdadeiros para o sistema da Oracle, mesmo assim, o carro-chefe de Larry Ellison não aguentou o tranco! O que deu errado?
Histórico de banco de dados e suas tecnologias
Edgar Frank Codd (1923 - 2003) foi um cientista da computação nascido em Portland, Inglaterra. Ele trabalhou nos anos 60 e 70 na International Business Machines (IBM) e se tornou famoso e entrou para a história por ser o inventor do modelo relacional para banco de dados, conhecida como a teoria de base para banco de dados relacionais (WIKIPEDIA, 2014).
Edgar listou doze regras que definiam como um banco de dados relacional deveria funcionar (WIKIPEDIA, 2013).
Nos anos 80 já havia vários fabricantes de bancos de dados alegando se tratar de um SGDB (sistema gerenciador de banco de dados relacional). DEVMEDIA (2013) afirma que a IBM foi uma das primeiras empresas a pesquisar e desenvolver bancos de dados relacionais e a linguagem que seria chamada de SQL (Structured Query Language), mas o grande salto foi dado com a Oracle, com o lançamento do primeiro banco de dados que usava e implementava tal linguagem.
Nos anos 90 foi a vez da Microsoft em parceria com a SyBase, lançar seu banco de dados para o sistema OS2. A Oracle lançou seu primeiro SGDB em 1979, já a IBM em 1983.
Portanto, na melhor das hipóteses, se hoje você usa banco de dados relacional está lidando com um conceito e tecnologia que tem no mínimo 24 anos de idade. É até provável que esta tecnologia seja mais velha que a pessoa que está lendo este artigo agora! :)
Vinte e quatro anos é uma eternidade para a tecnologia da informação, sobretudo depois das transformações profundas que começaram a acontecer a partir das décadas de 1990 e 2000. Será que estas tecnologias ainda estão aptas para uma nova realidade de dados que se apresenta hoje para a humanidade? A resposta é parcialmente não!
A Microsoft (2009) publicou a migração de um grande banco privado do Brasil (Banco Itaú) do sistema Mainframe para o sistema Microsoft SQL Server 2008, para cálculo de PDD (Provisionamento para Devedores Duvidosos) e simulações nas mudanças de políticas de concessão de crédito. O tempo de processamento de informações despencou de 12 horas para apenas e estarrecedoras TRÊS HORAS!
Concordo com o texto da Devmedia. Esta mudança deve ser interpretada muito além de sucesso na migração, curto tempo de ROI e a imagem de modernização que o Itaú estava disposto a transmitir para o mercado. Repetindo ipsis-iteris, "hoje SQL Server é o que o Mainframe era vinte anos atrás".
Bancos de dados relacionais são muito bons para garantir controle transacional de operações, como garantir que o dinheiro transferido de uma conta "A" chegue corretamente na conta "B" ou que todo o processo seja desfeito (rollback). Entretanto, as aplicações e necessidades atuais exigem sistemas de banco de dados compatíveis com sistemas complexos e poderosos de busca (o foco deste artigo), sistema de recomendações (muito usado em redes sociais e e-commerce), negociações de alta frequência, catálogo de produtos e serviços, ACLs para usuários e grupos, análises de logs, repositórios de mídia, armazenamento de mensagens e e-mail, entre outras tarefas. E bancos de dados relacionais, bem como softwares baseados nestes, não conseguem entregar boas respostas para estes desafios.
O fato é que até pouco tempo (na verdade até hoje, nas mentes dos que ainda não entenderam a era em que vivemos), as aplicações deviam se vergar ao banco de dados. Precisa armazenar um novo conteúdo e mostrar na sua aplicação e precisa de uma nova coluna em uma entidade do banco? Ajoelhe-se perante o DBA e justifique que a entidade precisa receber um ALTER TABLE para atender este requerimento. O banco de dados era o foco das aplicações.
Hoje, o foco é atender as necessidades e desejos do USUÁRIO. Logo todos os sistemas devem empregar esforços para satisfazer as necessidades esperadas pelos usuários, inclusive o banco de dados.
Uma destas necessidades é encontrar informações relevantes, com a maior precisão possível e de forma rápida. Mas, como fazer isso?
Estratégia de pesquisa de dados
Quando falamos em pesquisa de dados, existem hoje três estratégias disponíveis para serem usadas. É importante lembrar que elas não são mutuamente excludentes, ou seja, nada impede que uma estratégia complemente a outra.
- Categorização :: esta estratégia é geralmente conduzida e liderada por especialistas diretamente ligados ao negócio, durante a inserção de dados. O objetivo é (pelo menos) tentar antecipar pesquisas feitas por usuários e definir encadeamentos ontológicos que terão como missão responder aos pedidos mais comuns. É uma estratégia muito útil quando o usuário não tem a menor noção do que ele quer pesquisar, logo as ontologias expostas ajuda a refinar a pesquisa. Por outro lado ela tem sérias desvantagens, porque as ontologias podem não corresponder aos critérios de pesquisa imaginados pelos especialistas de negócio ou mesmo não fazer nenhum sentido para os usuários. Por exemplo, se eu pedir para 10 usuários do VOL organizar 100 livros, garanto que cada um vai organizar seguindo seus preceitos e, ao pedir para os usuários mutuamente verem as organizações feitas, a organização feita por um usuário do VOL pode não fazer sentido para os outros nove;
- Interface de pesquisa detalhada :: é uma estratégia muito útil quando o usuário sabe exatamente o que está procurando. Apresentam campos que permitem aos usuários ajustarem os parâmetros de pesquisa às suas necessidades de consulta. Mas exige que os usuários tenham conhecimento sobre como os dados estão organizados, além de ser uma solução pouco amigável para a maioria dos usuários;
- Interface de pesquisa amigável :: frequentemente resume-se a uma interface simples, composta por apenas um campo onde usuários informam livremente linguagem humana sob a forma de texto como insumo para localizar as informações desejadas. É uma estratégia que entrega uma excelente experiência ao usuário, por exigir do mesmo poucos insumos para o sistema, de forma livre. Entretanto, esta estratégia coloca uma pressão brutal sobre o sistema de buscas, que a partir de agora precisa "entender" a linguagem do usuário e traduzir isso em informação relevante e de qualidade.
O essa série de artigos terá como objetivo demonstrar um sistema de busca baseado na terceira estratégia.
Conclusão
O objetivo deste artigo foi contextualizar o cenário atual de Big Data, reforçar por que devemos estar atentos a isso e apresentar insumos para a estratégia que será usada sobre a solução que será apresentada (baseada em Apache Solr).
O próximo artigo apresentará conceitos mais técnicos, apresentando características de dados, tecnologias (onde serão apresentadas algumas ferramentas, além do Apache Solr) modelagem de dados e conceitos matemáticos envolvidos.
A partir do terceiro artigo, o mesmo se tornará mais hands-on, mostrando o
Apache Solr, como instalar o mesmo (Jetty, Tomcat, JBoss e GlassFish), prospectar dados, etc.
Até acho que para quem é técnico (como eu) e gosta de mão na massa, é frustrante passar por estas etapas até chegar a abrir a tela preta. Porém, são conceitos muito importantes para saber onde estamos enfiando o pé e, principalmente, justificar para lideranças por que esta abordagem, se bem conduzida, pode produzir resultados surpreendentes.
Só para dar água na boca, garanto que mesmo em ambientes modestos, o ambiente que produzirmos juntos poderá ser capaz de ter uma
query que retorna um milhões de registros EM MENOS DE UM SEGUNDO! o_O
Até a próxima.
Referências
EMC. Digital Universe Invaded By Sensors. Acesso em: 23 setembro 2014.
Disponível em:
SIENCE DAILY. Big Data, for better or worse: 90% of world's data generated over last two years. Acesso em: 23 setembro 2014.
Disponível em:
SEMANTIX. O que é Big Data? Acesso em: 15 setembro 2014.
Disponível em:
DEVMEDIA. Introdução a sistemas de busca corporativa - SQL Magazine 80. Acesso em 20 setembro 2014.
Disponível em:
WIKIPEDIA. Edgar F. Codd. Acesso em: 28 setembro 2014.
Disponível em:
WIKIPEDIA. Codd's 12 rules. Acesso em: 28 setembro 2014.
Disponível em:
MICROSOFT. Economia em alta: Banco Itaú desenvolve sistema para cálculo de provisionamento para devedores duvidosos e alcança ROI em menos de um ano. Acesso em: 29 setembro 2014.
Disponível em: