Perché esiste
Un'applicazione .NET che oggi vuole leggere una tabella Iceberg ha due opzioni poco attraenti: avviare un servizio JVM come Spark Connect o Trino e pagarne il costo in latenza e operazioni, oppure passare per un motore di query che nasconde i metadata Iceberg al chiamante. Non esiste un client nativo che dia a .NET lo stesso accesso di prima classe che pyiceberg dà a Python o iceberg-rust a Rust. IcebergSharp prova a colmare questo vuoto con una libreria focalizzata, read-only, che fa fluire batch Arrow dentro lo stack analitico .NET esistente — DuckDB.NET, ML.NET, Power BI — senza una JVM nel percorso.
Centro tecnico
Il progetto è diviso in pacchetti piccoli e componibili: IcebergSharp.Core possiede i metadata v1/v2 delle tabelle Iceberg, gli schemi, le partition spec, gli snapshot e il modello di dominio dei manifest; IcebergSharp.Avro è un lettore Avro OCF stream-based per manifest list e manifest, con codec null e deflate; IcebergSharp.Catalog è il client REST read-only del catalog con scoperta dinamica degli endpoint e autenticazione bearer / OAuth2 / SigV4. Il design tratta Arrow come substrato di output, così il layer di scan potrà passare i record batch direttamente al tooling analitico downstream quando le letture Parquet arriveranno nella Fase 5.
Disciplina di scope
Diversi confini sono intenzionali, non incidentali. Niente write path: scrivere Iceberg in modo corretto è circa il settanta per cento dello sforzo ingegneristico e il novanta per cento dei bug nelle implementazioni esistenti, quindi la v1 resta read-only. Niente merge-on-read: solo tabelle COW, con i delete file saltati sotto warning. Niente Hive Metastore: solo catalog REST, lasciando HMS a un adapter REST. Niente motore SQL incluso: la superficie restituisce IAsyncEnumerable<RecordBatch> e stream Arrow, e lascia al chiamante la scelta del layer di query. Sono queste esclusioni che impediscono al progetto di diventare un motore a metà invece di un lettore utile.
Prove correnti
Le fasi da 0 a 3 sono già nel repository: scaffolding della solution, CI con gating dotnet format, tipi core e metadata, lettori Avro stream-based per i manifest e il client REST read-only del catalog sono tutti in posto e coperti da test unitari. Le fasi 4 e 5 — scan planning con partition pruning e column-stats pruning, poi lettura Parquet con risoluzione dei field-id — sono i prossimi milestone verso una release NuGet 1.0. La matrice di compatibilità in docs/compatibility-matrix.md traccia le superfici di catalog e storage mentre passano da unit-covered a live-validated.