Un solo percorso di scrittura, più accessi: come Rippling utilizza Apache Iceberg™ gestito da Unity Catalog

Questo è un post ospite di Tae Lee, Staff Engineer, Data Platform presso Rippling

In Rippling, il motore che scrive una tabella non è sempre lo stesso che la legge. Un job Databricks potrebbe produrre una tabella, ma il consumatore a valle potrebbe essere il layer di query basato su Trino di Rippling Data Cloud, Snowflake o un altro lettore lakehouse. Questo rende la scelta del catalogo molto più di un semplice dettaglio sui metadati: determina chi può scrivere la tabella, chi la gestisce e come gli altri motori la leggono.

Ciò significa che l'obiettivo non è forzare ogni workload in un unico motore o catalogo. L'obiettivo è consentire a ciascun producer di utilizzare la piattaforma su cui offre le prestazioni migliori, continuando a pubblicare tabelle governate che i sistemi a valle possono consumare senza duplicazioni.

Le tabelle Iceberg gestite da Unity Catalog sono il pattern che utilizziamo per la parte di questa architettura prodotta da Databricks.

La proprietà del catalogo segue il writer

La nostra strategia per i cataloghi inizia con una regola semplice: il catalogo deve seguire il writer.

Per il compute nativo di AWS, utilizziamo AWS Glue Data Catalog. È la soluzione ideale per i workload scritti da motori AWS come Glue, Athena, EMR o infrastrutture correlate.

Per i workload prodotti da Databricks, utilizziamo Unity Catalog. Questo è particolarmente importante per Apache Iceberg™. Databricks può leggere tabelle Iceberg esterne tramite federazione, ma queste tabelle non sono uguali alle tabelle Iceberg gestite da Unity Catalog. Se Databricks deve scrivere sulla tabella, o se il workload dipende fortemente dalle prestazioni e dalla governance di Databricks, la tabella dovrebbe essere gestita da UC.

Per i dati prodotti da Snowflake che devono essere condivisi tra varie piattaforme, utilizziamo Snowflake Horizon Catalog con tabelle Iceberg gestite da Snowflake. Si tratta di una scelta di catalogo separata, guidata da Snowflake in qualità di producer.

Questa è la distinzione importante: Iceberg ci offre un formato di tabella aperto, ma il catalogo gestisce comunque i commit dei metadati, i permessi e il ciclo di vita della tabella. La portabilità del formato e la proprietà del catalogo sono correlate, ma non sono la stessa cosa.

Perché scegliere Iceberg gestito per i workload Databricks

Prima di questo pattern, un output prodotto da Databricks che doveva essere consumato altrove comportava solitamente un passaggio in più: esportare una seconda copia dopo la scrittura di Databricks, oppure scrivere direttamente nel sistema di consumo e rileggerlo tramite un connettore o un percorso di federazione quando Databricks ne aveva nuovamente bisogno. Entrambi gli approcci funzionano, ma aggiungono materializzazione duplicata, compute extra e limiti specifici del connettore. 

Iceberg gestito da Unity Catalog ci offre un confine più netto.

Databricks scrive la tabella in modo nativo. Unity Catalog gestisce i metadati, il modello di accesso e il ciclo di vita della tabella. I dati della tabella e i metadati Iceberg sono archiviati nello storage S3 di proprietà di Rippling. 

I motori esterni si connettono tramite l'API Iceberg REST Catalog o la federazione dei cataloghi. Il credential vending fornisce a questi motori un accesso con ambito definito allo storage sottostante. I motori leggono quindi i file Parquet direttamente da S3 utilizzando il proprio compute. 

Questa è la proprietà chiave per noi. Un job Databricks può produrre la tabella una sola volta e un motore a valle come Trino, Snowflake, Spark, Athena o EMR può consumare la stessa tabella tramite pattern di accesso Iceberg standard. Il consumatore non deve fare da proxy per ogni query attraverso il dialetto SQL o il layer di esecuzione di un altro motore, riducendo così la dipendenza dalla traduzione tra motori, dal comportamento di pushdown, dal throttling e dal compute lato producer per le letture a valle. 

Non si tratta di un'esportazione Databricks. È una tabella Iceberg aperta con un producer nativo di Databricks.

Dagli output di ML a Data Cloud

Questo pattern è particolarmente utile quando un output prodotto da Databricks deve entrare a far parte di un prodotto o di una superficie analitica più ampia.

In Rippling, i workload di ML e AI scelgono comunque la destinazione più adatta al caso d'uso: tabelle Delta, database vettoriali, OpenSearch o altre destinazioni create ad hoc. Iceberg gestito è un pattern di pubblicazione selezionato, non la destinazione predefinita per ogni output di ML.

Il punto in cui Iceberg gestito fa la differenza è l'handoff. Per output selezionati, un job Databricks può pubblicare una tabella Iceberg gestita da Unity Catalog una sola volta. Rippling Data Cloud può quindi consumare la stessa tabella attraverso il suo layer di query, inclusi i pattern di accesso basati su Trino, e utilizzarla in trasformazioni a valle, dashboard e funzionalità di prodotto basate sull'AI.

L'architettura si presenta così:

Questo ci fornisce una tabella governata e un unico percorso di scrittura. I consumatori a valle non hanno bisogno di una copia fisica duplicata e i Lakeflow Jobs non devono scrivere separatamente in ogni sistema di consumo.

La gestione operativa conta quanto l'apertura

I formati di tabella aperti sono solo una parte della storia. Le tabelle Iceberg hanno comunque bisogno di manutenzione: compattazione dei file, scadenza degli snapshot, pulizia dei file orfani e statistiche.

Per le tabelle Iceberg catalogate in Glue, tale manutenzione appartiene al percorso della piattaforma nativa di AWS. Glue dispone di funzionalità di ottimizzazione delle tabelle, ma si tratta comunque di un modello operativo separato: dobbiamo decidere dove abilitare tali funzionalità, come monitorarle e come convalidare il comportamento per i workload che utilizzano Glue.

Per Iceberg gestito da Unity Catalog, Databricks gestisce una parte maggiore di questo ciclo di vita tramite la Predictive Optimization, inclusi la manutenzione automatica delle tabelle, l'ottimizzazione e la compattazione dei file, la raccolta delle statistiche e l'ottimizzazione del layout dei dati per le tabelle gestite. Questo è utile perché la stessa piattaforma che scrive la tabella gestisce anche gran parte delle attività necessarie per mantenerla efficiente.

Questo è uno dei motivi per cui non consideriamo Iceberg gestito da UC solo come una funzionalità di interoperabilità. È anche un modello operativo. Per le tabelle prodotte da Databricks, il percorso di manutenzione conta quanto il percorso di lettura.

Essere precisi sul lock-in

Questa architettura riduce il lock-in dei dati, ma non elimina tutte le dipendenze.

Il lock-in dei dati è basso. La tabella è Iceberg su Parquet nello storage S3 di proprietà di Rippling.

I motori a valle possono leggere i dati direttamente tramite pattern Iceberg aperti.

La dipendenza dal catalogo e dalla governance è reale. Unity Catalog rimane il control plane per metadati, permessi, lineage e comportamento delle tabelle gestite. Se dovessimo abbandonare Databricks, i dati sarebbero portabili, ma dovremmo sostituire il catalogo e il sistema di manutenzione.

Si tratta di un compromesso accettabile per questa classe di tabelle. UC si guadagna il suo spazio quando Databricks è il producer e la tabella deve essere governata, gestita e leggibile da altri motori.

Il risultato pratico

Il valore di Iceberg gestito da Unity Catalog non sta nel fornirci un unico catalogo per ogni tabella. Non lo fa, e questo non è il nostro obiettivo.

Il valore sta nel fornirci un unico percorso di scrittura per le tabelle prodotte da Databricks che necessitano di un consumo a valle aperto. Databricks ottiene il percorso di scrittura e ottimizzazione nativo. I sistemi a valle ottengono l'accesso diretto ai dati aperti in S3. 

I motori che accedono alla tabella tramite il catalogo REST passano attraverso lo stesso layer di metadati e accesso, anziché aggirare la governance tramite percorsi di storage raw. Questo è il risultato pratico:

"Unity Catalog e Iceberg gestito ci offrono il meglio di entrambi i mondi: prestazioni native per le nostre pipeline di AI e ML e interoperabilità aperta per ogni consumatore a valle. Un unico percorso di scrittura, zero duplicazioni e un layer di governance rispettato da ogni motore, compresi i prodotti basati sull'AI che stiamo creando per il Data Cloud di Rippling."

Per Rippling, l'interoperabilità non consiste nel rendere intercambiabile ogni motore. Si tratta di consentire a ciascun motore di svolgere il lavoro in cui eccelle, mantenendo la tabella pubblicata portabile, governata e utilizzabile dai sistemi che ne hanno bisogno.

Per saperne di più su Unity Catalog e sul supporto per Iceberg, visita la pagina del prodotto Unity Catalog. 

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale