Questo è un guest post scritto da Mahesh Vandi Chalil, Chief Technology Officer di BookMyShow.

BookMyShow (BMS), una delle principali società di intrattenimento in India, fornisce una piattaforma di biglietteria online per film, spettacoli teatrali, concerti ed eventi sportivi. Vendendo fino a 200 milioni di biglietti su base annua (pre-COVID) a clienti in India, Sri Lanka, Singapore, Indonesia e Medio Oriente, BookMyShow offre anche un servizio di streaming multimediale online e una gestione end-to-end per esperienze di intrattenimento virtuali e sul campo di tutti i generi.

La pandemia ha offerto a BMS l'opportunità di migrare e modernizzare la nostra soluzione di analisi di 15 anni in una moderna architettura di dati su AWS. Questa architettura è un'architettura moderna, sicura, gestita e ottimizzata in termini di costi, con la possibilità di scalare fino a petabyte. BMS è stato migrato e modernizzato da on-premise e altre piattaforme cloud ad AWS in soli quattro mesi. Questo progetto è stato eseguito in parallelo con il nostro progetto di migrazione delle applicazioni e ha ottenuto un risparmio sui costi di archiviazione del 90% e un risparmio sui costi dell'80% nella spesa per l'analisi.

La piattaforma di analisi BMS soddisfa le esigenze aziendali per le vendite e il marketing, la finanza e i partner commerciali (ad es. cinema e proprietari di eventi) e fornisce funzionalità applicative per i team di pubblico, personalizzazione, prezzi e scienza dei dati. La precedente soluzione di analisi disponeva di più copie di dati, per un totale di oltre 40 TB, con circa 80 TB di dati in altri archivi cloud. I dati sono stati archiviati on-premise e nel cloud in vari archivi dati. Crescendo organicamente, i team hanno avuto la libertà di scegliere il proprio stack tecnologico per i singoli progetti, il che ha portato alla proliferazione di vari strumenti, tecnologie e pratiche. I singoli team per la personalizzazione, il pubblico, l'ingegneria dei dati, la scienza dei dati e l'analisi hanno utilizzato una varietà di prodotti per l'importazione, l'elaborazione dei dati e la visualizzazione.

Questo post discute il percorso di migrazione e modernizzazione di BMS e come BMS, AWS e AWS collaborano Tecnologie Minfy il team ha lavorato insieme per completare con successo la migrazione in quattro mesi e risparmiare sui costi. I principi della migrazione che utilizzano il file Architettura moderna dei dati AWS ha reso il progetto un enorme successo.

Sfide nella precedente piattaforma di analisi

• Tecnologia varia: più team hanno utilizzato vari prodotti, lingue e versioni del software.
• Progetto di migrazione più ampio: poiché la modernizzazione dell'analisi era un progetto parallelo con la migrazione delle applicazioni, la pianificazione era fondamentale per considerare i cambiamenti nelle applicazioni principali e nelle tempistiche del progetto.
• Risorse: abbandono di risorse esperte dal progetto di migrazione delle applicazioni e documentazione molto scarsa dei sistemi attuali.
• Dati : disponeva di più copie di dati e nessuna singola fonte di verità; ogni archivio dati forniva una vista per l'unità di business.
• Pipeline di acquisizione: complesse pipeline di dati hanno spostato i dati su vari datastore a varie frequenze. Abbiamo messo in atto diversi approcci per inserire i dati in Cloudera, tramite oltre 100 consumatori Kafka dai sistemi di transazione e MQTT (protocollo di messaggistica di trasporto di telemetria della coda di messaggi) per flussi di clic, procedure archiviate e processi Spark. Abbiamo svolto circa 100 lavori per l'inserimento di dati in Spark, Alteryx, Beam, NiFi e altri.
• Cluster Hadoop: Grande hardware dedicato su cui sono stati configurati i cluster Hadoop con costi fissi. La configurazione on-premise di Cloudera ha soddisfatto la maggior parte dei carichi di lavoro di elaborazione in batch di data engineering, audience e personalizzazione. I team hanno implementato HBase e Hive per il nostro pubblico e le applicazioni di personalizzazione.
• Data warehouse: il team di ingegneria dei dati ha utilizzato TiDB come data warehouse on-premise. Tuttavia, ogni team di consumatori aveva la propria prospettiva dei dati necessari per l'analisi. Con l'evolversi di questa architettura a silos, la manutenzione di questi ambienti separati ha comportato costosi costi operativi e di archiviazione.
• Database di analisi: il team di analisi ha utilizzato dati provenienti da altri sistemi transazionali e dati denormalizzati. Il team aveva la propria pipeline di estrazione, trasformazione e caricamento (ETL), utilizzando Alteryx con uno strumento di visualizzazione.

Seguirono i principi della migrazione che portarono al successo del progetto:

• Assegna priorità in base alla funzionalità aziendale.
• Applica le best practice durante la creazione di un'architettura di dati moderna sin dal primo giorno.
• Sposta solo i dati richiesti, canonicalizza i dati e archiviali nel formato più ottimale nella destinazione. Rimuovi il più possibile la ridondanza dei dati. Segna l'ambito dell'ottimizzazione per il futuro quando le modifiche sono invadenti.
• Costruisci l'architettura dei dati tenendo conto dei formati, dei volumi, della governance e della sicurezza dei dati.
• Semplifica l'ELT e l'elaborazione dei lavori classificando i lavori come ricollocati, riscritti e ritirati. Finalizza il formato canonico dei dati, la trasformazione, l'arricchimento, la compressione e il formato di archiviazione come Parquet.
• Rehost dei job di machine learning (ML) critici per il business.
• Lavorare a ritroso per raggiungere i nostri obiettivi, eliminare gli ostacoli e modificare le decisioni per andare avanti.
• Usa le opzioni serverless come prima opzione e paga per uso. Valutare il costo e lo sforzo per la riprogettazione per selezionare l'approccio giusto. Esegui un proof of concept per convalidarlo per ogni componente e servizio.

Strategie applicate per avere successo in questa migrazione:

• Team – Abbiamo creato un team unificato con persone provenienti da ingegneria dei dati, analisi e scienza dei dati come parte del progetto di migrazione dell'analisi. I team SRE (Site Reliability Engineering) e applicativi sono stati coinvolti quando erano necessarie decisioni critiche in merito ai dati o alla tempistica per l'allineamento. I team di analisi, ingegneria dei dati e scienza dei dati hanno dedicato molto tempo alla pianificazione, alla comprensione del codice e all'esame iterativo delle origini dati, delle pipeline di dati e dei processi di elaborazione esistenti. Il team AWS con il team partner di Minfy Technologies ha aiutato BMS ad arrivare a un piano di migrazione dopo una prova di concetto per ciascuno dei componenti nell'acquisizione dei dati, nell'elaborazione dei dati, nel data warehouse, nel machine learning e nei dashboard di analisi.
• Corsi – Il team AWS ha condotto una serie di workshop e giornate di immersione e ha istruito il team BMS sulla tecnologia e sulle best practice per distribuire i servizi di analisi. Il team AWS ha aiutato BMS a esplorare la configurazione e i vantaggi dell'approccio alla migrazione per ogni scenario (migrazione dei dati, pipeline di dati, elaborazione dei dati, visualizzazione e machine learning) tramite proof of concept (POC). Il team ha acquisito le modifiche richieste nel codice esistente per la migrazione. Il team BMS ha anche preso conoscenza dei seguenti servizi AWS:
• Verifica teorica – Il team BMS, con l'aiuto del partner e del team AWS, ha implementato diversi proof of concept per convalidare l'approccio alla migrazione:
  • Eseguita l'elaborazione in batch di processi Spark in Amazon EMR, in cui abbiamo verificato il runtime, le modifiche al codice richieste e il costo.
  • Ha eseguito processi di analisi del flusso di clic in Amazon EMR, testando la pipeline end-to-end. Il team ha condotto prove di concetto su AWS IoT Core per protocollo MQTT e streaming su Amazon S3.
  • Migrazione dei modelli ML su Amazon SageMaker e orchestrazione con Amazon MWAA.
  • Creazione di report e dashboard QuickSight di esempio, in cui sono state valutate le funzionalità e il tempo di realizzazione.
  • Configurato per scenari chiave per Amazon Redshift, in cui sono stati valutati il ​​tempo di caricamento dei dati, le prestazioni delle query e il costo.
• Analisi sforzo vs. costo – Il team ha eseguito le seguenti valutazioni:
  • Confrontando le pipeline di importazione, la differenza nella struttura dei dati in ogni negozio, la base dell'attuale esigenza aziendale per l'origine dati, l'attività di pre-elaborazione dei dati prima della migrazione, la migrazione dei dati ad Amazon S3 e l'acquisizione dei dati di modifica (CDC) dal applicazioni migrate in AWS.
  • Valutato lo sforzo per migrare circa 200 lavori, determinato quali lavori erano ridondanti o necessitavano di miglioramenti dal punto di vista funzionale e completato un elenco di migrazione per lo stato di destinazione. La modernizzazione del codice del flusso di lavoro MQTT in serverless richiedeva molto tempo, quindi ho deciso di eseguire il rehosting Cloud di calcolo elastico di Amazon (Amazon EC2) e modernizzazione a Cinesi amazzonica alla fase successiva.
  • Ha esaminato oltre 400 report e dashboard, ha assegnato priorità allo sviluppo in fasi e ha rivalutato le esigenze degli utenti aziendali.

Servizi cloud AWS scelti per l'architettura proposta:

• Data Lake – Abbiamo utilizzato Amazon S3 come data lake per archiviare l'unica verità delle informazioni per tutti i dati grezzi ed elaborati, riducendo così le copie dell'archiviazione dei dati e i costi di archiviazione.
• L'ingestione – Poiché avevamo più fonti di verità nell'architettura attuale, siamo arrivati ​​a una struttura comune prima della migrazione ad Amazon S3 e le pipeline esistenti sono state modificate per eseguire la pre-elaborazione. Questi lavori di pre-elaborazione una tantum sono stati eseguiti in Cloudera, poiché i dati di origine erano in locale e su Amazon EMR per i dati nel cloud. Abbiamo progettato nuove pipeline di dati per l'acquisizione da sistemi transazionali nel cloud AWS utilizzando AWS Glue ETL.
• Processando – I lavori di elaborazione sono stati separati in base al runtime in due categorie: batch e quasi in tempo reale. I processi batch sono stati ulteriormente suddivisi in cluster Amazon EMR transitori con runtime e requisiti delle applicazioni Hadoop variabili come HBase. I lavori quasi in tempo reale sono stati forniti in un cluster permanente Amazon EMR per l'analisi dei flussi di clic e una pipeline di dati dai sistemi transazionali. Abbiamo adottato un approccio serverless utilizzando AWS Glue ETL per nuove pipeline di dati dai sistemi transazionali nel cloud AWS.
• Data warehouse – Abbiamo scelto Amazon Redshift come nostro data warehouse e abbiamo pianificato come i dati sarebbero stati distribuiti in base ai modelli di query.
• Visualizzazione – Abbiamo creato i report in Amazon QuickSight in più fasi e ne abbiamo assegnato la priorità in base alla domanda aziendale. Abbiamo discusso con gli utenti aziendali le loro esigenze attuali e identificato i report immediati richiesti. Abbiamo definito le fasi di creazione di report e dashboard e creato i report in Amazon QuickSight. In futuro prevediamo di utilizzare report incorporati per utenti esterni.
• apprendimento automatico – I modelli ML personalizzati sono stati distribuiti su Amazon SageMaker. I DAG Airflow esistenti sono stati migrati su Amazon MWAA.
• Governance, sicurezza e conformità – Governance con Formazione del Lago Amazzonico è stato adottato dal primo giorno. Abbiamo configurato il catalogo dati di AWS Glue per fare riferimento ai dati utilizzati come origini e destinazioni. Abbiamo dovuto rispettare le linee guida PCI (Payment Card Industry) perché le informazioni di pagamento erano nel data lake, quindi abbiamo garantito le politiche di sicurezza necessarie.

Panoramica della soluzione

Architettura dati moderna BMS

Il seguente diagramma illustra la nostra moderna architettura dei dati.

L'architettura include i seguenti componenti:

1. Sistemi di origine – Questi includono quanto segue:
   • Dati provenienti da sistemi transazionali archiviati in MariaDB (prenotazione e transazioni).
   • Dati del flusso di clic sull'interazione dell'utente tramite consumatori Kafka a DataOps MariaDB.
   • Membri e informazioni sull'assegnazione dei posti da MongoDB.
   • SQL Server per offerte specifiche e informazioni di pagamento.
2. Pipeline di dati – I processi Spark su un cluster permanente Amazon EMR elaborano i dati del flusso di clic dai cluster Kafka.
3. Data Lake – I dati dai sistemi di origine sono stati archiviati nei rispettivi bucket Amazon S3, con prefissi per query di dati ottimizzate. Per Amazon S3, abbiamo seguito una gerarchia per archiviare dati grezzi, riepilogati e relativi a team o servizi in diverse cartelle principali in base all'origine e al tipo di dati. Le policy del ciclo di vita sono state aggiunte ai registri e alle cartelle temporanee di diversi servizi in base ai requisiti dei team.
4. Elaborazione dei dati – I cluster Amazon EMR transitori vengono utilizzati per elaborare i dati in un formato curato per il pubblico, la personalizzazione e i team di analisi. I lavori di unione di file di piccole dimensioni uniscono i dati del flusso di clic in un file di dimensioni maggiori, risparmiando sui costi per le query una tantum.
5. Governance LPI – AWS Lake Formation consente l'utilizzo dei crawler AWS Glue per acquisire lo schema dei dati archiviati nel data lake e le modifiche di versione nello schema. Il catalogo dati e la policy di sicurezza in AWS Lake Formation consentono l'accesso ai dati per ruoli e utenti in Amazon Redshift, Amazon Athena, Amazon QuickSight e lavori di data science. I processi ETL di AWS Glue caricano i dati elaborati in Amazon Redshift a intervalli pianificati.
6. Query – Il team di analisi ha utilizzato Amazon Athena per eseguire query una tantum sollevate dai team aziendali sul data lake. Poiché lo sviluppo dei report avviene in più fasi, per l'esportazione dei dati è stato utilizzato Amazon Athena.
7. Data warehouse – Amazon Redshift è stato utilizzato come data warehouse, dove vengono elaborati e archiviati i report per i team di vendita, la direzione e terze parti (ad esempio, teatri ed eventi) per un rapido recupero. Le visualizzazioni per analizzare le vendite totali, le tendenze delle vendite di film, il comportamento dei membri e le modalità di pagamento sono configurate qui. Utilizziamo viste materializzate per tabelle denormalizzate, schemi diversi per metadati e dati transazionali e comportamentali.
8. Report – Abbiamo utilizzato i report di Amazon QuickSight per vari casi d'uso aziendali, di marketing e di prodotti.
9. apprendimento automatico – Alcuni dei modelli distribuiti su Amazon SageMaker sono i seguenti:
   • Popolarità dei contenuti – Decide il contenuto consigliato per gli utenti.
   • Popolarità degli eventi dal vivo – Calcola la popolarità degli eventi di intrattenimento dal vivo in diverse regioni.
   • Ricerche di tendenza – Identifica le ricerche di tendenza in tutte le regioni.

Soluzione

Fasi di esecuzione della migrazione

Abbiamo standardizzato strumenti, servizi e processi per l'ingegneria dei dati, l'analisi e la scienza dei dati:

• Data Lake
  • Identificato i dati di origine da migrare da Archival DB, BigQuery, TiDB e il database di analisi.
  • Creato un modello di dati canonico adatto a più team aziendali e ridotto le copie dei dati, e quindi i costi operativi e di archiviazione. Lavori esistenti modificati per facilitare la migrazione a un formato canonico.
  • Identificato i sistemi di origine, la capacità richiesta, la crescita prevista, i proprietari e i requisiti di accesso.
  • Ha eseguito la migrazione dei dati in blocco ad Amazon S3 da varie fonti.
• L'ingestione
  • Sistemi di transazione – Mantenute le code e i consumatori Kafka esistenti.
  • Dati del flusso di clic – Condotto con successo un proof of concept per utilizzare AWS IoT Core per il protocollo MQTT. Tuttavia, poiché avevamo bisogno di apportare modifiche all'applicazione da pubblicare su AWS IoT Core, abbiamo deciso di implementarla come parte della modernizzazione dell'applicazione mobile in un secondo momento. Abbiamo deciso di eseguire il rehosting del server MQTT su Amazon EC2.
• Processando
• Ha elencato le pipeline di dati rilevanti per il business e le ha migrate con modifiche minime.
• Carichi di lavoro classificati in lavori critici, lavori ridondanti o lavori che possono essere ottimizzati:
  • I lavori Spark sono stati migrati in Amazon EMR.
  • I lavori HBase sono stati migrati ad Amazon EMR con HBase.
  • I metadati archiviati nei processi basati su Hive sono stati modificati per utilizzare il catalogo dati di AWS Glue.
  • I lavori NiFi sono stati semplificati e riscritti in Spark eseguito in Amazon EMR.
• I cluster Amazon EMR sono stati configurati come un cluster persistente per lo streaming dei flussi di clic e dei carichi di lavoro di personalizzazione. Abbiamo utilizzato più cluster transitori per l'esecuzione di tutti gli altri Spark ETL o processi di elaborazione. Abbiamo utilizzato le istanze Spot per i nodi di attività per risparmiare sui costi. Abbiamo ottimizzato l'archiviazione dei dati con lavori specifici per unire file di piccole dimensioni e conversioni di formati di file compressi.
• I crawler di AWS Glue hanno identificato nuovi dati in Amazon S3. I processi ETL di AWS Glue hanno trasformato e caricato i dati elaborati nel data warehouse di Amazon Redshift.
• magazzino dati
  • Definito lo schema del data warehouse classificando i report critici richiesti dall'azienda, tenendo presente il carico di lavoro e i report richiesti in futuro.
  • Definita l'area di staging per i dati incrementali caricati in Amazon Redshift, visualizzazioni materializzate e ottimizzazione delle query in base all'utilizzo. La transazione e i metadati primari vengono archiviati in Amazon Redshift per soddisfare tutti i requisiti di analisi e reporting dei dati. Abbiamo creato viste materializzate e tabelle denormalizzate in Amazon Redshift da utilizzare rispettivamente come origini dati per dashboard e attività di segmentazione di Amazon QuickSight.
  • Utilizzato in modo ottimale il cluster Amazon Redshift caricando i dati degli ultimi due anni in Amazon Redshift e utilizzato Spettro Amazon Redshift per interrogare i dati storici tramite tabelle esterne. Ciò ha contribuito a bilanciare l'utilizzo e il costo del cluster Amazon Redshift.
• Visualizzazione
  • I dashboard di Amazon QuickSight sono stati creati per il team di vendita e marketing nella Fase 1:
    • Rapporto di riepilogo delle vendite – Una dashboard di riepilogo esecutivo per ottenere una panoramica delle vendite in tutto il paese per regione, città, film, teatro, genere e altro.
    • Intrattenimento dal vivo – Un report dedicato agli eventi verticali di intrattenimento dal vivo.
    • Buoni e offerte promozionali – Un report per i coupon acquistati e riscattati.
    • PrenotaASmile – Una dashboard per analizzare i dati per BookASmile, un'iniziativa benefica.
• apprendimento automatico
  • Elencati i carichi di lavoro ML da migrare in base alle attuali esigenze aziendali.
  • I lavori di elaborazione ML prioritari sono stati distribuiti su Amazon EMR. I modelli sono stati modificati per utilizzare Amazon S3 come origine e destinazione e sono state esposte nuove API per utilizzare la funzionalità. I modelli ML sono stati distribuiti su Amazon SageMaker per i film, l'analisi del flusso di clic degli eventi live e la personalizzazione.
  • Gli artefatti esistenti nell'orchestrazione Airflow sono stati migrati su Amazon MWAA.
• Sicurezza
  • AWS Lake Formation è stata la base del data lake, con AWS Glue Data Catalog come base per il catalogo centrale per i dati archiviati in Amazon S3. Ciò ha consentito l'accesso ai dati da parte di varie funzionalità, tra cui il pubblico, la personalizzazione, l'analisi e i team di data science.
  • Le informazioni di identificazione personale (PII) e i dati di pagamento sono stati archiviati nel data lake e nel data warehouse, quindi abbiamo dovuto rispettare le linee guida PCI. La crittografia dei dati inattivi e in transito è stata considerata e configurata in ogni livello di servizio (Amazon S3, AWS Glue Data Catalog, Amazon EMR, AWS Glue, Amazon Redshift e QuickSight). Ruoli, responsabilità e autorizzazioni di accesso chiari per diversi gruppi di utenti e privilegi sono stati elencati e configurati in Gestione dell'identità e dell'accesso di AWS (IAM) e singoli servizi.
  • Per l'accesso degli utenti di Amazon QuickSight è stata utilizzata l'integrazione Single Sign-On (SSO) esistente con Microsoft Active Directory.
• Automazione
  • Abbiamo usato AWS CloudFormazione per la creazione e modifica di tutti i servizi core e analytics.
  • AWS Step Functions è stato utilizzato per orchestrare i processi Spark su Amazon EMR.
  • I lavori pianificati sono stati configurati in AWS Glue per il caricamento dei dati in Amazon Redshift in base alle esigenze aziendali.
  • Il monitoraggio dei servizi di analisi è stato effettuato utilizzando Amazon Cloud Watch metriche e il corretto dimensionamento delle istanze e della configurazione è stato raggiunto. Le prestazioni del lavoro Spark su Amazon EMR sono state analizzate utilizzando i log Spark nativi e l'interfaccia utente (UI) Spark.
  • Le policy del ciclo di vita sono state applicate al data lake per ottimizzare i costi di storage dei dati nel tempo.

Vantaggi di una moderna architettura dati

Una moderna architettura dati ci ha offerto i seguenti vantaggi:

• Scalabilità – Siamo passati da un'infrastruttura fissa all'infrastruttura minima richiesta, con configurazione scalabile su richiesta. Servizi come Amazon EMR e Amazon Redshift ci consentono di farlo con pochi clic.
• Agilità – Utilizziamo servizi gestiti appositamente creati invece di reinventare la ruota. L'automazione e il monitoraggio sono stati fattori chiave, che ci consentono di apportare modifiche rapidamente.
• serverless – Adozione di servizi serverless come Amazon S3, AWS Glue, Amazon Athena, AWS Step Functions e AWS Lambda supportaci quando la nostra attività ha picchi improvvisi con il lancio di nuovi film o eventi.
• Risparmio sui costi – Le nostre dimensioni di archiviazione sono state ridotte del 90%. La nostra spesa complessiva per l'analisi e il machine learning è stata ridotta dell'80%.

Conclusione

In questo post, ti abbiamo mostrato come una moderna architettura dei dati su AWS ha aiutato BMS a condividere facilmente i dati oltre i confini organizzativi. Ciò ha consentito a BMS di prendere decisioni con velocità e agilità su larga scala; garantire la conformità tramite accesso ai dati, sicurezza e governance unificati; e scalare i sistemi a basso costo senza compromettere le prestazioni. Lavorare con i team AWS e Minfy Technologies ha aiutato BMS a scegliere i servizi tecnologici corretti e completare la migrazione in quattro mesi. BMS ha raggiunto gli obiettivi di scalabilità e ottimizzazione dei costi con questa architettura aggiornata, che ha posto le basi per l'innovazione utilizzando database a grafo e migliorato i nostri progetti ML per migliorare l'esperienza del cliente.

Informazioni sugli autori

Mahesh Vandi Chalil è Chief Technology Officer di BookMyShow, la principale destinazione di intrattenimento in India. Mahesh ha oltre due decenni di esperienza globale, appassionato di creare prodotti scalabili che soddisfino i clienti mantenendo l'innovazione come obiettivo principale che motiva il suo team ad aspirare costantemente a questi. Mahesh investe le sue energie nel creare e nutrire la prossima generazione di leader tecnologici e imprenditori, sia all'interno che all'esterno dell'organizzazione. Un orgoglioso marito e padre di due figlie e gioca a cricket durante il suo tempo libero.

Priya Jatar è un Solutions Architect che lavora nel segmento Digital Native Business di AWS. Ha più di due decenni di esperienza IT, con esperienza nello sviluppo di applicazioni, database e analisi. È una builder a cui piace innovare con le nuove tecnologie per raggiungere gli obiettivi aziendali. Attualmente aiuta i clienti a migrare, modernizzare e innovare nel cloud. Nel tempo libero le piace dipingere e affinare le sue abilità di giardinaggio e cucina.

Vassal Shah è Senior Solutions Architect presso AWS con sede a Mumbai, in India. Ha più di nove anni di esperienza nel settore, inclusi ruoli di leadership nell'ingegneria dei prodotti, SRE e architettura cloud. Attualmente si concentra sul consentire alle grandi startup di semplificare le loro operazioni cloud e aiutarle a scalare sul cloud. È inoltre specializzato in casi d'uso di intelligenza artificiale e machine learning.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/big-data/how-bookmyshow-saved-80-in-costs-by-migrating-to-an-aws-modern-data-architecture/