Comment les données sont traitées dans des hubs FinOps

Les hubs FinOps effectuent de nombreuses activités de traitement des données pour nettoyer, normaliser et optimiser les données. Les sections suivantes montrent comment les données circulent de Cost Management dans une instance hub.

Configuration de la portée

Une étendue est un niveau au sein de la hiérarchie des ressources et des comptes cloud qui fournit l'accès aux données relatives aux coûts, à l'utilisation et au carbone. Pour les hubs FinOps, nous vous recommandons généralement d’utiliser des comptes de facturation Accord Entreprise (EA) ou des profils de facturation Contrat client Microsoft (MCA), mais toute étendue cloud est suffisante pour l’analyse de base. La principale préoccupation est de savoir si les données de prix et de réservation sont nécessaires, car Cost Management expose uniquement les données des comptes de facturation EA et des profils de facturation MCA.

Les hubs FinOps prennent en charge la configuration des étendues en configurant manuellement les exportations Cost Management ou en accordant aux hubs FinOps l’accès pour gérer les étendues en votre nom. Les étendues gérées sont configurées dans le fichier config/settings.json du stockage hub. Les informations décrivent ce qui se passe lorsqu’une nouvelle étendue managée est ajoutée à ce fichier. Les étendues non managées, où les exportations Cost Management sont configurées manuellement, ne nécessitent pas d’autres configurations.

Le déclencheur config_SettingsUpdated s’exécute lorsque le fichier settings.json est mis à jour.
Le pipeline config_ConfigureExports crée de nouvelles exportations pour toutes les nouvelles étendues ajoutées.

Ingestion des données

Le diagramme suivant illustre le processus d’ingestion de données de bout en bout dans les hubs FinOps :

(Facultatif) Si vous utilisez des exportations gérées :
1. Les déclencheurs config_DailySchedule et config_MonthlySchedule s’exécutent selon leurs planifications respectives pour lancer l’ingestion des données.
2. Le pipeline config_StartExportProcess récupère les exportations applicables pour le calendrier en cours.
3. Le pipeline config_RunExportJobs exécute chacune des exportations sélectionnées.
Cost Management exporte les détails des coûts bruts vers le conteneur msexports . Plus d’informations
Le pipeline msexports_ExecuteETL met en file d’attente le pipeline d'extraction, de transformation et de chargement (ETL) lorsque des fichiers sont ajoutés au conteneur msexports.
Le pipeline msexports_ETL_ingestion transforme les données au format parquet et les déplace vers le conteneur d'ingestion à l'aide d'une structure de fichier évolutive. Plus d’informations
(Facultatif) Si vous utilisez Azure Data Explorer :
1. Le pipeline ingestion_ExecuteETL met dans la file d'attente le pipeline d’ingestion de l’Explorateur de Données lorsque des fichiers manifest.json sont ajoutés au conteneur d’ingestion.
  - Si vous ingérez des jeux de données personnalisés en dehors des exportations Cost Management, créez un fichier manifest.json vide dans le dossier d’ingestion cible une fois tous les autres fichiers prêts (n’ajoutez pas ce fichier lorsque les fichiers sont toujours chargés). Le fichier manifest.json n’est pas analysé et peut être vide. Le seul objectif est d’indiquer que tous les fichiers pour cette tâche d’ingestion ont été ajoutés.
2. Le pipeline ingestion_ETL_dataExplorer ingère des données dans la {dataset}_raw table de l’Explorateur de données.
  - Le nom du jeu de données est le premier dossier du conteneur d’ingestion.
  - Toutes les tables brutes se trouvent dans la base de données d’ingestion dans l’Explorateur de données.
3. Lorsque les données sont ingérées dans des tables brutes dans l’Explorateur de données, une stratégie de mise à jour copie les données dans la table correspondante {dataset}_final_v1_0 à l’aide de la {dataset}_transform_v1_0() fonction pour normaliser toutes les données à aligner sur FOCUS 1.0.
4. Après l’ingestion, le pipeline ingestion_ETL_dataExplorer effectue un nettoyage, y compris la purge des données dans la table finale qui dépasse la période de rétention des données.
  - À compter de la version 0.7, l’Explorateur de données applique la rétention des données dans les tables brutes, tandis que la rétention des données dans les tables finales est appliquée par le pipeline d’ingestion. Si l’ingestion des données s’arrête, les données historiques ne sont pas purgées.
  - La rétention des données peut être configurée pendant le déploiement du modèle ou manuellement dans le fichier config/settings.json dans le stockage.
Rapports et autres outils tels que Power BI lisent des données à partir de l’Explorateur de données ou du conteneur d’ingestion .
- Les données de l’Explorateur de données peuvent être lues à partir de la base de données Hub .
  - Utilisez la {dataset}() fonction pour utiliser le schéma le plus récent.
    - Cette fonction est utile pour exploration rapide, mais peut introduire des modifications disruptives à mesure que l’instance du hub FinOps est mise à jour.
  - Utilisez la {dataset}_v1_0() fonction pour utiliser le schéma FOCUS 1.0.
    - Les schémas de fonction avec version ne doivent pas changer au fil du temps, mais les valeurs peuvent changer si la source de données modifie ces valeurs.
  - Évitez d’utiliser la base de données d’ingestion pour les requêtes. Bien que cela ne soit pas explicitement interdit, la base de données d'ingestion doit être considérée comme une zone interne de préparation et de préparation des données.
- Les données dans le stockage peuvent être lues à partir de ingestion/<dataset>/<year>/<month>/<scope-path>.
  - Les données doivent être lues de manière récursive à partir du dossier du jeu de données et éventuellement inclure davantage si nécessaire pour la spécificité.
  - Les fichiers de chaque dossier de jeu de données peuvent avoir des schémas différents en fonction de la source de données et du type de compte. Préparez-vous à transformer des données en cas d’ingestion dans d’autres systèmes, comme Microsoft Fabric.
  - La lecture à partir du stockage est déconseillée en raison de raisons de performances. L’Explorateur de données est recommandé lors de la création de rapports sur plus de 1 million de dollars de coûts.

À propos de l'ingestion de Data Explorer

Lorsque les données sont ingérées dans l’Explorateur de données, les {dataset}_transform_v1_0() fonctions appliquent des règles de transformation dans la base de données d’ingestion . Chaque jeu de données a un ensemble différent de règles de transformation couvertes dans les sections suivantes.

Pour obtenir la liste des modifications demandées, des idées à prendre en considération et ouvrir des questions sur les jeux de données Cost Management sous-jacents, consultez le problème #1111. Laissez des commentaires sur ce problème si vous trouvez des occasions de répondre à des préoccupations ou de faire part de votre soutien à l’un des problèmes spécifiques.

Transformations des données de coût

Jeux de données pris en charge :

Microsoft FocusCost : 1.0r2, 1.0, 1.0-preview(v1)

Les jeux de données suivants ont été pris en charge dans la conception, mais ne sont pas pris en charge en mode natif. Pour ingérer ces ensembles de données, créez un pipeline de données (ou un processus externe) qui pousse les fichiers Parquet dans le dossier ingestion/Costs/yyyy/mm/{scope-path} de stockage. Le {scope-path} peut s'agir de n'importe quel chemin unique, comme aws/123 ou gcp/projects/foo. La seule exigence est de s’assurer que chaque étendue se trouve dans un dossier distinct. Après avoir copié du contenu externe, créez également un fichier manifest.json pour déclencher l’ingestion de l’Explorateur de données.

Amazon Web Services (AWS) FOCUS 1.0
Google Cloud Platform (GCP) FOCUS 1.0
Oracle Cloud Infrastructure (OCI) FOCUS 1.0

Transformations :

v0.7+ :
- Alignez les noms de colonnes de l'aperçu FOCUS 1.0 sur FOCUS 1.0.
  - Inclut la conversion de focus 1.0 en préversion vers la version 1.0.
- Ajoutez x_IngestionTime pour indiquer quand la ligne a été mise à jour pour la dernière fois.
- Ajoutez x_SourceChanges pour identifier quand les données d’une ligne sont modifiées par les hubs.
- Mettez à jour ProviderName et PublisherName quand aucun paramètre n’est spécifié.
- Ajoutez x_SourceName, x_SourceProvider, x_SourceTypeet x_SourceVersion pour identifier le jeu de données ingéré d’origine.
- Remplissez les valeurs manquantes ListCost, ListUnitPrice, ContractedCost et ContractedUnitPrice en fonction de la grille tarifaire.
  - Ce processus exige que les prix soient exportés avant le coût. Les prix sont manquants pour le premier jour du mois si les coûts sont ingérés avant que les prix ne soient disponibles pour le mois.
- Correction de ContractedCost en cas de configuration incorrecte en raison d'un bug dans Microsoft Cost Management.
- Minuscules ResourceName et x_ResourceGroupName pour résoudre les problèmes de cohérence de casse qui interrompent le regroupement et le filtrage.
- Ajoutez x_BillingAccountAgreement en fonction du type de compte.
v0.8+ :
- Corrigez les ResourceType valeurs qui utilisent des ID de type de ressource interne (par exemple, microsoft.compute/virtualmachines).
v0.9+ :
- Minuscules de BillingAccountId pour garantir que la jointure des prix correspond à toutes les lignes.
- Minuscules de CommitmentDiscountId pour éviter les lignes en double lors de l'agrégation des données.
- Ajoutez de nouvelles x_SourceChanges vérifications pour ListCostLessThanContractedCost et ContractedCostLessThanEffectiveCost.
v0.10+ :
- Corrigez x_EffectiveUnitPrice lorsqu'il est calculé et qu'il existe une erreur d'arrondi comparée à x_BilledUnitPrice ou ContractedUnitPrice.
- Calculez PricingQuantity et ConsumeQuantity en cas de coût, mais pas de quantité.
- Définissez ContractedCost sur EffectiveCost lorsque ce n'est pas défini.
- Définissez ListCost sur ContractedCost lorsque ce n'est pas défini.
- Supprimez « -2 » dans la x_InvoiceSectionId colonne.
- Supprimez « Non attribué » dans la x_InvoiceSectionName colonne.
- Corrigé x_EffectiveUnitPrice lorsqu'il est calculé et présente une erreur d'arrondi.
- Ajouter de nouvelles x_SourceChanges vérifications pour MissingConsumedQuantity, MissingPricingQuantityet XEffectiveUnitPriceRoundingError.
v0.11+ :
- Remplacez BillingPeriodStart et BillingPeriodEnd pour être le premier jour du mois.

Transformations de données de prix

Jeux de données pris en charge :

Microsoft PriceSheet : 2023-05-01 (EA et MCA)

Transformations :

v0.7+
- Aligner les noms de colonnes sur FOCUS 1.0.
  - Inclut l'application de la cohérence des noms de colonnes EA et MCA.
  - Ne modifie pas les valeurs sous-jacentes, qui peuvent différer entre EA et MCA.
- Convertissez la x_SkuTerm durée ISO en nombre spécifique de mois en fonction des détails du coût.
  - Nous attendons que FOCUS détermine comment définir des durées avant de modifier cette valeur en ISO ou dans un autre format.
- Remplacez ContractedUnitPrice pour l'utilisation du plan d'épargne par l'équivalent à la requête.
- Définissez ListUnitPrice pour l'utilisation du plan d'épargne sur l'équivalent à la requête.
- Ajoutez SkuPriceIdv2 comme une valeur SkuPriceId plus précise que ce qui se trouve actuellement dans les détails du coût.
- Ajoutez x_IngestionTime pour indiquer quand la ligne a été mise à jour pour la dernière fois.
- Ajoutez x_CommitmentDiscountSpendEligibility et x_CommitmentDiscountUsageEligibility .
- Développez x_PricingUnitDescription dans PricingUnit et x_PricingBlockSize.
- Ajoutez x_BillingAccountAgreement en fonction du type de compte.
- Remplacez x_EffectivePeriodEnd par une date de fin exclusive.
- Ajoutez x_EffectiveUnitPriceDiscount, x_ContractedUnitPriceDiscount, et x_TotalUnitPriceDiscount pour résumer les remises disponibles par SKU.
- Ajoutez x_EffectiveUnitPriceDiscountPercent, x_ContractedUnitPriceDiscountPercent et x_TotalUnitPriceDiscountPercent pour résumer le pourcentage de remise par référence SKU.
- Ajoutez x_SourceName, x_SourceProvider, x_SourceTypeet x_SourceVersion pour identifier le jeu de données ingéré d’origine.
v0.9+ :
- Minuscules de BillingAccountId pour garantir que la jointure des coûts correspond à toutes les lignes.

Transformations des données de suggestion

Jeux de données pris en charge :

Microsoft ReservationRecommendations : 2023-05-01 (EA et MCA)

Transformations :

Aligner les noms de colonnes sur FOCUS 1.0.
- Inclut l'application de la cohérence des noms de colonnes EA et MCA.
- Ne modifie pas les valeurs sous-jacentes, qui peuvent différer entre EA et MCA.
Ajoutez x_SourceName, x_SourceProvider, x_SourceTypeet x_SourceVersion pour identifier le jeu de données ingéré d’origine.

Transformation des données de transaction

Jeux de données pris en charge :

Microsoft ReservationTransactions : 2023-05-01 (EA et MCA)

Transformations :

Aligner les noms de colonnes sur FOCUS 1.0.
- Inclut l'application de la cohérence des noms de colonnes EA et MCA.
- Ne modifie pas les valeurs sous-jacentes, qui peuvent différer entre EA et MCA.
Ajoutez x_SourceName, x_SourceProvider, x_SourceTypeet x_SourceVersion pour identifier le jeu de données ingéré d’origine.

Transformations des données d'utilisation des remises d'engagement

Jeux de données pris en charge :

Microsoft ReservationDetails : 2023-03-01 (EA et MCA)

Transformations :

Aligner les noms de colonnes sur FOCUS 1.0.
- Inclut l'application de la cohérence des noms de colonnes EA et MCA.
- Ne modifie pas les valeurs sous-jacentes, qui peuvent différer entre EA et MCA.
Ajoutez une ResourceType colonne avec le nom d’affichage du type de ressource.
Ajoutez ServiceName, ServiceCategoryet x_ServiceModel colonnes.
Remplacer « NA » sera nul pour x_CommitmentDiscountNormalizedGroup.
Ajouter x_CommitmentDiscountQuantity basé sur FOCUS 1.1.

À propos du conteneur d’ingestion

Les hubs FinOps s’appuient sur un chemin d’accès de dossier et un format de nom de fichier spécifiques dans le conteneur de stockage d’ingestion :

ingestion/{dataset}/{date-folder-path}/{scope-id-path}/{ingestion-id}__{original-file-name}.parquet

ingestion est le conteneur dans lequel le pipeline de données enregistre les données.
{dataset} est le type de jeu de données exporté. En cas d’ingestion dans Azure Data Explorer, la base de données d’Ingestion doit disposer d’une table « _raw » correspondante et sensible à la casse (par exemple, « Costs_raw »). Les hubs FinOps prennent en charge les jeux de données suivants dans cette version :
- CommitmentDiscountUsage : Exportation des détails de réservation de Microsoft Cost Management.
- Coûts - Focus sur les données de coût et d’utilisation.
- Prix - Exportation de la grille tarifaire Cost Management.
- Recommandations : exportation des recommandations de réservation de Cost Management.
- Transactions : Exportation des transactions de réservation de Microsoft Cost Management.
- Pour ingérer des ensembles de données personnalisés, créez une table {dataset}_raw correspondante et un mappage d'ingestion Parquet dans la base de données d'Ingestion.
{date-folder-path} peut être un ou plusieurs dossiers qui indiquent le nombre de jeux de données ingérés qui doivent être conservés. Exemples:
- all (ou tout espace réservé) pour ne pas suivre l’historique du jeu de données. Chaque ingestion remplace les données précédentes. Non pris en charge dans les rapports Power BI basés sur le stockage.
- {yyyy} sous la forme d'une année à quatre chiffres de l'ensemble de données exporté pour ne conserver que la dernière ingestion par an. Non pris en charge dans les rapports Power BI basés sur le stockage.
- {yyyy}/{mm} sous la forme d'une année à quatre chiffres et d'un mois à deux chiffres de l'ensemble de données exporté pour conserver la dernière ingestion par mois.
- {yyyy}/{mm}/{dd} sous la forme d'une année à quatre chiffres, d'un mois à deux chiffres et d'un jour à deux chiffres de l'ensemble de données exporté pour conserver la dernière ingestion par jour. Non pris en charge dans les rapports Power BI basés sur le stockage.
{scope-id-path} est l’ID de ressource complet du périmètre dont proviennent les données. Si vous ingérez des données non-Azure, nous vous recommandons d’utiliser une hiérarchie logique basée sur l’étendue des données (par exemple, aws/{account-id}, gcp/{project-name}, oci/{component-id}/{component-id}).
{ingestion-id} est un ID unique pour le jeu de données ingéré. Cet ID peut être un GUID, un horodatage ou n'importe quelle valeur à condition qu'il soit cohérent dans tous les fichiers de l'ensemble de données ingéré. Cette valeur est utilisée pour supprimer les données précédemment ingérées dans le même chemin d’accès au dossier.
{original-file-name} est destiné à être le nom de fichier d’origine ou un autre identificateur pour indiquer l’origine des données du fichier. Cette valeur est uniquement destinée à vos besoins de résolution des problèmes.

Le chemin complet du dossier et l’ID d’ingestion sont utilisés pour s’assurer que les données ne sont pas dupliquées dans le stockage ou dans Azure Data Explorer. Le nom de fichier d’origine est ajouté aux étendues d’Azure Data Explorer à des fins de résolution des problèmes, mais n’est pas suivi ou utilisé par les hubs FinOps.

Si vous devez utiliser des hubs pour surveiller les données non-Azure, convertissez les données en FOCUS et déposez-les dans le conteneur d’ingestion à l’aide de ces instructions. Notez que la prise en charge des données non-Azure n’a pas été testée explicitement dans la dernière version. Si vous rencontrez des problèmes, créez un problème.

À propos des exportations

Les hubs FinOps tirent parti des exportations Cost Management pour obtenir des données de coût. Cost Management contrôle la structure des dossiers pour les données exportées dans le conteneur de stockage msexports . Un chemin d’accès classique ressemble à ceci :

{container}/{path}/{date-range}/{export-name}/{export-time}/{guid}/{file}

Les hubs FinOps utilisent le fichier manifeste pour identifier l’étendue, le jeu de données, le mois, etc. La seule partie importante du chemin d’accès pour les hubs est le conteneur, qui doit être msexports.

N’exportez pas de données vers le conteneur d’ingestion . Les fichiers CSV exportés doivent être publiés dans le conteneur msexports pour être traités par le moteur hubs.

Pour ingérer des données personnalisées, enregistrez les fichiers Parquet dans le conteneur d'ingestion pour que les rapports Power BI de la boîte à outils FinOps fonctionnent comme prévu. Une fois tous les fichiers parquet ajoutés, ajoutez un fichier manifest.json vide pour déclencher l'ingestion.

Pour ingérer un fichier CSV à partir des exportations Cost Management, enregistrez les fichiers dans un dossier spécifique dans le conteneur msexports . Une fois tous les fichiers ajoutés, ajoutez un fichier manifest.json en fonction du modèle ci-dessous. Apportez les modifications suivantes pour garantir la réussite de l’ingestion :

Passez <export-name> à une valeur unique dans la portée de l'ensemble de données que vous ingérez.
- Ceci est uniquement utilisé pour les recommandations afin de différencier les nombreux types différents de suggestions ingérées qui ne sont pas identifiables à partir du manifeste d'exportation seul. Pour les suggestions de réservation, incluez idéalement le service, la portée (simple/partagée) et la période de rétrospection.
Changez <dataset> et <version> au type d’exportation et à la version de Cost Management. Consultez la liste ci-dessous pour connaître les jeux de données pris en charge.
Remplacez <scope> par l’ID de ressource Azure correspondant à l’étendue d’où proviennent les données.
Passer <guid> à un GUID unique.
Remplacez <yyyy-MM> par l'année et le mois du jeu de données.
Modifiez <path-to-file> pour le chemin d'accès complet du dossier sous le conteneur (ne pas inclure « msexports »).
Changez <file-name> au nom du premier fichier téléchargé sur le stockage.
Si vous avez plusieurs fichiers CSV, copiez l’objet blob pour chaque fichier que vous avez chargé et mettez à jour le nom du fichier.

{
  "blobCount": 1,
  "dataRowCount": 1,
  "exportConfig": {
    "exportName": "<export-name>",
    "type": "<dataset>",
    "dataVersion": "<version>",
    "resourceId": "<scope>/providers/Microsoft.CostManagement/exports/export-name"
  },
  "runInfo": {
    "runId": "<guid>",
    "startDate": "<yyyy-MM>-01T00:00:00"
  },
  "blobs": [
    {
      "blobName": "<path-to-file>/<file-name>.csv"
    }
  ]
}

Les hubs FinOps prennent en charge les types de jeux de données, les versions et les versions d’API suivants :

FocusCost : 1.0r2, 1.0, 1.0-preview(v1)
PriceSheet : 2023-05-01
Détails de réservation : 2023-03-01
ReservationRecommendations : 2023-05-01
Transactions de réservation : 2023-05-01
Versions de l’API : 2023-07-01-preview

FinOps Hubs v0.6

Les sections suivantes expliquent le processus de données dans Les hubs FinOps 0.6.

Configuration de la portée dans la version 0.6

Les étapes suivantes se produisent lorsqu’une nouvelle étendue managée est ajoutée à une instance de hub. Les étendues non managées (où les exportations Cost Management sont configurées manuellement) ne nécessitent aucune configuration dans les hubs.

Le déclencheur config_SettingsUpdated s’exécute lorsque le fichier settings.json est mis à jour.
Le pipeline config_ConfigureExports crée de nouvelles exportations pour toutes les nouvelles étendues ajoutées.

Ingestion de données dans v0.6

L’ingestion des données peut être divisée en deux parties :

Exporte les données push vers le stockage.
Hubs traite et ingère des données.

Pour les étendues managées, les hubs effectuent les étapes suivantes :

Les déclencheurs config_DailySchedule et config_MonthlySchedule s’exécutent selon leurs planifications respectives pour lancer l’ingestion des données.
Le pipeline config_StartExportProcess récupère les exportations applicables pour le calendrier en cours.
Le pipeline config_RunExportJobs exécute chacune des exportations sélectionnées.
Cost Management exporte les détails des coûts bruts vers le conteneur msexports . Plus d’informations
Le pipeline msexports_ExecuteETL met en file d’attente le pipeline d'extraction, de transformation et de chargement (ETL) lorsque des fichiers sont ajoutés au conteneur msexports.
Le pipeline msexports_ETL_ingestion transforme les données au format parquet et les déplace vers le conteneur d'ingestion à l'aide d'une structure de fichier évolutive. Plus d’informations
Power BI ou d’autres outils lisent les données du conteneur d’ingestion.

Une fois les exportations exécutées, qu’elles soient gérées ou non managées, les hubs effectuent les étapes suivantes :

Le pipeline msexports_ExecuteETL lance le processus d’extraction-transformation (ETL) lorsque des fichiers sont ajoutés au stockage.
Le pipeline msexports_ETL_ingestion transforme les données au format parquet et les déplace vers le conteneur d'ingestion à l'aide d'une structure de fichier évolutive. Plus d’informations
Power BI ou d’autres outils lisent les données du conteneur d’ingestion.

À propos de l'ingestion dans la version 0.6

Les hubs FinOps s’appuient sur un chemin d’accès de dossier et un format de nom de fichier spécifiques dans le conteneur d’ingestion :

ingestion/{dataset}/{date-folder-path}/{scope-id-path}/{ingestion-id}__{original-file-name}.parquet

ingestion est le conteneur dans lequel le pipeline de données enregistre les données.
{dataset} est le type de jeu de données exporté.
{date-folder-path} peut être un ou plusieurs dossiers qui indiquent le nombre de jeux de données ingérés qui doivent être conservés. Exemples:
- all (ou tout espace réservé) pour ne pas suivre l’historique du jeu de données. Chaque ingestion remplace les données précédentes. Non pris en charge dans les rapports Power BI basés sur le stockage.
- {yyyy} sous la forme d'une année à quatre chiffres de l'ensemble de données exporté pour ne conserver que la dernière ingestion par an. Non pris en charge dans les rapports Power BI basés sur le stockage.
- {yyyy}/{mm} sous la forme d'une année à quatre chiffres et d'un mois à deux chiffres de l'ensemble de données exporté pour conserver la dernière ingestion par mois.
- {yyyy}/{mm}/{dd} sous la forme d'une année à quatre chiffres, d'un mois à deux chiffres et d'un jour à deux chiffres de l'ensemble de données exporté pour conserver la dernière ingestion par jour. Non pris en charge dans les rapports Power BI basés sur le stockage.
{scope-id-path} est l’ID de ressource complet du périmètre dont proviennent les données. Si vous ingérez des données non-Azure, nous vous recommandons d’utiliser une hiérarchie logique basée sur l’étendue des données (par exemple, « aws/{account-id} », « gcp/{project-name} », « oci/{component-id}/{component-id} »).
{ingestion-id} est un ID unique pour le jeu de données ingéré. Cet ID peut être un GUID, un horodatage ou n'importe quelle valeur à condition qu'il soit cohérent dans tous les fichiers de l'ensemble de données ingéré. Cette valeur est utilisée pour supprimer les données précédemment ingérées dans le même chemin d’accès au dossier.
{original-file-name} est destiné à être le nom de fichier d’origine ou un autre identificateur pour indiquer l’origine des données du fichier. Cette valeur est uniquement destinée à vos besoins de résolution des problèmes.

À propos des exportations dans v0.6

Les hubs FinOps utilisent des exportations Cost Management pour obtenir des données de coût. Cost Management contrôle la structure des dossiers pour les données exportées dans le conteneur msexports . Un chemin d’accès classique ressemble à ceci :

{container}/{path}/{date-range}/{export-name}/{export-time}/{guid}/{file}

À compter de la version 0.4, les hubs FinOps ne s’appuient pas sur les chemins d’accès aux fichiers. Les hubs utilisent le fichier manifeste pour identifier l’étendue, le jeu de données, le mois, etc. La seule partie importante du chemin d’accès pour les hubs est le conteneur, qui doit être msexports.

Avertissement

N’exportez pas de données vers le conteneur d’ingestion . Les fichiers CSV exportés doivent être publiés dans le conteneur msexports pour être traités par le moteur hubs.
Pour ingérer des données personnalisées, enregistrez les fichiers parquet alignés sur FOCUS dans le conteneur d'ingestion pour que les rapports Power BI de la boîte à outils FinOps fonctionnent comme prévu.

Les manifestes d’exportation peuvent changer avec les versions d’API. Voici un exemple avec la version 2023-07-01-previewde l’API :

{
  "exportConfig": {
    "exportName": "<export-name>",
    "resourceId": "/<scope>/providers/Microsoft.CostManagement/exports/<export-name>",
    "dataVersion": "<dataset-version>",
    "apiVersion": "<api-version>",
    "type": "<dataset-type>",
    "timeFrame": "OneTime|TheLastMonth|MonthToDate",
    "granularity": "Daily"
  },
  "deliveryConfig": {
    "partitionData": true,
    "dataOverwriteBehavior": "CreateNewReport|OverwritePreviousReport",
    "fileFormat": "Csv",
    "containerUri": "<storage-resource-id>",
    "rootFolderPath": "<path>"
  },
  "runInfo": {
    "executionType": "Scheduled",
    "submittedTime": "2024-02-03T18:33:03.1032074Z",
    "runId": "af754a8e-30fc-4ef3-bfc6-71bd1efb8598",
    "startDate": "2024-01-01T00:00:00",
    "endDate": "2024-01-31T00:00:00"
  },
  "blobs": [
    {
      "blobName": "<path>/<export-name>/<date-range>/<export-time>/<guid>/<file-name>.<file-type>",
      "byteCount": ###
    }
  ]
}

Les hubs FinOps utilisent les propriétés suivantes :

exportConfig.resourceId pour identifier la portée.
exportConfig.type pour identifier le type de jeu de données.
exportConfig.dataVersion pour identifier la version du jeu de données.
runInfo.startDate pour identifier le mois exporté.

Les hubs FinOps prennent en charge les types de jeux de données, les versions et les versions d’API suivants :

FocusCost : 1.0, 1.0-preview(v1)
PriceSheet : 2023-05-01
Détails de réservation : 2023-03-01
ReservationRecommendations : 2023-05-01
Transactions de réservation : 2023-05-01
Versions de l’API : 2023-07-01-preview

FinOps Hubs v0.4-0.5

Les informations suivantes décrivent comment les données sont traitées dans FinOps Hubs v0.4 et v0.5.

Configuration de la portée dans V0.4-0.5

Le déclencheur config_SettingsUpdated s’exécute lorsque le fichier settings.json est mis à jour.
Le pipeline config_ConfigureExports crée de nouvelles exportations pour toutes les nouvelles étendues ajoutées.

Ingestion de données dans v0.4-0.5

Pour les étendues managées :

Les déclencheurs config_DailySchedule et config_MonthlySchedule s’exécutent selon leurs planifications respectives pour lancer l’ingestion des données.
Le pipeline config_ExportData obtient les exportations applicables pour la planification en cours d’exécution.
Le pipeline config_RunExports exécute chacune des exportations sélectionnées.
Cost Management exporte les détails des coûts bruts vers le conteneur msexports . Pour plus d’informations, consultez À propos des exportations dans v04-05.

Une fois les exportations terminées, pour les étendues managées et non managées :

Le pipeline msexports_ExecuteETL lance le processus d’extraction-transformation (ETL) lorsque des fichiers sont ajoutés au stockage.
Le pipeline msexports_ETL_ingestion transforme les données en un schéma standard et enregistre les données brutes au format parquet dans le conteneur d'ingestion. Pour plus d’informations, consultez À propos de l’ingestion dans v04-05.
Power BI lit les données de coût à partir du conteneur d’ingestion.

À propos de l'ingestion dans la version 0.4-0.5

Les hubs FinOps s’appuient sur un chemin d’accès de dossier spécifique dans le conteneur ingestion :

ingestion/{dataset}/{yyyy}/{mm}/{scope-id}

ingestion est le conteneur dans lequel le pipeline de données enregistre les données.
{dataset} est le type de jeu de données exporté.
{month} est l’année et le mois des données exportées mises en forme en tant que yyyyMM.
{scope-id} devrait être l'ID de ressource entièrement qualifié de la portée d'où proviennent les données.

Si vous devez utiliser des hubs pour surveiller les données non-Azure, convertissez les données en FOCUS et déposez-les dans le conteneur d’ingestion . Ce processus n’a pas été testé explicitement dans la dernière version. Si vous rencontrez des problèmes, créez un problème.

À propos des exportations dans v0.4-0.5

{container}/{path}/{date-range}/{export-name}/{export-time}/{guid}/{file}

À compter de la version 0.4, les hubs FinOps ne s’appuient pas sur les chemins d’accès aux fichiers. Les hubs utilisent le fichier manifeste pour identifier l’étendue, le jeu de données, le mois, et ainsi de suite. La seule partie importante du chemin pour les hubs est le conteneur, qui doit être msexports.

Remarque

N’exportez pas de données vers le conteneur d’ingestion . Les fichiers CSV exportés doivent être publiés dans le conteneur msexports pour être traités par le moteur hubs.

Pour ingérer des données personnalisées, enregistrez les fichiers parquet alignés sur FOCUS dans le conteneur d'ingestion pour que les rapports Power BI de la boîte à outils FinOps fonctionnent comme prévu.

Les manifestes d’exportation peuvent changer avec les versions d’API. Voici un exemple avec la version 2023-07-01-previewde l’API :

{
  "exportConfig": {
    "exportName": "<export-name>",
    "resourceId": "/<scope>/providers/Microsoft.CostManagement/exports/<export-name>",
    "dataVersion": "<dataset-version>",
    "apiVersion": "<api-version>",
    "type": "<dataset-type>",
    "timeFrame": "OneTime|TheLastMonth|MonthToDate",
    "granularity": "Daily"
  },
  "deliveryConfig": {
    "partitionData": true,
    "dataOverwriteBehavior": "CreateNewReport|OverwritePreviousReport",
    "fileFormat": "Csv",
    "containerUri": "<storage-resource-id>",
    "rootFolderPath": "<path>"
  },
  "runInfo": {
    "executionType": "Scheduled",
    "submittedTime": "2024-02-03T18:33:03.1032074Z",
    "runId": "af754a8e-30fc-4ef3-bfc6-71bd1efb8598",
    "startDate": "2024-01-01T00:00:00",
    "endDate": "2024-01-31T00:00:00"
  },
  "blobs": [
    {
      "blobName": "<path>/<export-name>/<date-range>/<export-time>/<guid>/<file-name>.csv",
      "byteCount": ###
    }
  ]
}

Les hubs FinOps utilisent les propriétés suivantes :

exportConfig.resourceId pour identifier la portée.
exportConfig.type pour identifier le type de jeu de données.
exportConfig.dataVersion pour identifier la version du jeu de données.
runInfo.startDate pour identifier le mois exporté.

Les hubs FinOps prennent en charge les types de jeux de données, les versions et les versions d’API suivants :

FocusCost : 1.0, 1.0-preview(v1)
PriceSheet : 2023-05-01
Détails de réservation : 2023-03-01
ReservationRecommendations : 2023-05-01
Transactions de réservation : 2023-05-01
Versions de l’API : 2023-07-01-preview

FinOps Hubs v0.2-0.3

Les étapes suivantes décrivent le processus d’exportation et de traitement des données de coût à l’aide des hubs FinOps versions 0.2-0.3 :

Cost Management exporte les détails des coûts bruts vers le conteneur msexports .
Le pipeline msexports_ExecuteETL lance le processus d’extraction-transformation (ETL) lorsque des fichiers sont ajoutés au stockage.
Le pipeline msexports_ETL_ingestion enregistre les données exportées au format parquet dans le conteneur d'ingestion.
Power BI lit les données de coût à partir du conteneur d’ingestion.

FinOps Hubs 0.2-0.3 utilise le chemin d’exportation pour déterminer l’étendue exportée et le mois. Ce point est important, car les mises à jour du chemin d’accès peuvent interrompre les pipelines de données. Pour éviter ce problème, nous vous recommandons de mettre à jour vers FinOps Hubs 0.4. Le chemin attendu doit imiter :

msexports/{scope-id}/{export-name}/{date-range}/{export-time}/{guid}/{file}

msexports est le conteneur spécifié sur l’exportation.

{scope-id} est le chemin d’accès au dossier spécifié sur l’exportation.

Les hubs 0.3 et antérieurs utilisent ceci pour identifier la portée d'où proviennent les données. Nous vous recommandons d’utiliser l’ID d’étendue, mais n’importe quelle valeur peut être utilisée. Les exemples d'IDs de portée incluent :

Type d'étendue Valeur d’exemple

Abonnement /subscriptions/###

Groupe de ressources /subscriptions/###/resourceGroups/###

Compte de facturation /providers/Microsoft.Billing/billingAccounts/###

Profil de facturation /providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###

{export-name} est le nom de l’exportation.

Les hubs ignorent ce dossier.
{date-range} est les données de plage de dates exportées.

Hubs 0.3 et versions antérieures l’utilisent pour identifier le mois. Le format de ce dossier est yyyyMMdd-yyyyMMdd. Hubs 0.4 utilise plutôt le manifeste.
{export-time} est un horodatage du moment où l'exportation a été exécutée.

Les hubs ignorent cela. Le format de ce dossier est yyyyMMddHHmm.
{guid} est un GUID unique et n’est pas toujours présent.

Les hubs ignorent cela. Cost Management n’inclut pas toujours ce dossier. Si elle est incluse ou non dépend de la version de l’API utilisée pour créer l’exportation.
{file} est un manifeste ou des données exportées.

La version 0.3 et les versions antérieures ignorent les fichiers manifestes et surveillent uniquement les fichiers *.csv . Dans une prochaine version, les hubs surveillent le manifeste.

Type d'étendue	Valeur d’exemple
Abonnement	`/subscriptions/###`
Groupe de ressources	`/subscriptions/###/resourceGroups/###`
Compte de facturation	`/providers/Microsoft.Billing/billingAccounts/###`
Profil de facturation	`/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###`

FinOps Hubs v0.1

Les étapes suivantes décrivent le processus d’exportation et de traitement des données de coût à l’aide des hubs FinOps version 0.1 :

Cost Management exporte les détails des coûts bruts vers le conteneur msexports .
Le pipeline msexports_transform enregistre les données brutes au format parquet dans le conteneur d'ingestion.
Power BI lit les données de coût à partir du conteneur d’ingestion.

Envoyer des commentaires

Faites-nous savoir ce que vous pensez de notre travail avec un petit avis. Nous utilisons ces révisions pour améliorer et développer les outils et ressources FinOps.

Envoyer des commentaires

Si vous recherchez quelque chose de spécifique, votez pour une idée existante ou créez une nouvelle idée. Partagez des idées avec d’autres personnes pour obtenir plus de votes. Nous nous concentrons sur les idées avec le plus de votes.

Voter ou suggérer des idées

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-04-18

Partager via

Comment les données sont traitées dans des hubs FinOps

Configuration de la portée

Ingestion des données

À propos de l'ingestion de Data Explorer

Transformations des données de coût

Transformations de données de prix

Transformations des données de suggestion

Transformation des données de transaction

Transformations des données d'utilisation des remises d'engagement

À propos du conteneur d’ingestion

À propos des exportations

FinOps Hubs v0.6

Configuration de la portée dans la version 0.6

Ingestion de données dans v0.6

À propos de l'ingestion dans la version 0.6

À propos des exportations dans v0.6

FinOps Hubs v0.4-0.5

Configuration de la portée dans V0.4-0.5

Ingestion de données dans v0.4-0.5

À propos de l'ingestion dans la version 0.4-0.5

À propos des exportations dans v0.4-0.5

FinOps Hubs v0.2-0.3

FinOps Hubs v0.1

Envoyer des commentaires

Contenu connexe

Commentaires

Ressources supplémentaires