Destrua seu Data Warehouse! Use BigQuery!
Como funciona o maior e melhor serviço de analytics atualmente: o Google BigQuery
O Tempo em TI é uma dimensão muito elástica. Já disse anteriormente, como a buzzword Big Data vem deslumbrando muita gente por aí. Também mostrei que nem tudo são flores nessa trilha...
Nos anos 90, um DBA competente conseguia sozinho atender chamados de produção, avaliar e revisar modelos de dados, cuidar da modelagem física dos servidores e ainda te dar uma mãozinha naquela Stored Procedure marota sua que demorava 50 minutos pra produzir um relatório. Famoso Ninja! Mas hoje, somente 20 anos depois, um especialista em MySQL não consegue mais segurar a onda dos dados de qualquer empresa que tenha um produto razoavelmente popular.
Atualmente, o estado da arte de uma boa arquitetura de dados exige conhecimento, não só teórico, mas -principalmente- prático em diversas ferramentas profundamente complexas e que têm uma interface de integração -ainda- não muito coerente e madura. Por mais maravilhosos que eu ache projetos como Apache Spark, Mesos e Druid, é inegável que dominar ferramentas como essas exigem aaaanos de experiência e estudo incessantes. Vai por mim, um MBA de 50k não basta…
O Open Source que sai caro
Pergunta rápida: Quantos caras você conhece que tem know-how suficiente para tomar conta de clusteres Hadoop/HDFS/Spark? Quais desses escrevem boas jobs MapReduce/Scala e domina Pig/Hive? E, além disso, não deixou enferrujar o bom e velho SQL, que é sempre útil?
Eu já sei a resposta… nenhum. Pois é… Eu também não conheço nenhum. E como é muito difícil achar desse unicórnio por aí, seu preço não vai ser algo bem acessível.
Suponha que você invista então em capacitação. Contrate alguns prodígios e treine-os com os melhores recursos. Quanto tempo isso levaria?
E mais: quantos desses caras seriam necessários para, além de manter, evoluir a arquitetura Big Data que você tanto sonhou e suou para construir?
O Open Source não sai de graça. Em tudo há tradeoff.
Como você não tem Netflix, Amazon ou uma Google, que esbanja grana, servidores e tem mais currículos incríveis do que vagas abertas, você desiste… Ou não?
Se não consegue vencê-los…
Apesar de eu falar que há muito marketing nesse Big Data Business, admito que há casos inevitáveis. Estes gigantes da tecnologia estão há um bom tempo fazendo muita coisa interessante por aí. E também há um bom espaço sobrando em seus servidores parrudos e no horário de seus engenheiros brilhantes. Por isso, chegam com algumas soluções impossíveis de serem contruídos por nós — reles mortais — no custo irrisório que eles disponibilizam para uso.
O maior deles nesse ramo, sem dúvida, é o protagonista desse artigo:
O incrível Big Query
Antes de entrar na Dito, eu ficava admirado com todos esses projetos novos da Apache. Construía clusteres e lia infinitas documentações e imaginava o quanto seria difícil chegar naquele ponto que destaquei logo no início: uma arquitetura no Estado da Arte do Big Data. Até que me mostraram o Google BigQuery, o nosso principal pilar de analytics, com mais de 5 bilhões de registros e milhões de inserções diárias.
Vou tentar me conter, já que não estou recebendo nenhum centavo por esse jabá… Se quiser ir direto para o deep dive em teoria, pule pra próxima seção onde eu explico como que funciona esse mutante e como consegue ter um custo-benefício tão bom.
Esse monstro é capaz de:
- Percorrer e agregar mais de 200 milhões de fucking linhas em segundos!
- Inserção de Streaming via Apache Beam/Google DataFlow.
- Aceita Standard e Legacy SQL.
- Tem lib em Ruby — always — (e fora .NET, Java, Python, Go e Node).
- Tem conector pra Hadoop e Spark.
- Você paga principalmente pelo tanto que consulta, não o quanto guarda.
Você deve estar se perguntando qual seria o preço disso tudo. Míseros 0.05$ por GBs inseridos e 5$ por TBs processados! Cara… é muito pechincha! Tem mutreta aí, tem não??? Desvio de Banda… Lavagem de Memória… alguma coisa têm!
Arquiteturalmente construído para ser barato
Antes de sair para o público, o BigQuery já era bastante utilizado internamente pela Google, mas com outro nome, menos comercial, porém bem mais bonito: Dremel. Tudo quanto é dado que precisava de análise, era jogado lá. Análise de documentos recuperados por crawlers, Resultados de OCR do Google Books, Debugar marcadores do Google Maps e mais uma porrada de coisa!
O Dremel foi construído sobre 3 conceitos principais que o tornam ao mesmo tempo poderoso e barato.
Modelo de Dados para Sistemas Distribuídos
Esse pessoal é tão esperto, que para definir os seus schemas, usaram o protocol buffers, outra tecnologia made in Google e amplamente utilizada lá dentro. O pb é forma de serialização e definição de dados interessantíssima que merecia até outro post. Basicamente é tipo um XML, muito mais simples, conciso, coeso e com anexos mais inteligentes e performáticos como o GRPC que é, tipo um WSDL, para comunicação remota, por exemplo.
Não precisa nem de documentação para entender, olha só um exemplo de mensagens definidas em proto:
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
optional group PhoneNumber {
required string number = 1;
optional string idc = 2;
}
repeated PhoneNumber phone = 4;
}Temos um esquema claro: uma entidade Pessoa, com campos obrigatórios multi-valorados, opcionais e que podem se repetir ou não.
Armazenamento Colunar Aninhado
Este conceito é um dos principais motivos do BigQuery ser eficiente e de seu modelo ter um custo benefício tão bom. Contudo é o mais difícil de entender. Se quiser entender melhor, leia este post do Twitter.
Não trocando em miúdos, o BQ ao armazenar os dados como protobuffer, se aproveita da estrutura mista entre dados colunares e dados aninhados para otimizar o tempo de execução das queries. Abaixo temos um exemplo de como estes dados são guardados.
Note que o schema tem uma estrutura parent-child, se assemelhando a um grafo, onde os dados são efetivamente organizados. Enquanto que, a nível de registros, campos de um mesmo documento também são colocados de forma aninhada
Considere uma operação de Seleção (cláusula WHERE) na representação colunar acima-da direita. O operador consegue “podar da árvore” registros que não satisfaçam alguma condição.
Agora uma Projeção (cláusula SELECT) na representação de registros -nested, a da esquerda. O operador consegue passar somente nos níveis que lhe interessa- o azul, por exemplo, ignorando todos dados referentes à outros campos -os vermelhos e verdes.
Dessa forma, o mecanismo de query consegue seguir um caminho mais curto, tanto em caso de agregações quanto em casos de projeções e agrupamentos.
Assim vemos o quanto o modelo de precificação do BigQuery consegue ser barato: Maioria das consultas passam por pouquíssimos dados para obter um resultado. Sem índices, sem referências. Só com conceitos estruturais simples.
Árvore de Execução Multi-Nível
Quem está familiarizado com as implementações do MapReduce ou o funcionamento de outros DBMS distribuídos, como o ElasticSearch, sabem que -bem alto nível- geralmente o mecanismo de busca se resume em 2 fases principais:
- Fase de Busca/Map: Um nó cliente/master recebe e distribui a consulta nos outros nós de dados/workers/slaves. Cada nó busca/agrupa/ordena -de acordo com a consulta, obviamente- os dados que têm em suas respectivas partes das tabelas/coleções e deixa disponível pra retorno assim que termina sua parte.
- Fase de Retorno/Reduce: O nó cliente/master vê se/que todos os slaves terminaram sua parte no trabalho, junta e ordena tudo -merge ‘n’ sort- e retorna o resultado completo para o usuário.
Num cluster pequeno, a fase de redução (vem de Reduce) normalmente é muito rápida e quase irrelevante no tempo total de query. Mas imagine num cluster com 2000 nós e 5000 TB de dados. É bem possível que esta fase vire um gargalo. Principalmente porquê a vida em computação distribuída é muito mais dura que na computação local e sequencial. Problemas:
- As queries retornam dos nós slaves praticamente ao mesmo tempo, supondo uma distribuição randômica/homogênea dos dados, trazendo gargalo de rede.
- Reduzir uma quantidade de dados grande demais num nó é muito pesada. Envolver muito disco/rede nessa operação vai fazê-la ficar muito mais lenta
Para evitar esse tipo de problema, o Dremel monta uma árvore de execução multi-nível. Ele cria uma ou várias camadas de nós para executar uma redução parcial dos resultados de cada nó slave -definido no paper do Dremel como leaf node.
Além de rapidez, o esquema traz resiliência, já que se algum dos nós slave falharem -e vão falhar!- durante a busca, o nó intermediário já tem parte do resultado computado, não deixando que o nó raiz/master se preocupe com ter que reavaliar a consulta.
Muito bonita essa arquitetura, não é? Tudo minuciosamente pensado para a construção de um verdadeiro Juggernaut de analytics. É óbvio que o Google BigQuery não resolve todos os problemas. Ele é ótimo para um Data Lake ou qualquer ponta final de um pipeline de dados. Ainda há casos onde o Apache Spark ou qualquer outra ferramenta Hadoop-like é mais apropriada, como para jobs muito complexas e de duração muito longa, e.g. Machine Leaning. Mesmo assim, o BigQuery a meu ver é quem resolve melhor o que se propõe a fazer, num custo baixíssimo, frente á soluções Open Source ou outros serviços nem tão bonitos assim…
Espero que tenha gostado de mais este post com misto de visão prática e teórica desse mundo bacana que o tal do BigData nos trouxe. Não deixe de se inscrever no Data Hackers: maior comunidade brasileira sobre dados! Se não gostou, comente! Se sim, recomende e compartilhe com seus colegas. Valeu e até mais!
