o problema
O MapReduce resolveu escala e esqueceu quem pergunta. Para descobrir quantos usuários de uma coorte fizeram alguma coisa na semana passada, alguém precisava escrever um programa: um mapper, um reducer, um binário compilado, um deploy no cluster. Isso funciona quando a pergunta se repete todo dia e alguém já pagou o custo de escrevê-la. Não funciona para análise ad hoc, que é justamente o caso em que a pergunta muda a cada resposta. Na prática, cada dúvida de um analista virava uma tarefa na fila de um engenheiro, e o custo da curiosidade ficava alto demais para a maioria das perguntas ser feita.
Do outro lado existia o mundo que já sabia responder a isso há décadas — bancos relacionais, SQL, otimizador — e que não chegava perto de petabytes em cluster de máquinas comuns. O Google tinha os dados, tinha o cluster, tinha o modelo de execução, e não tinha a linguagem. Pior: os dados não estavam num formato só. Havia registros estruturados, havia armazenamento colunar, havia sistemas diferentes guardando pedaços do mesmo problema. Qualquer camada de consulta teria que atravessar tudo isso sem obrigar ninguém a copiar 1,5 petabyte para um formato canônico primeiro.
a ideia
O Tenzing aceita o executor que já existe. Em vez de construir um motor distribuído novo para servir SQL, ele compila a consulta para o que o cluster já sabe rodar, e trata o MapReduce como um back end de execução. A parte cara do sistema — escalonamento, tolerância a falha, distribuição de dados — já estava paga e testada em produção; o que faltava era a fachada.
A escolha de fachada é SQL, e SQL quase inteiro, com extensões próprias. Isso importa mais do que parece: um dialeto reduzido teria empurrado o analista de volta para o engenheiro na primeira consulta com subquery. O paper também lista metadata awareness entre as características centrais — o motor sabe o que existe, onde está e em que formato, e é isso que sustenta a promessa de heterogeneidade. Um sistema que só entende um layout de dados não é uma camada de consulta, é mais um silo.
o que isso custou
A admissão está na primeira frase do resumo: a implementação de SQL é “mostly complete”. Existe uma borda, e o paper não esconde que existe — o que ele não faz é dizer no resumo onde ela fica. Vale a mesma leitura para “low latency”, que aparece listada como característica conquistada. Ninguém precisa anunciar baixa latência quando ela é gratuita; a lista está descrevendo o que foi arrancado de uma base que cobra materialização de resultado intermediário e shuffle entre estágios para cada passo do plano. Um motor batch com SQL por cima continua sendo um motor batch.
O outro limite é do meu lado. Este verbete foi escrito a partir do resumo do paper, não do texto completo. A arquitetura, a implementação e os benchmarks de consultas analíticas típicas estão lá nas dez páginas do VLDB de 2011, e é lá que se descobre quanto de latência sobrou e quais construções de SQL ficaram de fora. Se a pergunta for essa, o resumo não responde.
onde isso aparece hoje
O padrão vingou. Colocar uma linguagem de consulta declarativa sobre um executor distribuído que não foi projetado para ela virou o desenho default do processamento de dados em escala, e a peça de baixo foi trocada várias vezes desde então sem que a de cima mudasse muito. O MapReduce saiu de cena como camada de execução interativa; os RDDs do Spark e depois os motores de lakehouse ocuparam o lugar, com SQL continuando a ser a interface por onde a maioria das perguntas entra.
Dentro do próprio Google, o Tenzing é o ramo que apostou em reaproveitar o executor existente. O outro ramo é o Dremel, que construiu um motor próprio, colunar, para consulta interativa — e é dele que veio a linhagem que o mercado conhece pelo nome comercial. Ler os dois lado a lado é ler a mesma pergunta respondida de duas formas: adaptar o que já roda, ou escrever do zero o que a latência exige.