o problema
Em 2015 o argumento de que faltava capacidade de processar dados já não colava. MapReduce e a geração seguinte de frameworks tinham resolvido a parte difícil da distribuição: quem tinha um cluster conseguia varrer petabytes. O que os autores afirmam é que o gargalo migrou de lugar. Diante de um repositório grande, o que demora não é a máquina rodar — é a pessoa escrever o que quer perguntar.
A razão estrutural que o paper aponta é a costura. As ferramentas existentes embutem uma sublinguagem de pipeline paralelo dentro de uma linguagem de propósito geral, ou fazem o contrário: pegam uma linguagem de pipeline e penduram nela um mecanismo para chamar computação arbitrária. Nos dois casos o programador trabalha em duas linguagens ao mesmo tempo, com duas semânticas, dois modelos de dados e uma fronteira no meio que ele precisa administrar. A lógica que interessa fica espalhada dos dois lados dessa fronteira. Qualquer um que já escreveu uma UDF para fazer algo que a linguagem de consulta não fazia, ou que já montou um pipeline como sequência de chamadas de API numa linguagem hospedeira, conhece o imposto.
a ideia
O Yedalog trata pipeline paralelo e computação como cidadãos da mesma linguagem, em vez de tratar um como convidado do outro. É uma linguagem declarativa: você descreve as relações que quer, não a sequência de estágios que as produz.
A base escolhida é Datalog, e a escolha tem lógica própria. Datalog já é declarativo, já é relacional e já tem uma tradição de otimização de consultas por trás. Ele só é pequeno demais para o trabalho: falta computação de verdade e falta um modelo de dados que não seja tabela plana. O Yedalog acrescenta as duas coisas — recursos computacionais herdados de programação em lógica e suporte a dados estruturados como registros aninhados, que é como os dados reais chegam em qualquer lugar que não seja um data warehouse arrumado.
A terceira peça é o modo de execução. O mesmo programa roda numa máquina só ou distribuído num cluster, em batch ou em modo interativo, e os autores dizem que dá para misturar esses modos com facilidade. É o ponto que mais fala com quem explora dados na prática: a exploração começa interativa e pequena, e o momento de promover aquilo para um job grande normalmente é o momento de reescrever tudo em outra ferramenta. Aqui não deveria ser.
o que isso custou
O resumo não declara limitações, então o que segue são as contas que o próprio desenho implica, não confissões dos autores.
A primeira é óbvia e é a mais cara: o remédio para “o programador é o gargalo” é pedir ao programador que aprenda uma linguagem nova, e uma linguagem da família Datalog, que nunca foi majoritária fora de nichos. Trocar o custo da costura pelo custo da adoção é uma aposta, não um ganho garantido. A segunda é o preço padrão do declarativo: quando você descreve o quê e não o como, quem decide o como é o otimizador, e nas horas em que ele decide mal sobra menos lugar para intervir do que num pipeline escrito à mão.
E há o limite do que este texto sustenta. Trata-se de uma proposta apresentada num encontro sobre avanços em linguagens de programação — um fórum de posição. Do resumo não sai nenhum número: nem desempenho contra os frameworks que ele critica, nem evidência de que o programador de fato fica mais rápido, nem escala testada.
onde isso aparece hoje
A tensão que o paper nomeia não foi resolvida por ele. Ela continua sendo o eixo do ecossistema de dados: de um lado, SQL com funções definidas pelo usuário para o que SQL não faz, linhagem que passa pelo Tenzing e pelo Dremel; de outro, APIs de pipeline embutidas numa linguagem hospedeira, como as do MapReduce e do Spark. Hoje o mesmo padrão reaparece em DataFrames de Python e em camadas de transformação sobre SQL.
O detalhe dos registros aninhados aproxima o Yedalog do Dremel, que já tinha feito da estrutura aninhada o modelo de dados nativo em vez de exigir tabelas planas. E a ambição de unificar modos de execução tem um paralelo em outro eixo no Dataflow, que propôs um modelo único para batch e streaming no mesmo ano. Datalog, por sua vez, seguiu vivo onde o casamento com computação importa mais que a popularidade da sintaxe — análise estática de programas é o caso mais visível.