Connessione live? O connessione extract (in-memory)? Quando usare l’una e quando l’altra?
Diciamo che non c’è una risposta assoluta, bisogna considerare tutta una serie di questioni che viste nell’insieme faranno propendere per un metodo piuttosto che per l’altro.
Ma iniziamo a capire cosa sono questi due differenti tipi di connessione.
- Connessione live: come dice il nome stesso, la connessione è live, Tableau comunica (legge i dati, lancia query) con la fonte dei dati in modo diretto. Non servono refresh verso il datasource, tutte le volte che apriamo un workbook, i dati saranno i più aggiornati.
- Connessione extract: viene creata una tabella in formato .tde (tableau data extract) estremamente performante e Tableau comunica (legge i dati, lancia query) con l’estratto, che sarà uno snapshot, una foto statica del database dell’istante in cui l’extract è stato creato. Servono dei refresh affinché l’extract vada ad acquisire i dati aggiornati dal datasource originario.
Quindi la connessione live è una connessione diretta, extract è una connessione che prevede degli step intermedi (creazione dell’estratto e refresh nel tempo). Si potrebbe pensare che la connessione live sia quindi migliore (meno step=più velocità), MA potrebbero esserci dei casi in cui una connessione live:
- È TROPPO LENTA: ad esempio a causa di una rete aziendale lenta, creare un estratto in locale ci permette di saltare questo problema. Oppure la complessità delle query create (filtri, calcoli, aggregazioni, ecc, ecc, ecc…) potrebbe portare a rallentamenti che si eviterebbero con l’utilizzo di un estratto, che è una tabella indicizzata ottimizzata per le query.
- È IMPOSSIBILE: ad esempio pensiamo ad una serie di file excel, che a seguito di una union vanno oltre al limite di 1 milione di record. Possiamo creare un estratto del tabellone unito che potrà contenere quante righe vogliamo, superando la limitazione del milione di righe di Excel e dei suoi driver. Oppure se avessimo ad esempio la necessità di lavorare offline, l’estratto di Tableau è portable.
- DA’ ACCESSO A TROPPI DATI: supponiamo di dover far leggere il nostro workbook, connesso live al nostro MySQL aziendale, ad una persona esterna che non ha un’utenza per accedere al MySQL, e creargli un’utenza potrebbe significare dargli accesso a tutti i nostri dati. Oppure quando scrivete al nostro supporto e vi chiediamo un packaged workbook per poter risolvere i vostri ticket, ma magari i dati che state usando contengono dati sensibili. Con l’ultilizzo di filtri e nascondendo le colonne che non vogliamo mostrare, è possibile creare degli extract che altro non sono che delle basi di dati che mostrano esattamente quello che vogliamo far vedere, possiamo controllare la sicurezza dei dati.
Analogamente ci sono dei casi in cui una connessione extract:
- È IMPOSSIBILE: ad esempio se come fonte di dato abbiamo un cubo OLAP, il cubo è già un estratto di suo che non si può estrarre ulteriormente, siamo obbligati a usare una connessione live.
- È TROPPO STATICA: gli extract sono delle view che riportano i dati di un determinato momento, se ci arrivano dati aggiornati ogni minuto, potrebbe essere sconveniente dover aggiornare, fare un refresh dell’extract, ogni minuto (la creazione dell’extract e il refresh sono due task che richiedono del tempo e risorse, sia in caso di extract locali manuali che salvati su tableau server e schedulati in automatico).
- È TROPPO ELABORATA: riagganciandoci all’argomento del punto precedente, pensiamo ad un database big data, con tabelle che hanno dimensioni in petabyte… la creazione di un extract del genere potrebbe potrebbe richiedere tempo (e task server che si accavallano e restano in attesa) e spazio e risultare difficoltosa.
