{"id":5186,"date":"2022-11-25T14:08:22","date_gmt":"2022-11-25T13:08:22","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5186"},"modified":"2022-11-24T17:06:11","modified_gmt":"2022-11-24T16:06:11","slug":"come-creare-un-data-lake-datamart-su-amazon-s3-con-pre-ingestion-flows-ed-etl","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-creare-un-data-lake-datamart-su-amazon-s3-con-pre-ingestion-flows-ed-etl\/","title":{"rendered":"Come Creare un Data lake\/DataMart su Amazon S3 con pre-ingestion flows ed ETL"},"content":{"rendered":"\n
I Big Data hanno acquisito importanza a partire da met\u00e0 degli anni 2000 con lo sviluppo della metodologia MapReduce in Google e hanno continuato a crescere a un ritmo vertiginoso grazie allo sviluppo di strumenti sempre migliori: Apache Hadoop, Spark, Pandas sono stati tutti sviluppati in questo lasso di tempo. <\/p>\n\n\n\n
Parallelamente, sempre pi\u00f9 Cloud provider e service integrator hanno iniziato a offrire soluzioni gestite di Big Data\/Data Lake (da Cloudera ad AWS Glue) per soddisfare la crescente domanda di aziende sempre pi\u00f9 desiderose di analizzare i propri dati per trarne valore.<\/p>\n\n\n\n
Nel frattempo il termine “Big Data” ha smesso di essere una buzzword ed \u00e8 stato soppiantato in questo ruolo da parole pi\u00f9 nuove e pi\u00f9 accattivanti come Blockchain e Quantum computing, ma questo non ha diminuito la necessit\u00e0 delle aziende di sfruttare i dati per indirizzare meglio i propri clienti, ottimizzare il proprio prodotto e perfezionare i propri processi.<\/p>\n\n\n\n
In questo breve articolo descriveremo una delle soluzioni che abbiamo messo a terra per rispondere a questa necessit\u00e0. Vedremo come creare un Data Lake dinamico multi-account decentralizzato su AWS, sfruttando Glue, Athena e Redshift<\/strong>.<\/p>\n\n\n\n Solitamente i data lake sono repository di dati non strutturati<\/strong> che raccolgono dati di input da fonti di dati eterogenee come database SQL legacy, database di documenti (ad esempio MongoDB), database di tipo chiave-valore (ad esempio Cassandra) e file raw da varie fonti (server SFTP, Samba, Object storage). <\/p>\n\n\n\n In questo caso il nostro obiettivo \u00e8 quello di suddividere il database in modo che ogni progetto interno nella struttura aziendale del cliente possa accedere solo al proprio silo di dati segregato. Per farlo, imposteremo anche le operazioni ETL necessarie. Un numero selezionato di utenti dell’amministrazione generale sar\u00e0 in grado di accedere ai dati da diversi silos per leggerli e aggregarli per l’analisi a livello aziendale, la business intelligence e il reporting generale. <\/p>\n\n\n\n Per soddisfare questi requisiti e garantire la massima segregazione possibile tra diversi silos, abbiamo deciso di suddividere i progetti in diversi account AWS utilizzando AWS Organizations. La struttura degli account \u00e8 rappresentata nel diagramma sottostante:<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Per aggiungere valore alla soluzione, un altro requisito era quello di poter creare credenziali per terze parti per inviare i dati direttamente al data lake sia con API, che con SFTP. <\/p>\n\n\n\n Ci\u00f2 significa che ogni account conterr\u00e0 non solo il bucket S3 con i dati e i job di Glue\/Step Functions necessari per trasformarli, diversi per ogni silo, ma anche un’applicazione web di amministrazione per gestire l’accesso di terze parti tramite credenziali IAM temporanee e un frontend distribuito su Cloudfront per fornire una semplice interfaccia agli utenti per caricare i dati direttamente su S3.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Se vi state chiedendo come abbiamo gestito la parte SFTP, ecco la soluzione: abbiamo attivato il servizio AWS Transfer Family per SFTP<\/a> con una Lambda personalizzata per autenticare gli utenti con le stesse credenziali IAM utilizzate per l’accesso Web app.<\/p>\n\n\n\n Pertanto, sviluppando un’applicazione Web relativamente semplice, siamo riusciti a creare un’interfaccia completamente serverless per i nostri bucket S3 in modo che gli i membri dell’azienda possano creare credenziali temporanee per consentire agli utenti esterni di accedere a una dropzone S3 dove saranno in grado di caricare nuovi file. <\/p>\n\n\n\n Prima di proseguire, soffermiamoci su come sia possibile far funzionare Lambda(s) Backend del diagramma sopra senza un database. La risposta \u00e8 molto semplice: lo stato della nostra vending machine di credenziali \u00e8 una raccolta di risorse AWS (utenti , Roles, Buckets) che creiamo direttamente con cloudformation e di cui conserviamo lo stato direttamente nel template!<\/p>\n\n\n\n Utilizzando pipeline tra account, tutti i componenti dell’infrastruttura e dell’applicazione possono essere distribuiti automaticamente su ciascun account in modalit\u00e0 self-service: quando viene creato un account nell’apposita AWS Organization Unit, viene creato un set di stack CloudFormation nell’account che distribuisce i componenti dell’infrastruttura di base e una codepipeline AWS per recuperare il codice dell’applicazione dall’account Master Datalake e distribuirlo nell’account Silo di destinazione. <\/p>\n\n\n\nIl problema<\/strong><\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n
<\/figure><\/div>\n\n\n