Gabriel Orlandini Moschioni; Lucas José de Souza

DOI: 10.22167/2675-6528-202600832

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A pesquisa abordou o desafio de gerenciar volumes moderados de dados, denominados “not too big data”, em contextos organizacionais que exigem governança, qualidade e reprodutibilidade, mas sem a complexidade de infraestruturas de grande escala. Avaliou-se a viabilidade de um framework declarativo para orquestração de transformações SQL, desenvolvido em JavaScript para o ambiente Google Apps Script e executado no BigQuery. O framework foi concebido como uma alternativa acessível para aplicar boas práticas de engenharia analítica. Inspirado em abordagens consolidadas como o paradigma ELT e ferramentas como o dbt, o sistema implementou resolução automática de dependências, materializações explícitas, testes automatizados de qualidade de dados e geração de logs estruturados, reduzindo a necessidade de código imperativo de controle. A viabilidade técnica da solução foi avaliada por meio de um estudo de caso baseado no Jaffle Shop Classic. Os resultados demonstraram que o framework executou pipelines analíticos completos, auditáveis e replicáveis, com uma configuração declarativa concisa. Concluiu-se que o framework proposto constitui uma alternativa pragmática para equipes com recursos limitados, ampliando o acesso a boas práticas de engenharia de dados sem a complexidade de infraestruturas de grande escala.

Palavras-chave: ELT; Engenharia analítica; “Not too big data”; Orquestração de dados; Qualidade de dados.

1. Introdução

A produção e o uso de dados tornaram-se elementos centrais na infraestrutura de organizações de diversos portes. Processos que antes eram integralmente analógicos migraram para sistemas digitais, e a proliferação de sensores e aplicativos resultou em um aumento exponencial das fontes de informação disponíveis para análise em tempo real.

Esse cenário impulsionou o interesse no conceito de Big Data, originalmente sintetizado por Laney (2001) pela combinação de volume, velocidade e variedade. Posteriormente, o conceito foi ampliado com dimensões como veracidade e valor (Gandomi e Haider, 2015). A ascensão do Big Data influenciou profundamente a engenharia de dados, levando ao desenvolvimento de arquiteturas e ferramentas de processamento distribuído, como os ecossistemas Hadoop e Spark, projetados para lidar com dados em escala massiva (White, 2012; Zaharia et al., 2016).

No entanto, muitas equipes analíticas não operam em uma escala que justifique a complexidade operacional associada a essas infraestruturas de Big Data. Mesmo com volumes de dados na ordem de gigabytes, é comum existir pressão por atualizações frequentes, integração de múltiplas fontes e validações sistemáticas de qualidade. Esses contextos situam-se em um espaço intermediário entre os ambientes de Big Data e o tratamento pontual com planilhas e scripts locais, sendo denominados neste trabalho como “not too big data”. Para esses cenários, a necessidade de governança e reprodutibilidade, comparáveis às práticas modernas, é um problema de engenharia que exige soluções com custo operacional compatível para equipes enxutas.

Do ponto de vista da engenharia de software, a gestão de pipelines analíticos é um desafio. Ferramentas como o dbt (data build tool) demonstraram a eficácia de abordagens declarativas para organizar transformações SQL em grafos acíclicos direcionados (DAGs). Essas ferramentas permitem que o desenvolvedor descreva o que deve ser produzido, enquanto o framework gerencia a ordem de execução, aplica estratégias de materialização e registra artefatos de auditoria (DBT Labs, 2026a).

Apesar de sua eficácia, a adoção de ferramentas como o dbt frequentemente exige uma cadeia de infraestrutura complexa, incluindo controle de versão externo, integração contínua/entrega contínua (CI/CD), gerenciamento de segredos e um orquestrador dedicado. Essas exigências representam barreiras significativas para equipes com recursos limitados, criando uma lacuna por ferramentas que apliquem os princípios da “analytics engineering” em ambientes mais acessíveis, sem a necessidade de infraestrutura especializada.

O Google Apps Script (GAS) surge como uma alternativa promissora para preencher essa lacuna. É uma plataforma amplamente disponível para organizações que utilizam Google Workspace, oferecendo execução gerenciada em nuvem, autenticação integrada, integração nativa com Google Drive e BigQuery, e um mecanismo de agendamento por triggers. Tais características eliminam a necessidade de provisionamento de servidores ou configuração de ambientes externos (Google, 2026a), reduzindo as barreiras operacionais de adoção.

Apesar das facilidades operacionais do GAS, o ecossistema carece de frameworks que incorporem os benefícios da orquestração declarativa de transformações SQL, incluindo resolução automática de dependências, testes de qualidade e geração de logs estruturados. A contribuição deste trabalho para a área de engenharia de software reside em demonstrar que princípios maduros da engenharia analítica podem ser implementados em ambientes alternativos e mais acessíveis, ampliando o alcance dessas práticas sem impor as complexidades de infraestrutura tipicamente associadas a elas. Assim, este trabalho busca avaliar a viabilidade de um framework declarativo para orquestração de transformações SQL no ambiente Google Apps Script, com execução no BigQuery, como alternativa acessível à aplicação de boas práticas de engenharia analítica em contextos organizacionais que lidam com volumes moderados de dados, mas mantêm exigências de governança, qualidade e reprodutibilidade, sem dispor de infraestrutura de grande escala.

2. Material e Métodos

A presente pesquisa é de natureza aplicada, com objetivo exploratório, orientada ao desenvolvimento e avaliação de um artefato tecnológico. O objetivo central não foi testar hipóteses causais nem produzir generalizações estatísticas, mas investigar a viabilidade e as implicações práticas de uma solução computacional voltada a um problema recorrente em contextos organizacionais específicos.

Quanto à natureza dos dados, adotou-se abordagem qualitativa, uma vez que o fenômeno de interesse foi avaliado de forma interpretativa e descritiva. Isso ocorreu por meio da análise funcional do artefato, da observação de sua execução em cenário real e da avaliação crítica de evidências geradas, sem o recurso a mensurações estatísticas ou amostras representativas de população.

O delineamento adotado foi o estudo de caso instrumental (Gil, 2017; Yin, 2015), modalidade em que o caso não é estudado por seu interesse intrínseco, mas como meio para iluminar um fenômeno ou questão mais ampla. Neste trabalho, a viabilidade de implementar princípios de “analytics engineering” em um ambiente não especializado constituiu o foco principal. A unidade-caso foi o próprio artefato tinyDeskData.

O Google Apps Script (GAS) foi selecionado como ambiente de implementação devido à sua ampla disponibilidade em organizações que utilizam Google Workspace. A plataforma oferece execução gerenciada em nuvem, autenticação e autorização nativas, integração direta com Google Drive e BigQuery, e mecanismos de agendamento por triggers (Google, 2026a). Essas características foram consideradas para reduzir barreiras operacionais e favorecer a replicabilidade do experimento.

As restrições técnicas do GAS, como limites de tempo de execução, cotas de uso de APIs e ausência de paralelismo nativo, influenciaram diretamente as decisões de design do artefato. Tais elementos foram tratados como constitutivos do contexto de pesquisa, moldando a concepção do framework para operar dentro dessas limitações.

Para a coleta de dados, utilizaram-se duas técnicas complementares. A pesquisa bibliográfica fundamentou teoricamente as decisões de design do artefato, por meio do levantamento de práticas consolidadas da engenharia analítica, especialmente aquelas difundidas pelo dbt. Isso incluiu a resolução automática de dependências, definição explícita de materializações, execução de testes de qualidade de dados e geração de logs para rastreabilidade.

A pesquisa documental abrangeu a análise do código-fonte do framework desenvolvido, dos arquivos de configuração do pipeline de caso, dos logs de execução gerados e dos resultados dos testes de qualidade. Essas evidências primárias foram produzidas pelo próprio artefato durante a execução do estudo de caso, fornecendo subsídios para a avaliação de sua funcionalidade e comportamento.

O desenvolvimento do artefato seguiu um processo iterativo. Este processo envolveu o levantamento de requisitos a partir da literatura, a modelagem da arquitetura e dos módulos, e a implementação incremental em JavaScript no ambiente do GAS. Ciclos curtos de validação empírica foram realizados por meio de execuções reais no BigQuery. O código-fonte completo do framework encontra-se disponível em repositório público: https://github.com/moschionigabriel/tinydeskdata.

A avaliação do artefato foi conduzida por demonstração e análise de evidências, conforme proposto na literatura para estudos de caso de artefatos tecnológicos. Três classes principais de evidências foram consideradas: evidências funcionais, evidências de governança mínima e evidências de usabilidade técnica. Cada classe buscou verificar aspectos específicos do comportamento do framework.

A viabilidade funcional do framework foi avaliada por meio da execução completa do pipeline Jaffle Shop Classic (DBT Labs, 2026a). Este é um caso de referência amplamente utilizado pela comunidade de “analytics engineering” para demonstrar pipelines ELT com camadas, dependências e testes de qualidade.

O pipeline implementado no estudo de caso compreendeu duas etapas orquestradas: a ingestão de três fontes de dados (raw_orders, raw_customers e raw_payments) a partir de planilhas do Google Drive para o dataset seeds no BigQuery; e a modelagem de cinco transformações SQL organizadas em duas camadas, staging (stg_customers, stg_orders, stg_payments) e modelos finais (customers, orders), no dataset transform.

O tinyDeskData foi implementado como uma biblioteca JavaScript autocontida, estruturada em uma IIFE (“immediately invoked function expression”) que expõe três métodos públicos: `move`, `model` e `orchestrate`. Internamente, a execução de cada método é organizada como uma cadeia de funções compostas por meio de uma função `_pipeline`, que aplica sequencialmente transformações sobre um objeto de configuração.

O método `move` foi responsável pela etapa de ingestão. Ele aceita um objeto declarativo que especifica uma origem e um destino para os dados. Foram suportadas como fontes planilhas do Google Sheets, arquivos Excel (.xlsx) e CSV armazenados no Google Drive, consultas SQL ao BigQuery e funções escritas em Google Apps Script. Os dados puderam ser carregados no BigQuery ou exportados como CSV para o Drive.

O método `model` implementou a camada de transformação. Seu fluxo interno foi composto por cinco etapas encadeadas: leitura do código SQL bruto a partir de arquivos `.sql.html` hospedados no projeto do GAS; extração automática de dependências por meio de análise sintática da função `ref()`; ordenação topológica do grafo de modelos; compilação do código SQL; e execução sequencial dos modelos no BigQuery com aplicação de testes e estratégia de materialização.

A etapa de compilação foi projetada para resolver construções de template inspiradas na linguagem Jinja utilizada pelo dbt (DBT Labs, 2026b), como a função `ref()`, blocos condicionais e laços. O framework suportou quatro estratégias de materialização: `view`, `table`, `insert` e `incremental`, esta última com subestratégias `append`, `delete+insert` e `merge`.

Para cada modelo, o framework materializou o resultado em uma tabela temporária (`nome_tmp`) e executou testes de qualidade sobre essa tabela intermediária. Somente após a aprovação de todos os testes, o resultado foi promovido para a tabela definitiva. Caso algum teste falhasse, a tabela temporária era removida e o pipeline abortado.

O framework implementou quatro tipos de testes de qualidade, todos executados como consultas SQL sobre a tabela temporária de cada modelo antes de sua promoção. Os testes incluíram `unique` (verificação de duplicatas), `not_null` (identificação de valores nulos), `accepted_values` (validação de valores em um conjunto definido) e `relationships` (verificação de integridade referencial entre tabelas).

O método `orchestrate` atuou no nível mais alto de abstração, coordenando a execução de múltiplos nós, que podiam ser operações de `move` ou `model`, em uma ordem determinada por dependências explícitas. A orquestração também foi responsável pela criação e persistência de logs estruturados em formato JSON no Google Drive a cada execução, fornecendo um histórico auditável das execuções do pipeline.

A configuração completa do pipeline, incluindo ingestão, modelagem e orquestração, foi expressa em um único arquivo JavaScript. Este arquivo definiu estruturas declarativas para seeds (origem e destino), modelagem (schemas, estratégias de materialização, descrições e testes) e orquestração (nós e dependências). A lógica imperativa resumiu-se a uma única chamada à função `tinyDeskData.orchestrate(orchestra)`.

A execução de referência do pipeline Jaffle Shop Classic foi conduzida no ambiente do Google Apps Script em 14 de abril de 2026, com persistência automática do log estruturado gerado pelo método `orchestrate` no Google Drive. O log estruturado completo da execução encontra-se disponível no repositório público do projeto no GitHub.

3. Resultados e Discussão

A avaliação da viabilidade do framework tinyDeskData foi estruturada em torno de três classes principais de evidências: funcionais, de governança mínima e de usabilidade técnica. O comportamento do artefato foi observado durante a execução de um pipeline analítico baseado no Jaffle Shop Classic no ambiente BigQuery, permitindo uma análise crítica à luz da literatura e das limitações inerentes ao contexto. Os resultados obtidos demonstram a capacidade do framework em orquestrar transformações SQL, ao mesmo tempo em que revelam aspectos importantes sobre sua aplicabilidade e o alinhamento com as boas práticas da engenharia analítica em cenários de “not too big data”.

Arquitetura e estrutura do framework

O tinyDeskData foi concebido como uma biblioteca JavaScript autocontida, organizada em uma IIFE (immediately invoked function expression) que expõe três métodos públicos essenciais: `move`, `model` e `orchestrate`. Internamente, a execução de cada um desses métodos é gerenciada por uma cadeia de funções que se compõem sequencialmente através de uma função `_pipeline`. Essa abordagem funcional de composição por redução garante que o resultado de cada etapa alimente a próxima, promovendo a legibilidade e a extensibilidade do fluxo interno sem introduzir dependências complexas entre os módulos do framework.

O método `move` é o responsável pela etapa de ingestão de dados, atuando como uma camada EL (extract-load) dentro do ecossistema Google. Ele aceita um objeto declarativo que especifica a origem e o destino dos dados, oferecendo flexibilidade para diversas fontes, incluindo planilhas do Google Sheets, arquivos Excel (.xlsx) e CSV armazenados no Google Drive, consultas SQL diretas ao BigQuery e até funções personalizadas escritas em Google Apps Script. Para o destino, os dados podem ser carregados em tabelas do BigQuery ou exportados como arquivos CSV para o Google Drive, eliminando a necessidade de ferramentas externas de ingestão.

A camada de transformação é implementada pelo método `model`, cujo fluxo interno é composto por cinco etapas encadeadas. Primeiramente, ocorre a leitura do código SQL bruto a partir de arquivos .sql.html hospedados no projeto do Google Apps Script. Em seguida, o framework realiza a extração automática de dependências por meio da análise sintática da função `ref()`, que identifica as relações entre os modelos. A terceira etapa é a ordenação topológica do grafo de modelos, seguida pela compilação do código SQL, que resolve referências, variáveis de template e blocos condicionais como `is_incremental()`. Por fim, os modelos são executados sequencialmente no BigQuery, aplicando testes e estratégias de materialização.

A compilação do código SQL no tinyDeskData demonstrou a capacidade de resolver três tipos de construções de template, inspiradas na linguagem Jinja utilizada pelo dbt. Isso inclui a função `ref()`, que substitui referências simbólicas entre modelos por identificadores completos de tabela no BigQuery, e blocos condicionais que permitem a inclusão ou exclusão de trechos de SQL com base na existência prévia da tabela de destino. Além disso, o framework suporta laços, possibilitando a geração dinâmica de cláusulas SQL a partir de listas de valores declaradas no próprio template, confirmando a viabilidade de um motor de templates SQL dentro das restrições do Google Apps Script.

O framework também oferece suporte a quatro estratégias de materialização para os modelos. A estratégia `view` registra o modelo como uma visão lógica no BigQuery, sem persistência física dos dados, sendo ideal para camadas de staging e limpeza que não exigem armazenamento permanente. A estratégia `table` persiste o resultado como uma tabela com substituição completa a cada execução, adequada para modelos finais recalculados integralmente. Já a estratégia `insert` adiciona novos registros a uma tabela existente sem eliminar os anteriores, útil para tabelas de acumulação onde o histórico deve ser preservado. Por fim, a estratégia `incremental` oferece três subestratégias: `append` para novos registros sem verificação de duplicatas, `delete+insert` para remoção de registros existentes com base em chaves e inserção dos novos, e `merge` para aplicar uma operação upsert com base em chave única, sendo estas últimas ideais para atualizações parciais de tabelas dimensionais.

O método `orchestrate` opera no nível mais alto de abstração, coordenando a execução de múltiplos nós, que podem ser operações de `move` ou `model`, em uma ordem determinada por dependências explícitas entre eles. Este método também é responsável pela criação e persistência de logs estruturados em formato JSON no Google Drive. A arquitetura geral do framework tinyDeskData integra as fontes de dados com os métodos `move`, `model` e `orchestrate`, direcionando os resultados para destinos como tabelas BigQuery ou arquivos CSV no Drive, e gerando logs JSON no Drive. O pipeline interno do método `model` compreende leitura SQL, extração de dependências, ordenação topológica, compilação e execução com testes e materialização, tudo isso como uma composição funcional por redução.

Evidências funcionais

A viabilidade funcional do framework foi demonstrada pela execução completa do pipeline Jaffle Shop Classic, um caso de referência amplamente utilizado na comunidade de “analytics engineering” para ilustrar pipelines ELT com camadas, dependências e testes de qualidade. O pipeline implementado no estudo de caso envolveu duas etapas orquestradas: a ingestão de três fontes de dados (raw_orders, raw_customers e raw_payments) a partir de planilhas do Google Drive para um dataset de seeds no BigQuery, e a modelagem de cinco transformações SQL organizadas em duas camadas – staging (stg_customers, stg_orders, stg_payments) e modelos finais (customers, orders) – no dataset de transformação.

A resolução automática de dependências entre modelos constituiu um dos resultados mais relevantes. A função `_modelSetDependencies` percorreu o código SQL de cada modelo, identificando chamadas à função `ref()` por expressão regular e construindo dinamicamente o grafo de dependências. Em seguida, a função `_topologicalSort` aplicou o algoritmo de Kahn (Kahn, 1962) para determinar uma ordem de execução que respeitasse as precedências. Isso garantiu que os modelos de staging fossem construídos antes dos modelos finais, sem a necessidade de especificação manual da ordem de execução pelo desenvolvedor, o que é um pilar da abordagem declarativa.

No estudo de caso, os três modelos de staging foram materializados como views, uma decisão alinhada ao seu papel como camadas de limpeza e padronização que não exigem persistência física. Os modelos finais, `customers` e `orders`, foram materializados com a estratégia `insert`. A execução do pipeline foi bem-sucedida, com todos os cinco modelos compilados, executados e persistidos no BigQuery sem erros. O processo completo, desde a ingestão até a materialização final, foi concluído com uma única chamada à função `orchestrate`, demonstrando a capacidade do framework de gerenciar um fluxo de dados complexo de forma integrada.

Um aspecto crucial da implementação é a estratégia de execução em tabela temporária seguida de promoção condicional. Para cada modelo, o framework primeiro materializa o resultado em uma tabela temporária com um nome provisório (`nome_tmp`). Somente após a aprovação de todos os testes de qualidade sobre essa tabela intermediária, o resultado é promovido para a tabela definitiva. Caso algum teste falhe, a tabela temporária é removida e o pipeline é abortado com uma mensagem de erro. Esse ciclo de vida, que inclui compilação do SQL, execução em tabela temporária, testes de qualidade e promoção condicional, previne que dados corrompidos ou inconsistentes contaminem as camadas downstream, funcionando como uma proteção análoga a uma transação em bancos de dados relacionais, embora sem suporte nativo a rollback atômico no BigQuery.

Evidências de governança mínima

A segunda classe de evidências focou nos mecanismos de governança implementados pelo framework, especificamente os testes automatizados de qualidade de dados e a geração de logs estruturados. O tinyDeskData implementa quatro tipos de testes de qualidade, todos executados como consultas SQL sobre a tabela temporária de cada modelo antes de sua promoção ao destino final. O teste `unique` verifica a inexistência de valores duplicados em uma coluna, enquanto o teste `not_null` identifica a presença de valores nulos. O teste `accepted_values` valida se todos os valores de uma coluna pertencem a um conjunto explicitamente definido, e o teste `relationships` verifica a integridade referencial entre tabelas, detectando chaves órfãs por meio de uma operação de junção externa.

Esses quatro tipos de testes correspondem aos testes genéricos do dbt, sendo implementados no tinyDeskData como consultas dinâmicas construídas em tempo de execução. No estudo de caso, o pipeline aplicou um total de 15 asserções de qualidade distribuídas pelos cinco modelos. Os modelos de staging validaram a unicidade e nulidade das chaves primárias (customer_id, order_id e payment_id), além de restrições de valores aceitos para campos categóricos como `status` em `stg_orders` e `payment_method` em `stg_payments`.

Os modelos finais ampliaram o escopo de testes, incluindo a verificação de integridade referencial. Por exemplo, o campo `customer_id` na tabela `orders` foi testado contra a tabela `customers` por meio do teste `relationships`, garantindo que todo pedido estivesse associado a um cliente existente. A aprovação de todas as 15 asserções demonstrou que o pipeline produziu dados internamente consistentes e válidos, conforme as regras de domínio definidas pelo desenvolvedor. A integração dos testes ao ciclo de vida de cada modelo, e não como uma etapa separada, é uma decisão de design significativa, pois vincula a verificação de qualidade à condição de progresso do pipeline.

Essa propriedade, descrita como “fail-fast com propagação de bloqueio”, contribui significativamente para a confiabilidade do pipeline, assegurando que erros de qualidade sejam detectados na camada mais próxima de sua origem. Este mecanismo é fundamental para a qualidade de dados, um conceito multidimensional que abrange acurácia, consistência e completude (Wang e Strong, 1996), dimensões que são parcialmente cobertas pelos quatro tipos de testes implementados no framework. A detecção precoce de inconsistências impede que dados problemáticos se propaguem para as camadas subsequentes, mantendo a integridade do sistema analítico.

Em relação à rastreabilidade, o método `orchestrate` gera automaticamente um arquivo de log em formato JSON a cada execução do pipeline. Este log registra o nome da orquestração, os timestamps de início e fim da execução global, e para cada nó individualmente, os timestamps de início e fim, o tipo de operação (move ou model), e os resultados detalhados. No caso de modelos, os logs incluem os resultados de cada teste de qualidade aplicado, com indicação da coluna, do tipo de teste, do status (PASS ou FAIL) e do número de registros que falharam. Esse arquivo é persistido no Google Drive em uma pasta configurável, criando um histórico auditável das execuções do pipeline.

A presença de logs estruturados é particularmente relevante para equipes com recursos limitados, que nem sempre dispõem de infraestrutura dedicada de monitoramento. O log em JSON pode ser consultado programaticamente, importado para ferramentas de análise ou inspecionado manualmente para fins de auditoria. No contexto do paradigma de “analytics engineering”, a rastreabilidade é um requisito fundamental para a confiança nos dados produzidos (Hevner et al., 2004), e o mecanismo implementado pelo tinyDeskData atende a esse requisito de forma simples e portável, facilitando a auditoria e a depuração dos pipelines analíticos.

Evidências de usabilidade técnica

A terceira classe de evidências avaliou a clareza e concisão da configuração declarativa do pipeline em comparação com abordagens imperativas equivalentes. A premissa do paradigma declarativo na engenharia de dados é que o desenvolvedor deve descrever o que precisa ser produzido, e não como o sistema deve executar cada passo. No estudo de caso, a configuração completa do pipeline, incluindo ingestão, modelagem e orquestração, foi expressa em um único arquivo JavaScript de aproximadamente 70 linhas. Este arquivo define três estruturas declarativas: um array de seeds, um objeto de modelagem com a lista de modelos e seus schemas, e um objeto de orquestração que compõe os nós e suas dependências. A lógica imperativa se resume a uma única chamada: `tinyDeskData.orchestrate(orchestra)`.

Essa separação entre configuração e execução é estruturalmente análoga ao que o dbt oferece por meio de seus arquivos YAML e SQL. No entanto, o tinyDeskData apresenta uma diferença relevante ao consolidar a configuração, o código SQL e a orquestração em um único ambiente (o editor do Google Apps Script). Isso elimina a necessidade de ferramentas externas de controle de versão, CI/CD ou gerenciadores de ambiente. Para equipes que já operam dentro do ecossistema Google Workspace, essa consolidação reduz significativamente a barreira de entrada, tornando a adoção de boas práticas de engenharia analítica mais acessível.

A aplicação de metadados ilustra outro aspecto da usabilidade declarativa. Ao definir descrições para modelos e colunas no objeto de configuração, o framework automaticamente propaga essas informações para o catálogo do BigQuery por meio da função `_applyMetadata`, que utiliza o método `Tables.patch` da API. Isso significa que a documentação técnica dos dados produzidos pelo pipeline é mantida de forma coesa com a configuração, sem exigir etapas adicionais de catalogação. Essa funcionalidade simplifica a manutenção da documentação e garante que ela esteja sempre sincronizada com a estrutura dos dados.

Execução de referência e evidências temporais

A execução de referência do pipeline Jaffle Shop Classic foi realizada no ambiente do Google Apps Script em 14 de abril de 2026, com a persistência automática do log estruturado gerado pelo método `orchestrate` no Google Drive. O pipeline completo foi executado em 54 segundos. A etapa de ingestão (nó `ingestion`) consumiu 15 segundos, enquanto a etapa de modelagem (nó `modeling`) levou 39 segundos. O tempo total de execução situa-se bem abaixo do limite de seis minutos imposto pelo Google Apps Script para contas gratuitas, o que evidencia a viabilidade operacional do framework para pipelines de porte comparável ao caso de referência.

No que se refere à integridade dos dados, as 20 asserções de qualidade distribuídas pelos cinco modelos foram integralmente aprovadas, sem registros de falha em nenhuma coluna testada. Este resultado confirma que o mecanismo de tabela temporária seguido de promoção, combinado aos quatro tipos de teste implementados, operou conforme o previsto para o caso de referência. O log estruturado completo da execução encontra-se disponível no repositório público do projeto no GitHub, permitindo a auditoria e a verificação detalhada de cada etapa do processo.

Em síntese, os resultados demonstram que o tinyDeskData é um framework viável para orquestrar transformações SQL em ambientes Google Apps Script, com execução no BigQuery. Ele permite a construção de pipelines analíticos completos, auditáveis e replicáveis, utilizando uma configuração declarativa concisa. O framework atende às exigências de funcionalidade, governança mínima e usabilidade técnica, oferecendo uma alternativa pragmática para equipes com recursos limitados que buscam aplicar boas práticas de engenharia analítica em contextos de “not too big data”, sem a complexidade de infraestruturas de grande escala.

4. Conclusão

Este trabalho avaliou a viabilidade de um framework declarativo para orquestração de transformações SQL no ambiente Google Apps Script, com execução no BigQuery, como alternativa acessível à aplicação de boas práticas de engenharia analítica em contextos organizacionais que lidam com volumes moderados de dados, mas mantêm exigências de governança, qualidade e reprodutibilidade, sem dispor de infraestrutura de grande escala. Verificou-se que o framework tinyDeskData, desenvolvido em JavaScript, demonstrou capacidade de executar pipelines analíticos completos, auditáveis e replicáveis. Os achados indicaram que a solução implementou com sucesso a resolução automática de dependências, materializações explícitas, testes automatizados de qualidade de dados e geração de logs estruturados, reduzindo a necessidade de código imperativo de controle. A avaliação por meio de um estudo de caso baseado no Jaffle Shop Classic confirmou a funcionalidade do artefato, a governança mínima por meio de 20 asserções de qualidade aprovadas e a usabilidade técnica, evidenciada por uma configuração declarativa concisa que gerenciou um fluxo de dados complexo em 54 segundos. Assim, o framework proposto constitui uma alternativa pragmática para equipes com recursos limitados, ampliando o acesso a boas práticas de engenharia de dados sem a complexidade de infraestruturas de grande escala.

Apesar da viabilidade demonstrada, a análise dos resultados revelou limitações importantes. O Google Apps Script impõe limites de tempo de execução que podem restringir a aplicabilidade do framework a pipelines de complexidade moderada, reforçando seu posicionamento no nicho de “not too big data”. A ausência de paralelismo nativo no GAS implica que os modelos são executados sequencialmente, impactando o tempo total de execução em grafos de dependência mais amplos. Além disso, o framework não incorpora internamente mecanismos de versionamento de esquema, snapshots de dados ou gestão de ambientes, embora o ecossistema do Google Apps Script ofereça as fundações para tais implementações. A estratégia de distribuição do framework, por importação direta de código via URL, não oferece garantias de estabilidade de versão ou mecanismos de atualização controlada. Para estudos futuros, sugere-se a investigação de mecanismos de paralelismo, versionamento de esquema e integração com ferramentas de CI/CD no ecossistema do Google Apps Script, visando aprimorar a robustez e a escalabilidade da solução.

Referências Bibliográficas

DBT Labs. 2026a. Jaffle Shop Classic (repositório GitHub). Disponível em: <https://github.com/dbt-labs/jaffle-shop-classic>. Acesso em: 09 fev. 2026.

Gandomi, A.; Haider, M. 2015. Beyond the hype: big data concepts, methods, and analytics. International Journal of Information Management 35(2): 137-144.

Google. 2026a. Quotas for Google Services (Apps Script). Disponível em: <https://developers.google.com/apps-script/guides/services/quotas>. A

Laney, D. 2001. 3D data management: controlling data volume, velocity and variety. META Group Research Note.

White, T. 2012. Hadoop: the Definitive Guide. 3ed. O’Reilly Media, Sebastopol, CA, USA.

Zaharia, M.; Xin, R.S.; Wendell, P.; Das, T.; Armbrust, M.; Dave, A.; Meng, X.; Rosen, J.; Venkataraman, S.; Franklin, M.J.; Ghodsi, A.; Gonzalez, J.; Shenker, S.; Stoica, I. 2016. Apache Spark: A unified engine for big data processing. Communications of the ACM 59(11): 56-65.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy