Cloud Intelligence™
Usando zetaSQL para analisar a sintaxe de queries no BigQuery
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
About Eben Du Toit
I lead engineering teams in the Partner Channel space, building the tooling that helps customers make sense of their revenue — turning complex partner and billing data into something they can actually see, trust, and act on. The work sits at the intersection of cloud cost management, FinOps, and billing integrations, with data flowing across GCP, BigQuery, MongoDB Atlas, Snowflake, and the wider cloud ecosystem. It's technically meaty, and I love that about it.
My days are split between people and systems — growing and aligning multiple teams, helping the team navigate the environment, hiring, and partnering with stakeholders across the org. I shift between maker mode and manager mode depending on what's needed: sometimes I'm deep in the code building features, sometimes I'm in the room helping my teams move forward. I care a lot about building teams where good engineers can do their best work.
What I work on
Partner Channel engineering and revenue management tooling · Cloud cost management and FinOps · Billing data pipelines and integrations · Engineering leadership, hiring, and team process
Good topics to find me for
Anything Partner Channel, revenue, FinOps, or billing-related · Data engineering and pipeline architecture · Engineering management, hiring, or team culture
Outside work
When I'm not in a terminal, I'm usually behind a camera — shooting on a Nikon Z or whatever vintage film body I'm currently infatuated with. I follow mountain biking and trail running closely, have strong opinions about mechanical keyboards and good stationery, and watch more anime than I probably admit. I also play Rocket League with more optimism than results.
Cape Town · SAST (UTC+2)
My personal pageFoto de Reza Rostampisheh no Unsplash
No mundo dos parsers, o estado da arte em poder e funcionalidade de análise de texto está nos parsers capazes de montar uma árvore de sintaxe abstrata (AST) a partir do seu texto. A grande vantagem da AST é gerar uma string JSON com as classificações das informações analisadas. Isso é extremamente útil e facilita muito a construção de serviços em cima dela. E quando o texto de entrada é uma instrução SQL, melhor ainda.
Todo editor SQL que se preze usa um parser. O superQuery usa um parser chamado pegJs, um sistema baseado em JavaScript que foi aprimorado pela equipe recém-adquirida pela DoiT International para também dar conta de boa parte da sintaxe do Google BigQuery de forma eficiente.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Sobre o zetaSQL
No início de 2019, o Google abriu o código do parser baseado em AST chamado zetaSQL, usado em produção para fazer parsing e formatação de queries no Google BigQuery e no Cloud Spanner. O repositório está aqui. O zetaSQL pode ser compilado com bazel e é composto majoritariamente por código C++, mas também há uma implementação em Java disponível.
Mergulhando no código, dá para ver que o parser tem várias funcionalidades, entre elas:
- Formatar uma instrução SQL (sql_formatter.h)
- Analisar uma instrução SQL (analyzer.h)
- Identificar erros de sintaxe e devolver o erro, a linha e a coluna (parse_helpers.h)
Olhando o repositório, percebemos rapidamente que parece fácil de buildar. Para te poupar tempo, vale destacar que o arquivo .bazelrc é muito importante: ele define a versão correta do compilador C++, conforme o que os outros softwares do Google suportam. Por isso, é fundamental ter esse arquivo na hora do build.
Além disso, o repositório base do zetaSQL ainda não traz um Dockerfile que permita buildar e compilar a versão mais recente do zetaSQL. Eu disponibilizo um aqui, baseado no Ubuntu 18.04 e na versão mais recente do bazel.
Minha implementação (zetasql-analyzer-server) resolve o ponto 3 acima, ou seja, o identificador de erros de sintaxe. Ela se baseia em uma implementação Docker feita pelo apstndb, chamada zetasql-format-server (que resolve o ponto 2 acima). Por baixo dos panos, trata-se de um servidor em Go que encapsula a API do formatador (ou do analisador) do zetaSQL e expõe um endpoint no Google Cloud Run.
Exemplos
Um caso simples
Veja um exemplo de saída do endpoint do analisador para uma query com erro SELEC 1 (faltando o T):
São retornados a localização do erro, a linha, a coluna e a mensagem de erro para uma query simples.
Um caso mais complicado
No exemplo abaixo, o segundo nível aninhado da query está sem a palavra SELECT. Dá para ver que o parser aponta essa informação.
Localização do erro em uma query um pouco mais complicada.
E quanto à velocidade e ao desempenho?
Pelo número limitado de testes que rodei, a maioria das respostas (mesmo para queries com mais de 600 linhas) fica dentro de 1 segundo, com média de 300ms.
Veja os gráficos de tempo dos 2 exemplos a partir do meu laptop, com conexão de internet de alta velocidade:
Tempo de resposta do evento para "SELE 1"
Tempo de resposta do evento para o exemplo mais complicado acima.
A stack que viabiliza esse parsing em alta velocidade usa uma imagem de container distroless (https://github.com/GoogleContainerTools/distroless) e uma implementação de hardware serverless (Cloud Run) com C++ como linguagem de entrada.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
Instalação e uso
Para instalar, dá uma olhada no arquivo README aqui. Me avise em que posso ajudar para você colocar tudo no ar.
Depois de criar um endpoint no Cloud Run, você consegue obter informações dele com um comando curl:
curl -X POST -H 'Content-type: application/text' --data 'SLECT 1, ' https://<seu endpoint vai aqui>
Para finalizar
Bom parsing!
Referências
- zetasql-analyzer-server: https://github.com/ebendutoit/zetasql-analyzer-server
- zetaSQL: https://github.com/google/zetasql
- zetasql-format-server: https://github.com/apstndb/zetasql-format-server
