{"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\nIl problema<\/strong><\/h2>\n\n\n\n