Периодическое извлечение больших наборов данных о затратах с помощью функции экспорта

Узнайте, как регулярно экспортировать большие объемы данных с помощью функции экспорта данных из Управления затратами. Экспорт — это рекомендуемый способ извлечения неагрегированных данных о затратах, особенно если файлы данных о потреблении слишком велики для надежного вызова и загрузки с помощью API сведений о затратах. Экспортированные данные помещаются в выбранную учетную запись службы хранилища Azure. Из этой учетной записи вы можете загружать такие данные в свои системы и анализировать их по мере необходимости. Сведения о настройке функции экспорта на портале Azure см. в разделе Экспорт данных.

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

Общие конфигурации экспорта

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

• Повторение. Определяет частоту выполнения задания экспорта и момент, когда файл помещается в учетную запись службы хранилища Azure. Вы можете выбрать выполнение ежедневно, еженедельно или ежемесячно. Попробуйте настроить повторение так, чтобы оно соответствовало заданиям импорта данных, используемым внутренней системой вашей организации.
• Период повторения. Определяет время, в течение которого экспорт остается действительным. Файлы экспортируются только в течение периода повторения.
• Интервал времени— определяет объем данных, создаваемых экспортом в заданном запуске. Распространенными параметрами являются MonthToDate и WeekToDate.
• Дата начала. Позволяет задать начало для расписания экспорта. Экспорт создается на дату начала (StartDate), а затем с периодичностью, заданной параметром повторения.
• Тип — существует три типа экспорта:
  • ActualCost — показывает общее потребление и затраты за указанный период, по мере их начисления, а также указывает их в счете.
  • AmortizedCost — показывает общее потребление и затраты за указанный период с учетом амортизации, применяемой к соответствующим затратам на покупку резервирования.
  • Usage — все операции экспорта, созданные до 20 июля 2020 года, принадлежат к этому типу. Обновите все запланированные операции экспорта, установив для них тип ActualCost или AmortizedCost.
• Столбцы. Определяет поля данных, которые необходимо добавить в файл экспорта. Они соответствуют полям, доступным в API сведений о затратах.
• Секционирование — установите для этого параметра значение true, если у вас большой набор данных, который требуется разбить на несколько файлов. Это упрощает прием данных. Дополнительные сведения о секционировании см. в разделе Секционирование файлов для больших наборов данных.

Создание ежедневного экспорта за текущий месяц для подписки

URL-адрес запроса: PUT https://management.azure.com/{scope}/providers/Microsoft.CostManagement/exports/{exportName}?api-version=2020-06-01

{
  "properties": {
    "schedule": {
      "status": "Active",
      "recurrence": "Daily",
      "recurrencePeriod": {
        "from": "2020-06-01T00:00:00Z",
        "to": "2020-10-31T00:00:00Z"
      }
    },
    "format": "Csv",
    "deliveryInfo": {
      "destination": {
        "resourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MYDEVTESTRG/providers/Microsoft.Storage/storageAccounts/{yourStorageAccount} ",
        "container": "{yourContainer}",
        "rootFolderPath": "{yourDirectory}"
      }
    },
    "definition": {
      "type": "ActualCost",
      "timeframe": "MonthToDate",
      "dataSet": {
        "granularity": "Daily",
        "configuration": {
          "columns": [
            "Date",
            "MeterId",
            "ResourceId",
            "ResourceLocation",
            "Quantity"
          ]
        }
      }
    }
}

Копирование больших двоичных объектов из хранилища Azure

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

Команда провела тест производительности путем передачи больших двоичных объектов из учетных записей хранения, расположенных в западной части США, в тот же регион и в другие регионы. Показатели скорости колебались в диапазоне от 2 ГБ в секунду (в пределах региона) до 150 МБ в секунду (в учетные записи хранения в регионе "Юго-Восточная Азия").

Конфигурация теста

Для измерения скорости передачи больших двоичных объектов мы создали простое консольное приложение .NET на основе последней версии (2.0.1) библиотеки перемещения данных Azure (DLM), подключенной через NuGet. DLM представляет собой пакет SDK, предоставляемый командой службы хранилища Azure для поддержки программного доступа к службам передачи данных. Затем были созданы учетные записи хранения категории "Стандартный" 2-й версии в нескольких регионах, а в качестве исходного был выбран регион "Западная часть США". В учетных записях хранения были размещены контейнеры, содержащие по 10 блочных BLOB-объектов размером 2 ГБ. Эти контейнеры копировались в другие учетные записи хранения с помощью метода TransferManager.CopyDirectoryAsync() библиотеки DLM с параметром CopyMethod.ServiceSideSyncCopy. Тесты проводились на компьютере под управлением Windows 10 с 12 ядрами и одним сетевым подключением 1-GbE.

Использовались следующие параметры приложения:

• TransferManager.Configurations.ParallelOperations = Environment.ProcessorCount * 32. Мы обнаружили, что этот параметр больше всего влияет на общую пропускную способность. Выбранный вариант (значение, в 32 раза превышающее число ядер) обеспечил самую высокую пропускную способность для тестового клиента.
• ServicePointManager.DefaultConnectionLimit = int.MaxValue. При настройке значения максимальное значение эффективно передается полный контроль над параллелизмом в параметр ParallelOperations, упоминание ранее.
• TransferManager.Configurations.BlockSize = 4 194 304. Этот параметр немного влияет на скорость передачи, и в тесте размер 4 МБ оказался оптимальным.

Дополнительные сведения и пример кода см. в разделе "Связанное содержимое ".

Результаты теста

Параметры синхронной передачи

Ниже приведены некоторые характеристики передачи синхронизации на стороне службы, используемой с DML, которая относится к его использованию:

• DML может передавать один большой двоичный объект или каталог. Для передачи каталогов можно использовать шаблон поиска, чтобы сопоставлять большие двоичные объекты по префиксу.
• Передача блочных BLOB-объектов происходит параллельно. Все передачи завершаются ближе к концу процесса передачи. Отдельные блочные BLOB-объекты передаются параллельно.
• Перемещение выполняется на клиенте асинхронно. Состояние передачи можно периодически проверять с помощью обратного вызова к методу, который можно определить в объекте TransferContext.
• Операция передачи создает контрольные точки и предоставляет объект TransferCheckpoint. Этот объект представляет последнюю контрольную точку через объект TransferContext. Если объект TransferCheckpoint сохранен до отмены или прерывания передачи, процесс можно возобновить из этой контрольной точки в срок течение семи дней. Передачу можно возобновить из любой контрольной точки, а не только из последней.
• Если процесс передачи клиента убит и перезапущен без реализации функции проверка point:
  • Перед завершением передачи BLOB-объектов перезагрузится передача.
  • После завершения некоторых больших двоичных объектов передача перезапускается только для неполных больших двоичных объектов.
• Приостановка работы клиента приостанавливает и передачу данных.
• Механизм перемещения больших двоичных объектов прозрачно для клиента обрабатывает временные сбои. Например, регулирование учетной записи хранения обычно не приводит к сбою передачи, но замедляет передачу.
• При передаче на стороне службы создается низкая нагрузка на ресурсы ЦП и памяти клиента, пропускную способность сети и сетевые подключения.

Параметры асинхронной передачи

Вы можете вызвать метод TransferManager.CopyDirectoryAsync() с параметром CopyMethod.ServiceSideAsyncCopy. С точки зрения клиента он работает так же, как и механизм синхронной передачи, но в его работе есть следующие важные отличия:

• Скорость передачи медленнее эквивалентной передачи синхронизации (обычно 10 МБ/с или меньше).
• передача будет продолжена даже при завершении клиентского процесса;
• Хотя поддерживаются проверка точки, возобновление передачи с помощью TransferCheckpoint не возобновляется во время проверка точки, но в текущем состоянии передачи.

Итоги теста

Хранилище BLOB-объектов Azure поддерживает высокую скорость передачи данных при выполнении синхронной передачи на стороне службы. Использование этой возможности в приложениях .NET с помощью библиотеки перемещения данных выполняется очень просто. Экспорт в Управлении затратами позволяет менее чем за час надежно скопировать сотни гигабайт данных в учетную запись хранения, расположенную в любом регионе.

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

• Изучите исходный код библиотеки перемещения данных службы хранилища Microsoft Azure.
• Перенесите данные с помощью библиотеки перемещения данных.
• Изучите код примера приложения AzureDmlBackup.
• Узнайте, как обеспечить высокую пропускную способность при работе с Хранилищем BLOB-объектов Azure.