Modifica

Condividi tramite

Usare Azure Synapse Analytics per progettare una soluzione di business intelligence aziendale

Power BI
Azure Synapse Analytics
Azure Data Factory
Microsoft Entra ID
Archiviazione BLOB di Azure

Questo articolo descrive come trasferire dati da un data warehouse locale a un ambiente cloud e quindi usare un modello di Business Intelligence (BI) per gestire i dati. È possibile usare questo approccio come obiettivo finale o un primo passo verso la modernizzazione completa con i componenti basati sul cloud.

Queste linee guida si basa sullo scenario end-to-end di Azure Synapse Analytics. Questo processo usa le pipeline di Azure Synapse Analytics per inserire dati da un database SQL in pool SQL. Esegue quindi la trasformazione dei dati per l'analisi. Questo articolo è incentrato sulle pipeline di Azure Synapse Analytics, ma è anche possibile usare le pipeline di Azure Data Factory o le pipeline di Data Factory di Fabric per eseguire queste attività.

Quando usare questa architettura

È possibile usare vari metodi per soddisfare i requisiti aziendali per business intelligence aziendale. Vari aspetti definiscono i requisiti aziendali, ad esempio gli investimenti tecnologici correnti, le competenze umane, la sequenza temporale per la modernizzazione, gli obiettivi futuri e se si ha una preferenza per la piattaforma distribuita come servizio (PaaS) o software come servizio (SaaS).

Considerare gli approcci di progettazione seguenti:

L'architettura in questo articolo presuppone che si usi il data warehouse di Azure Synapse Analytics come livello permanente del modello semantico aziendale e si usa Power BI per business intelligence. Questo approccio PaaS offre la flessibilità necessaria per soddisfare diversi requisiti e preferenze aziendali.

Architettura

Diagramma che illustra l'architettura bi aziendale con Azure Synapse Analytics.

Scaricare un file di Visio di questa architettura.

Workflow

Origine dati

Inserimento e archiviazione dei dati

  • di Azure Data Lake Storage è un'area di gestione temporanea durante l'inserimento dei dati. È possibile usare PolyBase per copiare i dati in un pool SQL dedicato di Azure Synapse Analytics.

  • azure Synapse Analytics è un sistema distribuito che esegue analisi su dati di grandi dimensioni. Supporta l'elaborazione parallela elevata, in modo da poter eseguire analisi ad alte prestazioni. Il pool SQL dedicato di Azure Synapse Analytics è una destinazione per l'inserimento continuo dall'ambiente locale. Il pool SQL può gestire i dati per power BI tramite DirectQuery ed eseguire un'ulteriore elaborazione.

  • pipeline di Azure Synapse Analytics orchestrare l'inserimento e la trasformazione dei dati nell'area di lavoro di Azure Synapse Analytics.

Analisi e creazione di report

Componenti

Questo scenario usa i componenti seguenti:

  • database SQL di Azure è un server SQL PaaS ospitato in Azure. Questa architettura usa il database SQL per illustrare il flusso di dati per lo scenario di migrazione.

  • Data Lake Storage offre un'archiviazione cloud flessibile per i dati non strutturati usati per rendere persistenti i risultati della migrazione intermedia.

  • azure Synapse Analytics è un servizio di analisi aziendale per i sistemi di data warehousing e Big Data. Azure Synapse Analytics funge da risorsa di calcolo principale e archiviazione persistente nella modellazione semantica aziendale e nella manutenzione.

  • power BI Premium è uno strumento di business intelligence che presenta e visualizza i dati in questo scenario.

  • microsoft Entra ID è una suite di soluzioni di rete e identità multicloud che supporta il flusso di autenticazione e autorizzazione.

Architettura semplificata

Diagramma che mostra l'architettura semplificata di business intelligence aziendale.

Dettagli dello scenario

In questo scenario, un'organizzazione ha un database SQL che contiene un data warehouse locale di grandi dimensioni. L'organizzazione vuole usare Azure Synapse Analytics per eseguire l'analisi, quindi fornire queste informazioni dettagliate tramite Power BI agli utenti e alle analisi.

Autenticazione

Microsoft Entra ID autentica gli utenti che si connettono a dashboard e app di Power BI. Single Sign-On connette gli utenti all'origine dati in un pool di provisioning di Azure Synapse Analytics. L'autorizzazione viene eseguita nell'origine.

Caricamento incrementale

Quando si esegue un processo di estrazione, trasformazione, caricamento ,caricamento o estrazione, caricamento, trasformazione (ELT) automatizzato, è necessario caricare solo i dati modificati dopo l'esecuzione precedente. Questo processo viene chiamato caricamento incrementale. Viceversa, un caricamento completo carica tutti i dati. Per eseguire un caricamento incrementale, determinare come identificare i dati modificati. È possibile usare un approccio 'alta valore, che tiene traccia del valore più recente di una colonna di data e ora o di una colonna integer univoca nella tabella di origine.

È possibile usare tabelle temporali in SQL Server. Le tabelle temporali sono tabelle con controllo delle versioni di sistema che archiviano la cronologia delle modifiche dei dati. Il motore di database registra automaticamente la cronologia di ogni modifica in una tabella di cronologia separata. Per eseguire query sui dati cronologici, è possibile aggiungere una clausola FOR SYSTEM_TIME a una query. Il motore di database esegue internamente query sulla tabella di cronologia, ma questo processo è trasparente per l'applicazione.

Le tabelle temporali supportano i dati delle dimensioni, che possono cambiare nel tempo. Le tabelle dei fatti rappresentano una transazione non modificabile, ad esempio una vendita, e in questo caso la conservazione della cronologia delle versioni di sistema risulta superflua. Al contrario, le transazioni hanno in genere una colonna che rappresenta la data della transazione. La colonna può essere utilizzata come valore limite. Ad esempio, nel data warehouse AdventureWorks le tabelle SalesLT.* hanno un campo LastModified.

Di seguito il flusso generale per la pipeline ELT:

  1. Per ogni tabella del database di origine, tenere traccia del valore temporale limite relativo all'esecuzione dell'ultimo processo ELT. Archiviare tali informazioni nel data warehouse. Durante l'installazione iniziale tutti i valori temporali vengono impostati su 1-1-1900.

  2. Durante il passaggio di esportazione dei dati, il valore temporale limite viene passato come parametro a un set di stored procedure nel database di origine. Queste stored procedure eseguono query su tutti i record modificati o creati dopo il periodo di interruzione. Per tutte le tabelle dell'esempio, è possibile utilizzare la colonna ModifiedDate.

  3. Al termine della migrazione dei dati, aggiornare la tabella in cui sono archiviati i valori temporali limite.

Pipeline di dati

Questo scenario usa il database di esempio AdventureWorks come origine dati. Il modello di caricamento incrementale dei dati garantisce che vengano caricati solo i dati modificati o aggiunti dopo l'esecuzione della pipeline più recente.

Strumento di copia dei dati guidata da metadati

Lo strumento di copia basato sui metadati predefinito all'interno delle pipeline di Azure Synapse Analytics carica in modo incrementale tutte le tabelle contenute nel database relazionale.

  1. Usare un'interfaccia della procedura guidata per connettere lo strumento Copia dati al database di origine.

  2. Dopo la connessione, configurare il caricamento incrementale o il caricamento completo per ogni tabella.

  3. Lo strumento Copia dati crea le pipeline e gli script SQL necessari per generare la tabella di controllo. Questa tabella archivia i dati, ad esempio il valore limite elevato o la colonna per ogni tabella, per il processo di caricamento incrementale.

  4. Dopo l'esecuzione di questi script, la pipeline carica tutte le tabelle del data warehouse di origine nel pool dedicato di Azure Synapse Analytics.

Screenshot che mostra lo strumento Copia dati basato sui metadati in Azure Synapse Analytics.

Prima che lo strumento carichi i dati, vengono create tre pipeline per scorrere le tabelle nel database.

Le pipeline eseguono le attività seguenti:

  • Contare il numero di oggetti, ad esempio tabelle, da copiare nell'esecuzione della pipeline.

  • Scorrere ogni oggetto da caricare o copiare.

  • Dopo che una pipeline esegue l'iterazione su ogni oggetto, esegue le attività seguenti:

    • Controlla se è necessario un carico differenziale. In caso contrario, la pipeline completa un normale caricamento completo.

    • Recupera il valore limite massimo dalla tabella dei controlli.

    • Copia i dati dalle tabelle di origine nell'account di staging in Data Lake Storage.

    • Carica i dati nel pool SQL dedicato tramite il metodo di copia selezionato, ad esempio il comando PolyBase o Copy.

    • Aggiorna il valore limite massimo nella tabella dei controlli.

Caricare dati in un pool SQL di Azure Synapse Analytics

L'attività di copia copia i dati dal database SQL nel pool SQL di Azure Synapse Analytics. Questo database SQL di esempio si trova in Azure, quindi usa il runtime di integrazione di Azure per leggere i dati dal database SQL e scrivere i dati nell'ambiente di gestione temporanea specificato.

L'istruzione di copia carica quindi i dati dall'ambiente di gestione temporanea nel pool dedicato di Azure Synapse Analytics.

Usare le pipeline di Azure Synapse Analytics

Le pipeline in Azure Synapse Analytics definiscono un set ordinato di attività per completare un modello di carico incrementale. I trigger manuali o automatici avviano la pipeline.

Trasformazione dei dati

Il database di esempio in questa architettura di riferimento è di piccole dimensioni, quindi vengono create tabelle replicate senza partizioni. Per i carichi di lavoro di produzione, le tabelle distribuite possono migliorare le prestazioni delle query. Per altre informazioni, vedere Linee guida per la progettazione di tabelle distribuite in Azure Synapse Analytics. Gli script di esempio eseguono le query tramite una classe di risorse statica.

In un ambiente di produzione è consigliabile creare tabelle di staging con distribuzione round robin. Quindi trasformare e spostare i dati in tabelle di produzione con indici columnstore cluster, che offrono le migliori prestazioni complessive delle query. Gli indici columnstore sono ottimizzati per query di analisi di record numerosi.

Gli indici columnstore non vengono eseguiti in modo ottimale per le ricerche singleton o la ricerca di una singola riga. Se è necessario eseguire ricerche singleton frequenti, è possibile aggiungere un indice non cluster a una tabella, aumentando la velocità. Tuttavia, le ricerche singleton sono in genere meno comuni negli scenari del data warehouse rispetto ai carichi di lavoro di elaborazione delle transazioni online. Per altre informazioni, vedere tabelle index in Azure Synapse Analytics.

Nota

Le tabelle columnstore cluster non supportano tipi di dati varchar(max), nvarchar(max), o varbinary(max). Se si usano questi tipi di dati, considerare un heap o un indice cluster. È anche possibile inserire queste colonne in una tabella separata.

Usare Power BI Premium per accedere, modellare e visualizzare i dati

Power BI Premium supporta diverse opzioni per connettersi alle origini dati in Azure. È possibile usare i pool di cui è stato effettuato il provisioning in Azure Synapse Analytics per eseguire le attività seguenti:

  • Importazione: i dati vengono importati nel modello Power BI.
  • DirectQuery: i dati vengono estratti direttamente dall'archiviazione relazionale.
  • Modello composito: combinare l'importazione per alcune tabelle e DirectQuery per altre.

Questo scenario usa il dashboard DirectQuery perché presenta una piccola quantità di dati e una bassa complessità del modello. DirectQuery delega la query al potente motore di calcolo sottostante e usa funzionalità di sicurezza complete nell'origine. DirectQuery garantisce che i risultati siano sempre coerenti con i dati di origine più recenti.

La modalità di importazione offre il tempo di risposta della query più veloce. Prendere in considerazione la modalità di importazione se:

  • Il modello si adatta interamente alla memoria di Power BI.
  • La latenza dei dati tra gli aggiornamenti è accettabile.
  • Sono necessarie trasformazioni complesse tra il sistema di origine e il modello finale.

In questo caso, gli utenti finali vogliono accedere completamente ai dati più recenti senza ritardi nell'aggiornamento di Power BI e vogliono che tutti i dati cronologici superino la capacità del set di dati di Power BI. Un set di dati di Power BI può gestire 25-400 GB, a seconda delle dimensioni della capacità. Il modello di dati nel pool SQL dedicato è già in uno schema star e non richiede la trasformazione, quindi DirectQuery è una scelta appropriata.

Screenshot che mostra il dashboard in Power BI.

Usare Power BI Premium per gestire modelli di grandi dimensioni, report impaginati e pipeline di distribuzione. Sfruttare i vantaggi dell'endpoint predefinito di Azure Analysis Services. È anche possibile avere capacità dedicata con proposta di valore univoco.

Quando il modello di business intelligence aumenta o aumenta la complessità del dashboard, è possibile passare a modelli compositi e importare parti delle tabelle di ricerca tramite tabelle ibridee importare dati preaggregati. È possibile abilitare memorizzazione nella cache delle query all'interno di Power BI per i set di dati importati e usare due tabelle per la proprietà modalità di archiviazione.

All'interno del modello composito, i set di dati fungono da livello pass-through virtuale. Quando gli utenti interagiscono con le visualizzazioni, Power BI genera query SQL nei pool SQL di Azure Synapse Analytics. Power BI determina se usare l'archiviazione in memoria o DirectQuery in base all'efficienza. Il motore decide quando passare dalla memoria a DirectQuery ed esegue il push della logica nel pool SQL di Azure Synapse Analytics. A seconda del contesto delle tabelle di query, possono fungere da modelli compositi memorizzati nella cache (importati) o non memorizzati nella cache. È possibile scegliere quale tabella memorizzare nella cache in memoria, combinare i dati di una o più origini DirectQuery o combinare dati di origine DirectQuery e dati importati.

Quando si usa DirectQuery con un pool di provisioning di Azure Synapse Analytics:

  • Usare Azure Synapse Analytics la memorizzazione nella cache dei set di risultati per memorizzare nella cache i risultati delle query nel database utente per un uso ripetitivo. Questo approccio migliora le prestazioni delle query in millisecondi e riduce l'utilizzo delle risorse di calcolo. Le query che usano set di risultati memorizzati nella cache non usano slot di concorrenza in Azure Synapse Analytics, quindi non vengono conteggiate rispetto ai limiti di concorrenza esistenti.

  • Usare Azure Synapse Analytics viste materializzate per precompilare, archiviare e gestire dati come una tabella. Le query che usano tutti i dati o un subset dei dati nelle viste materializzate possono ottenere prestazioni più veloci senza dover fare riferimento direttamente alla vista materializzata definita per usarla.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

La modernizzazione del cloud introduce problemi di sicurezza, ad esempio violazioni dei dati, infezioni da malware e inserimento di codice dannoso. È necessaria una soluzione di servizi o provider di servizi cloud in grado di risolvere i problemi perché misure di sicurezza inadeguate possono creare problemi gravi.

Questo scenario risolve i problemi di sicurezza più impegnativi usando una combinazione di controlli di sicurezza a più livelli: controlli di rete, identità, privacy e autorizzazione. Un pool di cui è stato effettuato il provisioning di Azure Synapse Analytics archivia la maggior parte dei dati. Power BI accede ai dati tramite DirectQuery tramite Single Sign-On. È possibile usare Microsoft Entra ID per l'autenticazione. Sono inoltre disponibili controlli di sicurezza estesi per l'autorizzazione dei dati all'interno dei pool di cui è stato effettuato il provisioning.

Alcune domande comuni sulla sicurezza includono:

  • Definire chi può visualizzare i dati.

    • Assicurarsi che i dati siano conformi alle linee guida federali, locali e aziendali per attenuare i rischi di violazione dei dati. Azure Synapse Analytics offre più funzionalità di protezione dei dati per ottenere la conformità.

  • Determinare come verificare l'identità di un utente.

  • Scegliere una tecnologia di sicurezza di rete per proteggere l'integrità, la riservatezza e l'accesso alle reti e ai dati.

  • Scegliere gli strumenti per rilevare e notificare le minacce.

    • Usare Azure Synapse Analytics funzionalità di rilevamento delle minacce, ad esempio il controllo SQL, il rilevamento delle minacce SQL e la valutazione della vulnerabilità per controllare, proteggere e monitorare i database.

  • Determinare come proteggere i dati nell'account di archiviazione.

    • Usare gli account di archiviazione di Azure per i carichi di lavoro che richiedono tempi di risposta rapidi e coerenti o con un numero elevato di operazioni di input/output al secondo. Gli account di archiviazione possono archiviare tutti gli oggetti dati e avere diverse opzioni di sicurezza dell'account di archiviazione .

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

In questa sezione vengono fornite informazioni sui prezzi per i diversi servizi coinvolti in questa soluzione e vengono menzionate le decisioni prese per questo scenario con un set di dati di esempio. Usare questa configurazione iniziale nel calcolatore prezzi di Azure e modificarla in base allo scenario.

Azure Synapse Analytics

Azure Synapse Analytics è un'architettura serverless che è possibile usare per ridimensionare i livelli di calcolo e archiviazione in modo indipendente. Le risorse di calcolo comportano costi in base all'utilizzo. È possibile ridimensionare o sospendere queste risorse su richiesta. Le risorse di archiviazione comportano costi per terabyte, quindi i costi aumentano man mano che si inseriscono i dati.

Pipeline di Azure Synapse Analytics

Tre componenti principali influenzano il prezzo di una pipeline:

  • Attività delle pipeline di dati e ore del runtime di integrazione
  • Dimensioni e implementazione del cluster dei flussi di dati
  • Addebiti per le operazioni

Per informazioni dettagliate sui prezzi, vedere la scheda integrazione dei datiprezzi di Azure Synapse Analytics.

Il prezzo varia a seconda di componenti o attività, frequenza e numero di unità di runtime di integrazione.

Per il set di dati di esempio, che usa il runtime di integrazione ospitato in Azure standard, l'attività di copia dei dati funge da core della pipeline. Viene eseguito su una pianificazione giornaliera per tutte le entità (tabelle) nel database di origine. Lo scenario non contiene flussi di dati. E non comporta costi operativi perché le pipeline eseguono meno di un milione di operazioni al mese.

Pool e archiviazione dedicati di Azure Synapse Analytics

Per il set di dati di esempio, è possibile effettuare il provisioning di 500 unità data warehouse (DWU) per offrire un'esperienza uniforme per i carichi analitici. È possibile mantenere il calcolo durante l'orario di ufficio per la creazione di report. Se la soluzione passa alla produzione, usare la capacità riservata del data warehouse come strategia conveniente. Usare varie tecniche per ottimizzare le metriche relative ai costi e alle prestazioni.

Per informazioni dettagliate sui prezzi per un pool dedicato di Azure Synapse Analytics, vedere la scheda Data Warehousingprezzi di Azure Synapse Analytics. Nel modello di consumo dedicato i clienti comportano costi per ogni DWU di cui è stato effettuato il provisioning, per ora di tempo di attività. Considerare anche i costi di archiviazione dei dati, incluse le dimensioni dei dati inattivi, gli snapshot e la ridondanza geografica.

Archiviazione BLOB

Prendere in considerazione l'uso della capacità riservata di Archiviazione di Azure per ridurre i costi di archiviazione. Con questo modello si ottiene uno sconto se si riserva la capacità di archiviazione fissa per uno o tre anni. Per altre informazioni, vedere Ottimizzare i costi per l'archiviazione BLOB con capacità riservata. Questo scenario non usa l'archiviazione permanente.

Power BI Premium

Questo scenario usa aree di lavoro di Power BI Premium con miglioramenti delle prestazioni predefiniti per soddisfare esigenze analitiche impegnative.

Per altre informazioni, vedere prezzi di Power BI.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

  • Usare una pipeline di versione di Azure DevOps e GitHub Actions per automatizzare la distribuzione di un'area di lavoro di Azure Synapse Analytics in più ambienti. Per altre informazioni, vedere integrazione continua e recapito continuo per un'area di lavoro di Azure Synapse Analytics.

  • Inserire ogni carico di lavoro in un modello di distribuzione separato e archiviare le risorse nei sistemi di controllo del codice sorgente. È possibile distribuire i modelli insieme o singolarmente come parte di un processo di integrazione continua e recapito continuo (CI/CD). Questo approccio semplifica il processo di automazione. Questa architettura ha quattro carichi di lavoro principali:

    • Il server del data warehouse e le risorse correlate
    • Pipeline di Azure Synapse Analytics
    • Asset di Power BI, inclusi dashboard, app e set di dati
    • Scenario simulato da locale a cloud

  • Prendi in considerazione la possibilità di staging dei carichi di lavoro laddove possibile. Distribuire il carico di lavoro in varie fasi. Eseguire i controlli di convalida in ogni fase prima di passare alla fase successiva. Questo approccio esegue il push degli aggiornamenti negli ambienti di produzione in modo controllato e riduce al minimo i problemi di distribuzione imprevisti. Usare di distribuzione blu-verde e strategie di rilascio canary per aggiornare gli ambienti di produzione live.

  • Usare una strategia di rollback per gestire le distribuzioni non riuscite. Ad esempio, è possibile ridistribuire automaticamente una distribuzione precedente con esito positivo dalla cronologia della distribuzione. Usare il flag --rollback-on-error nell'interfaccia della riga di comando di Azure.

  • Usare monitoraggio di Azure per analizzare le prestazioni del data warehouse e l'intera piattaforma di analisi di Azure per un'esperienza di monitoraggio integrata. Azure Synapse Analytics offre una ricca esperienza di monitoraggio nel portale di Azure per scoprire informazioni dettagliate sul carico di lavoro del data warehouse. Usare il portale di Azure per monitorare il data warehouse. Fornisce periodi di conservazione configurabili, avvisi, raccomandazioni e grafici e dashboard personalizzabili per metriche e log.

Per altre informazioni, vedere le risorse seguenti:

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Questa sezione fornisce informazioni dettagliate sulle decisioni di dimensionamento per supportare questo set di dati.

Pool di provisioning di Azure Synapse Analytics

È possibile usare varie configurazioni del data warehouse .

DWU Numero di nodi di calcolo Numero di distribuzioni per nodo
DW100c 1 60
-- TO --
DW30000c 60 1

Per visualizzare i vantaggi delle prestazioni dell'aumento delle prestazioni, in particolare per le DWU di dimensioni maggiori, usare almeno un set di dati da 1 TB. Per trovare il numero migliore di DWU per il pool SQL dedicato, provare a aumentare e ridurre le prestazioni. Eseguire query con diversi numeri di DWU dopo il caricamento dei dati. La scalabilità è rapida, quindi è possibile sperimentare facilmente vari livelli di prestazioni.

Trovare il numero migliore di DWU

Per un pool SQL dedicato in fase di sviluppo, selezionare un numero ridotto di DWU come punto di partenza, ad esempio DW400c o DW200c. Monitorare le prestazioni dell'applicazione per ogni numero di DWU. Si supponga una scala lineare e determinare quanto è necessario aumentare o diminuire le DWU. Continuare ad apportare modifiche finché non si raggiunge un livello di prestazioni ottimale per i propri requisiti aziendali.

Ridimensionare un pool SQL di Azure Synapse Analytics

Per le funzionalità di scalabilità e ottimizzazione delle prestazioni delle pipeline in Azure Synapse Analytics e dell'attività di copia usata, vedere guida alle prestazioni e alla scalabilità dell'attività di copia.

Per altre informazioni, vedere le risorse seguenti:

Power BI Premium e Fabric

Questo articolo usa la capacità Power BI Premium F64 per illustrare le funzionalità di business intelligence. Le capacità di Power BI dedicate nell'infrastruttura vanno da F64 (8 vCore) a F1024 (128 vCore).

Per determinare la capacità necessaria:

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi