Обработка данных в центрах FinOps

Центры FinOps выполняют множество действий по обработке данных для очистки, нормализации и оптимизации данных. В следующих разделах показано, как данные передаются из Управления затратами в экземпляр концентратора.

Настройка диапазона

Область — это уровень в иерархии облачных ресурсов и учетных записей, который предоставляет доступ к затратам, использованию и углеродным данным. Для центров FinOps обычно рекомендуется использовать учетные записи выставления счетов по соглашению с предприятием (EA) или профили выставления счетов по соглашению с клиентами Microsoft (MCA). Однако для базового анализа достаточно любой облачной области. Основная проблема заключается в том, требуются ли данные о ценах и резервировании, так как управление затратами предоставляет только данные для учетных записей выставления счетов EA и профилей выставления счетов MCA.

Центры FinOps поддерживают настройку областей путем ручной настройки экспорта управления затратами или предоставления концентраторам FinOps доступа для управления областями от вашего имени. Управляемые области настраиваются в файле конфигурации/settings.json в хранилище концентратора. Сведения описывают, что происходит при добавлении новой управляемой области в этот файл. Неуправляемые области, в которых экспорты управления затратами настраиваются вручную, не требуют другой настройки.

Триггер config_SettingsUpdated запускается при обновлении файла settings.json.
Конвейер config_ConfigureExports создает новые экспорты для всех добавленных областей.

Прием данных

На следующей схеме показан комплексный процесс приема данных в центрах FinOps:

(Необязательно) При использовании управляемых экспортов:
1. Триггеры config_DailySchedule и config_MonthlySchedule запускаются по соответствующим расписаниям, чтобы начать прием данных.
2. Конвейер config_StartExportProcess получает применимые экспорты для выполняемого расписания.
3. Конвейер config_RunExportJobs выполняет каждый из выбранных экспортов.
Управление затратами экспортирует необработанные сведения о затратах в контейнер msexports . Подробнее.
Конвейер msexports_ExecuteETL ставит в очередь процесс извлечения-преобразования-загрузки (ETL), когда файлы добавляются в контейнер msexports.
Конвейер msexports_ETL_ingestion преобразует данные в формат parquet и перемещает его в контейнер приема с помощью масштабируемой структуры файлов. Подробнее.
(Необязательно) При использовании Azure Data Explorer:
1. Конвейер ingestion_ExecuteETL ставит в очередь конвейер приема данных Data Explorer при добавлении manifest.json файлов в контейнер приема.
  - Если вы обрабатываете пользовательские наборы данных вне экспорта из Управления затратами, создайте пустой файл manifest.json в целевой папке для импорта после подготовки всех остальных файлов (не добавляйте этот файл, пока файлы еще загружаются). Файл manifest.json не анализируется и может быть пустым. Единственной целью является указать, что все файлы для этой задачи импорта добавлены.
2. Конвейер ingestion_ETL_dataExplorer отправляет данные в таблицу {dataset}_raw в обозревателе данных.
  - Имя набора данных — это первый каталог в контейнере обработки.
  - Все необработанные таблицы находятся в базе данных поглощения в Обозревателе данных.
3. При приеме данных в необработанные таблицы в Обозревателе данных политика обновления копирует данные в соответствующую таблицу {dataset}_final_v1_0 с помощью функции {dataset}_transform_v1_0() для нормализации всех данных для выравнивания с FOCUS 1.0.
4. После приема конвейер ingestion_ETL_dataExplorer выполняет некоторые очистки, включая удаление данных в итоговой таблице, которые находятся за пределами периода хранения данных.
  - По состоянию на версию 0.7, Data Explorer применяет хранение данных в необработанных таблицах, в то время как хранение данных в окончательных таблицах осуществляется через трубопровод интеграции. Если прием данных останавливается, исторические данные не удаляются.
  - Хранение данных можно настроить во время развертывания шаблона или вручную в файле конфигурации /settings.json в хранилище.
Отчеты и такие средства, как Power BI, считывают данные из обозревателя данных или из контейнера приема.
- Данные в Data Explorer можно считывать из базы данных концентратора .
  - Используйте функцию {dataset}() для использования последней схемы.
    - Эта функция полезна для быстрого изучения, но может привести к критическим изменениям при обновлении экземпляра концентратора FinOps.
  - Используйте функцию {dataset}_v1_0() для использования схемы FOCUS 1.0.
    - Схемы функций с версиями не должны изменяться с течением времени, но значения могут изменяться, если источник данных изменяет эти значения.
  - Избегайте использования базы данных приема для запросов. База данных Ингестия, хотя и не запрещена явно, должна рассматриваться как внутренняя область для промежуточного хранения и подготовки данных.
- Данные в хранилище можно считывать из ingestion/<dataset>/<year>/<month>/<scope-path>.
  - Данные должны быть считываться рекурсивно из папки набора данных и при необходимости включать дополнительные сведения, необходимые для конкретности.
  - Файлы в каждой папке набора данных могут иметь разные схемы на основе источника данных и типа учетной записи. Подготовьтесь к преобразованию данных при приеме в других системах, таких как Microsoft Fabric.
  - Из соображений производительности не рекомендуется читать из хранилища. При составлении отчетов о затратах на более чем 1 млн долларов рекомендуется использовать Обозреватель данных.

Сведения о загрузке данных в Data Explorer

При загрузке данных в Data Explorer функции {dataset}_transform_v1_0() применяют правила преобразования в базе данных Ingestion. Каждый набор данных имеет другой набор правил преобразования, описанных в следующих разделах.

Список запрошенных изменений, идеи, которые рассматриваются, и открытые вопросы о базовых наборах данных управления затратами, см. в вопросе no 1111. Оставьте комментарии по этой проблеме, если вы найдете возможности решить любые проблемы или выразить поддержку любой из конкретных проблем.

Преобразования данных о расходах

Поддерживаемые наборы данных:

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

Следующие наборы данных были учтены в проектировании, но не поддерживаются в собственном коде. Для обработки этих наборов данных создайте конвейер данных (или внешнюю процедуру), который отправляет файлы parquet в папку ingestion/Costs/yyyy/mm/{scope-path} в хранилище. {scope-path} может быть любым уникальным путем, таким как aws/123 или gcp/projects/foo. Единственное требование — убедиться, что каждая область находится в отдельной папке. После копирования внешнего содержимого, также создайте файл manifest.json для запуска Data Explorer.

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

Преобразует:

v0.7+:
- Выравнивание имен столбцов FOCUS 1.0-preview до FOCUS 1.0.
  - Включает преобразование предварительной версии FOCUS 1.0 в версию 1.0.
- Добавьте x_IngestionTime, чтобы указать время последнего обновления строки.
- Добавьте x_SourceChanges, чтобы определить, когда данные в строке изменяются с помощью узлов.
- Обновите ProviderName и PublisherName, если не указано.
- Добавьте x_SourceName, x_SourceProvider, x_SourceTypeи x_SourceVersion для идентификации исходного набора данных.
- Заполните отсутствующие значения ListCost, ListUnitPrice, ContractedCostи ContractedUnitPrice на основе прайс-листа.
  - Для этого процесса необходимо сначала экспортировать цены, а затем стоимость. Цены отсутствуют в первый день месяца, если затраты обрабатываются до того, как цены становятся доступными в этом месяце.
- Исправление ContractedCost при неправильном установке из-за ошибки в службе "Управление затратами".
- Приведите ResourceName и x_ResourceGroupName к строчному регистру для устранения проблем согласованности регистра, мешающих группировке и фильтрации.
- Добавьте x_BillingAccountAgreement на основе типа учетной записи.
v0.8+:
- Исправьте все значения ResourceType, использующие идентификаторы типов внутренних ресурсов (например, microsoft.compute/virtualmachines).
v0.9+:
- Нижний регистр BillingAccountId , чтобы убедиться, что соединение цены соответствует всем строкам.
- Понизьте регистр CommitmentDiscountId, чтобы избежать повторяющихся строк при агрегировании данных.
- Добавьте новые проверки для x_SourceChanges, ListCostLessThanContractedCost и ContractedCostLessThanEffectiveCost.
v0.10+:
- Исправьте x_EffectiveUnitPrice, когда оно вычисляется и возникает ошибка округления по сравнению с x_BilledUnitPrice или ContractedUnitPrice.
- Вычислите PricingQuantity и ConsumedQuantity, когда есть затраты, но нет количества.
- Установите ContractedCost на EffectiveCost, если оно не задано.
- Установите ListCost на ContractedCost, если оно не задано.
- Удалите "-2" в столбце x_InvoiceSectionId .
- Удалите "Unassigned" в столбце x_InvoiceSectionName.
- Исправлено x_EffectiveUnitPrice при его вычислении и наличии ошибки округления.
- Добавьте новые x_SourceChanges проверки для MissingConsumedQuantity, MissingPricingQuantityи XEffectiveUnitPriceRoundingError.
v0.11+:
- Измените BillingPeriodStart и BillingPeriodEnd на первый день месяца.

Преобразования ценовых данных

Поддерживаемые наборы данных:

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

Преобразует:

v0.7+
- Выровнять имена столбцов с FOCUS 1.0.
  - Включает обеспечение согласованности имен столбцов EA и MCA.
  - Не изменяет базовые значения, которые могут отличаться между EA и MCA.
- Переведите продолжительность x_SkuTerm в формате ISO в конкретное количество месяцев для сопоставления со сведениями о затратах.
  - Мы ждем, когда FOCUS определит, как определить длительности, прежде чем изменить это значение на ISO или другой формат.
- Замените ContractedUnitPrice для использования плана экономии эквивалентом по запросу.
- Установите ListUnitPrice для использования плана экономии, приравненного к эквиваленту по запросу.
- Добавьте SkuPriceIdv2 в качестве более точного значения SkuPriceId, чем то, что в настоящее время находится в сведениях о затратах.
- Добавьте x_IngestionTime, чтобы указать время последнего обновления строки.
- Добавьте x_CommitmentDiscountSpendEligibility и x_CommitmentDiscountUsageEligibility.
- Расширьте x_PricingUnitDescription, добавив PricingUnit и x_PricingBlockSize.
- Добавьте x_BillingAccountAgreement на основе типа учетной записи.
- Измените x_EffectivePeriodEnd на монопольную дату окончания.
- Добавьте x_EffectiveUnitPriceDiscount, x_ContractedUnitPriceDiscountи x_TotalUnitPriceDiscount для суммирования доступных скидок по каждому SKU.
- Добавьте x_EffectiveUnitPriceDiscountPercent, x_ContractedUnitPriceDiscountPercentи x_TotalUnitPriceDiscountPercent, чтобы суммировать процент скидки на единицу SKU.
- Добавьте x_SourceName, x_SourceProvider, x_SourceTypeи x_SourceVersion для идентификации исходного набора данных.
v0.9+:
- Привести BillingAccountId к нижнему регистру, чтобы гарантировать, что соединение затрат соответствует всем строкам.

Преобразования данных рекомендательных систем

Поддерживаемые наборы данных:

Рекомендации по резервированию Microsoft: 2023-05-01 (EA и MCA)

Преобразует:

Выровнять имена столбцов с FOCUS 1.0.
- Включает обеспечение согласованности имен столбцов EA и MCA.
- Не изменяет базовые значения, которые могут отличаться между EA и MCA.
Добавьте x_SourceName, x_SourceProvider, x_SourceTypeи x_SourceVersion для идентификации исходного набора данных.

Преобразования данных транзакций

Поддерживаемые наборы данных:

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

Преобразует:

Выровнять имена столбцов с FOCUS 1.0.
- Включает обеспечение согласованности имен столбцов EA и MCA.
- Не изменяет базовые значения, которые могут отличаться между EA и MCA.
Добавьте x_SourceName, x_SourceProvider, x_SourceTypeи x_SourceVersion для идентификации исходного набора данных.

Преобразование данных об использовании скидок за обязательства

Поддерживаемые наборы данных:

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

Преобразует:

Выровнять имена столбцов с FOCUS 1.0.
- Включает обеспечение согласованности имен столбцов EA и MCA.
- Не изменяет базовые значения, которые могут отличаться между EA и MCA.
Добавьте столбец ResourceType с отображаемым названием типа ресурса.
Добавьте столбцы ServiceName, ServiceCategoryи x_ServiceModel.
Замените "NA" на значение NULL в x_CommitmentDiscountNormalizedGroup.
Добавьте x_CommitmentDiscountQuantity на основе FOCUS 1.1.

Сведения о контейнере приема

Центры FinOps используют конкретный путь к папке и формат имени файла в контейнере приема и хранения:

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

ingestion — это контейнер, в котором конвейер данных сохраняет данные.
{dataset} — экспортируемый тип набора данных. При загрузке в Azure Data Explorer база данных для загрузки должна иметь одноименную таблицу с учетом регистра "_raw" (например, "Costs_raw"). Центры FinOps поддерживают следующие наборы данных в этом выпуске:
- CommitmentDiscountUsage — экспорт сведений о резервировании в управлении затратами.
- затраты — данные о стоимости и использовании FOCUS.
- цены — экспорт ценовой таблицы управления затратами.
- Рекомендации - Экспорт рекомендаций по резервированию управления затратами.
- Транзакции — экспорт операций по управлению затратами на резервирование.
- Чтобы загрузить пользовательские наборы данных, создайте соответствующую таблицу {dataset}_raw и настройте сопоставление для приёма данных формата parquet в базе данных Ingestion.
{date-folder-path} может быть одной или несколькими папками, указывающими, сколько наборов данных следует хранить. Примеры:
- all (или любой заполнитель), чтобы не отслеживать историю для набора данных. Каждая загрузка заменяет предыдущие данные. Не поддерживается в отчетах Power BI на основе хранилища.
- {yyyy} в качестве четырехзначного года экспортированного набора данных, чтобы сохранить только последнее импортирование в каждом году. Не поддерживается в отчетах Power BI на основе хранилища.
- {yyyy}/{mm} в виде четырехзначного года и двухзначного месяца экспортированного набора данных для сохранения последней загрузки данных за месяц.
- {yyyy}/{mm}/{dd} в качестве четырехзначного года, двухзначного месяца и двухзначного дня экспортированного набора данных для сохранения последней загрузки за день. Не поддерживается в отчетах Power BI на основе хранилища.
{scope-id-path} — это полный идентификатор ресурса контекста, из которого получены данные. При обработке данных, отличных от Azure, мы рекомендуем использовать логическую иерархию на основании объёма данных (например, aws/{account-id}, gcp/{project-name}, oci/{component-id}/{component-id}).
{ingestion-id} — это уникальный идентификатор для загруженного набора данных. Этот идентификатор может быть GUID, меткой времени или любым значением, если он одинаковый во всех файлах для приема набора данных. Это значение используется для удаления ранее полученных данных в том же пути папки.
{original-file-name} предназначено для исходного имени файла или другого идентификатора, чтобы указать, где произошли данные в файле. Это значение предназначено только для устранения неполадок.

Полный путь к папке и идентификатор приема используются для обеспечения того, чтобы данные не дублировались в хранилище или в Azure Data Explorer. Исходное имя файла добавляется в экстенты Azure Data Explorer для устранения неполадок, но не отслеживается или не используется центрами FinOps.

Если необходимо использовать центры для мониторинга данных, отличных от Azure, преобразуйте данные в FOCUS и поместите их в контейнер получения с помощью этого руководства. Обратите внимание, что поддержка данных, отличных от Azure, не была явно проверена в последнем выпуске. При возникновении проблем создайте проблему.

Сведения о экспорте

Центры FinOps используют экспорт управления затратами для получения данных о затратах. Управление затратами управляет структурой папок для экспортированных данных в контейнере хранилища msexports. Типичный путь выглядит следующим образом:

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

Центры FinOps используют файл манифеста для определения области, набора данных, месяца и т. д. Единственной важной частью пути для узлов является контейнер, который должен быть msexports.

Не экспортируйте данные в контейнер для приема. Экспортированные CSV-файлы должны быть опубликованы в контейнере msexports для обработки движком концентраторов.

Чтобы загрузить пользовательские данные, сохраните файлы parquet в контейнере ввода данных для корректной работы отчетов Power BI набора средств FinOps. После добавления всех файлов parquet добавьте пустой файл manifest.json для запуска загрузки.

Чтобы получить CSV-файл из экспорта управления затратами, сохраните файлы в определенной папке в контейнере msexports . После добавления всех файлов добавьте файлmanifest.json на основе приведенного ниже шаблона. Внесите следующие изменения, чтобы обеспечить успешное прием:

Измените <export-name> на уникальное значение в рамках набора данных, который вы используете.
- Это используется только для рекомендаций, чтобы отличать множество различных типов рекомендаций, получающих обработку, которые невозможно определить только по манифесту экспорта. Для рекомендаций по резервированию в идеале включают службу, область (один или общий) и период обратного просмотра.
Измените <dataset> и <version> на тип экспорта и версию службы Cost Management. См. список ниже для поддерживаемых наборов данных.
Измените <scope> на идентификатор ресурса Azure для области, откуда поступили данные.
Измените <guid> на уникальный GUID.
Измените значение <yyyy-MM> года и месяца набора данных.
Измените <path-to-file> на полный путь к папке в контейнере (не включайте msexports).
Измените <file-name> имя первого файла, отправленного в хранилище.
Если у вас несколько CSV-файлов, скопируйте объект BLOB-объекта для каждого отправленного файла и обновите имя файла.

{
  "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"
    }
  ]
}

Центры FinOps поддерживают следующие типы наборов данных, версии и версии API:

FocusCost: 1.0r2, 1.01.0-preview(v1)
Прайс-лист: 2023-05-01
Данные о бронировании: 2023-03-01
Рекомендации по резервированию: 2023-05-01
Транзакции бронирования: 2023-05-01
Версии API: 2023-07-01-preview

Узлы FinOps версии 0.6

В следующих разделах описан процесс обработки данных в Центрах FinOps 0.6.

Настройка области в версии 0.6

Следующие шаги выполняются при добавлении новой управляемой области в экземпляр хаба. Неуправляемые области (где экспорты управления затратами настраиваются вручную) не требуют установки в центрах.

Триггер config_SettingsUpdated запускается при обновлении файла settings.json.
Конвейер config_ConfigureExports создает новые экспорты для всех добавленных областей.

Прием данных в версии 0.6

Прием данных можно разделить на две части:

Экспортирует push-данные в хранилище.
Узлы обрабатывают и поглощают данные.

Для управляемых областей центры выполняют следующие действия:

Триггеры config_DailySchedule и config_MonthlySchedule запускаются по соответствующим расписаниям, чтобы начать прием данных.
Конвейер config_StartExportProcess получает применимые экспорты для выполняемого расписания.
Конвейер config_RunExportJobs выполняет каждый из выбранных экспортов.
Управление затратами экспортирует необработанные сведения о затратах в контейнер msexports . Подробнее.
Конвейер msexports_ExecuteETL ставит в очередь процесс извлечения-преобразования-загрузки (ETL), когда файлы добавляются в контейнер msexports.
Конвейер msexports_ETL_ingestion преобразует данные в формат parquet и перемещает его в контейнер приема с помощью масштабируемой структуры файлов. Подробнее.
Power BI или другие инструменты считывают данные из контейнера приема.

После выполнения экспорта, независимо от того, является ли он управляемым или неуправляемым, узлы выполняют следующие действия:

Конвейер msexports_ExecuteETL запускает процесс извлечения-преобразования-загрузки (ETL) при добавлении файлов в хранилище.
Конвейер msexports_ETL_ingestion преобразует данные в формат parquet и перемещает его в контейнер приема с помощью масштабируемой структуры файлов. Подробнее.
Power BI или другие инструменты считывают данные из контейнера приема.

Сведения о погрузке данных в версии v0.6

Центры FinOps зависят от определенного пути к папке и формата имени файла в контейнере ингибации:

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

ingestion — это контейнер, в котором конвейер данных сохраняет данные.
{dataset} — экспортируемый тип набора данных.
{date-folder-path} может быть одной или несколькими папками, указывающими, сколько наборов данных следует хранить. Примеры:
- all (или любой заполнитель), чтобы не отслеживать историю для набора данных. Каждая загрузка заменяет предыдущие данные. Не поддерживается в отчетах Power BI на основе хранилища.
- {yyyy} в качестве четырехзначного года экспортированного набора данных, чтобы сохранить только последнее импортирование в каждом году. Не поддерживается в отчетах Power BI на основе хранилища.
- {yyyy}/{mm} в виде четырехзначного года и двухзначного месяца экспортированного набора данных для сохранения последней загрузки данных за месяц.
- {yyyy}/{mm}/{dd} в качестве четырехзначного года, двухзначного месяца и двухзначного дня экспортированного набора данных для сохранения последней загрузки за день. Не поддерживается в отчетах Power BI на основе хранилища.
{scope-id-path} — это полный идентификатор ресурса контекста, из которого получены данные. Если вы получаете данные, не относящиеся к Azure, мы рекомендуем использовать логическую иерархию на основе области данных (например, "aws/{account-id}", "gcp/{project-name}", "oci/{component-id}/{component-id}").
{ingestion-id} — это уникальный идентификатор для загруженного набора данных. Этот идентификатор может быть GUID, меткой времени или любым значением, если он одинаковый во всех файлах для приема набора данных. Это значение используется для удаления ранее полученных данных в том же пути папки.
{original-file-name} предназначено для исходного имени файла или другого идентификатора, чтобы указать, где произошли данные в файле. Это значение предназначено только для устранения неполадок.

Сведения о экспорте в версии 0.6

Центры FinOps используют экспорт управления затратами для получения данных о затратах. Управление затратами управляет структурой папок для экспортированных данных в контейнере msexports . Типичный путь выглядит следующим образом:

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

С версии 0.4 центры FinOps не зависят от путей к файлам. Центры используют файл манифеста для определения области, набора данных, месяца и т. д. Единственной важной частью пути для концентраторов является контейнер, который должен быть msexports.

Предупреждение

Не экспортируйте данные в контейнер для приема. Экспортированные CSV-файлы должны быть опубликованы в контейнере msexports для обработки движком концентраторов.
Чтобы загрузить пользовательские данные, сохраните FOCUS-выравненные файлы parquet в контейнере ингестации, чтобы отчеты Power BI набора средств FinOps работали должным образом.

Экспорт манифестов может изменяться в зависимости от версий API. Ниже приведен пример версии API 2023-07-01-preview:

{
  "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": ###
    }
  ]
}

Центры FinOps используют следующие свойства:

exportConfig.resourceId для определения области.
exportConfig.type для идентификации типа набора данных.
exportConfig.dataVersion для идентификации версии набора данных.
runInfo.startDate для идентификации экспортированного месяца.

Центры FinOps поддерживают следующие типы наборов данных, версии и версии API:

FocusCost: 1.0, 1.0-preview(v1)
Прайс-лист: 2023-05-01
Данные о бронировании: 2023-03-01
Рекомендации по резервированию: 2023-05-01
Транзакции бронирования: 2023-05-01
Версии API: 2023-07-01-preview

Центры FinOps версии 0.4-0.5

В следующих сведениях описывается обработка данных в центрах FinOps версии 0.4 и v0.5.

Настройка области видимости в версии 0.4-0.5

Триггер config_SettingsUpdated запускается при обновлении файла settings.json.
Конвейер config_ConfigureExports создает новые экспорты для всех добавленных областей.

Прием данных в версии 0.4-0.5

Для управляемых областей:

Триггеры config_DailySchedule и config_MonthlySchedule запускаются по соответствующим расписаниям, чтобы начать прием данных.
Конвейер config_ExportData получает применимые экспорты для выполняемого расписания.
Конвейер config_RunExports выполняет каждый из выбранных экспортов.
Управление затратами экспортирует необработанные сведения о затратах в контейнер msexports . Дополнительные сведения см. в разделе "Сведения о экспорте" в версии 04-05.

После завершения экспорта для управляемых и неуправляемых областей выполните следующие действия:

Конвейер msexports_ExecuteETL запускает процесс извлечения-преобразования-загрузки (ETL) при добавлении файлов в хранилище.
Конвейер msexports_ETL_ingestion преобразует данные в стандартную схему и сохраняет сырые данные в формате Parquet в контейнер ingestion. Дополнительные сведения см. в разделе о приеме в версии 04-05.
Power BI считывает данные о затратах из контейнера для сбора данных.

Сведения о приеме в версии 0.4-0.5

Центры FinOps опираются на определенный путь к папке в контейнере загрузки:

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

ingestion — это контейнер, в котором конвейер данных сохраняет данные.
{dataset} — экспортируемый тип набора данных.
{month} — это год и месяц экспортированных данных, отформатированных как yyyyMM.
{scope-id} Ожидается, что это полный идентификатор ресурса, откуда поступают данные.

Если вам нужно использовать средства обработки для мониторинга данных, отличных от Azure, преобразуйте данные в FOCUS и поместите их в контейнер ingestion. Этот процесс не был явно протестирован в последней версии. При возникновении проблем создайте проблему.

Сведения о экспорте в версии 0.4-0.5

Центры FinOps используют экспорт управления затратами для получения данных о затратах. Управление затратами управляет структурой папок для экспортированных данных в контейнере msexports . Типичный путь выглядит следующим образом:

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

С версии 0.4 центры FinOps не зависят от путей к файлам. Центры используют файл манифеста для определения области, набора данных, месяца и т. д. Единственная важная часть пути для концентраторов — контейнер, который должен быть msexports.

Примечание.

Не экспортируйте данные в контейнер для приема. Экспортированные CSV-файлы должны быть опубликованы в контейнере msexports для обработки движком концентраторов.

Чтобы загрузить пользовательские данные, сохраните FOCUS-выравненные файлы parquet в контейнере ингестации, чтобы отчеты Power BI набора средств FinOps работали должным образом.

Экспорт манифестов может изменяться в зависимости от версий API. Ниже приведен пример версии API 2023-07-01-preview:

{
  "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": ###
    }
  ]
}

Центры FinOps используют следующие свойства:

exportConfig.resourceId для определения области.
exportConfig.type для идентификации типа набора данных.
exportConfig.dataVersion для идентификации версии набора данных.
runInfo.startDate для идентификации экспортированного месяца.

Центры FinOps поддерживают следующие типы наборов данных, версии и версии API:

FocusCost: 1.0, 1.0-preview(v1)
Прайс-лист: 2023-05-01
Данные о бронировании: 2023-03-01
Рекомендации по резервированию: 2023-05-01
Транзакции бронирования: 2023-05-01
Версии API: 2023-07-01-preview

Центры FinOps версии 0.2-0.3

Ниже описан процесс экспорта и обработки данных о затратах с помощью Центров FinOps версии 0.2-0.3:

Управление затратами экспортирует необработанные сведения о затратах в контейнер msexports .
Конвейер msexports_ExecuteETL запускает процесс извлечения-преобразования-загрузки (ETL) при добавлении файлов в хранилище.
Конвейер msexports_ETL_ingestion сохраняет экспортированные данные в формате parquet в контейнере ingestion.
Power BI считывает данные о затратах из контейнера для сбора данных.

Центры FinOps 0.2-0.3 используют путь экспорта для определения экспортируемой области и месяца. Это важно, так как обновления пути могут нарушить конвейеры данных. Чтобы избежать этой проблемы, мы рекомендуем обновить платформу FinOps до версии 0.4. Ожидаемый путь должен имитировать:

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

msexports — это контейнер, указанный в экспорте.

{scope-id} — это путь к папке, указанный в экспорте.

Центры версии 0.3 и более ранние используются для идентификации области, из которой поступают данные. Рекомендуется использовать идентификатор области, но любое значение можно использовать. Примеры идентификаторов областей:

Тип области Пример значения

Подписка /subscriptions/###

Группа ресурсов /subscriptions/###/resourceGroups/###

платежный аккаунт /providers/Microsoft.Billing/billingAccounts/###

Профиль выставления счетов /providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###

{export-name} — имя экспорта.

Центры игнорируют эту папку.
{date-range} — это экспортируемые данные диапазона дат.

Версии Hubs 0.3 и более ранние используют это для определения месяца. Формат этой папки yyyyMMdd-yyyyMMdd. В версии 0.4 Hubs вместо этого используется манифест.
{export-time} — метка времени выполнения экспорта.

Центры игнорируют это. Формат этой папки yyyyMMddHHmm.
{guid} является глобально уникальным идентификатором и не всегда присутствует.

Центры игнорируют это. Управление затратами не всегда включает эту папку. Независимо от того, включена ли она, зависит от версии API, используемой для создания экспорта.
{file} — это манифест или экспортированные данные.

Версия 0.3 и более ранние игнорируют файлы манифеста и отслеживают только файлы *.csv . В будущем выпуске хабы будут отслеживать манифест.

Тип области	Пример значения
Подписка	`/subscriptions/###`
Группа ресурсов	`/subscriptions/###/resourceGroups/###`
платежный аккаунт	`/providers/Microsoft.Billing/billingAccounts/###`
Профиль выставления счетов	`/providers/Microsoft.Billing/billingAccounts/###/billingProfiles/###`

Центры FinOps версии 0.1

Ниже описан процесс экспорта и обработки данных о затратах с помощью центров FinOps версии 0.1:

Управление затратами экспортирует необработанные сведения о затратах в контейнер msexports .
Конвейер msexports_transform сохраняет необработанные данные в формате parquet в контейнер ingestion.
Power BI считывает данные о затратах из контейнера для сбора данных.

Оставить отзыв

Сообщите нам ваше мнение о нашей работе, оставив краткий отзыв. Эти отзывы используются для улучшения и расширения средств и ресурсов FinOps.

Отзывы

Если вы ищете что-то конкретное, проголосуйте за существующую или создайте новую идею. Поделитесь идеями с другими пользователями, чтобы получить больше голосов. Мы сосредоточимся на идеях с большинством голосов.

Проголосовать или предложить идеи

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-04-02

Поделиться через

Обработка данных в центрах FinOps

Настройка диапазона

Прием данных

Сведения о загрузке данных в Data Explorer

Преобразования данных о расходах

Преобразования ценовых данных

Преобразования данных рекомендательных систем

Преобразования данных транзакций

Преобразование данных об использовании скидок за обязательства

Сведения о контейнере приема

Сведения о экспорте

Узлы FinOps версии 0.6

Настройка области в версии 0.6

Прием данных в версии 0.6

Сведения о погрузке данных в версии v0.6

Сведения о экспорте в версии 0.6

Центры FinOps версии 0.4-0.5

Настройка области видимости в версии 0.4-0.5

Прием данных в версии 0.4-0.5

Сведения о приеме в версии 0.4-0.5

Сведения о экспорте в версии 0.4-0.5

Центры FinOps версии 0.2-0.3

Центры FinOps версии 0.1

Оставить отзыв

Связанный контент

Обратная связь

Дополнительные ресурсы