L’architettura dati dietro gli audit di GeoSonar

Quando abbiamo definito lo schema dati di GEO Audit Result, la prima sfida è stata semantica: Come descrivere un audit in modo stabile, validabile e interoperabile?

Subito dopo è arrivata una domanda più concreta: Come usare quel risultato quando non deve più servire soltanto a generare un report, ma anche ad alimentare dashboard, confronti storici, analisi per brand, aggregazioni sulle fonti e controlli sulle citazioni?

Finché un audit viene letto come documento finale, un JSON validato è sufficiente. Quando lo stesso audit deve diventare una base dati interrogabile, il problema cambia.

Non basta persisterlo. Bisogna poterlo analizzare senza perdere il significato che lo rende utile.

Lo stack dati di GeoSonar nasce da questa esigenza. JSON conserva il contratto completo dell'audit. Parquet rende più efficienti le letture di dati colonnari. DuckDB e MotherDuck permettono di effettuare query analitiche su viste derivate. Polars mantiene coerenti trasformazioni, scoring e confronti tra serie storiche.

L'obiettivo finale era di evitare che un risultato ricco, nato come contratto strutturato, tornasse a essere un documento difficile da interrogare.

Per farla breve

La scelta dello stack dati di GeoSonar nasce da una netta separazione delle responsabilità architetturali:

• JSON conserva la forma completa e canonica del risultato.
• Parquet rende interrogabili le parti analitiche in forma colonnare.
• DuckDB permette query SQL leggere su dati analitici.
• MotherDuck rende condiviso e persistente il livello analitico quando serve andare oltre il processo locale.
• Polars trasforma e calcola dati strutturati in modo coerente, dal singolo audit alle serie storiche.
• PostgreSQL persiste lo stato applicativo e transazionale della soluzione.

Questa architettura non sostituisce il formato base dell'audit, ma ne facilita l'interrogazione.

Il flusso può essere letto così:

flowchart TD
    A[Audit GEO] --> B[JSON canonico<br/>risultato completo]
    B --> C[Report e API<br/>lettura documentale]
    B --> D[Proiezioni Parquet<br/>parti analitiche]
    D --> E[DuckDB<br/>query e viste locali]
    D --> F[MotherDuck<br/>livello analitico condiviso]
    D --> G[Polars<br/>trasformazioni e scoring]
    E --> H[Dashboard<br/>KPI e aggregazioni]
    F --> H
    G --> I[Confronti storici<br/>batch e ricalcoli]
    J[PostgreSQL<br/>stato applicativo] --> K[Utenti, progetti<br/>configurazioni]

Perché un audit GEO diventa un dataset

Un audit GEO non contiene solo gli score. Include findings, fonti citate, competitors, test di citazione, evidenze, raccomandazioni e priorità operative.

Gli stessi dati servono per due usi diversi.

Il primo è documentale: un report deve spiegare ad un utente che cosa è emerso, quali problemi sono rilevanti e quali azioni sono prioritarie.

Il secondo è analitico: il risultato deve poter rispondere a domande ripetibili, confrontabili e interrogabili nel tempo.

Qui nasce la differenza tra conservare un audit e poterlo usare nel tempo. Il risultato completo deve restare leggibile, ma le sue evidenze devono poter diventare righe, colonne e aggregazioni.

Il JSON conserva il significato dell'audit

Il GEO Audit Result descrive che cosa significa un audit: quali punteggi contiene, quali evidenze li sostengono, quali fonti sono state citate, quali competitor sono comparsi e quali azioni derivano dai finding.

Questa forma completa deve rimanere disponibile. Serve per validare il risultato, generare report, servire API, mantenere compatibilità tra sistemi e ricostruire il contesto dell'audit. In questo senso, JSON resta la forma naturale del contratto.

Il limite non è il formato JSON in sé. Il limite emerge quando ogni interrogazione analitica deve attraversare l'intero documento, anche quando servono solo poche dimensioni. Se vuoi contare fonti, confrontare finding o osservare variazioni storiche, non ha senso rileggere ogni volta tutto il report.

Il contratto mantiene il significato complessivo dell'audit. Le viste derivate permettono di lavorare sulle parti che devono essere filtrate, contate o confrontate.

Dalla narrativa del report alla lettura analitica

Molti elementi di un audit GEO hanno una doppia natura.

Una fonte citata fa parte del racconto del report, ma può diventare anche un record analitico.

Un finding spiega un problema all'utente, ma può essere filtrato per categoria, severità o audit di provenienza.

Un competitor aggiunge contesto strategico, ma può diventare anche un segnale misurabile tra query, motori e audit successivi.

Questa doppia natura è il motivo per cui il risultato completo deve generare viste analitiche derivate.

Il report rimane il documento che spiega il risultato. Le evidenze diventano anche dati interrogabili.

Parquet ottimizza le interrogazioni analitiche

Parquet entra nello stack perché è un formato colonnare: organizza i dati in modo adatto a letture selettive, filtri, aggregazioni e analisi su molte righe.

Il vantaggio non è che Parquet sia più moderno o più elegante. Il vantaggio è che nasce per un problema diverso rispetto al JSON.

Quando vuoi sapere quali fonti vengono citate più spesso, non ti serve tutto il report. Ti servono motore, dominio, query, frequenza e contesto.

Quando vuoi confrontare due audit, non ti serve caricare ogni sezione narrativa. Ti servono punteggi, categorie, finding e variazioni.

Quando devi costruire una dashboard, non vuoi reinterpretare ogni volta un documento annidato. Vuoi leggere solo i campi necessari, filtrare subito e aggregare i dati in modo prevedibile.

Il JSON conserva il risultato completo. Parquet rende più efficiente l’analisi delle componenti che si ripetono nel tempo.

DuckDB e MotherDuck rendono interrogabili le viste analitiche

Molte interrogazioni sugli audit si esprimono naturalmente in SQL.

Quante volte compare questa fonte?

Quali motori citano il brand?

Quali categorie peggiorano nel tempo?

Quali raccomandazioni hanno priorità alta?

DuckDB permette di eseguire questo tipo di analisi senza spostare immediatamente i dati in un data warehouse tradizionale. Può leggere formati colonnari, costruire viste, aggregare risultati e produrre dataset riutilizzabili dal resto del sistema.

MotherDuck estende questo modello quando il livello analitico deve diventare interoperabile, condiviso, persistente e accessibile anche in cloud.

In questa architettura, DuckDB e MotherDuck non sostituiscono il database applicativo transazionale. Hanno un ruolo diverso: rendere interrogabili le viste analitiche derivate dagli audit. La separazione è importante perché PostgreSQL non deve trasformarsi anche in data warehouse, motore analitico e backend per ogni dashboard. Lo stack rimane più solido quando stato applicativo e analisi mantengono responsabilità distinte.

Polars mantiene coerente la logica tra audit e serie storiche

Polars è comunemente noto come una libreria veloce per DataFrame, cioè per strutture tabellari usate nell'elaborazione dei dati.

Nel caso di GeoSonar, il punto non era solo la velocità. Il punto era avere una grammatica coerente per trasformare dati strutturati.

Una formula di scoring può nascere su un singolo audit. Ma se la stessa logica deve funzionare anche su audit storici, benchmark, confronti tra brand o ricalcoli periodici, non ha senso riscriverla ogni volta in una forma diversa.

Quando la logica viene espressa come trasformazione applicabile a colonne e dataset, lo stesso modello può servire sia l’audit individuale sia l’elaborazione su larga scala.

Questo evita un problema concreto: avere una logica nell’audit operativo e una diversa nelle analisi.

Polars serve anche a questo: non solo a leggere Parquet in modo efficiente, ma a mantenere coerente il calcolo tra audit singoli, benchmark e serie storiche.

Una separazione di responsabilità, non una competizione tra tecnologie

Quando si parla di stack dati, è facile trasformare l’architettura in una contrapposizione tra strumenti: PostgreSQL contro DuckDB, JSON contro Parquet, SQL contro DataFrame. In realtà, nel caso di GeoSonar, questa lettura sarebbe sbagliata. Ogni componente esiste per risolvere un problema diverso.

PostgreSQL gestisce lo stato applicativo e il contratto operativo dell’audit. JSON conserva il risultato completo e spiegabile. Parquet rende efficienti le analisi ricorrenti. DuckDB e MotherDuck interrogano i dati derivati. Polars mantiene coerente la logica di trasformazione tra audit individuali e analisi aggregate.

La separazione serve a evitare due errori opposti. Il primo è trattare ogni audit solo come un report: leggibile, ma difficile da confrontare, aggregare e analizzare nel tempo. Il secondo è trattare tutto come una tabella: interrogabile, ma privo del contesto necessario per spiegare il risultato.

GeoSonar ha bisogno di entrambe le dimensioni. Un audit deve restare comprensibile come documento e utilizzabile come dataset.

Un’architettura analitica proporzionata al problema

Una delle ragioni per cui questa architettura è utile è che evita un eccesso abbastanza comune nei prodotti in cui il dato diventa parte centrale del sistema: introdurre subito un data warehouse tradizionale, un lakehouse completo e una catena di servizi che richiedono più manutenzione del problema che devono risolvere.

Per intenderci: confrontare nel tempo le fonti citate da un insieme di audit, o calcolare quali finding ricorrono più spesso per categoria, non richiede necessariamente una piattaforma dati enterprise. Richiede prima di tutto viste stabili, dati colonnari e query ripetibili.

GeoSonar aveva bisogno di un livello intermedio: abbastanza leggero da restare vicino al sistema applicativo, abbastanza solido da supportare analisi storiche e interrogazioni granulari.

PostgreSQL gestisce lo stato operativo e transazionale del sistema. Il risultato completo dell’audit resta disponibile come rappresentazione canonica. DuckDB e MotherDuck forniscono il livello analitico interrogabile. Parquet rende efficienti le proiezioni colonnari e mantiene compatibilità con storage aperti. Polars permette di trasformare, arricchire e ricalcolare i dati mantenendo coerente la logica tra audit individuali e serie storiche.

Il vantaggio principale di questa architettura è la separazione delle responsabilità. Lo stato operativo del sistema non coincide con il livello analitico. Il documento canonico dell’audit non coincide con le proiezioni derivate usate per confronti, aggregazioni e dashboard. Questo permette di mantenere insieme due esigenze diverse: preservare il risultato completo dell’audit e rendere interrogabili le sue componenti ricorrenti.

È però una scelta pensata per un perimetro preciso. In GeoSonar, DuckDB e MotherDuck funzionano bene come livello analitico per dashboard, reportistica, confronti storici e workload orientati alla lettura. Non sono pensati per sostituire database transazionali ad alta concorrenza, né un’infrastruttura enterprise distribuita progettata per organizzazioni, team e volumi molto più grandi.

Per questo i formati aperti restano importanti. Parquet non serve solo all’efficienza: mantiene il sistema portabile e riduce il rischio di legare l’intero modello a un singolo motore. Se in futuro alcune componenti dovessero evolvere verso un’architettura lakehouse, cioè un modello basato su storage aperto e query analitiche distribuite, le proiezioni analitiche sarebbero già strutturate come dati autonomi, non come estensioni implicite del report finale.

La differenza tra persistere dati e analizzarli

La differenza tra le due architetture emerge soprattutto a livello operativo. Non cambia solo dove risiedono i dati: cambia il tipo di lavoro che il sistema riesce a sostenere senza duplicare logiche, appesantire il database applicativo o trasformare ogni report in un parsing continuo.

Il valore dello stack non dipende dal numero di componenti, ma dalla chiarezza delle responsabilità. Ogni livello esiste per risolvere un problema specifico: conservare il risultato completo, produrre viste analitiche, interrogare dati storici o mantenere coerente la logica di trasformazione nel tempo.

Il principio cardine: l'infrastruttura dati deve preservare il contesto

Un audit GEO non è solo un insieme di metriche. È una struttura che descrive come un brand viene interpretato dai motori generativi: quali fonti sostengono le risposte, quali competitor compaiono con maggiore frequenza, dove mancano evidenze, quali contenuti rafforzano la citazione e quali interventi possono migliorare la leggibilità del brand per i sistemi AI.

Il problema nasce perché il formato migliore per rappresentare un audit completo non coincide con quello più efficiente per analizzarlo nel tempo.

Se il risultato resta soltanto un documento ricco di struttura, ogni confronto storico diventa costoso da interrogare. Se invece tutto viene ridotto a viste tabellari indipendenti dal risultato originale, l’analisi guadagna velocità ma perde parte del significato dell’audit.

La soluzione sta nell'equilibrio:

• un contratto completo per dire che cosa rappresenta l'audit;
• proiezioni colonnari per interrogare le parti che cambiano nel tempo;
• un livello SQL leggero per leggere e aggregare;
• trasformazioni coerenti per evitare logiche duplicate tra singolo audit e serie storiche.

Lo schema definisce che cosa rappresenta un audit. Lo stack dati determina quanto quel modello resti interrogabile, confrontabile e riutilizzabile nel tempo.

Quando rappresentazione e livello analitico evolvono separatamente, il sistema tende a dividersi in due estremi: report completi ma difficili da aggregare, oppure dataset efficienti ma scollegati dal significato originale dell’audit.

Quando invece restano coerenti, l’audit smette di essere solo un risultato statico. Diventa una base interrogabile su cui costruire confronti storici, letture aggregate e analisi evolutive senza perdere il legame con il contesto iniziale.

FAQ

Che cos’è lo stack dati di GeoSonar?

È l’architettura che permette di gestire un audit GEO sia come risultato completo sia come base analitica interrogabile. Combina PostgreSQL, JSON, Parquet, DuckDB, MotherDuck e Polars per separare stato operativo, rappresentazione canonica e letture analitiche derivate.

Perché il JSON completo resta centrale?

Perché rappresenta la forma canonica dell’audit. Conserva struttura, evidenze, spiegazioni e relazioni necessarie per report, API, validazione e ricostruzione del contesto originale. Le viste analitiche non lo sostituiscono: derivano da quel risultato.

Parquet sostituisce JSON?

No. JSON conserva il risultato completo dell’audit. Parquet serve a rendere efficienti interrogazioni, aggregazioni e confronti sulle componenti che si ripetono nel tempo, come fonti, finding, competitor o punteggi.

DuckDB sostituisce PostgreSQL?

No. PostgreSQL gestisce lo stato operativo e transazionale del sistema. DuckDB viene usato per leggere e aggregare dati analitici derivati dagli audit, senza sovraccaricare il database applicativo.

Perché usare anche MotherDuck?

MotherDuck estende il modello DuckDB a un livello condiviso e persistente. Diventa utile quando dataset, query e viste analitiche devono essere accessibili da più ambienti, processi o componenti del sistema.

Qual è il ruolo di Polars nello scoring?

Polars permette di applicare la stessa logica di trasformazione sia a un audit individuale sia a serie storiche e benchmark. Questo evita di mantenere implementazioni separate tra calcolo operativo e analisi aggregata.

Perché separare audit canonico e viste analitiche?

Perché il formato migliore per rappresentare un audit completo non è lo stesso più efficiente per analizzarlo nel tempo. Separare risultato canonico e proiezioni derivate permette di mantenere insieme spiegabilità, confrontabilità e interrogazioni efficienti.

Perché usare formati aperti come Parquet?

Per mantenere il sistema portabile e indipendente da un singolo motore analitico. Le proiezioni derivate restano riutilizzabili anche se in futuro l’architettura dovesse evolvere verso sistemi analitici diversi o più distribuiti.

Riferimenti tecnici e metodologici

• Polars documentation
• Polars lazy optimizations
• DuckDB documentation
• DuckDB integration with Polars
• DuckDB Parquet support
• MotherDuck documentation
• MotherDuck architecture and capabilities
• DuckDB: Modern Data Stack in a Box
• MotherDuck: DuckDB in the cloud and in the client
• Apache Parquet documentation
• Apache Arrow columnar format
• PostgreSQL documentation