A primeira coisa que escrevemos sobre o Event Horizon Data foi que a última milha não devia precisar de um analista. Isso não mudou. Filtros, agregações, drill-through, cohorts, previsões, análise de drivers, tudo arrasta-e-larga, continua a ser o padrão e continua a ser o objetivo.

Mas um produto é usado por uma equipa, e uma equipa não é um só tipo de pessoa. Há quem escreva SQL, e há quem viva num notebook em vez de num dashboard. Pedir a essas pessoas que abram mão disso é a troca errada. Por isso construímos duas coisas para elas, e construímos ambas sobre carris.

Escreves SQL contra as tuas tabelas, não contra o nosso warehouse

Há agora um editor SQL dentro do Explore. Escreves SQL normal, joins, CTEs, subqueries, funções de janela, contra os teus buckets como se cada um fosse uma tabela. O que não vês, e não precisas de ver, é como o warehouse guarda de facto essas linhas por baixo. Isso é de propósito, e é o desenho todo:

O teu texto nunca corre tal-e-qual. Toda a query é parseada, verificada contra um allowlist que nega por omissão, e reconstruída no servidor antes de tocar na base de dados. A versão que executa é uma que construímos a partir do significado da tua query, trancada ao teu tenant. Uma query que não se consiga exprimir em segurança não corre, é recusada com uma razão.
És cego ao nosso schema, de propósito. Um bucket é uma tabela para ti. Como está particionado, em tiers e guardado é nosso para mudar sem partir uma única query que tenhas gravado. Ficas com uma superfície estável; nós ficamos com a liberdade de a tornar mais rápida por baixo.

Toda a query é verificada em custo antes de correr

Quem já geriu um warehouse já viu uma query descuidada varrer uma fortuna. Fazemos o que o dry-run do BigQuery faz, e fazemos para todas as queries, sempre: antes de uma query correr, estimamos quanto leria e comparamos com o orçamento do teu plano. Uma que leria demasiado é recusada à cabeça, com a estimativa à frente, para a poderes estreitar, e não depois de a fatura chegar. Além disso, uma query pode juntar no máximo quatro das tuas tabelas, e o tempo de execução, a memória e o tamanho do join estão todos limitados, com o SQL ad-hoc a correr com prioridade abaixo dos dashboards. Somos precisos em vez de absolutos: a estimativa conta linhas LIDAS, e um join faz trabalho proporcional ao produto dos lados, por isso o que estes limites compram é que uma query pesada se degrade a si própria e ceda, em vez de levar o warehouse atrás.

Gostaste de uma query? Grava-a e larga-a diretamente num dashboard como widget. Uma query SQL e um widget de arrasta-e-larga são aqui o mesmo tipo de objeto.

Um connector para o teu notebook

A segunda coisa é uma API HTTP, para quem é de notebook poder ficar no notebook. Aponta o Python, o R ou o Jupyter a um endpoint, envia SQL, recebe linhas em JSON ou CSV. Corre pelos mesmíssimos carris do editor na app: o mesmo parse, a mesma reconstrução, o mesmo cost gate.

A autenticação é um token revogável que geras tu, opcionalmente com data de validade. O tenant vem do token, nunca do corpo do pedido, por isso um token de uma conta não consegue pedir dados de outra. Há um teste que o prova, e faz falhar o nosso build se isso alguma vez deixar de ser verdade.

Porque é que "sobre carris" importa

Teria sido mais rápido dar aos power users uma ligação em bruto e desejar-lhes sorte. Não o fizemos, pela mesma razão por que o produto existe: a parte difícil e pouco glamorosa, três quartos do analytics, é a que te mantém seguro e rápido quando não és o único tenant na máquina. Isolamento entre tenants, controlo de custo, e um schema que podemos mudar sem partir a ninguém não são coisas que se aparafusam depois de uma fuga ou de uma fatura surpresa. São os carris, e preferimos construí-los uma vez, para todos, a deixá-los ao critério de cada query.

Se quiseres ver como o isolamento aguenta um atacante em vez de acreditares na nossa palavra, fizemos red-team à nossa própria fronteira e publicámos o resultado. Está na página de segurança. O argumento arquitetural mais longo está no whitepaper.