Big Data- Parte VII- Os Big Data e as formas de armazenamento-Soluções tradicionais.

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.  

Consultores e Consultoria-Últimas metáforas-Parte II

Quando comecei a minha vida de consultor, lá pelo final dos anos 70, eu trabalhava na Cemig e fazia o “Consulting by night”. Depois do expediente, lá ia eu sozinho orientar empresas a montar bancos de dados, modelos de dados, esquemas, dicionário de dados, etc. Os amigos, maldosamente, diziam que eu tinha criado o álibi perfeito. Mal sabiam que os meus “esquemas” eram de entidades, relacionamentos e atributos. Se bem que os esquemas que eles , maliciosamente sugeriam, também tinha por coincidência, esses 3 mesmos elementos, principalmente atributos.... Ponto, parágrafo.

Foram alguns anos vivenciando essa nova forma de atuação, até então inédita para mim. Quando comecei a planejar o CCOMP.MG, em 2004, defini um modelo de trabalho, ligeiramente diferente, pensando em 2 consultores por empresa. Embora no contrato haja somente a obrigatoriedade da presença de um consultor na empresa cliente, a minha ideia sempre foi um trabalho em pares. Algo como uma dupla sertaneja, onde um tem a voz principal e o outro complementa na harmonia perfeita, embora dissonante. A princípio, um deles com um pouco mais de experiência, seria o consultor líder e o outro, com um pouco menos de “estrada” seria o adjunto. Ambos  formariam  uma equipe equilibrada sempre com o compromisso de formar, no ciclo de hoje, os novos experientes de amanhã. Com o tempo, teríamos quase sempre pares de  consultores líderes atuando na mesma empresa. Oito grupos de empresas depois, com mais de 50 implementações realizadas, percebi que a estratégia deu certo. A equipe de consultores de que dispomos tem hoje em torno de 15 profissionais , todos com o status de líderes e temos uns 3 ou 4  ainda na trilha de adjuntos, que logo migrarão para o patamar de líderes.

O trabalho de dois consultores atuando na mesma sessão de consultoria exige alguns cuidados. É, mal comparando, como se tivéssemos dois médicos atendendo ao mesmo paciente, no mesmo consultório, numa única consulta. Quando há a combinação de um líder e um adjunto, por “default”  aparece uma inibição natural do menos experiente em expor suas posições, visto que o outro, teoricamente mais experiente, está ali justamente para fazer a condução das ideias . Esse recolhimento espontâneo do implementador adjunto é natural, deve ser gerenciado pelo líder, e normalmente não cria ambientes de contraposição entre eles. O líder deve trabalhar para que o adjunto sempre seja incentivado a colocar suas posições, mesmo que alguma “correção sutil” seja aplicada no curso das suas interlocuções. Entretanto quando os dois consultores são líderes, podem acontecer algumas situações de “conflitos”, que devem ser resolvidas pelo bom senso de ambos. Nesse momento entra em campo a maturidade dos consultores, que devem ter o “feeling” de convergirem para um ponto único, para que o cliente não perceba a distensão ou não se sinta desconfortável com opiniões divergentes, vindo justamente de quem esperava coerência. Aqui entra uma frase de Benjamim Franklin que publiquei recentemente e fala de um ingrediente fundamental nos trabalhos em dupla: a humildade. Franklin diz “que a humildade é uma obrigação com os superiores, uma cortesia com os pares e uma nobreza com os inferiores”. Exercitar humildade não é uma das coisas mais fáceis do universo, mas é fator crítico de sucesso nesses cenários. Nem sempre a força de nossas personalidades permite o exercício linear desse elemento fundamental de cortesia.

A dupla de consultores deve sempre trabalhar como dois meio campistas de um time de futebol vencedor. Pensem num... Devem saber jogar por música, se comunicar com os olhos e um deles assumir a conduta da bola, quando o outro não se mostrar bem naquele momento do jogo. Nesse caso em particular, a metáfora não permite substituição. Outro ponto importante nesse jogo de meio de campo é que cada um dos consultores deve entender os pontos fortes do outro e assim, deixar que aquele com mais suficiência naquela jogada conduza a bola, no caso a interlocução. O outro fica mais no desarme nesse momento, entrando nas jogadas quando essa característica for a mais exigida. Como todos temos pontos fortes e fracos nas nossas formações, o importante é conhecermos esse mapeamento(tanto nosso, quanto do parceiro) e a humildade para sermos coadjuvante quando o momento pede uma proficiência  num terreno, em que não somos o melhor. Como a equipe é equilibradamente formada, em outro momento você, que foi coadjuvante há 20 minutos,  aparecerá como o condutor dali em diante. Esse, na tradução “barbieriana”, é o fator “espelho”, apontado por Jerry Weinberg no seu trabalho “More secrets of Consulting: The consultant tool kit”.

Outros ponto  a ser considerado pela dupla(ou pelo consultor, quando sozinho) é o fator “telescópio”. Aqui é a velha frase, aprendida nas curvas da baixada fluminense, de ficar com um olho no peixe e outro no gato. Significa a capacidade de enxergar as adjacências da área consultada e pessoas envolvidas, tentando entender os algoritmos de “engine humano”, complexos e criptografados. No caso, dois consultores podem quebrar esses códigos blindados com mais facilidade, o que acontece normalmente, na viagem de volta das consultorias...”Você não acha que o fulano, parece que ........,etc,etc.

Outro ponto importante é entender também que as sessões de consultorias devem ser profissionais, mas não precisam seguir a liturgia “vaticana” de uma missa. Nela cabem, momentos de descontração via pequenos “ causos contados”, que permitem paralelizar situações ou mesmo a provocação de sorrisos não técnicos. Lembre-se da máxima de Oscar Wilde, “que diz que a vida é muito importante para ser levada(tão) a sério”.  O “tão” é grifo meu.  Weinberg chama esse fator de “feather”, ou seja uma “pena”, com a qual se faz cócegas num ambiente hermético e formal, produzindo momentos de risos e de descontração. Lembre-se que há sempre tempo para se conjugar essas interpolações de sorrisos, desde que você controle o outro fator, o “hourglass”, ou seja desde que relógio de areia esteja sob seu controle.

Outra ferramenta usada como metáfora, emprestada de Weinberg, é o grampo de alpinista(carabiner). É aquele grampo de metal usado para ser encaixado nas fendas e que evita as quedas dos alpinistas. Normalmente fazem a diferença entre a sustentação  e a queda fatal. A mensagem aqui é sempre verificar itens importantes, evitando surpresas , principalmente quando o trabalho estiver para ser avaliado por outro(auditorias, avaliações, etc). No MPS.BR, isso acontece com frequência:  Por exemplo, para as empresas  que fazem nível C, alguns dos “grampos”  a serem observados  seriam as Ap1.1, Ap2.1, e Ap2.2, que nos níveis de maior maturidade não podem falhar e devem estar firmes como as rochas.

Ao longo desses quase  7 anos tenho trabalhado com pares brilhantes, com quem aprendo muito, embora para eles seja eu que esteja no papel de professor. Pobres (in)observadores... Como quase todos tem a idade de meus filhos, estabeleci um método matreiro de trabalho baseado no “hit” de Zé Ramalho, através do qual cruzo com eles, de cabelos brancos e botas longas,  as soleiras  (das empresas) , confiando nos seus alforjes de  grandes caçadores....Sou o velho e invisível avôhai....