Condividi tramite


Consumo di database KQL e eventhouse

Gli eventhouse e i database KQL operano su un motore Kusto completamente gestito. Con un database Eventhouse o KQL, è possibile prevedere un calcolo disponibile per l'analisi entro 5-10 secondi. Le risorse di calcolo aumentano con le esigenze di analisi dei dati. Questo articolo mostra la creazione di report sull'utilizzo del calcolo dei database KQL in Microsoft Fabric, tra cui KustoUpTime e archiviazione.

Quando si usa una capacità di Fabric, gli addebiti per l'utilizzo vengono visualizzati nel portale di Azure nella sottoscrizione in Gestione costi Microsoft. Per comprendere la fatturazione di Fabric, vedere Informazioni sulla fattura di Azure per una capacità di Fabric.

Importante

Modifiche alla frequenza di utilizzo del carico di lavoro di Microsoft Fabric

Le tariffe a consumo sono soggette a variazioni in qualsiasi momento. Microsoft compirà sforzi ragionevoli per fornire comunicazioni tramite posta elettronica o tramite notifica nel prodotto. Le modifiche saranno valide alla data indicata nelle note sulla versione di Microsoft o nel Blog di Microsoft Fabric. Se una modifica a una tariffa di consumo del carico di lavoro di Microsoft Fabric aumenta materialmente le unità di capacità (CU) necessarie per usare un determinato carico di lavoro, i clienti possono usare le opzioni di annullamento disponibili per il metodo di pagamento scelto.

Capacità

In base alla capacità di SKU acquistato in Fabric, si ha diritto a un set di unità di capacità (CU) condivise in tutti i carichi di lavoro di Fabric. Per maggiori informazioni sulle licenze supportate, vedere Licenze di Microsoft Fabric.

La capacità è un set dedicato di risorse disponibile per l'uso in un momento specifico. La capacità definisce l'abilità di una risorsa di eseguire un'attività o di produrre output. Le diverse risorse usano CU in momenti diversi. La quantità di capacità usata da un database KQL si basa sull'operazione KustoUpTime.

KustoUpTime

KustoUpTime per un eventhouse è il numero di secondi in cui l’eventhouse è attivo in relazione al numero di core virtuali usati dall’eventhouse. Un meccanismo di scalabilità automatica viene usato per determinare le dimensioni dell’eventhouse. Questo meccanismo garantisce l'ottimizzazione dei costi e delle prestazioni in base al modello di utilizzo. Un eventhouse con più database KQL collegati mostra solo KustoUpTime per l'elemento eventhouse. Non verrà visualizzato l'utilizzo per l'elemento secondario del database KQL.

Ad esempio, un eventhouse con 4 database KQL che usano 4 core virtuali attivi per 30 secondi userà 120 secondi di unità di capacità.

KustoUpTime per un database KQL è il numero di secondi in cui il database KQL è attivo in relazione al numero di core virtuali usati dal database. Viene usato un meccanismo di scalabilità automatica per determinare le dimensioni del database KQL. Questo meccanismo garantisce l'ottimizzazione dei costi e delle prestazioni in base al modello di utilizzo.

Ad esempio, un database che usa 4 core virtuali attivi per 30 secondi userà 120 secondi di unità di capacità.

Nota

Se il database KQL è un sottoinsieme di un eventhouse, KustoUpTime viene riflesso nell'elemento eventhouse e l'elemento del database non viene visualizzato nell'elenco.

Monitorare KustoUpTime

È possibile monitorare KustoUpTime con l'app Microsoft Fabric Capacity Metric. Informazioni su come comprendere la pagina di calcolo dell'app Metriche in Comprendere la pagina di calcolo delle app per le metriche. Questo esempio mostra informazioni specifiche per il monitoraggio di KustoUpTime.

Nota

È necessario essere un amministratore della capacità per monitorare l'utilizzo della capacità. Per maggiori informazioni, vedere Informazioni sui ruoli di amministratore di Microsoft Fabric.

L'immagine seguente mostra una pagina di calcolo di esempio dal monitoraggio della capacità nell'app Fabric Capacity Metric:

Screenshot del tempo di attività nell'app Microsoft Fabric Capacity Metric.

Ecco alcune informazioni dettagliate che è possibile ottenere dall'esempio:

  • La capacità esaminata è denominata rtafielddemo.
  • Le unità di capacità per il giorno selezionato sono state usate da una singola area di lavoro denominata RTA Field Demo.
  • La visualizzazione Items è stata filtrata per visualizzare sia Eventhouse che KQL Database.
  • La selezione di un singolo elemento, ad esempio un elemento eventhouse, suddivide l'utilizzo del CU in base alle operazioni.
  • Il grafico di utilizzo, sul lato destro dell'app, mostra quasi il 100% di utilizzo CU nel tempo. Questo utilizzo elevato può spiegare la limitazione delle query riscontrata dagli utenti e indica la necessità di aumentare le unità di capacità.

Fatturazione Archivio

L'archiviazione viene fatturata separatamente dalle unità di capacità Fabric o Power BI Premium. I dati inseriti in un database KQL vengono archiviati in due livelli di archiviazione: OneLake Cache Storage e OneLake Standard Storage.

  • L’Archiviazione di OneLake Cache è un'archiviazione premium usata per fornire i tempi di risposta alle query più veloci. Quando si impostano i criteri della cache, si influisce su questo livello di archiviazione. Ad esempio, se in genere si esegue una query su sette giorni, è possibile impostare la conservazione della cache su sette giorni per ottenere prestazioni ottimali. Questo livello di archiviazione è paragonabile al livello Premium di Azure ADLS (Azure Data Lake Storage).

Nota

L'abilitazione del consumo minimo significa che non vengono addebitati costi per OneLake Cahce Storage. Quando viene impostata la capacità minima, l’eventhouse è sempre attivo, con conseguente aumento del 100% di KustoUpTime.

  • L’archiviazione Standard di OneLake è una risorsa di archiviazione standard usata per salvare in modo permanente e archiviare tutti i dati su cui è possibile eseguire query. Quando si impostano i criteri di conservazione, si influisce su questo livello di archiviazione. Ad esempio, se è necessario mantenere 365 giorni di dati su cui è possibile eseguire query, è possibile impostare la conservazione su 365 giorni. Questo livello di archiviazione è paragonabile al livello ad accesso frequente di Azure ADLS (Azure Data Lake Storage).

Monitorare l'archiviazione OneLake

L'app Fabric Capacity Metric di Microsoft consente a qualsiasi amministratore della capacità di monitorare l’archiviazione di OneLake. Informazioni su come comprendere la pagina di archiviazione app Metriche nella pagina Informazioni sull'archiviazione app metriche.

L'immagine seguente mostra una pagina di archiviazione di esempio dal monitoraggio di un database KQL nell'app Fabric Capacity Metric:

Screenshot dell'app Fabric capacity metrics con i dati di Intelligence in tempo reale.