Chi gestisce i legacy Topics di Amazon Quick insieme ai propri dataset conosce il problema: due asset che devono restare sincronizzati, ciascuno con permessi, lineage e versioning propri. I sinonimi delle colonne divergono, i calculated field si disallineano, e una rinomina nel dataset può rompere silenziosamente il Topic legato. Con Dataset Enrichment, la nuova esperienza di data prep, quel contesto di business (descrizioni delle colonne, sinonimi, calculated field, custom instructions e business rule) vive direttamente dentro il dataset. Un solo asset, una sola fonte di verità, un solo punto di governance.
Il cambiamento non è cosmetico: i semantics propri del singolo dataset scendono dove appartengono, mentre il Topic viene elevato a layer semantico multi-dataset, il costrutto in cui più dataset vengono composti, si definiscono le relazioni, si scrivono le metriche di business e si mappa la terminologia. Dataset Enrichment è la fondazione che rende possibile tutto questo: ogni dataset deve portare il proprio contesto semantico prima che i Topics possano unificarli a un livello superiore.
Cosa cambia e cosa resta uguale
La differenza chiave è dove vivono i metadati: non più in un oggetto Topic separato ma dentro i metadati del dataset. La nuova definizione introduce semantic_model_configuration con due livelli: metadati a livello di colonna (Description e AdditionalNotes per i sinonimi) dentro il TableMap, e metadati a livello di dataset (Description e CustomInstructions per formule, entità e regole) dentro SemanticMetadata.
Restano invariati diversi aspetti: i rules dataset non richiedono migrazione, lo storage SPICE e la modalità Direct Query non sono toccati, dashboard e analisi non vanno ricostruite (usano il dataset arricchito) e il modello di interazione Q&A in linguaggio naturale per gli utenti non cambia.
Tre scenari di migrazione
Il post distingue tre situazioni. Nello Scenario 1 (dataset legacy senza Topic) e nello Scenario 2 (Topic legacy su dataset legacy) i dataset usano LogicalTableMap e non supportano Dataset Enrichment: non esiste un percorso di upgrade in place, occorre creare un nuovo dataset con la nuova data prep. Solo lo Scenario 3 (Topic legacy su dataset già in new data prep, con DataPrepConfiguration) consente una migrazione diretta in place, passando SemanticModelConfiguration alla API update-data-set.
Per automatizzare, il post fornisce uno script Python che estrae i metadati del Topic via describe-topic e li scrive nel dataset: descrizioni e sinonimi diventano ColumnProperties, i calculated field vengono iniettati come CreateColumnsStep nella pipeline di data prep, mentre named entity, filtri e custom instruction vengono consolidati in un blocco testuale di CustomInstructions. I prerequisiti includono AWS CLI v2 (2.34.50 o successiva), Python 3.6+, Amazon Quick Enterprise con Q abilitato e i permessi IAM DescribeDataSet, UpdateDataSet e DescribeTopic.
Da tenere presente: la API update-data-set richiede la sostituzione completa della configurazione a ogni chiamata, named entity e filtri non hanno campi dedicati e vanno espressi come testo nelle CustomInstructions, e non tutte le espressioni di calcolo si traducono direttamente (i calculated field di dataset operano row-by-row, con le aggregazioni al momento della query).
- Dataset Enrichment sposta descrizioni, sinonimi, calculated field e business rule dai legacy Topics dentro il dataset stesso, con un unico punto di governance.
- Solo i dataset che usano già
DataPrepConfigurationsupportano una migrazione diretta in place; quelli legacy vanno ricreati. - La validazione consigliata prevede un set di 10-20 domande in linguaggio naturale e confronti side-by-side tra Topic legacy e dataset arricchito prima del cutover.
Fonte: Enrich your datasets with business context: Migrating from legacy Topics to semantic datasets in Amazon Quick — https://aws.amazon.com/blogs/machine-learning/enrich-your-datasets-with-business-context-migrating-from-legacy-topics-to-semantic-datasets-in-amazon-quick/
Hai qualcosa da aggiungere? Unisciti alla discussione.