Отчет о затратах и использовании AWS автоматически генерирует почасовые или ежедневные отчеты о выставлении счетов и переносит данные в корзину S3.
Отчет о затратах и использовании, или CUR, является преемником старого подробного отчета по выставлению счетов. И CUR, и DBR генерируют оценочные затраты на основе сервиса AWS, типа использования, тегов ресурсов и т. Д. И переносят их на S3 для анализа. Затем их можно использовать для агрегирования и анализа затрат для лучшей наглядности и контроля расходов AWS.
Разница заключается в том, что, хотя DBR генерирует файлы CSV, CUR генерирует более удобные для базы данных файлы GZ или Parquet. AWS Athena, AWS Redshift и AWS QuickSight могут затем напрямую использовать их для анализа.
Вам также могут понравиться: 7 методов оптимизации затрат AWS
Введение в AWS Athena
Афина — это серверная служба запросов. Данные хранятся в виде статических файлов в S3 и считываются в режиме реального времени для анализа с использованием Presto, который является стандартным механизмом SQL стандарта ANSI.
Athena извлекает данные, используя функцию под названием schema-on-read, что означает, что она накладывает схему на базовые данные при выполнении запроса. Серверное программное обеспечение или демон не запущены, поэтому используется термин «безсерверный».
Преимущество Athena состоит в том, что она освобождает нас от обычной деятельности по обслуживанию базы данных и настройке производительности. Мы можем рассчитывать на превосходную надежность S3 для надежного и надежного хранения данных. Предостережение заключается в том, что формат данных и структура разделов становятся критическими для производительности запросов.
В целом, эта архитектура делает Athena очень производительной, надежной и экономически эффективной.
Настройка отчетов о стоимости и использовании в AWS
Настроить CUR с помощью Athena очень просто.
AWS предоставляет стек Cloudformation со всем, что готово к работе. Просто следуйте инструкциям в документации, чтобы включить CUR, настроить корзину S3 и настроить стек Cloudformation.
Когда стек готов, мы можем проверить состояние CUR, перейдя в нашу базу данных и выполнив следующий запрос:
Оболочка
xxxxxxxxxx
1
SELECT status FROM cost_and_usage_data_status;
Приведенный выше запрос вернет либо READY
либо UPDATING
, либо последний указывает, что Афина может вернуть неполные результаты.
Если статус есть READY
, мы можем проверить его, посчитав общее количество элементов в нашей базе данных Athena.
SQL
xxxxxxxxxx
1
SELECT
2
COUNT(identity_line_item_id) AS Count
4
5
FROM my_cur_db.my_cur_table
6
WHERE
8
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
9
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4));
10
Оператор
MONTH(CURRENT_DATE)
извлекает текущий месяц как целое число иCAST()
преобразует его в строку.
Приведенный выше запрос вернет количество строк, которые в данный момент находятся в таблице счетов.
Athena CUR Колонны для Ценообразования
Давайте рассмотрим наш набор данных и определим столбцы, которые нам понадобятся для анализа наших затрат. В документации есть соответствующие детали всех столбцов, которые будет заполнять CUR. Вот несколько примеров:
Столбцы для выставления счетов
line_item_blended_cost
: Смешанная стоимость этой позиции.line_item_line_item_type
Тип оплаты, покрываемый этой позицией. Возможные значения: Кредит , DiscountsUsage , Плата , Возврат , RIFee , Налог и Использование .pricing_public_on_demand_cost
: Стоимость позиции, основанная на общедоступных ставках экземпляров по запросу.
Столбцы ресурса
line_item_resource_id
: Идентификатор ресурса этой позиции, если он включен в CUR. Например, хранилище Amazon S3, вычислительный экземпляр Amazon EC2 или база данных Amazon RDS могут иметь идентификатор ресурса.line_item_line_item_description
: Описание типа позиции.resource_tags_user_name
: Содержит значениеName
тега ресурса.
Столбцы конфигурации
line_item_availability_zone
: Зона доступности, в которой размещена эта позиция, напримерus-east-1a
илиus-east-1b
.product_instance_type
Описывает тип экземпляра, размер и семейство, которые определяют процессор, сеть и емкость хранилища вашего экземпляра.product_instance_family
: Описывает семейство экземпляров Amazon EC2.
Столбцы использования
line_item_usage_account_id
: Идентификатор аккаунта, который использовал эту позицию. Для организаций это может быть основная учетная запись или учетная запись участника.line_item_operation
: Конкретная операция AWS, охватываемая этой позицией.line_item_usage_type
: Сведения об использовании этой позиции.line_item_usage_start_date
,line_item_usage_end_date
: Даты начала и окончания соответствующей позиции в формате UTC. Формат: ГГГГ-ММ-ДДЧЧ: мм: ссЗ. Дата начала включительно, а дата окончания - исключительна.month
,year
: Месяц и год этой позиции.line_item_product_code
: Код продукта этой позиции. Например,AmazonEC2
это код продукта для Amazon Elastic Compute Cloud.
Разбивка стоимости на компоненты
Во-первых, давайте посчитаем общую стоимость за текущий месяц.
line_item_blended_cost
Поле будет содержать заряд для позиции. В него discount_total_discount
будут включены любые скидки, которые нам нужно будет скорректировать, чтобы получить чистую стоимость.
xxxxxxxxxx
1
SELECT
2
SUM(line_item_blended_cost + discount_total_discount)
4
5
FROM my_cur_db.my_cur_table
6
WHERE
8
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
9
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4));
10
Теперь давайте выясним общую стоимость отдельных аккаунтов. Этот запрос полезен, если у нас несколько учетных записей под основной.
xxxxxxxxxx
1
SELECT
2
line_item_usage_account_id AS AccountID,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
12
GROUP BY line_item_usage_account_id
13
ORDER BY Cost DESC;
15
Давайте посмотрим, какую стоимость несут отдельные сервисы AWS, от самых высоких до самых низких.
x
1
SELECT
2
line_item_product_code AS ProductCode,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
12
GROUP BY line_item_product_code
13
ORDER BY Cost DESC;
Собрав все это вместе, мы можем получить информацию о стоимости, понесенной отдельными учетными записями и услугами, следующим образом.
SQL
x
1
SELECT
2
line_item_usage_account_id AS AccountID,
4
line_item_product_code AS ProductCode,
5
SUM(line_item_blended_cost + discount_total_discount) AS Cost
6
7
FROM my_cur_db.my_cur_table
8
WHERE
10
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
11
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
12
13
GROUP BY line_item_usage_account_id, line_item_product_code
14
ORDER BY Cost DESC;
16
Еще одна замечательная особенность CUR заключается в том, что он также заполняет любые теги ресурсов, которые мы настраиваем. Мы можем использовать это для просмотра затрат, сгруппированных по отдельным центрам затрат.
Допустим, у нас есть Project
тег ресурса со значениями различных проектов в нашей организации. Мы можем сгруппировать расходы по проектам, чтобы определить, где наши расходы самые высокие.
x
1
SELECT
2
resource_tags_user_project AS Project,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
12
GROUP BY resource_tags_user_project
13
ORDER BY Cost DESC;
15
Комбинируя вышеуказанный запрос с идентификаторами ресурсов, мы видим, какие ресурсы в рамках каких проектов имеют наибольшую стоимость.
x
1
SELECT
2
line_item_resource_id AS ResourceID,
4
resource_tags_user_project AS Project,
5
SUM(line_item_blended_cost + discount_total_discount) AS Cost
6
7
FROM my_cur_db.my_cur_table
8
WHERE
10
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
11
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
12
13
GROUP BY line_item_resource_id, resource_tags_user_project
14
ORDER BY Cost DESC;
16
Определение самых дорогих ресурсов в рамках услуг
Допустим, мы хотим выяснить самые дорогие функции Lambda, серверы EC2, экземпляры RDS и т. Д.
Мы можем сделать это довольно быстро, используя line_item_product_code
столбец и агрегируя на основе идентификаторов ресурсов.
Например, чтобы узнать самые дорогие лямбда-функции :
x
1
SELECT
2
line_item_resource_id AS Resource,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND line_item_product_code = 'AWSLambda'
12
AND line_item_resource_id != ''
13
14
GROUP BY line_item_resource_id
15
ORDER BY Cost DESC
17
LIMIT 25;
19
Приведенный выше запрос довольно прост: отфильтруйте все ресурсы AWSLambda
службы, агрегируйте по идентификаторам ресурсов и отсортируйте по общей стоимости этих ресурсов. Комбинируя это с тегами ресурсов, мы можем автоматизировать ежедневные или еженедельные отчеты по электронной почте, чтобы следить за расходами нашего проекта.
Давайте продолжим.
Самые дорогие ресурсы EC2:
x
1
SELECT
2
line_item_resource_id AS Resource,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND line_item_product_code = 'AmazonEC2'
12
AND line_item_resource_id != ''
13
14
GROUP BY line_item_resource_id
15
ORDER BY Cost DESC
17
LIMIT 25;
19
Самые дорогие ресурсы RDS:
x
1
SELECT
2
line_item_resource_id AS Resource,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND line_item_product_code = 'AmazonRDS'
12
AND line_item_resource_id != ''
13
14
GROUP BY line_item_resource_id
15
ORDER BY Cost DESC
17
LIMIT 25;
19
Самые дорогие группы журналов CloudWatch:
x
1
SELECT
2
line_item_resource_id AS Resource,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND line_item_product_code = 'AmazonCloudWatch'
12
AND line_item_resource_id LIKE '%log-group%'
13
14
GROUP BY line_item_resource_id
15
ORDER BY Cost DESC
17
LIMIT 25;
19
Самые дорогие экземпляры DynamoDB:
x
1
SELECT
2
line_item_resource_id AS Resource,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND line_item_product_code = 'AmazonDynamoDB'
12
AND line_item_resource_id != ''
13
14
GROUP BY line_item_resource_id
15
ORDER BY Cost DESC
17
LIMIT 25;
19
Самые дорогие ковши S3:
x
1
SELECT
2
line_item_resource_id AS Resource,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND line_item_product_code = 'AmazonS3'
12
AND line_item_resource_id != ''
13
14
GROUP BY line_item_resource_id
15
ORDER BY Cost DESC
17
LIMIT 25;
19
Афина может помочь нам определить самые дорогостоящие операции в рамках услуги. Например, как мы можем определить безудержные затраты на переход ледника в S3?
Самые дорогие операции с ковшом S3:
x
1
SELECT
2
line_item_resource_id AS Resource,
4
line_item_operation AS Operation,
5
SUM(line_item_blended_cost + discount_total_discount) AS Cost
6
7
FROM my_cur_db.my_cur_table
8
WHERE
10
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
11
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
12
AND line_item_product_code = 'AmazonS3'
13
AND line_item_resource_id != ''
14
15
GROUP BY line_item_resource_id, line_item_operation
16
ORDER BY Cost DESC
18
LIMIT 25;
20
Другим важным вариантом использования является проверка стоимости ресурсов по их именам.
Допустим, у меня есть несколько ресурсов с названием моего проекта myfrontendproject
. Это может быть ec2-myfrontendproject
, или rds-myfrontendproject-master
, или s3-assets-myfrontendproject
, и т. Д. Мы можем использовать столбец тегов ресурсов, чтобы также сгруппировать затраты по именам.
x
1
SELECT
2
resource_tags_user_name AS ResourceName,
4
SUM(line_item_blended_cost + discount_total_discount) AS Cost
5
6
FROM my_cur_db.my_cur_table
7
WHERE
9
MONTH = CAST(MONTH(CURRENT_DATE) AS varchar(4))
10
AND YEAR = CAST(YEAR(CURRENT_DATE) AS varchar(4))
11
AND lower(resource_tags_user_name) LIKE '%myfrontendproject%'
12
13
GROUP BY resource_tags_user_name
14
ORDER BY Cost DESC
16
LIMIT 25;
18
Что нужно помнить при использовании Афины
Безсерверный характер Athena обеспечивает огромные преимущества в плане стоимости и надежности, но есть несколько соображений.
Во-первых, по умолчанию установлен предел параллелизма 20, который ограничивает количество запросов, которые могут выполняться параллельно. Обратитесь к странице сервисных лимитов для более подробной информации.
Во-вторых, при использовании SELECT
запросов мы должны ограничивать столбцы тем, что нам нужно. Athena взимает плату в зависимости от объема обрабатываемых данных, поэтому ограничение столбцов - это отличная производительность и оптимизация затрат.
В-третьих, формат хранения данных окажет значительное влияние на время обработки запроса. Форматы паркета будут более производительными, чем CSV, поскольку они являются столбчатыми и могут использовать сжатие Snappy.
В-четвертых, при объединении нескольких таблиц оставьте большую таблицу слева от объединения и меньшую справа. Афина распределяет правую таблицу по рабочим узлам и направляет левую таблицу для объединения.
В-пятых, Athena не поддерживает пользовательские функции, хранимые процедуры, индексы, подготовленные или EXPLAIN
операторы. Полный список ограничений здесь .
Заключение
Комбинация Athena и CUR может помочь в решении многих проблем, связанных с «черным ящиком». Обзор расходов и отчеты о бюджете - это хорошо, но есть некоторые проблемы, которые может решить только чудовищное четверное соединение.
CUR также доступен для Redshift и QuickSight. Если лимиты параллелизма Athena вызывают проблемы или если вам нужна полнофункциональная СУБД для анализа затрат, то Redshift - это то, что вам нужно. Для визуализации QuickSight может использовать столбцы напрямую, но не результаты запроса, поэтому что-то вроде Redash или Tableau может быть лучше для более сложных панелей мониторинга.
Ресурсы
- Начало работы с Amazon Athena - биллинг и управление затратами AWS
- Идентификационные данные - AWS Billing и управление затратами
- Амортизация зарезервированных экземпляров - AWS Billing и управление затратами
- Что такое AWS для выставления счетов и управления затратами? - AWS биллинг и управление затратами
- Общие сведения о консолидированных счетах - AWS Billing и управление затратами
- Как улучшить производительность AWS Athena: полное руководство
Дальнейшее чтение
9 вещей, которые следует учитывать при рассмотрении Афины Амазонки