Blog que objetiva a discussão de conceitos de Governança e Gestão de Dados com os serviços de DM (Data Management) associados(Arquitetura,Modelagem de dados,BD,DWBI,MDM,DNE,Qualidade de dados,Metadados,etc) Também aspectos de maturidade via modelos MPS.BR,CMMI(ambos para Eng de SW) e DMM (Dados), além das novas formas e influências dos dados na sociedade digital.
Total de visualizações de página
quinta-feira, 29 de dezembro de 2011
Big Data- Parte X- Os Big Data e a cafeína.
quarta-feira, 21 de dezembro de 2011
Big Data- Parte IX- Os Big Data e as formas de armazenamento-Novas soluções-II.
Continuação
do post anterior: Discutindo alternativas para implantação de Big Data com
novas proposições e estruturações físicas.
Triplestore:
Outra forma de estruturação de dados se avizinha, buscando uma maior
flexibilidade na definição dos bancos de dados construídos na era dos
zettabytes. É chamada de Triplestore e nasceu como uma forma de embutir dados e
metadados na própria estrutura armazenada. Diferentemente dos modelos
relacionais que se baseiam na definição de ênuplas(várias colunas com valores,
numa relação normalizada), conceito simplificado para tuplas, a abordagem de
triplestore chega com uma proposta diferente. A ideia é que a unidade de
armazenamento mínima seja uma tripla, ou seja a conjugação de “sujeito” “predicado”
e “objeto”. Por exemplo, “Barbieri” “escreveu”
“livro” , ou “Isabella” “toca” “violão”, ou “Cláudio” “tem” “30”
(idade). Dessa forma, o armazenamento se
dá conjugando os metadados com os dados, explicitados através da tripla
combinação desses elementos. Isso sugere uma maior flexibilização na
incorporação de novos atributos, visto que se insere uma estrutura atômica do
modelo, sem impacto direto em conceitos de tabelas, linhas, etc. O modelo se
baseia no framework RDF- Resource Description Framework (RDF) .
Semelhantemente ao modelo relacional existe também acoplado a ele uma linguagem
de acesso e possibilidades de indexações instantâneas. Os gerenciadores de
triplestore já se mostram com a capacidade para armazenar bilhões de
triplas e alguns nomes já surgem nesse novo cenário, engrossando os conceitos
da Web semântica. Por exemplo, 3store, Allegrograph, Bigdata, BigOWLIM, Sesame,
Soprano,Virtuoso,etc são nomes que aparecem nesse cenário de novas alternativas
estruturais. O site da W3C http://www.w3.org/wiki/LargeTripleStores mostra uma
relação com diversos produtos desta nova cepa e alguns resultados
alcançados por mais de 15 desses RDF Data Base Engine. Alguns desses produtos,
como Virtuoso apresenta novas formas de indexações com bitmap, tradicionalmente
usado em pesquisas de campos de baixa cardinalidade.
Casssandra:
Outra variante de modelo de dados para esses novos tipos de Bancos de
dados é, por exemplo, o usado no Cassandra:
a)As colunas, que são as residências das informações, são associadas
logicamente em conjuntos chamados “família”. Uma família de colunas pode ter
várias colunas, ou até uma outra família dentro dela. As famílias são definidas
no momento da criação do BD. Porém, após esse momento, pode-se criar colunas
novas dentro daquela família de colunas;
b)As colunas são associadas a chaves específicas, ou seja uma
tupla(linha no relacional) pode ter colunas diferentes. No modelo relacional
deve-se usar o conceito de “nulos” para as colunas que não tem valores naquela
tupla. Os valores de uma família de colunas, associadas a uma chave, são
armazenadas juntas.
Em alguns produtos semelhantes, as colunas são armazenadas também
contendo as regras de de domínios, numa
espécie de acoplamento dos dados com os seus metadados, todos habitando o mesmo
espaço. Isso permite que consistências e
integridades sejam aplicadas no momento de acesso ao dado, agilizando as
verificações e manipulações aplicadas
sobre eles e definidas como regras.
MongoDB
Um dos produtos que começa a aparecer nessa nova seara de NoSQL é o
MongoDB. Já usado em algumas aplicações específicas em BH, o produto se
denomina um Banco de dados de documentos. Na realidade, o conceito de documento
apresentado pelo produto pode ser entendido como o de um “objeto complexo”.
Semelhantemente aos SGBDOO(Bancos de Dados orientados a objetos) dos anos 80, o
Mongo permite sob a capa de um documento, a definição de um objeto complexo. E o que é um objeto complexo, então? Um objeto
complexo é a definição de uma estrutura de dados, totalmente flexível e sem
regras estruturais colocadas, como vimos no modelo relacional, ou um pouco nos
anteriores(hierárquico e rede). Nessa nova proposta, por exemplo, cada linha(só
para dar a equivalência conceitual com os relacionais), pode conter qualquer
número de dados associados a uma chave primaria, um Object-id definido
internamente. Os dados associados a cada chave podem formar famílias de
colunas, sendo que cada coluna pode ser , por sua vez, uma estrutura complexa,
como outra família de colunas, ou array, ou apontadores recursivos. Cada linha,
identificada, pode ter um número de colunas diferente de outras linhas da mesma
Entidade. Por exemplo, um certo cliente poderá ter 20 colunas, e outro
100, fugindo um pouco das abordagens de campos nulos, trazidos nos conceitos
relacionais, para tornar as linhas homogêneas. Assim, por exemplo, um documento (objeto) Projeto pode ser formado
de dados de projetos, de dados de Equipes, que por sua vez são
formadas de dados de Empregados. O que acontece é que o
que seriam estruturas bem comportadas em modelos relacionais ou hierárquicos,
no MongoDB, pode aparecem como um objeto complexo, como que já “joined” e
entrelaçados. Embora com uma estruturação complexa, passível de recursividades,
o produto permite que a busca seja feita somente trazendo os pedaços
de informações desejadas. Usam a indexação baseada em BTree e permitem acessos
muito rápidos em dados estruturados segundo essa concepção. Não oferece
conceitos transacionais padrão de ACID e de SQL, ficando por conta do
programador a incumbência de estabelecer esses controles, caso desejados. Tem
forte vocação para inserções em massa, com dados sem grande volatilidade de
modificações. Exatamente como se espera em aplicações como Twitter, Linkedin,Facebook,
e-mails, etc onde milhões de “posts” são
inseridos, mas não deletados ou modificados. A sua estrutura de objeto complexo
permite a modelagem de informações de forma rica, criando possibilidades de
aplicações em gerência de conhecimento, repositórios para produtos de BPM, etc.
Resumo da ópera:
Com a diminuição de custos de armazenamento e a busca por maior rapidez e flexibilidade nas estruturações e pesquisas, o conceito de BI2 também se valerá dessas novas proposições, principalmente para armazenamento de grandes volumes de dados que se mostram como forte tendência nessa década. Existe um conjunto enorme de alternativas desenvolvidas e em desenvolvimento, na sua maioria dentro do espaço dos códigos livres. O segredo para se adotar uma proposição correta será:
1)Analisar cuidadosamente os seus requisitos de dados(estruturados,
semi-estruturados, ou não estruturados), com análise crítica das necessidades
de volumes, velocidade de processamento e periodicidade e tipos de atualização;
2)Executar provas de conceitos, usando essas novas propostas e
verificando a sua efetiva aplicação no item anterior(requisitos). Essas
ferramentas podem ser “baixadas” de núcleos sérios como Fundação Apache, por
exemplo;
3)Analisar a relação custo benefício, que envolverá não somente a
parte de arquitetura de “nós” , mas também a capacitação da equipe em técnicas
em conceitos returbinados como DFMS(Distributed File Management System),
processamentos em arquiteturas paralelas,
ambiente de alta tolerância, replicações,etc;
4)Finalmente decidir na teoria do melhor “encaixe” nas necessidades da
empresa, cuidando para deixar de lado o
ímpeto pelo uso dos modismos. Lembre-se que para cada problema poderá aparecer
uma solução adequada, seja ela o velho e tradicional SGBDD, ou os novos e
desafiadores frameworks, como Hadoop/MapReduce, ou soluções NOSQL.
A figura abaixo ilustra os principais conceitos que diferenciam o
tradicional modelo relacional e os novos modelos NoSQL.
A figura abaixo ilustra os principais conceitos que diferenciam o
tradicional modelo relacional e os novos modelos NoSQL.
Fontes:
Barbieri,C. BI2-Business Intelligence-Modelagem e Qualidade. Elsevier,2011
Roebuck, K. Storing and
managing big data-NoSQL,Hadoop and more
O´Reilly Radar Team. Big
Data Now: Current perspectives from O´Reilly Radar
Sydle-Entrevista com a equipe de BD da empresa, sobre a aplicação de
MongoDB-Novembro de 2011
sábado, 10 de dezembro de 2011
Big Data- Parte VIII- Os Big Data e as formas de armazenamento-Novas soluções-I.
Com o aparecimento do conceito de Big Data, novas formas de
armazenamento e acesso aos dados, agora em escalas muito superiores, começaram
a aparecer. Acostumados com os conceitos de Bancos de Dados e de DataWarehouse
como sinônimos de depósitos de grandes volumes, a comunidade começou a se
inteirar de novos termos e produtos, até então desconhecidos na camada das
aplicações tradicionais. Nomes como Hadoop, BigCouch, BigTable, Cassandra,
Cloudera, MongoDB, Hive, etc começam a surgir e a serem discutidos como
soluções para essa nova fase de estruturação e acesso de grandes volumes de
dados, sem uma grife por trás, digamos assim. Marcas desconhecidas no grande
mercado dos gerenciadores de dados.
De maneira geral esses produtos podem ser entendidos como
participantes de camadas que tem estruturações arquiteturais diferentes. Uns
são mais voltados para o armazenamento
dos dados, normalmente na forma distribuída, onde as unidades de
informações(dados, metadados etc) são espalhadas por centenas e até milhares de
“nós” processadores ligados em rede, com topologias diferentes(master-slave, ou
peer-to-peer). Podem ter a conformação de Gerenciadores de bancos de dados
distribuídos (SGBDD) ou de gerenciadores de arquivos distribuídos(DFS). A diferença está
no conjunto de funcionalidades embutidas, com os SGBD distribuídos, que normalmente oferecem aspectos de schemas, DDL,
conceitos de ACID, acrônimo para Atomicidade, Consistência, Isolamento e Durabilidade.
Nessa categoria, os produtos ditos NOSQL DB podem oferece características
diferentes dos “ tradicionais” SGBDD, não se utilizando de linguagem SQL e
modificando os aspectos de normalização(por exemplo, abdicando da 1ª forma normal),
e assim, se afastando do modelo
relacional, tradicional nos produtos SGBD a partir da década de 80. Nessa
categoria aparecem o BigTable, da Google, o Dynamo da Amazon, o Cassandra do Facebook,
por exemplo. São produtos de BD que priorizaram a disponibilidade dos dados à sua
consistência., em função do volume e do
estilo de aplicação a que foram direcionados inicialmente. Por outro lado, no
domínio dos DFS(sistemas de arquivos distribuídos), aparecem nomes como Hadoop,
framework inspirado no GFS(Google File System), inspirado inicialmente nos
laboratórios de Mountain View. Acoplados às camadas de distribuição e
armazenamento de dados, aparecem frameworks capazes de comandar o tratamento
das pesquisas , agora resolvidas em milhares de “nós”, com dados replicados
para garantir alta tolerância e retornar os dados selecionados, filtrados e
consolidados. Nesse universo apareceu o padrão MapReduce. Essa dupla, Haddop-MapReduce
é hoje, um par de conceitos dentre os mais discutidos na computação de nuvem e
serviram para a produção de várias tecnologias derivadas.
Hadoop-MapReduce
Oriundos do fenômeno Google que ensinou ao mundo como processar e
pesquisar montanhas gigantescas de dados, essa nova tendência aparece com muita
força nas soluções emergentes do mercado de altíssimo volume de dados. Em 2003,
quando o Google se defrontou com o desafio de indexar a internet toda, colocando
todas as páginas passíveis de serem acessadas pelas suas máquinas de buscas,
apareceram as primeiras ideias. Para resolver esse enigma, um conjunto de
engenheiros da Google definiu o conceito de MapReduce, conjugado com o complexo sistema de
gerência de dados (FMS) desenvolvido pela própria Google, que seria a origem do
Hadoop.
A ideia por trás do MapReduce é um framework de programação que foca fortemente
o processamento e o armazenamento distribuído de dados, além de estruturações
de dados que em nada lembram as tradicionais tabelas e relações que conhecemos.
Com o melhor da filosofia “dividir para
conquistar”, a proposta visa a quebrar um enorme conjunto de dados em “tascos”
menores que serão espalhados por
milhares de nós processadores. Um nó controlador, tipo master, quebra as
perguntas em pequenas consultas que são enviadas aos nós processadores
subordinados e depois retornam, quando são agregadas numa resposta coesa. O
Google reescreveu todo o seu sistema de indexação para se utilizar das
vantagens da proposta de MapReduce. Além de trabalhar com essa esquadrilha de
nós processadores, o framework ainda
possibilita a estratégia de fault-tolerance,
que garante que, mesmo que haja queda em alguns dos muitos nós, os
remanescentes se incumbirão de realizar as tarefas que não puderam ser
terminadas. Os dados são replicados em vários nós, garantindo que no caso de falhas
de uma cópia, outras estarão disponíveis.
A proposta foi revolucionária na medida em que permitiu que, em vez de
um ou alguns supercomputadores, todo o processamento possa ser executado por inúmeras
máquinas menores, mais baratas e com menor investimento. Um conjunto de
processadores comprados como “commodities”, alocados em vários racks, acabaram
formando um instrumento poderoso para processar altos volumes de dados. No
conceito de cluster Haddop, cada um dos servidores da rede pode ter 2,4 ou 8
processadores e você poderá ter centenas de servidores, cada qual tomando conta
de um pedaço do grande volume de dados, traduzido em fragmentos distribuídos. O resultado oriundo desses milhares de
processadores, originados de uma consulta, retornam para uma camada redutora
que transforma os milhares de resultados parciais em um conjunto final a ser
entregue a quem fez a solicitação. A
tecnologia permitiu que a Google tornasse o seu sistema muito mais inteligente
trocando a complexidade anteriormente existente pelas análises de
comportamentos dos usuários Google, com oferecimento de novos produtos e
desenvolvimento de melhorias que alcançaram também os produtos Google Maps e
Google Earth. Os detalhes mais secretos da tecnologia MapReduce e de seu Google
FMS permaneceram proprietários, porém a empresa permitiu a publicação aberta de
alguns conceitos subjacentes. Essas publicações permitiram o desenvolvimento de
alternativas no mercado. Quando o site
Yahoo percebeu a força da proposta do concorrente, juntou esforços para
desenvolver algo semelhante, criando o Hadoop, batizado em função do nome de um
brinquedo (baby elephant). O Hadoop
não é considerado propriamente um SGBD (Sistema Gerenciador de Bancos de Dados),
ficando mais centrado na categoria de um gerenciador distribuído de arquivos -
DFMS (Distributed File Management System). É caracterizado pela ausência de uma
linguagem específica como o SQL e por uma
forma estrutural menos rigorosa, como a definida pelo modelo relacional,
que é moldado por normalizações e regras de dependências funcionais. O Hadoop,
ao contrário, permite uma forma flexível de definições estruturais e não
oferece uma linguagem DML (Data Manipulation Language) padrão, podendo ser
trabalhado por qualquer linguagem do mercado. O Hadoop tem grande parte de sua
força na combinação com a estratégia de distribuição de dados, através de uma
arquitetura MPP, em que uma esquadrilha de servidores oferece “escalabilidade”
linear. O Hadoop aplica o modelo de programação do MapReduce, possibilitando a
criação de aplicativos em qualquer linguagem e que roda em paralelo, dentro da
arquitetura distribuída estabelecida. O Hadoop não trabalha na forma
transacional, sendo vocacionado para processamentos batchs que executam os programas desenvolvidos. Nesse estágio não
há consultas interativas. Não comporta acessos randômicos aos dados,
trabalhando de forma sequencial, o que pode trazer certas restrições em tipos
de processamentos com workload misto (atualização
e consulta) que exigem acessos aleatórios. Hoje o Hadoop se destaca como um
ambiente de processamento com “escalabilidade” infinita, tratando altíssimos
volumes de dados que seriam inviáveis de ser tratados (armazenados e
processados) num RDBMS tradicional. Como um DFMS, o Hadoop permite o tratamento
de dados estruturados, semiestruturados e não estruturados, potencializando o
seu uso na web. Hoje o Hadoop permite
a análise do que cerca de 300 milhões de pessoas veem no site do Yahoo, minerando o seu comportamento e alternando
dinamicamente home páginas por onde
eles se deslocam. O Yahoo estima um investimento de dezenas de milhões de
dólares no seu desenvolvimento, mas a sua essência é mantida como open-source. Até a Microsoft,
normalmente refratária aos aspectos de open-source,
também adotou o Hadoop quando incorporou a empresa Powerset a fim de melhorar a
sua máquina de busca. No Facebook, o Hadoop é usado para gerenciar 40 bilhões
de fotos armazenadas na maior das redes sociais. A empresa Eyealike, por sua
vez, aplica o Hadoop para o reconhecimento facial em fotos. O Hadoop agora é um framework de código aberto da Apache e está sendo usado
por algumas empresas como Comscore (especializada em aplicações de inteligência
no mercado digital) e CBS Interactive (com foco em marketing digital)
para tratar gigantescos volumes de dados e prepará-los para estruturas de BI/analytics.
O produto pode ser obtido na Apache
Foundation, em módulos independentes, mas pode ser comprado de terceiros como
Cloudera e IBM, em pacotes.
O pacote é uma unidade com vários componentes testados para
garantir compatibilidade e estabilidade entre as partes, além de vir com
suporte e serviços na base de assinatura. A Cloudera também
está desenvolvendo aplicativos focados
em segmentos verticais, como financeiro, biotecnologia, energia, varejo e
seguros baseados nos conceitos do MapReduce e em um FMS (File Management
System) similar (com busca paralelizada em sistemas MPP e fault tolerance). Em algumas soluções,
como a da Aster, são
desenvolvidas funções de tratamento de pesquisa, otimização, particionamento de
dados, classificação, etc., por vezes embutidas numa sintaxe SQL-like e que são executadas nos “nós” em
que partições de dados são previamente armazenadas. Isso tudo dentro do estilo
de arquitetura que envolve dezenas de centenas de nós, alguns com objetivos
específicos, como armazenamento de metadados, analisador, otimizador e
distribuidor de consultas . Com o objetivo de
otimizar os acessos, o Hadoop adota blocos físicos de tamanho grande (64MB). A
solução também foca o processamento in-memory
e máquinas MPP (Massive Parallel Processing). Essa arquitetura é voltada para o
tratamento de grandes arquivos, como click-stream
data base, que registram os passos de um internauta pelo site através dos cliques de uma sessão,
ou para o processamento de dados da Catalina, por exemplo, em que pesquisam
dados de milhões de clientes que usam cupom, para montar modelos de
comportamento. A parte cuidadosa na
adoção de umas solução dessas é
exatamente a sua imaturidade,
comparada com o SQL quarentão, além de conceitos novos, incomuns e não tão
fáceis como os tradicionais relacionais. A Google e a IBM têm programas para o
ensino do Hadoop nas universidades, visando à sua maior adoção. Outros produtos
dessa linhagem são GreenPlum, adquirido pela gigante do mundo de
armazenamento EMC e DataMeer.
Pontos fortes da estratégia Hadoop:
Sempre que as novidades aparecem é
importante analisá-las sob certos aspectos, conforme a seguir:
Custo: o software
é livre e, quando comparado com o custo de uma estrutura de SGBD relacional
necessário para tratar dados no volume da era dos zettabytes, torna-se mais atraente ainda;
Dados: por possuir uma abordagem sem esquema
formal de dados o Hadoop e o MapReduce
trabalham bem com qualquer tipo de dados. O MapReduce interpreta os dados em
tempo de execução, baseado em estruturas simplificadas do tipo “chave=valor” definidos em um programa de MapReduce. Dessa
forma, o programa pode trabalhar com facilidade no tratamento de dados
estruturados, semiestruturados e não-estruturados, como imagens, textos, etc;
Escalabilidade: o produto
é um DFMS que trabalha em
arquitetura MPP que roda em um conjunto de servidores,
oferecendo “escalabilidade” linear. Possui overhead
pequeno se comparado com os gerenciadores relacionais;
Modelos de dados: o Hadoop
é um DFMS que não necessita de um esquema ou conceitos de normalização para
tratar os dados, nem uma linguagem especial para acessá-los. O produto oferece
alta performance e facilidade, via aplicações como Flume, para receber, tratar
e transferir altos volumes de dados;
Administração do ambiente: o produto
automaticamente gerencia as falhas nos diversos nós da arquitetura, além de
oferecer facilidades para manipulação grandes clusters de máquinas, rodando programas que executam em arquitetura
paralela.
A figura abaixo ilustra o conceito de
Hadoop-MapReduce
Grande volume de
dados
(Tera-Peta-Exa)
dividido em
milhares de
pequenos arquivos
|
Milhares
de nós processadores, com dados e funções de Map e Reduce
|
• Dados e funções
replicadas,
• Armazenamento key-value,
alta
taxa
de compressão
• MPP
• Fault Tolerant
|
Consulta:
é mapeada (dividida) em diversas subconsultas
Enviada
a diversos nós processadores, controlado pelo nó master
Retornam
ao Master que os consolida (Reduce) na resposta
|
Nó
master
|
Resultado
|
Map
|
Reduce
|
Outros
“nós”
|
Grande volume de
dados
(Tera-Peta-Exa)
dividido em
milhares de
pequenos arquivos
|
Milhares
de nós processadores, com dados e funções de Map e Reduce
|
• Dados e funções
replicadas,
• Armazenamento key-value,
alta
taxa
de compressão
• MPP
• Fault Tolerant
|
Consulta:
é mapeada (dividida) em diversas subconsultas
Enviada
a diversos nós processadores, controlado pelo nó master
Retornam
ao Master que os consolida (Reduce) na resposta
|
Nó
master
|
Resultado
|
Map
|
Reduce
|
Outros
“nós”
|
Grande volume de
dados
(Tera-Peta-Exa)
dividido em
milhares de
pequenos arquivos
|
Milhares
de nós processadores, com dados e funções de Map e Reduce
|
• Dados e funções
replicadas,
• Armazenamento key-value,
alta
taxa
de compressão
• MPP
• Fault Tolerant
|
Consulta:
é mapeada (dividida) em diversas subconsultas
Enviada
a diversos nós processadores, controlado pelo nó master
Retornam
ao Master que os consolida (Reduce) na resposta
|
Nó
master
|
Resultado
|
Map
|
Reduce
|
Outros
“nós”
|
Assinar:
Postagens (Atom)