Standard operativi per una piattaforma dati unificata

Questo articolo aiuta i decision maker a stabilire standard operativi per lo sviluppo e l'uso di prodotti dati in una piattaforma dati unificata.

Le organizzazioni devono decidere in che modo i domini dati rendono disponibili i dati tramite OneLake e li trasformano in prodotti dati attendibili per il riutilizzo nell'intera organizzazione. La governance centrale deve stabilire standard a livello di organizzazione. I domini di dati devono possedere i propri prodotti dati e prendere decisioni di implementazione all'interno di tali perimetri.

Gli standard coerenti riducono la duplicazione non necessaria e aiutano i consumer a trovare e usare dati attendibili con protezione appropriata. Questo articolo illustra l'acquisizione dei dati, la trasformazione, la pubblicazione, il consumo, la gestione del ciclo di vita, la sicurezza e le eccezioni.

1. Acquisizione dei dati

Quali standard dovrebbero disciplinare l'acquisizione dei dati? L'organizzazione deve stabilire standard che definiscano quali dati di origine diventano disponibili tramite OneLake e i metodi preferiti per renderli disponibili. Rendere disponibili i dati di origine tramite OneLake solo se supportano un prodotto dati approvato o una necessità analitica.

1.1 Metodi di acquisizione dei dati

In che modo i domini dati devono rendere disponibili i dati di origine tramite OneLake? L'organizzazione deve preferire modelli che riducono al minimo lo spostamento dei dati non necessario.

• I tasti di scelta rapida devono essere il modello preferito quando i dati supportati possono rimanere all'origine.
• Il mirroring deve essere il modello preferito per le origini supportate quando Fabric richiede l'accesso sincronizzato a un database o a un catalogo esterno.
• Lo spostamento dei dati deve essere usato quando Fabric richiede una copia dei dati e dei collegamenti o del mirroring non soddisfano i requisiti.

I domini dati possono scegliere un altro metodo di assunzione approvato quando il modello preferito non soddisfa il requisito. Vedere Unificare i dati con i collegamenti OneLake e il mirroring.

1.2 Origini dati

Come integrare origini dati diverse? I domini dati devono rendere disponibili output attendibili tramite OneLake anziché ricreare l'elaborazione equivalente in Fabric senza un vantaggio organizzativo misurabile.

• Microsoft 365: Microsoft 365 in genere deve rimanere il sistema di riferimento per il contenuto di collaborazione. I domini dati devono portare Microsoft 365 contenuto nella piattaforma dati unificata solo quando un prodotto dati approvato lo richiede, ad esempio per l'analisi strutturata.

• Database operativi: i database operativi devono rimanere ottimizzati per i carichi di lavoro transazionali. I domini dati non devono consentire ai carichi di lavoro analitici o di intelligenza artificiale di eseguire query direttamente su un database operativo, a meno che il proprietario del database non abbia approvato il carico di lavoro previsto e stabilito i controlli necessari.

• Piattaforme dati esistenti: i data lake esistenti e le piattaforme di trasformazione, ad esempio Azure Databricks, devono rimanere attivi quando continuano a soddisfare i requisiti dell'organizzazione. La migrazione o la ricreazione in Fabric devono richiedere un vantaggio organizzativo misurabile. Vedere Collegamenti, mirroring Azure Databricks Catalogo Unity e Integrare OneLake con Azure Databricks.

2. Trasformazione dei dati

Come trasformare i dati in prodotti dati? L'organizzazione deve stabilire una piattaforma di trasformazione preferita per ridurre la duplicazione non necessaria delle funzionalità. Microsoft Fabric può essere usato come predefinito quando soddisfa i requisiti del prodotto dati. Le piattaforme esistenti, ad esempio Azure Databricks, devono rimanere in uso quando forniscono funzionalità necessarie o rappresentano un investimento aziendale stabilito.

Pattern di trasformazione: l'architettura medallion deve essere il modello preferito quando i dati traggono vantaggio dal perfezionamento progressivo. I domini dati devono usare solo le fasi di qualità necessarie per produrre un prodotto dati attendibile.

Vedere Fabric viste del lago materializzate, Medallion Lakehouse Architecture in Fabric e Analisi end-to-End con Microsoft Fabric.

3. Pubblicazione

Cosa deve esistere per la pubblicazione di un prodotto dati? Un prodotto dati può essere costituito da uno o più asset tecnici che forniscono collettivamente un'offerta aziendale supportata. Ogni prodotto dati pubblicato deve avere un proprietario accountable, uno scopo aziendale supportato, un uso previsto, un processo di accesso e uno stato di qualità. Quando i consumer dipendono dalla disponibilità tempestiva, dovrebbe anche definire un impegno operativo.

• Controlli di sicurezza: i controlli di sicurezza obbligatori devono essere applicati prima della pubblicazione. I prodotti dati sensibili devono avere i requisiti di classificazione e gestione necessari. Vedere Etichette di riservatezza di Purview.

• Metadati: l'organizzazione deve definire i metadati minimi per i prodotti dati pubblicati. I consumer devono essere in grado di determinare il dominio dei dati proprietario, il proprietario accountable, l'uso supportato, l'impegno di qualità e i requisiti di accesso. Vedere i tag nei metadati personalizzati di Fabric e Purview.

• Lineage dei dati: il lineage disponibile deve fornire informazioni sufficienti per comprendere le dipendenze a monte rilevanti e valutare l'impatto downstream. Vedi Lineage in Fabric.

4. Individuazione

In che modo i consumatori possono trovare i prodotti di dati? I prodotti dati pubblicati devono essere facilmente individuabili per impostazione predefinita. Usare OneLake Catalog per l'individuazione nativa di Fabric. Rappresentare un prodotto dati in Microsoft Purview Unified Catalog quando richiede contesto aziendale a livello di impresa o governance nell'intero patrimonio di dati.

Vedi Panoramica del catalogo di OneLake e Prodotti di dati in Unified Catalog.

5. Avallo

In che modo i consumatori devono determinare se un prodotto dati è attendibile per il riutilizzo? L'approvazione in Fabric può aiutare i consumatori a valutare il livello di garanzia fornito dagli articoli che supportano un prodotto dati. L'organizzazione deve stabilire significati e requisiti coerenti per ogni livello di approvazione.

• Promozione deve indicare che il dominio dati proprietario consiglia il prodotto dati per il riutilizzo.

• La certificazione deve indicare che un revisore autorizzato ha confermato che il prodotto dati soddisfa gli standard organizzativi definiti.

La pubblicazione non dovrebbe richiedere la certificazione. La pubblicazione stabilisce la soglia organizzativa minima per il riutilizzo supportato. La certificazione garantisce un'ulteriore garanzia. Vedere Approvazione in Fabric.

6. Consumo approvato

Quando i consumatori possono usare un prodotto dati senza ulteriore approvazione? I prodotti dati possono supportare molti modelli di consumo, tra cui analisi, applicazioni, grounding per l'IA e agenti. Gli stessi standard approvati per l'uso e la sicurezza si applicano indipendentemente dalla tecnologia utilizzata. Il dominio dati proprietario deve definire gli usi supportati da ogni prodotto dati pubblicato. I consumatori devono essere in grado di usare il prodotto dati senza ulteriore approvazione quando l'uso proposto rientra in tali limiti.

L'organizzazione deve definire usi che richiedono sempre una revisione aggiuntiva. Questi usi devono includere situazioni in cui l'utilizzo modifica materialmente il rischio dei dati, ad esempio la divulgazione esterna o l'uso dell'IA con effetti significativi.

L'approvazione per un utilizzo non deve implicare l'approvazione per un'altra. Ad esempio, un prodotto dati approvato per la creazione di report interni non deve essere approvato automaticamente per la pubblicazione esterna. Un prodotto dati approvato per il grounding di intelligenza artificiale non deve essere approvato automaticamente per un agente che può eseguire azioni consequenziali.

7. Ciclo di vita del prodotto di dati

In che modo i domini dati devono gestire i prodotti dati da cui dipendono i consumer? I prodotti dati pubblicati creano dipendenze che il dominio dati proprietario deve gestire. L'organizzazione deve stabilire standard per le modifiche e la dismissione, in modo che i consumatori possano pianificare le interruzioni e la transizione quando necessario. Insieme, i requisiti di pubblicazione e gli impegni relativi al ciclo di vita stabiliscono il contratto tra il dominio dati proprietario e i consumer del prodotto dati.

7.1 Affidabilità

Quali standard di affidabilità devono essere applicati ai prodotti di dati pubblicati? L'organizzazione deve stabilire i requisiti di affidabilità in base all'impatto aziendale di un prodotto dati che diventa non disponibile o perde i dati. I domini dati devono applicare questi requisiti al prodotto dati completo anziché presupporre che l'affidabilità di OneLake o un altro componente della piattaforma fornisca il livello di protezione richiesto.

• Classificazione dell'affidabilità: l'organizzazione deve definire i requisiti di affidabilità per ogni livello di criticità aziendale. I domini dati devono garantire che il prodotto dati completo soddisfi i requisiti applicabili.

• Requisiti di ripristino: il dominio dei dati proprietario deve garantire che il prodotto dati completo soddisfi i requisiti di affidabilità associati alla criticità aziendale. La progettazione del ripristino deve tenere conto del prodotto di dati e delle dipendenze necessarie per il relativo utilizzo. I prodotti dati critici per l'azienda devono avere un processo di ripristino testato.

• Fabric requisiti di capacità: i domini dati devono garantire che la capacità di Fabric condivisa non impedisca ad alcun prodotto dati assegnato di soddisfare i requisiti di affidabilità. Usare capacità separata quando un prodotto dati richiede controlli a livello di capacità che non devono essere applicati ad altri prodotti.

Non considerare la replica di OneLake come ripristino completo del prodotto di dati. Ogni prodotto dati critico per l'azienda deve avere un piano di ripristino che copra i dati e gli elementi Fabric necessari. Vedere il ripristino di emergenza di OneLake e la protezione dei dati e le indicazioni sul ripristino di emergenza specifiche dell'esperienza Fabric.

7.2 Modifiche

In che modo i domini dati devono gestire le modifiche che influiscono sui consumer? I proprietari dei domini di dati devono gestire le modifiche incompatibili in base all'impatto aziendale del prodotto dati. Devono identificare i consumatori interessati prima di apportare una modifica che causa un'interruzione e fornire un periodo di transizione proporzionale all'impatto.

Gli impegni di modifica devono aumentare man mano che aumentano le dipendenze e la criticità aziendale. Un prodotto dati ampiamente riutilizzato che supporta un processo aziendale critico deve avere requisiti di modifica più rigorosi rispetto a un prodotto dati con uso limitato.

I domini dati devono usare l'analisi della tracciabilità dei dati e dell'impatto disponibili per identificare le dipendenze tecniche. Devono anche tenere conto delle dipendenze aziendali note che il lineage tecnico non acquisisce. Vedere Analisi dell'impatto di Fabric.

7.3 Pensionamento

In che modo un dominio dati deve ritirare un prodotto dati pubblicato? L'organizzazione deve stabilire requisiti minimi per il pensionamento. Prima della dismissione, il dominio dati proprietario deve valutare le dipendenze attive e fornire un periodo di transizione proporzionale all'impatto aziendale.

Il dominio di dati proprietario deve identificare una sostituzione approvata quando ne esiste una. Deve rimuovere l'approvazione quando i consumer devono interrompere la creazione di nuove dipendenze. I clienti esistenti devono ricevere un avviso sufficiente prima che termini l'accesso.

8. Sicurezza del data product

Come devono essere applicati i requisiti di autorizzazione quando vengono utilizzati i prodotti dati? Un nuovo percorso di consumo non deve indebolire la protezione richiesta dal prodotto dati di origine. L'organizzazione deve classificare i modelli di consumo approvati in base al fatto che i requisiti di autorizzazione del prodotto dati rimangano efficaci.

8.1. Autorizzazione di origine mantenuta

Quando un modello di consumo mantiene l'autorizzazione del prodotto dati di origine? Un modello di consumo può basarsi sull'autorizzazione del prodotto dati di origine quando mantiene l'identità del consumer e continua a applicare le restrizioni di accesso necessarie.

Ad esempio, se un prodotto di dati di vendita limita ogni venditore ai clienti assegnati, il modello di consumo deve mantenere tale restrizione per ogni consumatore. Le organizzazioni devono convalidare ogni modello approvato prima di consentirgli di utilizzare dati riservati.

Vedere agenti dati di Fabric, Power BI e server OneLake MCP.

8.2. Nuovo confine di autorizzazione

Quali standard si applicano quando un modello di consumo deve stabilire un nuovo perimetro di autorizzazione? Un modello di consumo che non mantiene i requisiti di autorizzazione del prodotto dati di origine deve stabilire un nuovo perimetro di autorizzazione che fornisce una protezione equivalente. L'organizzazione non deve approvare il pattern per i dati con restrizioni quando non può fornire tale protezione.

Questa situazione si verifica in genere quando un servizio crea un'altra rappresentazione dei dati o accede ai dati di origine tramite un'identità dell'applicazione condivisa.

• Indici: un indice di ricerca crea un'altra rappresentazione dei dati di origine. I dati con restrizioni nell'indice devono rimanere protetti in base ai requisiti di autorizzazione del prodotto dati di origine. L'organizzazione deve convalidare il modo in cui le autorizzazioni di origine vengono rappresentate e applicate nell'indice anziché presupporre che i controlli di accesso di OneLake proteggono automaticamente il contenuto indicizzato. Vedere OneLake Indexer, controllo di accesso a livello di documento e Azure AI Search procedure consigliate per la sicurezza.

• Identità del servizio o condivise: quando un servizio consumatore accede a un prodotto dati tramite un'identità del servizio anziché l'identità del consumatore, l'autorizzazione di origine si applica a tale identità del servizio. La soluzione consumer deve applicare qualsiasi autorizzazione a livello di consumer richiesta dal prodotto dati. Vedere Autenticazione per gli strumenti MCP (Model Context Protocol) e Usare l'autenticazione dell'entità servizio con l'agente dati di Fabric.

9. Eccezioni agli standard

Quali eccezioni può approvare un dominio dati? L'organizzazione deve definire quali domini di dati standard possono variare e quali richiedono l'approvazione centrale.

• I domini di dati devono disporre dell'autorità per approvare le eccezioni che influiscono solo sul budget o sul modello operativo locale. Non devono approvare eccezioni che indebolino i requisiti a livello di organizzazione per la sicurezza o la conformità alle normative. L'approvazione centrale deve essere necessaria anche per le eccezioni che indebolino i requisiti di interoperabilità a livello di organizzazione o lo standard minimo di pubblicazione del prodotto dati.

• La governance centrale deve possedere standard a livello di organizzazione ed esaminarli man mano che le funzionalità di Fabric e le procedure organizzative si evolvono. I domini dati devono fornire eccezioni ricorrenti come input per queste revisioni. Le eccezioni ripetute possono indicare che uno standard aziendale deve cambiare.