Datta Intelligent Query Layer — Discovery e Fundações

Camadas de "inteligência de consulta" costumam chegar com uma exigência incômoda: mudar como as pessoas consultam. O Datta Intelligent Query Layer foi projetado para o contrário — ele se acopla ao que a plataforma já tem (Trino como motor analítico, Neo4j como grafo, OpenSearch como índice de busca e telemetria, a ontologia como camada de significado) e melhora as consultas por observação, sem pedir nada a quem escreve SQL. Esta página registra o levantamento que originou a camada: o que existia antes dela, onde ela se conecta, as decisões fechadas e os riscos mapeados.

Nome e navegação

Rótulo na interface: o que antes aparecia como "SIQL" hoje se chama "Intelligent Query Layer" (menu e trilha; "Datta Intelligent Query Layer" segue como nome por extenso). A sigla SIQL continua sendo o nome curto usado internamente — na permissão SIQL:ADMIN, na base de grafo dedicada datta-siql-db, no tópico de eventos datta-siql.trino-events e nesta documentação.
Onde fica: o console é uma funcionalidade da categoria Descobrir da tela Features — DescobrirIntelligent Query Layer, ao lado de Knowledge Catalog e Explorar Dados. Histórico: nasceu no submenu Data Layer (junto de Neo4j, OpenSearch, cache da plataforma, Kafka, LLM/vLLM, Spark, Trino e MinIO), depois virou item do grupo Sistema em Configurar, e em 2026-08-07 foi promovido a funcionalidade — é um workbench de inteligência de consultas (NL-to-SQL, aprendizagem, feature store), não apenas configuração.
Trilha de navegação: DATTA | Descobrir | Intelligent Query Layer.
Efeitos da mudança: abrir a página realça a entrada correspondente do menu lateral — não mais o grupo Sistema de Configurar; o card correspondente segue fora do painel de visão geral do Data Layer.

As mudanças foram puramente de apresentação: a rota da página (?view=settings-siql), a base de dados, a permissão e os nomes internos permaneceram os mesmos.

O que a camada encontrou pronto

O levantamento partiu de um princípio: não trocar o motor analítico nem reescrever a plataforma, e sim acoplar a inteligência ao que já roda.

Componente	Estado encontrado
Motor analítico	Trino 480, com o catálogo `iceberg` apontando para um Hive Metastore (Derby embutido) sobre HDFS, formato Parquet + Snappy. Não há REST catalog nem Glue/Nessie. Catálogos auxiliares: `hive` (tabelas Parquet legado) e `memory`
Eventos de consulta	Nenhum. O motor não publicava eventos de execução em lugar algum — nem em tópico, nem por HTTP
Grafo	Neo4j em cluster causal de 3 cores, com suporte a múltiplas bases — o que permitiu isolar a camada em base própria
Índice de busca e telemetria	OpenSearch já em produção, com templates de índice e políticas de ciclo de vida ativos; convenção de nome `datta-<dominio>-*` para índices com rollover
Barramento de eventos	Kafka 3.8.0 (KRaft) com 3 brokers, disponível para publicação assíncrona
Camada semântica	Ontologia investigativa (tipos de entidade, relacionamentos, mapeamentos semânticos, gêmeos digitais, importação/exportação OWL/SHACL, resolução de entidades e materialização) e glossário de negócio do Knowledge Catalog, ambos já existentes
LLM	Modelos de linguagem já integrados à plataforma

A integração com a camada semântica ficou reservada para a fase 5; no MVP apenas se documentou onde ela se pluga. O uso de LLM ficou fora do escopo da fase 1.

Como a camada se encaixa

Consulta SQL do usuario
        |
        v
  Motor analitico (Trino 480)
        |
        |-- ouvinte de eventos de consulta
        |        |-- publica no topico datta-siql.trino-events
        |        '-- (contingencia) envia direto a camada, por HTTP
        v
  Datta Intelligent Query Layer
        |- conselheiro (caminho quente, orcamento de 20 ms)
        |- consumidor dos eventos de consulta
        '- atualizador de snapshots (diario; le metadados Iceberg via Trino)
                 |
        +--------+-------------------+
        v                            v
  Grafo de metadados            Telemetria e analytics
  (base datta-siql-db)          (indices datta-siql-events-*)

O usuário continua escrevendo SQL normal — nada muda na forma de consultar. A camada recebe os eventos de consulta e responde às solicitações do conselheiro por endpoints próprios; veja a referência de API.

O acoplamento ao otimizador do motor (envolver os metadados do conector para consultar o conselheiro durante o planejamento) ficou previsto para a fase 2 — no MVP a camada só observa.

Decisões fechadas

Decisão	Valor
Nome oficial da funcionalidade	`datta-intelligent-query-layer`
Nome curto interno	SIQL
Porta do serviço	8240
Base de grafo dedicada	`datta-siql-db` — isolada das demais, menos contenção
Índice de telemetria	`datta-siql-events-<yyyy-MM-dd>`, diário
Tópico de eventos	`datta-siql.trino-events`
Modo de publicação dos eventos	Duplo: o plugin tenta o tópico e, em caso de falha, envia por HTTP direto à camada
Modo padrão do conselheiro	`STATS_ONLY` — só devolve linhas e bytes estimados, não tenta podar leitura. Os modos `RANKING` e `FULL` chegam nas fases seguintes
Permissão	`SIQL:ADMIN`
Cache	Espaço lógico dedicado no cache da plataforma, sem compartilhamento com outros módulos
Interface de configuração	Reusa o padrão visual das demais páginas de configuração da plataforma

Riscos mapeados e como foram tratados

Risco	Tratamento
O motor analítico não tinha ouvinte de eventos de consulta	Um plugin próprio, compilado contra a API de extensão do Trino 480, é distribuído junto com a instalação e passa a publicar cada evento de execução
O catálogo Iceberg usa Hive Metastore, sem REST catalog	O atualizador de snapshots lê os metadados pelo próprio motor analítico, consultando as tabelas de sistema `$snapshots`, `$files`, `$manifests` e `$partitions`. Não depende de catálogo REST externo
O conselheiro precisa caber em 20 ms	Cache em duas camadas (memória local + cache da plataforma). O caminho quente é apenas uma consulta por hash da requisição; grafo e índice só são tocados quando falta no cache, em paralelo e com 15 ms por origem. Se o orçamento estoura, a resposta cai para um resultado determinístico
Carga adicional no cluster de grafo	A camada escreve apenas na sua base dedicada, sempre em lote e em segundo plano — nunca no caminho da consulta do usuário
Volume de telemetria no índice	Índice diário com ciclo de vida de 7 dias quente → 30 dias morno → remoção aos 90 dias. Um shard e uma réplica no MVP
Dados pessoais em predicados `WHERE`	Um estágio de mascaramento roda antes de qualquer gravação: valores literais e o SQL registrado passam por máscara
Dependência da versão do motor	O plugin é compilado contra a versão estável em produção (480); um upgrade do motor exige recompilar o plugin

Perguntas em aberto

Catálogo Iceberg REST: a instalação atual usa o Hive Metastore. Se no futuro migrar para Nessie ou outro catálogo REST, o atualizador de snapshots precisará parametrizar o cliente. Não bloqueia o MVP.
Cadastro central de conexões: a plataforma exige que toda fonte externa seja registrada no cadastro central. O conselheiro não abre conexão a nenhuma fonte JDBC — ele apenas lê metadados pelo motor analítico, pelo grafo e pelo índice, todos internos —, então não há exceção à regra. Se uma fase futura passar a ler direto de um catálogo Iceberg REST, essa origem deve ser cadastrada normalmente.

Para saber mais

Especificação da camada — o valor e o escopo em uma página.
NL-to-SQL — perguntas em português viram SQL governado.
Referência de API — os endpoints expostos pela plataforma.