none
Progetto Datawarehouse su Azure RRS feed

  • Domanda

  • Ciao Ragazzi, 

    Premetto che Azure lo conosco molto poco...

    Mi è stato chiesto di pensare ad una soluzione per una sorta progetto di piccolo datawarehouse.

    Lo scenario è questo: una azienda software ha realizzato un loro prodotto MES per la gestione della produzione.
    Questo software è utilizzato da diverse società indipendenti una dall'altra ed è installato su diverse loro filiali ( da 0-20 massimo ).
    Bene, ognuna di queste filiali dovrà fare il PUSH dei dati su una piattaforma centralizzata, la quale importerà i dati giornalmente li elaborerà e fornirà della reportistica.

    Scenari simili li ho sempre visti in contesti aziendali dove ogni server è dentro la stessa rete, qui invece lo scenario è diverso:

    La nuova piattaforma centralizzata è fuori dalla rete dei client, per questo motivo ( ancor di più ) , puntavo ad una architettura con Azure.

    Quello che ho pensato io inizialmente era questo:

    1. Server Web + Sql 2016 Ent , il tutto su una unica macchina Azure ( non prevedo molto carico di lavoro )
    2. Push dei dati in formato CVS o XML tramite FTP ( parcheggio i file in folder dedicati )
    3. Procedura ETL tramite SSIS oppure .net Console application ( import tramite BULK INSERT ed elaborazione )
    4. Procedura schedulata su SQL che elabora i dati e prepara delle tabelle che verranno lette flat dai report
    5. Database di Staging per truncate/import dei file ( backup Simple )
    6. Database di Fact nel quale verranno salvati i dati ricevuti ( backup Simple schedulato al termine del caricamento dei dati )
    7. Database di Report nel quale verranno contenuti i dati elaborati dalla procedura notturna ( backu Simple schedulato al termine dell'elaborazione dei dati )
    8. Reportistica con Reporting Services oppure applicazione web dedicata

    Bene, ora le domande per voi :-)

    1. Quali altre alternative potrei avere a livello di architettura?
    2. Riguardo al Push dei dati, che alternative di comunicazioni potrebbero essere pensate? ( tralasciamo orchestratori quali Biztalk e stiamo sul semplice )
    3. Stando su Azure, quali accorgimenti dovrei prendere?
    4. Supponendo che la strada sia questa, inizialmente si partirebbe con una società di test e con le sue 10 filiali.
      All'aggiungersi di una seconda società, mi conviene creare una nuova istanza SQL sulla macchina oppure creare solamente altri 3 database dedicati sempre sulla stessa istanza?
      Volevo capire nel caso quale fosse la strada migliore e se l'aggiunta di una nuova istanza SQL mi costasse altri soldi
      in termini di sottoscrizione...

    Grazie a tutti Ragazzi !

    venerdì 7 luglio 2017 09:05

Tutte le risposte

  • Provo a risponderti anche se ogni punto del tuo elenco avrebbe avuto bisogno di molte più informazioni ... anzi ogni punto sarebbe potuto diventare argomento di discussione....

    Il punto 1. con la frase "non prevedo molto carico di lavoro " già mette in crisi l'intero scenario futuro..., il rischio è di dover pagare (euro alla mano) eventuali errori di analisi, nelle architetture in cloud le risorse usate si pagano e sarebbe opportuno quantificarle per avere una idea dei costi ... es. se si tratta di una sola filiale o di venti (il caso 0 non lo prendiamo in considerazione :)

    Il punto 2. perché non usare delle get/post  per uplodare  i tuoi file xml/csv, nel punto 8. parli di applicazione web dedicata  a questo punto gli fai fare anche la gestione della ricezione, perché aggiungere un ftp server!

    Per il punto 3. perché usare un ETL  dato che le sorgenti dei dati che alimentano i db sono omogenee, generate solamente dal MES, eviterei layer intermedi .

    Punti 4./5./6./7. Perché avere i report il giorno dopo??? Perché non elaborarli contestualmente al loro arrivo? Mi sembra una soluzione datata avere i report il "day after"
    Qualora decidessi di avere una applicazione web che riceve i file xml potresti generare la reportistica più di frequente (es. ogni ora) e ogni filiale e il boss di turno potrebbero sapere come sta andando la giornata produttiva senza dover aspettare il giorno seguente ...

    Sulle domande per la prima, tralasciando i concorrenti principali di azure (amazon/google), potresti valutare anche un private cloud... alla seconda ho risposto sopra. Gli accorgimenti sono da prendere in relazione all tuo MES ma non sappiamo nulla (punto 1. dell'elenco). Per la quarta domanda, lo devi sapere tu...  se usare un pool elastico o dei db singoli, devi scegliere in relazione ai carichi e non in base ai costi (questo è quello che vorrebbero i gestori dei cloud, il rischio è avere una piattaforma non efficiente e dover pagare per farla correre!)

    Ciao e in bocca al lupo

    Gastone


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    martedì 11 luglio 2017 05:39
  • Ciao Gastone e grazie per il tuo riscontro, cercavo proprio di mettere in discussione la mia soluzione.

    Continuo a risponderti per punti:

    1) Non prevedo picchi di carico in quanto nello scenario più pesante, avrei 20 filiali con circa 10 utenti che chiedono dei report su tabelle precalcolate tramite elaborazioni schedulate.
    I report che chiedono sono mensili/annuali/settimanali , oppure visualizzazione di ordini singoli ( quindi dati letti con indice cluster ovunque bene o male )

    2) Vero, ci avevo pensato anche io, solo che passare i dati tramite post/get HTTP può dare problemi sul timeout della richiesta dalla parte del client o anche del server. Credo che il protocollo FTP sia più idoneo.
    Non conosco la dimensione di questi file di dati, ho presupposto di avere un set di 6 files dei fatti da circa 10-15mb e altri 10 files di master data da circa 1mb.
    Passare tutta questa mole di dati tramite http mi spaventa un po'.
    Ho optato per il file CSV in quanto lo trovo più snello di un file xml/json in quanto come saprai già, nei file xml/json i nomi dei campi sono ripetuti.

    3) Non capisco la tua risposta... Le installazioni MES dovranno fare un push dei dati su una piattaforma centralizzata, quindi dovrò procedere al caricamento di questi dati.

    4) Hai pienamente ragione, solo che il cliente ha accettato di avere i dati il giorno dopo ben consolidati.
    Volendo potrei anche schedulare elaborazioni più frequenti.

    Sul discorso Azure sono d'accordo con te, un private cloud è quello a cui pensavo.

    Sul discorso dei db singoli / istanze non so come funziona il licensing di Azure...

    Avere più istanze SQL sulla stessa macchina mi comporta dei costi aggiuntivi ?

    In tal caso partirei con DB dedicati sulla stessa istanza. Il cliente è medio/piccolo, sicuramente tenderà al risparmio.

    Grazie!

    Dario

    martedì 11 luglio 2017 07:12
  • Ciao Dario,

    il punto 1. (secondo me) riamane vago

    Per le post http sono cruciali la banda in upload e come viene fatto il codice lato client che esegue la post, ma  con le dimensioni dei file puoi stare tranquillo (16MB di file xml/json con 4mb in upload impiegherebbero 32").

    Se poi abiliti la compressione  potresti ridurre di circa ~100 volte questi tempi (es file xml di 160MB solita banda 4mbit tempo di upload circa 3 secondi ), i problemi iniziano se devi uplodare file 2GB ( anche su un  server web in rete locale...), insomma usare un ftp server è una ormai una soluzione desueta, avendo una applicazione web potresti anche attivare delle procedure alla ricezione file ... e ottenere dei report  "quasi in real time", ma a te servono settimanali...

    per i prezzi

    https://azure.microsoft.com/it-it/pricing/details/sql-database/

    https://www.google.it/?gws_rd=ssl#hl=it&source=hp&q=prezzi+azure+database&aq=f&aqi=g10&aql=&oq=&gs_rfai=&fp=9fca69c98b5d77d7

    Ciao Gas


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    martedì 11 luglio 2017 11:49
  • Ciao Gastone,

    Rispondo ancora per punti:

    1) Ho già avuto a che fare con datawharehouse molto più complessi con svariati utenti e con report che non poggiavano su tabelle precalcolate ma sulle tabelle dei fatti e posso dire di non aver mai riscontrato problemi di performance... Niente timeout, al massimo qualche report lento a caricare quello si.
    Qui la situazione dovrebbe essere più snella, meno tabelle e meno elaborazioni sui dati...
    Purtroppo non so bene quale sia la situazione reale in quanto non me l'hanno ancora fornita... 

    Riguardo la compressione dei POST sinceramente non avevo mai valutato questa possibilità.
    Mi sono subito indirizzato verso la strada sicura dell' FTP in quanto già utilizzata più volte.
    Sinceramente mi spaventa un po' questa strada dei POST con compressione in quanto il programma che deve effettuare il push dovrà essere installato su ogni client MES, quindi in caso di problemi ed eventuale aggiornamento del tool bisogna procedere alla distribuzione su tutti i client, cosa che vorrei evitare...

    Cmq approfondirò anche questa strada di sicuro ;-)

    mercoledì 12 luglio 2017 06:35
  • Il primo punto rimane carente sia quantitativamente che qualitativamente per la progettazione di una infrastruttura...

    Puoi spiegare come verrà implementata la push via ftp?  avviene autoamticamente e come? Usi un client ftp? La push ftp, avviene contestualmente alla creazione di un singolo ordine?

    SULLA POST. Senza complicarti la vita con una post compressa (lato server è getita da iis ed easy lato client c'è da lavorare) potresti creare una procedura che zippa il file xml/json/csv e fa la post, questo ridurrebbe le dimensioni di almeno 90 volte.

    Ciao


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    giovedì 13 luglio 2017 00:33
  • Ciao Gastone,

    Effettivamente si, non è ben chiara ancora la situazione.
    Ad oggi ho solo delle specifiche ridotte fatte da chi non ha mai realizzato architetture simili...
    Addirittura avevano abbozzato l'idea di utilizzare un database noSql per uno scenario simile, assurdo!

    La push su FTP verrà fatta da ogni installazione client del programma MES.
    Di sicuro non hanno un'orchestratore quale Biztalk e molto probabilmente si opterà per la realizzazione di console application .net schedulate utilizzando lo schedulatore di SQL SERVER oppure di windows...

    Come dici tu si potrebbe quindi creare una procedura che zippa i file csv ed esegua il push sul server FTP.
    Qui poi un'altra console application o pacchetto SSIS scompatta i file e li processa.
    Non ho mai lavorato con gli Zip su .Net, il framework già offre qualcosa di valido a livello di compressione oppure è meglio comprare librerie di terze parti ?

    La push FTP lato client pensavo di farla su base schedulata, magari ogni ora, idem la procedura che importa.

    Si potrebbe anche implementare un meccanismo che esegua il push su ogni ordine creato ma non usando un orchestratore, mi spaventa un po' sincronizzare il tutto...

    Si potrebbe anche pensare a push singoli su creazione di ordini tramite WebApi e Push giornaliero notturno che manda il mese YTD su FTP per essere sicuri che tutto sia allineato.

    Quello che proprio vorrei evitare sono i classici problemi di non ricezione del dato che comportano ricarichi manuali... Purtroppo in certe realtà sono scenari molto comuni: non è stato trasmesso un datafile e si procede a farlo salire manualmente...

    Ciao

    giovedì 13 luglio 2017 07:46
  • Ciao Gastone,

    Avrei bisogno ancora del tuo parere su come architetturare al meglio il db nel caso scegliessimo la soluzione WebApi/POST.

    Nel mio solito scenario di PUSH su FTP dei client ero solito concatenare i 10 datafiles ( tutti uniformi ) provenienti dai vari client e procedere quindi alla BULK INSERT in tabelle temporanee di STAGING per poi eseguire il merge dei dati sul database dei fatti.

    Ora supponendo di lavorare in ambiente WEBAPI/POST dove i client inviano tramite json l'ordine non appena viene consolidato, cosa mi conviene fare?

    Conviene creare N tabelle di staging per ogni singolo client che invia i dati oppure delle tabelle uniche per tutti i clienti che vengono svuotate ( truncate ) e ripopolate ad ogni call ?

    Mi spaventa un po' il dover gestire la concorrenza delle transazioni , non vorrei perdere qualche dato.

    Grazie!

    venerdì 14 luglio 2017 05:40
  • "Qui poi un'altra console application o pacchetto SSIS scompatta i file e li processa.
    Non ho mai lavorato con gli Zip su .Net, il framework già offre qualcosa di valido a livello di compressione oppure è meglio comprare librerie di terze parti ?"

    Non so con che linguaggio lavori, fare questa cosa in powershell che usa 7-zip e posta(http post) l'ordine zippato è abbatanza facile. Usare la compessione zip nativamente, da un linguaggio managed te la sconsiglio, dovresti avere su tutti i tuoi client MES il framework 4.5, nelle versioni precedenti la classe ZipFile System.IO.Compression non c'era... (o 7-zip o dotnet 4.5)

    "Ora supponendo di lavorare in ambiente WEBAPI/POST dove i client inviano tramite json l'ordine non appena viene consolidato, cosa mi conviene fare?"

    Lo staging lo puoi fare anche con i singoli file json ricevuti e salvati sul server, non è che devi avere per forza un database per fare lo staging. Dovrai aver cura che lo staging su file, non abbia collisioni nei nomi a questo punto non perderai nulla, poi con calma, una procedura andrà ad alimentare il db dei fatti alimentandosi dai file json salvati...

    Ciao


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere


    venerdì 14 luglio 2017 20:46