Eseguire il debug delle query mediante istruzioni SELECT INTO

Nell'elaborazione dei dati in tempo reale può essere utile conoscere l'aspetto dei dati nel mezzo di una query. Poiché gli input o i passaggi di un processo di Analisi di flusso di Azure possono essere letti più volte, è possibile scrivere istruzioni SELECT INTO aggiuntive. In questo modo vengono generati dati intermedi nella risorsa di archiviazione che consentono di controllare la correttezza dei dati, esattamente come fanno le variabili di controllo quando si esegue il debug di un programma.

Usare SELECT INTO per controllare il flusso dei dati

La seguente query di esempio in un processo di Analisi di flusso di Azure ha un input di flusso, due input di dati di riferimento e un output in Archiviazione tabelle di Azure. La query unisce i dati dell'hub eventi e di due BLOB di riferimento per ottenere le informazioni di nome e categoria:

Esempio di query SELECT INTO

Si noti che il processo è in esecuzione ma non vengono generati eventi nell'output. Nel riquadro Monitoraggio, illustrato di seguito, è possibile vedere che l'input produce dati, ma non sa quale passaggio del JOIN ha causato l'eliminazione di tutti gli eventi.

Riquadro Monitoraggio

In questa situazione è possibile aggiungere alcune istruzioni SELECT INTO aggiuntive per "registrare" i risultati intermedi di JOIN e i dati che vengono letti dall'input.

In questo esempio sono stati aggiunti due nuovi "output temporanei". Può trattarsi di qualsiasi sink desiderato. Qui si usa Archiviazione di Azure come esempio:

Aggiunta di ulteriori istruzioni SELECT INTO

È quindi possibile riscrivere la query come segue:

Query SELECT INTO riscritta

Ora avviare nuovamente il processo e lasciarlo in esecuzione per alcuni minuti. Quindi eseguire una query su temp1 e temp2 con Visual Studio Cloud Explorer per generare le tabelle seguenti:

temp1 table SELECT INTO temp1 table

temp2 table SELECT INTO temp2 table

Come si può vedere, temp1 e temp2 hanno entrambe dati e la colonna del nome viene popolata in modo corretto in temp2. Tuttavia, poiché non sono ancora presenti dati nell'output, c'è qualcosa di sbagliato:

Tabella SELECT INTO output1 senza dati

Tramite il campionamento dei dati, è possibile essere quasi certi che il problema riguardi il secondo JOIN. È possibile scaricare i dati di riferimento dal BLOB e dare un'occhiata:

Tabella SELECT INTO riferimento

Come si può notare, il formato del GUID in questi dati di riferimento è diverso dal formato della colonna [da] di temp2. Ecco perché i dati non arrivavano in output1 come previsto.

È possibile correggere il formato dei dati, caricarlo nel BLOB di riferimento e riprovare:

Tabella SELECT INTO temporanea

Questa volta i dati nell'output vengono formattati e popolati come previsto.

Tabella SELECT INTO finale

Ottenere aiuto

Per ulteriore assistenza, provare il Forum di Analisi dei flussi di Azure.

Passaggi successivi