01
Coleta
Fontes aeronauticas, meteorologicas e regulatorias são acessadas por DAGs especializadas.
1. Visão Arquitetural Consolidada
O AirData opera como um ecossistema composto por frentes distintas, conectadas por dados, semântica e serviços de consulta. A arquitetura se organiza em torno de um núcleo analítico sustentado por Apache Airflow e PostgreSQL, sobre o qual se apoiam camadas de qualidade, publicação semântica e recuperação inteligente.Ref. Airflow + PostgreSQL
Arquiteturalmente, a plataforma de dados aeronáuticos organiza-se em quatro domínios canônicos: ingestão e transformação, armazenamento analítico, modelagem semântica e recuperação inteligente de conhecimento.
Leitura macro
- Fontes externas heterogeneas alimentam DAGs especializadas.
- O PostgreSQL atua como warehouse e ponto de convergencia operacional.
- A qualidade funciona como camada de observabilidade e confianca.
- A ontologia organiza o dominio e a camada RAG amplia a consulta ao conhecimento.
2. Mapa do Ecossistema Arquitetural
O diagrama abaixo resume a composição geral do ecossistema e a relação entre fontes, processamento, armazenamento, semantica e interfaces de consumo.
Visualização tridimensional técnica
Esta peca traduz a arquitetura logica em um arranjo espacial: fontes, orquestração, warehouse, ontologia, RAG e interfaces aparecem como camadas interdependentes do ecossistema.
Como interpretar a cena
O núcleo de dados permanece no centro, enquanto semantica, IA e interfaces irradiam valor a partir dele.
A composição 3D não substitui o diagrama analítico; ela o complementa. Seu papel e tornar explicito que o ecossistema depende de um centro operacional robusto e de camadas especializadas que se apoiam nesse núcleo para entregar qualidade, interpretação e consulta inteligente.
Fontes e pipelines como entrada continua
PostgreSQL como convergencia operacional
Ontologia e RAG como expansao semantica e cognitiva
Fontes
ANAC / VRA
DECEA / AISWEB
ICEA / Odin
IEM / ASOS
LexML / PDFs
↓
Orquestração e ETL
Apache Airflow
DAGs de extração
Pipelines de transformação
↓
Núcleo analítico
PostgreSQL / Data Warehouse
Schemas AirData
Base para métricas e exploração
↓
Qualidade e observabilidade
FastAPI
Quality Agent
Dashboard Web
Camada semântica
Ontologia OWL
ROBOT / WIDOCO
Portal OntoSite
Consulta inteligente
Embeddings
Qdrant
Ollama / API RAG / Chat
Em termos simples, dados e documentos entram por pipelines distintas, convergem em armazenamento e depois irradiam valor por observabilidade, semântica e recuperação inteligente.
3. Fluxo de Dados e Processamento
A espinha dorsal do ecossistema é o fluxo operacional dos dados. O Apache Airflow coordena a ingestão contínua, enquanto o PostgreSQL cumpre o papel prescritivo de warehouse central para análise, exploração e monitoramento.
02
Orquestração
O Airflow agenda, controla dependencias, gerencia status e serializa a execução dos fluxos.
03
Persistencia
O PostgreSQL centraliza os dados já estruturados para consumo analítico e operacional.
04
Consumo
Camadas superiores de qualidade, ontologia, visualização e IA consomem o núcleo de dados.
4. Camada Semantica e Publicação Ontologica
O ecossistema mantém uma separação estrita da governança: a ontologia opera como fonte exclusiva da verdade conceitual em backoffice, viabilizando sua publicação, aprovação rigorosa e validação através de uma esteira técnica automatizada até o portal público.Ref. OWL / RDF
01
Fonte semantica
Arquivos OWL versionados preservam a ontologia como fonte principal da verdade conceitual do dominio.
02
Tratamento técnico
Scripts de análise e automações preparam validações, consistencia estrutural e geração de artefatos.
03
Toolchain ontologica
ROBOT, WIDOCO e WebVOWL transformam o modelo em documentação, visualização e material navegavel.
04
Publicação e consumo
O OntoSite e os relatorios resultantes tornam a ontologia acessivel para consulta, governança e comunicação institucional.
5. Camada RAG, Busca Vetorial e IA Aplicada
A arquitetura RAG provê uma camada especializada para consulta acelerada ao acervo regulatório. O pipeline de ingestão capta documentos brutos via scrapers, convertendo-os em chunks e embeddings armazenados no Qdrant, enquanto o backend consumido pelo usuário final estrutura a IA via Ollama.Ref. Qdrant / Ollama
01
Extração documental
DECEA, LexML e PDFs locais são baixados e convertidos em documentos processaveis.
02
Chunking e embeddings
Os textos são fragmentados e transformados em vetores com Legal-BERTimbau.
03
Busca vetorial
O Qdrant indexa o acervo e recupera trechos semanticamente próximos da pergunta.
04
Geração e entrega
Ollama e a API RAG produzem a resposta, servida ao chat web com citações e contexto.
6. Implantação Operacional e Relação com a Infraestrutura
A arquitetura lógica exige uma decomposição operacional clara por domínios técnicos, garantindo alocação eficiente na infraestrutura on-premises de GPUs e servidores estáveis.
Dominio de dados
Airflow
PostgreSQL
ETL / DAGs
Dominio semantico
Ontologia OWL
ROBOT / WIDOCO
Portal semantico
Dominio de IA
Embeddings
Qdrant
Ollama / RAG API
Para a hospedagem, a separação restringe o acesso direto aos bancos de dados persistentes e às cargas de inferência, reforçando a governança, a performance local e mitigando contenção de recursos em um mesmo host.
7. Diagrama de Implantação por Host e Dominio Técnico
A alocação de componentes obedece ao perfil de carga e à especialização das VMs. Este desenho operacional define a topologia canônica recomendada para isolar workloads pesados e escalar as funções do ecossistema.
Host 1 · Lessonia
Dominio de IA e busca vetorial
32 cores · 1 TB RAM · 2x L40S · ~16 TB NVMe
Qdrant e indices vetoriais
Ollama e serviços de inferencia
RAG API e interface de chat
Processamentos intensivos em GPU
Host 2 · VM secundaria
Dominio de dados e operação
104 vCPU informadas · 2 TB ou ~931 GB RAM · 2x L40S
Apache Airflow e DAGs
PostgreSQL / schemas AirData
Quality Check e dashboards
Serviços web de apoio e publicação
Camada publicada
Entrega externa e acesso institucional
Interfaces e documentos expostos para consumo técnico, institucional e operacional.
OntoSite / GitHub Pages
Portal Next.js de documentação
Dashboard de qualidade
Chat RAG exposto via dominio
A
Dominio de ingestao
Airflow, ETL e PostgreSQL operam como núcleo persistente e devem ficar próximos do storage e das rotinas de manutenção.
B
Dominio de IA
Embeddings, Qdrant, Ollama e a API RAG se beneficiam de isolamento e afinidade com GPU e memoria alta.
C
Dominio de publicação
Portais e dashboards podem ficar desacoplados, reduzindo acoplamento com serviços de banco e inferencia.
D
Governança operacional
Essa separação facilita observabilidade, backup, politicas de acesso e planejamento de crescimento por dominio.
| Domínio | Componentes sugeridos | Motivo de colocação |
|---|---|---|
| Ingestao e warehouse | Airflow, DAGs, PostgreSQL, Quality Check | Maior proximidade com persistencia, ETL, I/O e rotina operacional continua. |
| RAG e IA | Qdrant, embeddings, Ollama, API RAG | Uso intensivo de GPU, memoria e latencia baixa entre componentes vetoriais. |
| Publicação e navegação | OntoSite, portal documental, interfaces web | Serviços mais leves e com melhor desacoplamento para exposição e manutenção. |
8. Rede, Reverse Proxy e Exposição de Serviços
A topologia de rede define explicitamente a fronteira de exposição, isolando os bancos de dados, chaves de API e motores de inferência em redes privadas, deixando expostos unicamente os gateways de HTTP (Reverse Proxy) e os frontends web.
Serviços internos conhecidos
- Quality Check local em `127.0.0.1:9010`.
- RAG Web atras do Nginx em `127.0.0.1:8082`.
- RAG API atras do Nginx em `127.0.0.1:8083`.
- Qdrant exposto em `6333` e `6334`.
- Ollama exposto em `11434`.
Pontos publicos conhecidos
- `http://chatbot.airdata.ita.br/ragweb/` para a interface RAG.
- `http://data.airdata.ita.br/` para o dashboard de qualidade.
- `https://ita-airdata.github.io/OntoSite/index.html` para o portal ontologico.
Leitura operacional
- Integração nativa de proteção SSL/TLS no gateway.
- Motor Ollama e Database PostgreSQL rigidamente bloqueados para acessos de fora da rede.
- Isolamento entre workloads expostos (RAG Web) e os motores persistentes isolados.
Segurança e acessos (Compliance)
- Chaves do Airflow operacionais registradas via secrets manager seguros.
- Exigência total de credenciais em APIs RAG publicadas.
- Permissões delimitadas via RBAC para gerir chaves de indexação vetorial.
Camada 1
Usuarios e consumidores
Perfis que interagem com o ecossistema por consulta, operação e consumo institucional.
Pesquisadores
Operação / Engenharia
Consumidores institucionais
Camada 2
Exposição publica
Endpoints e frentes externas conhecidas para acesso as aplicações e publicações do projeto.
chatbot.airdata.ita.br/ragweb/
data.airdata.ita.br
GitHub Pages / OntoSite
Camada 3
Reverse proxy e aplicações
Faixa intermediaria de entrega, roteamento e publicação das interfaces web e APIs expostas.
Nginx /ragweb -> 8082
Nginx /ragapi -> 8083
FastAPI Quality Check 9010
Camada 4
Backends e persistencia
Serviços persistentes e internos que sustentam armazenamento, recuperação e execução central do ecossistema.
PostgreSQL
Qdrant 6333 / 6334
Ollama 11434
Airflow / DAGs
| Serviço | Exposição conhecida | Porta / caminho | Comentário operacional |
|---|---|---|---|
| Quality Check | Dominio público e execução local documentada | `9010` local; `data.airdata.ita.br` publicado | Precisa de validação de como o dominio público esta roteado ate a aplicação. |
| RAG Web | Publicação via Nginx | `/ragweb/` -> `8082` | Ha indicio claro de reverse proxy HTTP no README de deploy. |
| RAG API | Publicação via Nginx | `/ragapi/` -> `8083` | Deve permanecer protegida por chave API e preferencialmente com menor exposição externa. |
| Qdrant | Serviço interno de suporte ao RAG | `6333` / `6334` | Idealmente restrito a rede interna e aos serviços de IA. |
| Ollama | Serviço interno de inferencia | `11434` | Também deve ficar protegido e próximo da camada GPU. |
| OntoSite | Publicação estatica | GitHub Pages | Baixo acoplamento com a infraestrutura de aplicação principal. |
9. Matriz dos Sistemas e Integrações
| Sistema | Função principal | Entradas | Saídas / consumo | Responsável |
|---|---|---|---|---|
| `ita-airdata-pipelines` | Extração, transformação e orquestração de dados. | ANAC, DECEA, ICEA, IEM/ASOS e outras fontes aeronauticas. | Dados estruturados no PostgreSQL. | Felipe Lelis (Data Engineering / Arquitetura) |
| `ita-airdata-quality-check` | Observabilidade, integridade e monitoramento de qualidade. | PostgreSQL, status do Airflow, métricas de sistema. | Dashboard, APIs e logs de qualidade. | Guilherme (Quality Engineering) |
| `ita-airdata-ontology` | Modelagem conceitual e distribuição da ontologia. | Domínio aeronáutico e modelagem semântica. | Artefatos OWL, documentação, grafo e relatórios. | Jairo (Especialista em Semântica OWL) |
| `ita-airdata-owl` | Pipeline técnico da ontologia e publicação do site. | Arquivos OWL versionados. | HTML, WebVOWL, changelog, relatórios de qualidade. | Jairo (Especialista em Semântica OWL) |
| `ita-airdata-rag-system-llm` | Busca vetorial e geração de respostas sobre documentos normativos. | DECEA, LexML, PDFs locais, Qdrant, Ollama. | API RAG, chat web e respostas contextualizadas. | Vitor (Especialista de IA / RAG) |
| `data-retention-policy` / portal atual | Governança documental, arquitetura e consolidação institucional. | Conhecimento transversal do ecossistema. | Portal técnico e documentação integrada. | Felipe Lelis (Data Engineering / Arquitetura) |
10. Matriz de Dependencias e Criticidade Operacional
Além de compreender o papel de cada sistema, e importante tornar explicita a cadeia de dependencias e o impacto provavel de uma indisponibilidade. Essa leitura ajuda a priorizar recuperação, monitoramento e desenho de contingencia de forma mais objetiva.
| Sistema | Dependências críticas | Impacto se indisponível | Criticidade | Prioridade de recuperação |
|---|---|---|---|---|
| `ita-airdata-pipelines` | Airflow, conectores externos, PostgreSQL, credenciais e agenda de execução. | Interrompe ingestao de novas cargas, degrada atualização do warehouse e afeta sistemas dependentes. | Alta | Imediata |
| PostgreSQL / núcleo analítico | Storage, rede interna, politicas de backup, manutenção e hosts de dados. | Afeta pipelines, dashboards, validação de qualidade e parte relevante da inteligência operacional. | Alta | Imediata |
| `ita-airdata-quality-check` | PostgreSQL, Airflow, FastAPI, acesso de rede e logs. | Reduz observabilidade e dificulta detecção precoce de degradação da base e dos fluxos. | Media | Alta |
| `ita-airdata-rag-system-llm` | Qdrant, Ollama, corpus ingerido, API RAG, reverse proxy e GPU. | Interrompe o serviço de consulta inteligente, mas não paralisa o núcleo de ingestao e warehouse. | Media | Alta |
| Qdrant | Storage local, rede interna, embeddings e pipeline de ingestao documental. | Inviabiliza busca vetorial e degrada a camada RAG, mantendo o restante do ecossistema operacional. | Media | Alta |
| Ollama | GPU, modelos carregados, runtime local e conectividade interna com a API. | Interrompe geração de respostas, embora parte da recuperação vetorial ainda possa existir separadamente. | Media-baixa | Media |
| `ita-airdata-ontology` / `ita-airdata-owl` | Arquivos OWL, toolchain ROBOT/WIDOCO e publicação estatica. | Afeta documentação e governança semantica, mas com menor impacto imediato sobre a operação diaria. | Media-baixa | Planejada |
| Portal documental Next.js | Hospedagem web estatica ou app, rotas e conteudo versionado. | Reduz acesso ao conhecimento institucional, mas não interrompe os serviços centrais de dados. | Baixa | Planejada |
Meta de RTO
PostgreSQL e Airflow devem ter o menor RTO possivel, porque sustentam a maior parte do ecossistema. Camadas documentais e semanticas podem ter janelas mais flexiveis.
Meta de RPO
O RPO aceitavel do warehouse deve acompanhar a cadencia das cargas e o custo operacional de reprocessamento. Quanto menor a janela de perda, menor o acumulo de inconsistencia.
Prática essencial
Backup sem teste de restauração não fecha a disciplina de continuidade. O plano precisa prever ensaio periodico de recovery em ambiente controlado.
11. Continuidade Operacional, Backup e Recovery
A arquitetura também precisa ser lida pela lente da continuidade operacional. Em um ecossistema como o AirData, o ponto central não e apenas publicar componentes, mas garantir que dados, pipelines, vetores, modelos e interfaces possam ser restaurados com previsibilidade minima.
Prioridade estrutural
PostgreSQL e Airflow constituem a espinha operacional do ecossistema. Sua recuperação deve preceder a retomada de camadas como RAG, ontologia e portais publicos.
Monitoramento minimo
E recomendavel acompanhar disponibilidade de serviços, atraso das DAGs, crescimento de disco, saude do PostgreSQL, uso de GPU, Qdrant, Ollama, latencia das interfaces e falhas de publicação externa.
| Domínio | Mecanismo mínimo recomendado | Objetivo operacional | Cadência sugerida |
|---|---|---|---|
| PostgreSQL / warehouse | Backup logico recorrente, snapshot em storage e teste periodico de restauração. | Preservar schemas, dados históricos e capacidade de retomada do núcleo analítico. | Backup diario; teste semanal de restore. |
| Airflow e pipelines | Versionamento continuo das DAGs, export de variaveis e conexoes, inventario de credenciais. | Retomar orquestração e permitir reprocessamento com rastreabilidade. | Sincronização continua por Git; revisao quinzenal de configurações. |
| Qdrant e indices vetoriais | Persistencia das coleções, snapshot do volume e procedimento de reindexação documentado. | Reduzir o tempo de reconstrução da camada RAG e manter o corpus vetorial disponivel. | Snapshot diario; ensaio mensal de rebuild parcial. |
| Ollama e inferencia | Catalogo versionado de modelos, checklist de runtime e automação de provisionamento local. | Permitir reativação previsivel da geração sem depender de ajuste manual extenso. | Validação a cada troca de modelo; revisao mensal. |
| Reverse proxy e apps web | Versionamento de Nginx, compose ou systemd, além de inventario de dominios, portas e caminhos. | Restabelecer exposição externa com menor risco de erro de roteamento. | Versionamento continuo; teste a cada mudanca de deploy. |
| Ontologia e publicação semantica | Versionamento dos OWLs, artefatos de build e pipeline reproduzivel do portal ontologico. | Preservar a base conceitual do projeto e a capacidade de republicação confiavel. | Por commit relevante e antes de cada publicação. |
01
Detectar
Identificar a falha por dashboard, alarme, log, atraso de DAG ou indisponibilidade percebida pelos usuarios.
02
Isolar
Separar rapidamente se o incidente esta em dados, rede, publicação, aplicação, GPU ou camada vetorial.
03
Restaurar
Executar o recovery pela cadeia de prioridade, comecando pelo núcleo de dados e avancando para serviços dependentes.
04
Validar
Confirmar integridade, consistencia dos dados, retomada das rotas publicas e normalização da carga operacional.
Meta de RTO
PostgreSQL e Airflow devem ter o menor RTO possivel, porque sustentam a maior parte do ecossistema. Camadas documentais e semanticas podem ter janelas mais flexiveis.
Meta de RPO
O RPO aceitavel do warehouse deve acompanhar a cadencia das cargas e o custo operacional de reprocessamento. Quanto menor a janela de perda, menor o acumulo de inconsistencia.
Prática essencial
Backup sem teste de restauração não fecha a disciplina de continuidade. O plano precisa prever ensaio periodico de recovery em ambiente controlado.
Metas sugeridas de RTO e RPO por dominio
| Domínio / serviço | RTO sugerido | RPO sugerido | Justificativa arquitetural |
|---|---|---|---|
| PostgreSQL / núcleo analítico | 2 a 4 horas | Ate 24 horas, idealmente menor conforme a janela de carga | E o ponto de convergencia do ecossistema e afeta pipelines, qualidade e exploração analítica. |
| Airflow / orquestração | 4 horas | Baixo, desde que DAGs e variaveis estejam versionados | Sem orquestração, o projeto perde capacidade de atualização e reprocessamento previsivel. |
| Quality Check | 8 horas | 24 horas | Não interrompe o dado central, mas reduz observabilidade e aumenta tempo de detecção de falhas. |
| Qdrant / busca vetorial | 8 a 12 horas | 24 horas ou rebuild controlado | A camada RAG fica degradada, porem o restante do ecossistema continua funcional. |
| Ollama / inferencia | 12 horas | Baixo, desde que catalogo de modelos esteja documentado | A indisponibilidade afeta geração, mas não paralisa ingestao, warehouse ou publicação semantica. |
| Ontologia e publicação semantica | 24 horas ou mais | Por release ou commit relevante | Tem alto valor institucional, mas menor urgencia frente ao núcleo de dados e operação continua. |
| Portal documental | 24 a 48 horas | Por commit ou publicação | E importante para governança e acesso ao conhecimento, mas não interrompe serviços centrais. |
Diagrama logico de backup e restore entre hosts
Etapa 1
Host operacional
Serviços que precisam ser protegidos como núcleo ativo do ecossistema.
PostgreSQL
Airflow / DAGs
Qdrant
Ollama / modelos
Nginx / configs
Etapa 2
Camada de proteção
Mecanismos minimos para preservar dados, configuração, histórico e capacidade de recomposição.
Backups logicos
Snapshots de volume
Repositorio Git
Inventario de segredos
Artefatos de build
Etapa 3
Destino de recovery
Possiveis rotas de recomposição apos falha, restore ou reativação assistida.
Mesmo host restaurado
Host secundario
Ambiente de contingencia
Reprocessamento controlado
Validação funcional
A leitura recomendada e separar a proteção por natureza do ativo: dados persistentes com backup e snapshot, configuração por Git e inventario, e componentes reconstitutiveis por provisionamento e reprocessamento controlado.
Runbooks minimos por tipo de incidente
| Incidente | Primeira ação | Recuperação mínima | Validação final |
|---|---|---|---|
| Falha do PostgreSQL | Congelar escritas e monitorar o IOPS alertado por dashboard ativo. | Executar o script 'make restore-db' no cluster para engajar o último snapshot diário. | Conferir schemas via Quality Agent test loop. |
| Paralisação do Airflow | Verificar scheduler, banco interno, e segredos criptografados. | Recriar orquestradores acionando o docker-compose ou kubernetes YAML oficial. | Confirmar retomada de agenda pelo dashboard de DAGs principal. |
| Indisponibilidade do Qdrant | Isolar o cluster vetorial no balanceador de carga preventivo. | Reconstituir persistência reiniciando storage local e reengatando embeddings. | Passar a suíte de testes de aproximação semântica da API local. |
| Falha do Ollama ou da GPU | Verificar integridade do kernel driver CUDA e limites do host físico. | Recarregar modelos base com parâmetros do manifest de configuração original. | Garantir SLO alvo em prompts de validação do check de saúde. |
| Quebra de publicação web ou proxy | Inspecionar Nginx ingress, certificados auto renovados, e rotas internas fechadas. | Refazer deploy de conf estática aprovada pelo pipeline e reiniciar worker. | Ping HTTP 200 nas URLs de saída pública em todos os domínios mapeados. |
12. Decisoes Arquiteturais que Fazem Sentido no Ecossistema
Airflow para orquestração
Faz sentido pela natureza batch e agendada das extrações, além da necessidade de reprocessamento e rastreabilidade.
PostgreSQL como convergencia
E uma base solida para consolidar multiplas fontes e servir analises, embora exija governança de crescimento.
OWL para governança conceitual
A ontologia ajuda a estabilizar vocabulario, relações e interoperabilidade entre sistemas e equipes.
Qdrant para busca semantica
Adequado para recuperar trechos normativos por similaridade e sustentar a experiencia de RAG.
Ollama local
Reforca autonomia de execução, controle sobre o ambiente e alinhamento com a capacidade GPU on-premises.
Portal documental em Next.js
Unifica documentação, inventario, arquitetura e governança institucional em uma camada única de navegação.
13. Lacunas Arquiteturais e Próximos Passos
Para solidificar ainda mais a governança absoluta da plataforma de dados, os seguintes passos arquiteturais representam a prioridade canônica das próximas sprints:
Lacunas a preencher
- Mapa de ambientes: desenvolvimento, homologação e produção.
- Portas, dominios, autenticação e fronteiras de rede.
- Dependencias entre serviços hospedados em cada VM.
- Politica de backup, recovery e observabilidade integrada.
Proxima evolução sugerida
- Diagrama de implantação por host ou VM.
- Mapa C4 de containers e integrações internas.
- Inventario de portas e caminhos de acesso.
- Matriz de risco arquitetural por sistema.