O Big Data segundo análise não é uma ferramenta concreta e nem mesmo uma metodologia concreta, mas é um conceito de processamento de dados de mercados públicos.
Para entender melhor, é preciso fazer um retrospecto das evoluções no campo de banco de dados:
1) Arquivo
Este fenômeno trouxe ao processamento de dados o primeiro poder de armazenamento em pequena escala para agregar a sigla EPS (Entrada->Processamento->Saída). Em outras palavras com o desenvolvimento dos processadores, também foram desenvolvidos meios de armazenamento cada vez mais seguros, velozes e maiores.
2) Banco de dados simples
Após a descoberta de tecnologias físicas para persistir os dados processados, o campo da lógica desenvolveu o catálogo de arquivos para possibilitar a um processo organizar todos seus contextos em arquivos distintos. Vide o sucesso do DBASE nas plataformas de menor porte e do VSAM em plataformas altas com grande capacidade de processamento.
3) Banco de dados relacional
Após transformar arquivos em catálogos, ainda o campo da lógica percebera a necessidade de poupar espaços ao denominar valores repetidos de grandes tamanhos em tabelas (arquivos físicos). Para isso, criou adereço de relacionamento menor para representar o valor muito grande (em bytes) e muito repetido. O adereço é a chave utilizada para relacionar o grande valor não mais repetido ao seu registro original quando este fosse requisitado.
Aqui ocorreram grandes transformações no campo do banco de dados, pois para maior velocidade na recomposição do registro original, tabelas de registros precisavam ser ligadas com tabelas redutoras de volumes de dados, conhecidas hoje como tabelas de cadastros ou de domínios, mas de maneira veloz e não se podia para cada registro armazenado em fragmentos buscar sua composição varrendo completamente as tabelas de domínio.
Para resolver o problema, inventaram e evoluíram bastante as técnicas de índices. Os índices começaram com um clone da tabela a ser varrida, porém organizada pela chave de busca (o adereço de relacionamento) e estas tabelas eram denominadas de arquivos lógicos (logical file) e a tabela de registros era chamada de arquivo físico (physical file). Cada índice gerava um arquivo lógico não explícito normalmente por ser unicamente de interesse do gerenciamento do banco de dados. Porém, no início a atualização destes arquivos físicos perdia a integridade com facilidade e rotinas de reindexação eram entregues juntas com o banco de dados para serem executadas manualmente. Algo bastante recorrente.
Para resumir, as buscas mesmo com os índices eram morosas de serem programadas e por isso foi inventada a linguagem SQL para elevar a manipulação unitária de registros para a manipulação em escala.
Este fenômeno teve um impacto real na capacidade de produção de softwares no mundo inteiro. Aqui é importante destacar, a comunidade do Big Data busca algum feito equivalente, mas ao invés de atender uma escala corporativa, pretende impactar a forma de processamento de dados em uma escala maior ainda a utilizar a Internet como meio condutor.
4) Sistema Gerenciador de Banco de Dados (SGBDs)
Logo após o banco de dados relacional SQL e ainda com a contribuição dos gurus da época, as empresas de softwares passaram a desenvolver, sob a tutela do órgão regulamentador ANSI, bancos de dados profissionais capazes de armazenamentos e recuperação totalmente sofisticados a ressaltar o SYBASE, o seu herdeiro SQL Server comprado e renomeado pela Microsoft, o DB2 da IBM, o Oracle Database Enterprise da Oracle, o Ingress da CA, Informix hoje da IBM, o MySQL hoje da Oracle, o PostGresql ainda comunitário e outros de menor evidência no mercado, mas de grande importância para alguns ramos peculiares do processamento de dados como o geoprocessamento e o sócio-processamento demandados por setores normalmente governamentais ou militares.
Os SGBDs ainda são predominantes no mercado por causa da maturidade, garantias, desempenho, integridade, fácil desenvolvimento e manutenção alcançados em paralelo com a evolução das máquinas, meios de armazenamento e superação de muitos paradigmas computacionais a ressaltar o último, a própria Internet.
5) Banco de dados multi dimensional
No início deste milênio, muito se propagou a respeito deste tipo de banco de dados, porém ele emprestava como escravo os convencionais SGBDs e cuidava apenas de transformar dados operacionais em dados gerenciais a partir da ordem multi dimensional. Todos os SGBDs passaram a permitir a configuração em modo operacional (OLTP) em modo analítico (OLAP) porque a distinção entre estes modos determina consideravelmente a lógica de processamento de dados e armazenamento a ser realizada pelo SGBD.
O conceito do banco de dados multi dimensional foi pautado em reprocessar o banco de dados Entidade-Relacionamento (entenda por SGBD ao pé da letra) para a organização de Fatos, Dimensões e Tempo. Os Fatos na terminologia multi dimensional é uma ocorrência relevante financeiramente e histórica, ou seja, o fato é o registro transacional. As Dimensões são conhecidas como as entidades substantivas e por isso equivalem as tabelas de cadastro ou domínio do SGBD. Já o tempo foi externado como um entidade cronológica e escalonada em unidades de acordo com a necessidade do cliente final.
Em suma, o Fato é a tabela operacional ponderada ao patamar de granularidade (detalhada ao extremo , resumida ao extremo ou graduada entre estes dois últimos) desejada pelo analista e atribuída das chaves de ligação as Dimensões e Tempos encontradas em uma espécie de Fato.
A partir desse bastidor, ferramentas permitem ao usuário analista montar suas análises operacionais, táticas e estratégicas com arrastar de soltar de fatos, dimensões e tempo. Algo semelhante a geração de uma cross table em Excel, se você já fez isso alguma vez vai entender melhor este último passo.
O banco de dados organizado para fim gerencial (OLAP) é chamado de Data Warehouse. Simplesmente um nome simples para armazém de dados para o contexto analítico e não operacional.
6) Banco de dados orientado à objetos
Esta empreita foi um grande fiasco, pois muitos entusiastas e desconhecedores da história dos SGBDs pensaram em banir com o modelo Entidade-Relacionamento e no lugar de entidades pensavam em gravar o Objeto conceituado da Orientação à Objetos.
A ideia não era nada mal em primeira avaliação, porém isso acabaria com a capacidade de economia de recursos de armazenamento, desempenho e a flexibilidade da rastreabilidade relacional, atributos estes totalmente maduros nos SGBDs.
Este banco de dados orientado à objetos não vingou no mercado e se ainda existe, é em porção pífia.
7) Big Data
O futuro normalmente recorre ao passado, isso é uma verdade a ser considerada.
O Big Data ainda não tem nenhum consórcio e nem órgão normatizador determinados para desenvolvê-lo sem os vícios tendenciosos de empresas gigantes como a IBM ou Oracle somente por ilustração.
Mas sua ideia é clara quando se fala na maneira de armazenamento, algo parecido com o banco de dados multi dimensional ou grandes catálogos de arquivos sem normalização da Entidade-Relacionamento justamente para imprimir grande desempenho ao processamento. É daqui a primeira frase "O futuro normalmente recorre ao passado".
Se as informações são guardadas sem fatoração ou denominações de adereços para redução de espaço, sua recomposição torna-se muito mais veloz e esta é a proposta essencial do Big Data. Basta relembrar da flex table muito representada pelo VSAM e outros arquivos indispensáveis para o processamento em larga escala encontrado em programas sobre processadores RISC.
Note, o Big Data é o campo da lógica correlacionado com a evolução dos processadores, estes hoje atendem com maturidade a computação distribuída e a computação paralela. Ainda vale destacar um feito importante do campo dos processadores, o uso da preempção para priorizar racionalmente as demandas computacionais e de uma maneira federativa e organizada imprimir grande capacidade de processamento com menor custo. Se você tem um tablet ou um smartphone mais recentes, certamente esta evolução dos processadores está em suas mãos e você provavelmente não sabe.
No entanto, o Big Data sabe onde pretende chegar, porém ainda deve tratar de três obstáculos:
- onde armazenar tantos dados?
- como acessar estes dados reaproveitando todas as técnicas de busca desenvolvidas em outras gerações bancos de dados?
- como coordenar os computadores em unidades computacionais para obtenção de informações do Big Data tendo como meio condutor a Internet?
O armazenamento certamente será dividido por profissionais do ramo de grandes empreendimentos para adquirirem Data Centers inicialmente mais aplicados em Big Datas para compilar dados de alguns mercados e; ainda por estudantes e cientistas porque estes já estão em busca de novos paradigmas de armazenamento redundante cujo objetivo é a confiabilidade na integridade da informação. Talvez nada seja capaz de levar o Big Data a este patamar nos próximos anos porque os meios de armazenamento ainda são escassos e caros para todos, por isso uma solução híbrida que recompõe uma parcela dos dados perdida a partir de rotinas mais inteligentes de manutenção cuide desta escassez tida como obstáculo. Menciono indiretamente um armazenamento distribuído, porém em meios seguros e autorizados sem tentar roubar espaços dos bilhões de usuários leigos na Internet com a instalação forçada de aplicações escravizadoras de seus computadores pessoais. Esta ideia é por si insegura e ilegal.
O acesso as informações depende é claro de índices não vetoriais como a maior parte dos índices usados em SGBDs hoje. Aqui caberá como desafio a junção de índices com relacionamentos, ligações menores, mas registradas em metadados para responder em tempo hábil consultas sobre o Big Data.
Por último obstáculo, a coordenação das unidades computacionais é um desafio cuja computação nas nuvens já tem respostas porque esta se pauta em sistemas operacionais não exclusivo de uma máquina, é uma expansão gritante dos tímidos investimentos em clusters de processamento e das bem-sucedidas evoluções das máquinas virtuais. É opção de um Big Data utilizar do benefício da computação nas nuvens ou tentar uma solução melhor, apesar de aparentemente não existir. Se a computação é nas nuvens, há um receio do mercado de uma chuva de dados incontrolável, mas este receio já está sendo mitigado por cientistas e empresários da área porque a computação nas nuvens é um futuro esperado por muitos anos quando se falava ainda em ter apenas um terminal simples para processar os dados armazenados na Internet.
Empresas podem até dizer que superaram todos os desafios, mas ainda é cedo e os obstáculos ainda não foram transpostos ou contornados em fórum mundialmente organizado como foi o caso dos SGBDs com a ANSI.
Espero ter contribuído e se você tiver informações para agregar, entra em contato.
Boa sorte.
