Depois de publicarmos uma série de artigos sobre Big Data, com uma breve pausa para falar de consultores e consultoria, uma pergunta
recorrente que aparece é: estamos com tecnologia capaz de enfrentar esses
gigantescos depósitos de informações, formados cada vez mais por volumes massivos de informações? . O desafio
tem uma quadra de letras “V”: volume, velocidade, variedade e volatilidade de dados. A resposta é sim,
considerando essas variáveis e vem por conta das evoluções tecnológicas que
normalmente acompanham os movimentos e tendências da sociedade e da indústria,
ou seja teremos, sim, arsenal para esse enfrentamento. A começar pelos
tradicionais fornecedores de soluções de BI, quer sejam IBM, Oracle, Microsoft e
Teradata. Não somente pelas tecnologias de que já dispunham, ainda que num
nicho especial, como Oracle RAC (Real Application Clusters), Teradata, IBM-DB2
Parallel Edition mas também pela busca de
novas formas de disponibilização capazes de enfrentar esses gigantescos
depósitos de dados. Para isso os grandes fornecedores de máquinas e de software
estão atualizando as suas plataformas
visando à capacitação para grandes consultas em peta/zettavolumes. Além disso, aparece um conjunto de novas
propostas, desenvolvido nos ninhos dos grandes produtores de informações de
hoje(Yahoo, Google, EBay, FaceBook, Twitter,Linkedin, etc) servirem de exemplo
para casos em que se busca uma relação confortável de custo benefício entre
petavolumes e investimentos necessários para acolhê-los. Apareceram nesse
pacote propostas como Haddop/MapReduce,
e novos formatos de Bancos de dados, como MongoDB, Google´s Big Table, Dynamo(Amazon),
HBase, Cassandra,CouchDB etc. Esses
novos produtos serão discutidos em “posts” futuros. Hoje, falaremos um pouco
sobre os velhos e conhecidos SGBD´s e suas propostas para o desafio dos grandes
volumes. Importante entender, entretanto é que os SGBD´s relacionais continuam
vocacionados para as aplicações que usam
dados mais estruturados, demandam transações com “workload” misto de alto volume de modificações e leitura,
precisam da blindagem do conceito transacional de ACID e estão acostumadas com
a linguagem SQL, sem a qual não conseguem diálogo. As outras soluções, como
veremos adiante, foram pensadas para outros cenários.
IBM:
A Big Blue tem várias propostas para o tratamento dos
petavolumes. Com a proposta Smart
Analytics a IBM oferece uma plataforma completa de hardware fortemente
vocacionada para grandes volumes aliada à uma camada de software especializada
em “analytics”, com serviços de cubos OLAP, data mining para textos e outras
formas de dados estruturados e não estruturados, dashboards e scoreboards. Por exemplo, o IBM Smart Analytics System,
usado numa operadora inglesa de telefonia móvel, a Hutchison, trabalha com
arquivos de 33TB e com perspectiva de mudança para 60TB em um ano. Além disso,
com a aquisição da Cognos, Netezza e da SPSS, este último um pacote
especializado em aplicações estatísticas, a Big Blue se considera pronta para o
“zettawar”.
Essas soluções estão normalmente associadas a um conceito de
“appliance”, que traduzido diretamente significa
utensílio doméstico com uma função específica. Nesses cenários, a solução do
tipo “appliance” permite uma forte combinação escalável de hdw/sw, no
tratamento de altos volumes, meio que tipo porteira fechada, envolvendo o SGBD
turbinado, o sistema de armazenamento e a arquitetura dos servidores
envolvidos. Tudo com certa vocação para altos volumes, conforme veremos adiante. A grande aquisição da IBM,
nesse campo, foi a Netezza. Empresa criada em 2000, ela se especializou na
produção de soluções de alta performance para grandes volumes de dados(BD,
DataWarehouses,etc), atuando com foco em segmentos específicos, como energia, utilities,
varejo, telecomunicações, finanças, saúde e governo. A idéia da Netezza foi
desenvolver uma solução integrando softwares de tratamento de dados, servidores
com arquiteturas MPP e sistemas de storage, com um grau de acoplamento entre
eles capaz de obter níveis de performances, impossíveis de serem conseguidos
com soluções, digamos em camadas separadas. A ideia da Neteza se baseia em
otimização de comandos de bancos não somente mais em níveis de otimizadores de
softwares, mas também trazendo o hardware e o firmware para fazerem parte do
mecanismo de upgrade de performance. Com uma arquitetura de hardware disposta em duas camadas, a primeira tem a função de receber a requisição
do comando , digamos SQL, que será dividido em diversos subcomandos(planos de
execução). Esses subcomandos serão enviados para a segunda camada , composta
por lâminas(blades) de processadores, que poderão ter vários elementos de
processamento(multi core-duo,quad,hexa,octa,etc). O sistema de disco, com
drivers independentes permitirá a busca paralela dos dados no seu armazenamento
físico, acionados pelos processadores independente do “ blade” . Além disso, a
Netezza desenvolveu soluções proprietárias, como o FPGA(Field Programmable Gate
Array), que pode ser entendido como chips otimizados, modificados em campo,
capazes de resolver, no plano de firmware/hardware, funções de seleção,
compressão e descompressão de dados. Ou seja, alguns desses chips/processadores
são dedicados a funções específicas de dados. Dessa forma, além dos aspectos de
otimização de código feito pelos SGBD´s, também melhorias de performance de
comandos são realizadas num plano físico de processadores. Essas melhorias
integradas no conceito de appliance, permitem
o alcance de taxas de vários TB de dados por hora, tanto para carga quanto para
backups . Essas melhorias se acoplam a
outras, como o de processamento in-database.
Esse tipo de processamento busca aproximar os SGBDs dos dados, na medida em que
oferecem recursos extras, como funções especializadas para tratamentos
analíticos, já dentro do kernel do
SGBD, evitando transferências de dados para outros ambientes a fim de se submeter
a um processamento analítico. É algo como um engine SQL dotado de funções e otimizações de acessos às estruturas
específicas dos ambientes de BI, como modelos dimensionais, resolução direta de
esquemas estrelas, por exemplo. É como se a máquina de banco de dados daquele
produto tivesse tratamentos analíticos, digamos, “ in natura”. Além disso, as soluções
genericamente conhecidas como “in-memory”, onde se utiliza de grandes tascos de
memória RAM/flash para acomodar partes significativas dos dados a serem
acessados, evitando os tempos de “delay” de discos e priorizando a velocidade
eletrônica das memórias. A solução
Nettteza é a aposta da IBM para o devido
enfrentamento com a proposta Oracle Exadata.
Oracle:
A Oracle oferece a sua contrapartida que é o Oracle Exadata V2. O
produto, além de um nome oportuno que remete aos exabytes, escala seguinte aos petabytes
e anterior aos zettabytes, se junta aos produtos da Sun-Oracle, procurando,
além de otimizações no kernel do
SGBD, também melhorias no campo do processamento in-memory. Para tal, oferecem arrays
de memórias flash gigantescas, nas
quais se alojam os dados de um grande depósito informacional, acessados, a
partir delas, com velocidade eletrônica. Além disso, com a boa vizinhança da
Sun, agora parte da família Ellison, há o inevitável encontro com máquinas MPP,
contendo centenas ou milhares de “nós”, cada qual com sua capacidade de
processamento e de armazenamento, focando o processamento massivo paralelo,
saída inescapável para o tratamento dos petavolumes. É o que a Oracle chama de Exadata
data machine, integrando processadores e discos, que outrora tinha a plaquinha
“Sun”, com altíssima escalabilidade. A solução busca o alcance de performance
extrema combinando software e hardware, se permitindo aplicações com perfil
misto(transações OLTP e transações OLAP)
Microsoft:
A Microsoft também oferece sua sugestão para o tratamento dos grandes
depósitos de informação, com o logo Windows.
O seu produto é o Microsoft SQL Server 2008 R2 Parallel Data Warehouse,
também focado em máquinas MPP. Tem capacidade para escalar até 100 TB, rodando
em máquinas HP e Dell. A solução já vem integrada com um arsenal complementar
para ETC(Extração,Transformação e Carga), BI, MDM(Master Data management) e
RTDW(Data Warehousing em tempo real). A solução pode ser casada com produtos de
BI de outros sabores como Microstrategy, BO(Business Object) da SAP e
Informática(agora parceira Oracle). O produto oferece, via conectores
customizáveis, acessos ao emergente mundo Hadoop, permitindo tratamento de
dados estruturados e não estruturados,
com a faceta modernista da fundação Apache. O Enterprise Data Warehouse foi
otimizado para trabalhar com o SQL Server 2008 R2 Parallel Data Warehouse, que suporta conectividades com Hadoop de forma que você poderá rodar operações
MapReduce e converter os dados a serem
carregados no SQL Server. Como sempre a Microsoft chega um
pouquinho depois dos grandes nomes, embora seja hoje forte e respeitada e vai
encontrar amplo espaço no seu domínio particular do mundo windows. Foi assim
com o SQL Server, como SGBD, e agora desembarcando no mundo dos zettavolumes do
BI2. A conferir.
Além desses três conhecidos, há também a
Teradata, empresa que há tempos se especializou em domar esses mamutes de
dados. A empresa sempre trabalhou no segmento dos grandes volumes de dados, com
foco em aplicações analíticas. Originalmente uma perna da NCR, tornou-se
independente depois de 2007. A empresa foi uma das pioneiras no uso de máquinas
MPP(Massive Parallel Processing), com arquitetura shared nothing. A Teradata
oferece, através de sua linha especial de produtos para grandes DW, além desse
arsenal de máquinas MPP, processamento in-database
e in-memory, experimentado em grandes
DW de grandes clientes. Somente para relembrar os velhos momentos de BD, abaixo
um esquema de arquiteturas de máquinas MPP aplicadas nos tratamentos desses
grandes volumes. Conhecida como Shared nothing,
palavra que gerou o neologismo “sharding”,
essa arquitetura, como o próprio nome explica, se baseia em boxes com maior independência de
componentes (cada qual com sua memória, seus buffers, software e
sistemas de I/O) de maneira a prover alto desacoplamento entre eles e,
consequentemente, maior “escalabilidade”. É claro que o ambiente é conectado,
por debaixo dos panos, de tal forma a permitir que as partes, fracamente
interligadas (loosely coupled, como
chamadas), sejam “vistas” como um todo. É uma abordagem escolhida para aplicações
especiais e apresenta uma maior complexidade relativa, tanto operacional quanto
tecnológica. Os sistemas nessa arquitetura exigem que os SGBD´s sejam mais elaborados para
extrair todo o potencial de paralelismo da arquitetura, tanto na busca quanto
no tratamento(agora redução, daí o Map Reduce).
Nessa abordagem, as tabelas de dados são particionadas em nós
processadores diferentes e exigem, por consequência, mais cuidados, tanto por
parte dos analistas de suporte/DBA quanto do próprio SGBD, que deverá ter formas
(catálogo central, por exemplo) de identificar a localização das diferentes
partições de dados. A figura, a seguir, ilustra o conceito da arquitetura MPP,
ou shared nothing., que já ganhou uma
nova corruptela “sharding”.
No próximo “post” discutiremos um pouco sobre as novidades
apresentadas no “front” dos petavolumes, com as presenças de Haddop/MapReduce etc
e as outras alternativas de Bancos de dados, chamados NOSQL. O interessante é que já se vislumbra o
casamento dessas técnicas mais antigas, com as novas proposições, criando
híbridos entre Bancos relacionais e Hadoop MapReduce, cada qual oferecendo a
sua melhor parte e todos entendendo que cada uma é melhor vocacionada para
certos tipos de sistemas, workloads e volumes específicos.
No próximo “post” discutiremos um pouco sobre as novidades
apresentadas no “front” dos petavolumes, com as presenças de Haddop/MapReduce etc
e as outras alternativas de Bancos de dados, chamados NOSQL. O interessante é que já se vislumbra o
casamento dessas técnicas mais antigas, com as novas proposições, criando
híbridos entre Bancos relacionais e Hadoop MapReduce, cada qual oferecendo a
sua melhor parte e todos entendendo que cada uma é melhor vocacionada para
certos tipos de sistemas, workloads e volumes específicos.