Con Fivetran, ingerire dati in Apache Iceberg su un data lake è la parte facile; governarli è dove si gioca la partita. Chi può accedere a quali tabelle? Come si mantiene coerente il metadata quando più engine leggono gli stessi file? Cosa succede se qualcuno interroga i Parquet grezzi invece di passare dal catalog? Il Managed Data Lake Service (MDLS) è pensato attorno a questi problemi: scrive i dati una volta come Parquet mantenendo in parallelo metadata Iceberg e Delta Lake, e automatizza il lifecycle che molti team gestiscono male o non gestiscono affatto.
Un’unica fonte di verità per i metadata
Ogni destination ottiene un proprio Fivetran Iceberg REST Catalog, basato su Apache Polaris. Il modello di governance sta in una frase: solo Fivetran scrive metadata, tutti gli altri leggono. Il catalog è read-only dal punto di vista degli engine di query; Fivetran lo aggiorna a ogni sync. Se un catalog esterno come Glue va fuori sincrono, Fivetran lo rileva al sync successivo e ripubblica la versione corretta.
Controllo degli accessi a più livelli
Gli engine si autenticano al REST Catalog via OAuth2 client credentials. Il pezzo forte sono le vended credentials: quando un engine richiede dati, il catalog emette credenziali S3 a vita breve, limitate alla directory che contiene i file di quella tabella. Niente permessi ampi su tutto il bucket: least-privilege applicato in automatico allo storage layer. Si aggiungono un ruolo IAM cross-account con External ID, la gestione di KMS, Lake Formation dove abilitato e PrivateLink sul piano Business Critical per l’isolamento di rete.
Multi-engine e lifecycle
Gli engine che parlano il protocollo Iceberg REST si collegano direttamente; Athena e Redshift passano invece da AWS Glue, mantenuto in sync dal meccanismo self-healing. Sul lifecycle, MDLS automatizza la snapshot retention configurabile, la gestione dei metadata file (versione corrente più le 3 precedenti), la pulizia degli orphan file ogni due settimane e compaction e deduplica con approccio copy-on-write. L’evoluzione dello schema è gestita automaticamente durante i sync.
Per un team di data governance il messaggio pratico è chiaro: non modificare le tabelle manualmente o tramite catalog esterni, perché Fivetran tratta il proprio catalog come single source of truth e sovrascriverà le modifiche.
In sintesi
- Il catalog Iceberg REST su Polaris è read-only per gli engine: solo Fivetran scrive metadata, con self-healing verso Glue.
- Le vended credentials danno accesso S3 a scope ristretto e a vita breve, applicando il least-privilege in automatico.
- Snapshot retention, pulizia orphan file, compaction ed evoluzione dello schema sono automatizzate.
Fonte: Governing your lakehouse with Fivetran Managed Data Lake Service — https://www.fivetran.com/blog/governing-your-lakehouse-with-fivetran-managed-data-lake-service
Hai qualcosa da aggiungere? Unisciti alla discussione.