o problema
Em 2010, analisar dados na escala do Google significava escrever um job em lote. Você descrevia a computação, submetia para um cluster, esperava. O tempo de resposta ficava na casa dos minutos, quando não das horas. Isso é aceitável quando você sabe exatamente o que quer perguntar. É péssimo quando você não sabe: análise exploratória é feita de perguntas malformuladas que geram perguntas melhores, e uma latência de vinte minutos entre uma e outra mata o processo. O analista para de explorar e passa a planejar.
Havia um segundo problema, mais específico. Os dados dentro do Google não eram tabelas planas. Eram registros aninhados — estruturas com campos repetidos e opcionais, do tipo que sai de um protocol buffer, não de uma linha de CSV. O armazenamento colunar, que na época já era conhecido como o jeito certo de acelerar agregação analítica, tinha sido pensado para o mundo plano: uma coluna, um valor por linha. Guardar registro aninhado em coluna e conseguir remontá-lo depois não era uma questão resolvida.
a ideia
Dremel ataca os dois de uma vez, e a graça está em atacar juntos.
De um lado, a execução vira uma árvore de vários níveis. A consulta desce por essa árvore sendo quebrada em pedaços cada vez menores até chegar nas folhas, que tocam os dados; os resultados parciais sobem sendo agregados no caminho. É a mesma intuição de uma busca web servida por milhares de máquinas: ninguém varre tudo, todo mundo varre um pedaço e alguém costura. A diferença em relação ao lote é que não existe materialização intermediária no meio do caminho — a consulta é um fluxo, não uma sequência de estágios que gravam e leem.
Do outro lado, o armazenamento é colunar, e colunar de um jeito que aceita registro aninhado. Uma agregação típica toca dois ou três campos de um registro que tem centenas. No layout por linha, você lê o registro inteiro para descartar quase tudo. No layout por coluna, você lê só o que a consulta pede. Essa é a economia que torna trilhão de linhas em segundos uma frase possível: o gargalo da análise em escala é I/O, e a coluna é a forma de não pagá-lo.
A restrição que sustenta as duas escolhas é read-only. Dremel não é banco transacional e não tenta ser. Dados que não mudam podem ser reorganizados livremente na hora de gravar, porque ninguém vai atualizar um campo no meio de uma coluna comprimida depois.
o que isso custou
O resumo do trabalho não enumera limitações, então o que dá para dizer honestamente vem do contorno das próprias escolhas — e esse contorno é nítido.
O sistema é de consulta ad hoc sobre dados somente leitura. Isso exclui escrita transacional e exclui, também, a classe de computação que o MapReduce atende: transformações arbitrárias, pipelines que produzem novos conjuntos de dados, código do usuário rodando sobre cada registro. O paper é explícito ao se colocar como complemento, e essa palavra carrega a admissão. Agregação interativa e processamento em lote continuam sendo dois problemas, com dois motores.
Há um custo implícito de arquitetura, também. Um sistema que só responde rápido quando tem milhares de CPUs disponíveis é um sistema que assume um data center atrás dele. A latência baixa é comprada com paralelismo largo, não com esperteza que caiba numa máquina.
onde isso aparece hoje
A separação que o Dremel institucionalizou — um motor colunar interativo ao lado de um motor de lote, cada um no seu papel — virou o desenho padrão de plataforma de dados. O MapReduce continuou existindo para o que é transformação; a consulta exploratória saiu de cima dele.
A parte de armazenamento ganhou continuação própria dentro do Google, com Storing and Querying Tree-Structured Records in Dremel detalhando o tratamento de registros em árvore. E a ideia de expor esse tipo de motor como serviço, sem cluster para administrar, é o formato em que os data warehouses de nuvem da década seguinte chegaram ao mercado — The Snowflake Elastic Data Warehouse é o exemplo mais documentado desse arranjo. Externamente, o Dremel é conhecido por outro nome: o BigQuery é a face pública dele.
Vale notar que o trabalho circulou duas vezes: a versão de 2010 e a republicação nas Communications of the ACM em 2011, que é a citada na página do Google Research. Um paper de sistema interno raramente atravessa para a CACM.