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”

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....