Power BI: caricamento incrementale da sharepoint e merge tra tabella incrementale e tabella non incrementale

[Rippy_2007]

Buongiorno,
è da poco tempo che utilizzo Power BI e non sono molto ferrata con le logiche di caricamento incrementale.
Ho un problema con il caricamento incrementale da SharePoint.

Sto caricando due tabelle a partire dai file contenuti in uno SharePoint

Tabella dei Fatti "CALLS_ONLY": caricata a partire da file di questo tipo
calls_20231031.csv
calls_20231130.csv
calls_20231231.csv
e così via
Il caricamento è di tipo incrementale, si basa sulla data presa dal nome del file e ricarica solo l'ultimo mese (30 giorni).

Tabella dimensioni "AGENT_FINAL": caricata ogni volta tutta, a partire da un file Excel
Anagrafica_agenti.xlsx

Il caricamento delle due tabelle separate funziona senza problemi.
Il problema riguarda una terza tabella "CALLS_FINAL" che viene creata dal merge tra "CALLS_ONLY" e "AGENT_FINAL"

let
Source = Table.NestedJoin(CALLS_ONLY, {ID_AGENT"}, AGENT_FINAL, {"ID_AGENT"}, "AGENT_FINAL", JoinKind.LeftOuter),
#"Filtered Rows" = Table.SelectRows(Source, each [Date] > RangeStart and [Date] <= RangeEnd),
ecc....

Ho applicato le logiche del caricamento incrementale anche a quest'ultima tabella tabella.

Al 01/02/2024 viene aggiunto il file calls_20240131.csv. Supponiamo che al 01/02/2024 cambi il contenuto del file degli Agenti, perchè si è riscontrato un errore nel file precedente.
La tabella "AGENT_FINAL" cambia i dati. La tabella "CALL_FINAL", essendo incrementale, si aggiorna solo per il mese di gennaio, mentre le partizioni da ottobre a dicembre 2023 rimangono invariate con i vecchi agenti.
E' possibile fare in modo che la tabella "CALL_FINAL" si aggiorni tutta (in maniera non incrementale) e prenda i dati a partire dalla "CALLS_ONLY" salvata sulle partizioni precedenti e non solo dalla partizione che sto caricando in questo momento?
Non so se mi sono spiegata...
Vi ringrazio

[Andrea90]

@Rippy_2007

Perché ti serve quel merge tra le due tabelle? Se una è una tabella dei fatti e l’altra è quella dimensionale, perché non lasciarle distinte e caricarle nel modello e metterle in relazione con il campo chiave?

Andrea

Andrea

[Rippy_2007]

@Andrea90
Ciao ti ringrazio e cerco di spiegare perché ho unito le tabelle. Premetto che i dati sono molti sporchi e non c'è la possibilità di mettere le mani sul DB sorgente (non so nemmeno quale sia) ma solo di recuperali i dati dai file così come sono.

La chiave (che poi chiave non è ) della tabella "AGENT_FINAL" in realtà è MESE_AGENTID.
LE due tabelle di collegano per MESE_AGENTID. Non è detto che gli agenti siano presenti per tutti i mesi in cui hanno chiamate. A volte si le persone che gestiscono il sorgente si dimenticano di copiarli per il mese successivo.
Se per una chiamata di dicembre non si trova l'agente in anagrafica di dicembre, l'agente va cercato nei mesi precedenti e la chiamata va collegata all'anagrafica agente piu recente.
Ad esempio agente ABC è in "AGENT_FINAL" solo ad ottobre 2023, ma su CALL_ONLY ci sono chiamate di dicembre con quell'agente.
E' necessario collegare la chiamata all'anagrafica di ottobre.
Le chiamate di 202312_ABC andranno collegate all'utente 202310_ABC
Per fare ciò abbiamo creato un'altra tabella "AGENT_MAXMESE" dove per ogni utente è salvata la massima anagrafica.
Se si non trova nulla dal join con AGENT_FINAL , la tabella va in merge solo per AGENTID con AGENT_MAXMESE e collega la massima anagrafica.

Inoltre per ogni mese non è detto che l'agent id sia unico. Anagrafica_agenti.xlsx è un file che viene da una tabella senza chiavi.
Per uno stesso mese, lo stesso AGENT_ID può comparire due volte. Sono dati sporchi. Esempio
mese_userid= 202312_Cgat; User_name= Cane Gatto; Market: ITA
altra riga
mese_userid= 202312_Cgat; User_name= C. Gatto; Market: Francia
Sulla tabella delle chiamate c'è solo mese_userid, non è possibile sapere a quale riga di anagrafica è collegato
La richiesta dell'utente è di tenere le due anagrafiche, entrambe con le chiamate totali dell'agente, saranno loro (gli utenti ) poi ad analizzare il dato. Il numero di chiamate è duplicato...ma loro ne sono consapevoli. Ed è quello che chiedono.

Se tengo CALL e AGENT separate poi da Power BI non sono in grado di collegare l'utente all'ultimo mese in cui è disponibile la sua anagrafica.
E poi rimarrebbe comunque una relazione molti a molti, che non saprei come gestire.

Da qui la mia domanda se è possibile fare il merge tra una tabella incrementale e una non incrementale.

Come dicevo non sono pratica di Power BI, vengo da 10 anni di Business Object collegato a un Datawarehouse, dove i tabelle dei fatti, dimensioni, erano tutti dati puliti.


Grazie ancora per il supporto

[Andrea90]

@Rippy_2007

Se tu chiedi l’incremental refresh significa che vuoi lavorare sull’ultima porzione di dati che ti interessa (infatti avrai impostato due parametri che utilizzi per filtrare a monte il tuo dataset). La vecchia porzione ti rimarrà tale e quale a come l’avevi lasciata.

Se tu invece vuoi che il merge abbia effetto anche sulle righe precedenti (quelle inizialmente escluse) è chiaro che internamente dovrai andare a rileggere tutti i valori, rendendo dunque inutile il refresh incrementale che avevi impostato.

Andrea

[Rippy_2007]

@Andrea90
Ti ringrazio, è quello che immaginavo, ma non avevo la certezza.
Un collega, anche lui zero esperto in Power BI, mi ha suggerito di provare con due pbix.
Creare la tabella incrementale con un pbix a parte e poi importare il dataset ottenuto in un secondo pbix, e da li unire alla tabella non incrementale
E' una soluzione perseguibile?
Grazie ancora

[Andrea90]

@Rippy_2007

Di che mole di dati stiamo parlando? Siete partiti subito con un refresh incrementale oppure prima avete lavorato in modalità standard e poi avete provato ad implementare l’incrementale?

Considera che il refresh incrementale lavora bene quando la query che estrapola i dati lavora con una fonte che permette il query folding … e una cartella sharepoint non è uno di questi casi… avreste dovuto vedere un alert quando avete impostato il refresh la prima volta.

Andrea

[Rippy_2007]

@Andrea90
Ci è stato richiesto in partenza l'incrementale perché vengono mantenuti nello SharePoint non più di 3 mesi. (a fine fine gennaio, verrà eliminato il file csv di ottobre). Il csv di ogni mese contiene intorno alle 150.000 righe.
Abbiamo sviluppato il report ad inizio dicembre. Abbiamo caricato ottobre e novembre insieme come primo caricamento e poi il mese di dicembre con l'incrementale.
Esatto il messaggio di alert è comparso. Abbiamo provato ad andare avanti e ha funzionato. Non so nei prossimo cosa succeda...
Perdona la mia ignoranza cosa è il query folding?

Grazie ancora

[Andrea90]

@Rippy_2007

Il query folding è una metodologia di estrazione dati che Power Query riesce ad applicare solo su certe tipologie di dataset.

Praticamente quando la fonte lo permette Power Query è in grado di tradurre l’interrogazione che stai eseguendo direttamente nel linguaggio del db sorgente, rendendo l’estrazione dati nettamente piu performante. Infatti la prassi prevede che più l’utente è in grado di accorpare step di query in modalità folding e più l’estrazione dati risulterà ottimale.

Come lèggerai dell’articolo che ti allego, il query folding è richiesto per l’incremental refresh. Perché se non è possibile applicare il folding (e ripeto sharepoint folder non è supportato dal query folding) non è detto che power bi non sia in realtà costretto ad estrapolare comunque l’intero dataset (rendendo praticamente inutile il suo utilizzo).

https://learn.microsoft.com/en-us/power ... ry-folding

Andrea

[Rippy_2007]

@Andrea90
Grazie ancora, ho capito. Forse sarebbe il caso che lasciassero tutti i file nello SharePoint e si facesse sempre un caricamento standard

[Andrea90]

@Rippy_2007

Proverei a vedere se con un caricamento normale la cosa si riesce a gestire.

Se i tempi diventassero lunghi si può sempre provare ad utilizzare python all’interno di power query per eseguire la lettura dei files da cartella sharepoint.

Magari è in grado di migliorare le performance di lettura del dato.

Andrea