亚马逊AWS官方博客
利用 Amazon QuickSight 实现对账单多维度精细化分析
前言
随着组织对云使用成熟度上的成长,云数据/资源的使用越来越深入和复杂,组织需要对产生的成本进行更好地管理、分析、预测、预警,以便及时进⾏调整和优化,从⽽更好地控制成本;同时各个组织/部门在使⽤云的过程中,也需要基于更多的维度,更加清晰直观地了解所使⽤资源的成本消耗情况、费⽤占比,以及是否超预期等。
AWS 在 23 年底的 re:Invent 上宣布推出由 Amazon QuickSight 提供⽀持的成本和使⽤交互式仪表板(Dashboard),通过 AWS 控制台配置的⽅式简化了将 CUR(AWS 成本和使⽤情况报告)数据摄⼊ AmazonQuickSight 的过程,并且在 QuickSight 已经预置好了丰富的 Dashboard,满足大多数客户的使⽤需求。但还是会有⼀些客户在实际的使用中需要基于企业自身的情况和特点进行 Dashboard 的定制化,比如:
- 需要更灵活地按要求构建 Dashboard,并且⽀持二开;
- 需要更小的时间维度分析(小时);
- 需要⽀持⾃定义的 Tag 字段维度进⾏分析;
- 需要将 Dashboard 内容进⾏拆分,并按权限划分;
- 存在多账号,需要统一的聚合展示;
- 关联外部数据/自定义维度表,使之更丰富更易读;
- 利用 QuickSinht AI 能力对账单进行构建、分析、预测、总结等;
- 使⽤ JDBC 进⾏连接开发特定需求。
在定制化的过程中,我们就必须知道其架构和原理,以及对于 CUR 账单字段含义⽤法都有⼀定了解。这篇 Blog 中,我们会分别介绍标准⽅案和⾃定义⽅案的实施部署⽅式,满⾜客户不同的需求。
另外如果您对账单需要有更加专业和细致化的整理、分析、解读、优化,也可以选择订阅 AWS Enterprise Support,将由客户技术经理提供技术⽀持。 详情可见:链接。
相关服务说明
CUR
AWS 成本和使⽤情况报告(AWS CUR)包含了极为全⾯详尽的成本和使用情况数据。您可以使⽤成本和使⽤情况报告发布 AWS 向您拥有的 Amazon Simple Storage Service(Amazon S3)存储桶提交账单报告。您可以接收按小时、日或月份、按产品或产品资源,或是按您自己定义的标签细分的成本报告。
Glue
AWS Glue 是⼀项⽆服务器数据集成服务,它简化了发现、准备、移动和集成来⾃多个来源的数据以进⾏分析、机器学习(ML)和应⽤程序开发的工作。
在标准⽅案中,未使⽤到 Glue;⽽在⾃建⽅案中,我们⽤了 Glue 爬⾍对于 CUR 数据进⾏ schema 的爬取,并对其 catalog 进⾏管理,这样的好处在于当有新的 tag 激活时,能够⾃动地更新 catalog。
Athena
Amazon Athena 是⼀种交互式查询服务,让您能够轻松使⽤标准 SQL 直接分析 Amazon Simple Storage Service(Amazon S3)中的数据。
在此标准⽅案中,未使⽤到 Athena;⽽在自建⽅案中,我们将使⽤ Athena 结合 Glue Data Catalog 元数据信息查询 S3 中 CUR 数据,QuickSight 并将 Athena 作为数据源进⾏关联使⽤,同时客户也可以使⽤ Athena JDBC 连接进行独立查询。
QuickSight
Amazon QuickSight 是⼀种云规模的商业智能(BI)服务,⽆论您身在何处,都可以使⽤它向与之共事的⼈提供 easy-to-understand 见解,主要有以下三个部分:
- 数据集(DataSets):在数据集层,您可以从不同的来源中提取数据,定义连接条件,应⽤初步过滤器,为列提供更友好的名称,并准备数据以在分析层中可视化。
- 分析(Analysis):您可以在分析中分析和可视化数据,完成后,您可以将分析作为仪表板(Dashboard)发布。
- 视觉对象(Visual):数据的图形化表⽰,包含字段列表(Fields list),视觉对象类型(Visual types)等部分。
在此⽅案中,QuickSight 数据集通过对数据的关联和导⼊,最终形成 Dashboard 来提供客户的查询和分析。
前置条件
1、开启 QuickSight 服务
2、激活需要进⾏统计的 Tag 标签(此功能只在自定义方案中有效)
如果需要在账单中按 Tag 展⽰和分析,需要对成本分配标签进⾏激活。激活后的标签将在 CUR 以 resource_tags_user_tagname 字段进⾏存储。
标准方案
标准方案架构
标准方案部署
1、在账单和成本管理-数据输出中创建导出和控制⾯板
选择“由 QuickSight 提供⽀持的成本和⽤量控制⾯板”,填写相应字段,点击创建后,等待⼏分钟即可完成所有配置操作。
需要注意的是,CUR 账单将在 UTC 1 时左右更新到 S3,因此初始创建完后 QuickSight 中的 Dashboard 会提⽰“没有数据”,需等待第二⽇再查看即可,并且只会有至开始后产生的账单数据。
2、在 QuickSight 中可以查看数据集和自动创建好的 Dashboard,可以点击直接进⾏查询和分析
自建方案
自建方案架构
以上所有步骤均需要进⾏单独配置,便于后续的⾃定义 Dashboard 的使⽤,在实施之前,我们来先了解下 CUR 中的主要字段。
字段/使用说明
CUR 数据总共有 200 多个字段,以下简要罗列⼀些比较关键的核⼼字段:
类别 | 字段名称 | 字段说明 | 备注 |
数据标识 | identity_line_item_id | 行项目生成的唯一标识 | |
账单 | bill_billing_period_start_date | 账单开始日期 | 账单分析使用该时间 |
bill_billing_period_end_date | 账单结束日期 | ||
bill_billing_entity | 发票交易对象 | 如:AWS/AWS Marketplace | |
bill_payer_account_id | 付款账户ID | ||
行项目 | line_item_availability_zone | 可用区 | |
line_item_usage_start_date | 行项目使用开始时间 | 按天分析使用该实践 | |
line_item_usage_emd_date | 行项目使用结束时间 | ||
line_item_resource_id | 资源id | 如:EC2 i-052265fee612fa28a | |
line_item_line_item_type | 行项目费用类型,计费方式 | 如:Useage/Discount/SavingPlans*/BundledDiscount/Credit/Fee/Refund等 | |
line_item_usage_account_id | 行项目账户ID | 在多账户环境下,可以单独创建一个维表或视图,关联注明账号所属名称 | |
line_item_product_code | 产品服务code | 如:AmazonEC2/AmazonS3/AmazonGlacier | |
line_item_operation | 行项目特定操作 | 如:RunInstances/Get/PutMetricData | |
line_item_line_item_description | 行类型表述 | 计费说明 | |
line_item_usage_type | 用量信息标识 | 如:(EC2)Spot / BoxUsage:t2.large / APN1-DataTransfer-Regional-Bytes | |
line_item_unblended_cost | 使用费用个人账户的服务使用量相关的费率*指定时间段内产生的用量 | 核心计费字段 | |
product | product_region | 服务所在region | |
product_product_name | 服务全名 | line_item_product_code全写 | |
如:Amazon Simple Storage Service | |||
product_instance_type | 实例类型 | 如:db.m5d.xlarge | |
product_database_engine | 数据库引擎 | 如:MySQL/Aurora MySQL | |
product_product_family | 产品类型的类别 | 如:(EC2)Compute Instance/Data Transfer/IP Address | |
product_group | 类别详情 | 如:EC2服务下IP Address对应的有ElasticIP:Address | |
product_location_type | 终端节点 | AWS Region/AWS Edge Location/Other | |
product_from_location | 来源位置 | 如:product_product_family=Data Transfer 将注明来源 | |
product_to_location | 目标位置 | 如:product_product_family=Data Transfer 将注明目标 | |
product_current_generation | 是否当前最新实例 | ||
定价 | pricing_unit | 定价单位 | 如 (ECS)vCPU-Hours / (AmazonS3)Requests |
pricing_term | 预留或按需 | 如:OnDemand/Spot/Reserved | |
pricing_public_on_demand_cost | 公开的按需成本 | 注意:在savingplans下时,非公开报价 | |
预留 | reservation_effective_cost | RI 的预付和小时费率的总和,平均计算为有效的小时费率 | line_item_line_item_type = ‘Discountedusage’时,计算费用使用此字段 |
reservation_amortized_upfront_cost_for_usage | 全预付或部分预付,预付抵扣金额 | line_item_unblended_cost-reservation_amortized_upfront_cost_for_usage = 该实例实付金额 | |
savings plans | savings_plan_savings_plan_effective_cost | Savings Plan 每月承诺金额的比例 | |
标签 | resource_tags_user_* | 自定义tag标签 | 需要先在成本分配标签中激活 |
抵扣 | 抵扣费用 | 如:Shield Advanced 抵扣WAF费用 | |
拆分 | 成本拆分 | AWS 成本和使用情况报告中使用了成本拆分后数据将得到提现 |
费用类别举例
我们知道 AWS 有三种计费模式,On Demand/RI/Spot,我们分别来看下三种模式在 CUR 数据中是如何体现的。
- On Demand:
实例按需使⽤时, l_item_line_item_type = ‘Usage’ and pricing_term = ‘OnDemand’,计算费⽤直接使用 line_item_unblended_cost 字段,例如:
ap-northeast-1,t3.small 实例,按需费⽤ 0.0272$/hour,实际使⽤费⽤ 0.0272$/ hour。
- Spot:
实例使⽤ Spot 时,line_item_line_item_type = ‘Usage’ and pricing_term = ‘Spot’,计算费⽤直接使⽤ line_item_unblended_cost 字段,节省成本 = pricing_public_on_demand_cost – line_item_unblended_cost,例如:
ap-northeast-1,c5d.large 实例,原本按需费⽤ $0.122/hour,实际使⽤费⽤ $0.0351/hour,节省成本 $0.0869/hour。
- 预留:
实例使⽤预留时,line_item_line_item_type = ‘DiscountedUsage’ and pricing_term = ‘Reserved’,计算费⽤使⽤ reservation_effective_cost 字段,节省成本 = pricing_public_on_demand_cost – reservation_effective_cost。
⽆预付:
例如 ap-northeast-1,t3.micro 实例,原本按需费⽤ $0.0136/ hour,RI 费⽤(⼀年⽆预付)$0.0086/hour,实际使⽤费⽤ 0.0086$/hour,节省成本 0.005$/ hour。
全预付:
例如 ap-northeast-1,t3.micro 实例,原本按需费⽤ $0.0136/hour,RI 费⽤(⼀年全预付 $70/year)$0.00799/hour,节省成本 $0.0056/hour。
全预付⽀付费⽤:
RI 抵扣实例,计费⽅式:
相⽐与⽆预付,reservation_amortized_upfront_cost_for_usage 等于预付抵扣⾦额。
Saving plans:
实例使⽤ Saving plans 时,相对⽽⾔是⽐较复杂的:
当实例费全覆盖时,line_item_line_item_type = ‘Usage’,line_item_unblended_cost = 0;
当实例费部分覆盖时,line_item_line_item_type = ‘Usage’,line_item_unblended_cost = 除覆盖后剩余⾦额。
⽆预付:
例如 us-east-1,购买了 $0.001 的 savingplans,覆盖到实例 t3.small,原本按需费⽤ $0.0208/hour,Saving Plans EC2 ⼀年⽆预付 $140.16/year,折合 $0.013/hour,⽽ $0.001 的 savingplans 在该实际中抵扣掉了 $0.00139/hour,剩余的按需费⽤为 $0.0194/hour;
因此该 EC2 实际使⽤费⽤ = 0.0194 + 0.001 = 0.0204,节省成本 $0.00039。
全预付:
例如 ap-northeast-1,购买了 $148.92 的 savingplans,覆盖到实例 t3.small,原本按需费⽤ $0.0272/hour,Saving Plans EC2 ⼀年全预付折合为 $0.016/hour,节省费⽤ $0.0112/hour。
全预付费⽤:
SavingPlans 抵扣实例,计费方式:
举例总结:
类别 | 条件 | 实付⽀付⾦额 | 实际抵扣⾦额 |
On demand | line_item_line_item_type = “Usage”line_item_operation = “Runlnstances” pricing_term = “OnDemandˮ |
line_item_unblended_cost | pricing_public_on_demand_cost |
Spot | line_item _line_item_type = “Usage”line_item_operation like “Runlnstances%” pricing_term = “Spotˮ |
line_item_unblended_cost | pricing_public_on_demand_cost |
RI | line_item _line_item_type = “DiscountedUasge” line_item_operation = “Runlnstances” pricing_term = “Reservedˮ |
reservation_effective_cost | pricing_public_on_demand_cost |
SavingPlans | line_item _line_item_type =”SavingsPlanCoveredUsage” line_item_operation = “Runlnstances” pricing_term = “OnDemandˮ |
savings_plan_savings_plan_effective_cost | pricing_public_on_demand_cost |
RI/SavingPlans 预付项计费说明:
类别 | 条件 | 实际⽀付⾦额 |
RI | line_item_line_ item_type = “Fee” | line_item_unblended_cost |
SavingPlans | line_item_line_ item_type = “SavingsPlanRecurringFee” | line_item_unblended_cost |
自建方案部署
CUR
创建成本使⽤报告,新客户可以选择ˮ标准数据导出“(相⽐“旧版 CUR 导出ˮ有⼀些改进),设置存放 S3 存储桶,以及时间粒度(小时/天/月),比如每天波峰波谷明显,弹性扩缩容频繁,可以选用小时更细时间粒度进行记录,数据格式建议采⽤ Patquet。
新版支持自定义导出字段,但是一部分字段会合并成一个 map 数组进行存储,为了更方便的拆分统计,这里我们选择旧版 CUR 导出。
Glue
创建爬⾍,获取元数据信息,⽣成数据⽬录。
虽然使用 Athena 也可是使用 SQL 方式直接创建数据目录,但由于后续我们可能会有一些新加的自定义 TAG,激活后需要接入 QuickSight 中使用,那么数据目录需要进行更新,利用 Glue 可以更加方便重复执行。
添加数据源,选择对应 CUR 存储位置:
选择使⽤⾓⾊,可以点击 Create 进⾏⾃动创建:
选择数据⽬录存数数据库:
设置参数配置,点击创建完成:
注意:当有数据表变更时,选择添加新列。这样设置的作⽤在于⽐如后续⽤新的资源 TAG 激活后,在 CUR 中,就会形成新的列,如:resource_tags_user_xxx。
按照需要设置 Crawlers 执⾏计划,⼀般⼀天⼀次即可:
预览并创建:
运⾏ Crawlers,等待执行完成。
Athena
Athena 中对数据进⾏检查,也可以使⽤ presto sql 来对数据进⾏查询和分析:
对于⼀些⾃⼰写监控和分析的需求,可以使⽤ Athena JDBC 来连接使⽤。
Athena 查询示例
QuickSight
在前置条件中,我们已经启⽤了 QuickSight,只需完成数据集的配置,即可开始⾃定义开发;Dashboard 添加数据集 DataSets,这⾥需要选择 Athena:
选择对应的数据库和表:
关于选择数据是否使⽤ SPICE:
QuickSight 数据集可以在直接查询或 SPICE 模式下⼯作。
在直接查询模式下,每次加载仪表板/分析(使⽤数据集)时都会针对后端数据源执⾏查询。
在 SPICE 模式下,QuickSight 提取数据的时间点快照 – 根据数据集中指定的联接从数据集中定义的所有表中提取数据。提取的数据存储在 QuickSight SPICE 层中,⽤于驱动针对该数据集的所有请求。 SPICE 层中的数据可以按计划刷新(可以从 UI 设置),也可以通过 create-ingestion API 调⽤作为数据刷新管道中的最后⼀步触发。
查询模式可以来回切换,⽽不影响数据集中定义的元数据。使⽤ SPICE 模式有几个好处:
- 规模 – QuickSight 处理所有负载,⽽不增加底层数据源的负担。因此,您不必担⼼是否有 10 个⽤户或 10K 个⽤户通过⼀个或多个仪表板访问数据集。
- 速度 – SPICE 层专为 QuickSight 构建,注重性能,并提供超快速的仪表板加载。
- 成本 – $0.38/GB
如果设置为使⽤ SPICE,注意要记得维护数据更新计划。
可以将需要的字段建立转化映射关系,更加并于视图的阅读,⽐如以下将 AccountID 做⼀个名称的映射。
Athena 中创建视图:
将视图加⼊ QuickSight 数据集:
对 CUR 数据集进⾏编辑,将之与映射关系视图建⽴关联,Left 关联:
再⽐如我们可以将 region 对应国家名称做⼀个映射表,进⾏关联,查询也会更加直观:
QuickSight 建⽴⾃定义 Dashboard
以下均为测试数据,展⽰图形也只作为举例参考,客户在实际操作中,基于⾃⾝的需求灵活创建使⽤。
整体 Dashboard 示例:
以下举例⼀些常⽤的统计视图。
按账单显⽰总⾦额、环⽐增⻓数、环比增⻓率,以及可以单独获取 RI/SavingPlans 预付费⽤:
这⾥展示的总费⽤⽤到了自定义的计算字段,用以下方式进行添加:
按分组显⽰使⽤占比:
⽐如按 AccountID、Region 进⾏分组统计:
按资源 Tag 进⾏分组统计,⽐⽅说这⾥是按“project” Tag 进行统计,并且展示了 3 个月的环比,同时加⼊互动,可以点击与对应的 project,进⾏筛选后按 Service 拆解分析:
要实现按自定义 TAG(如 project)进行环比,需单独加入计算字段:
按 Service 进⾏分组同时,同样加⼊互动,点击 Service 可以实现过滤按指定 Service 的类⽬拆解分析:
要实现按服务进行环⽐,需单独加⼊计算字段:
按 Service 统计近 3 个月的趋势以及占比:
查看 Instances 按使⽤类别统计实付与抵扣占比:
需要实现这类统计,同样⽐较容易的⽅式是加⼊计算字段:
基于具体服务查看使⽤情况,如 EC2 按天统计使⽤⼩时数与费⽤:
利⽤ QuickSight ⻅解功能加速分析:
Analysis 中导出下载 PDF:
将 Analysis 发布 Dashboard:
Dashboard 中邮件定时通知&异常值通知:
总结
本⽂介绍了使⽤ QuickSight 进⾏账单分析的两种⽅式,标准功能使⽤起来⽅便快捷,提供了预置丰富的多维图标,但是缺乏灵活性;⾃定义构建使⽤起来更加灵活,⽅便扩展和按需设置,但是需要⼀定的研发投⼊。客户在使⽤时还是需要基于⾃⾝特点和需求选择构建⽅式,通过多为分析实现数据的价值,最终提⾼您云⽀出的透明度、控制度、可预测性,优化成本及使用,实现企业数字化转型。