Update hub.json

[fivetran-joemarkiewicz]

Description

Tell us about your new package!

This package models AWS Cloud Cost data from Fivetran's AWS Cloud & Usage Report connector. It uses data in the format described by the Fivetran AWS Cost & Usage Report.

The main focus of the package is to transform the core object tables into analytics-ready models, including:

• Materializes AWS Cloud Cost staging tables which leverage data in the format described by the AWS Cost & Usage Report. These staging tables clean, test, and prepare your AWS Cloud Cost data from Fivetran's connector for analysis by doing the following:
  • Names columns for consistency across all packages and for easier analysis:
    • Column names are shortened for convenience and to avoid redundancy.
  • Takes the latest export of each account's billing month report.
• Creates analytics-ready end models for monitoring and investigating cost & usage of different AWS services across your organizations.
• Generates a comprehensive data dictionary of both your AWS Cloud Cost source and modeled data through the dbt docs site.

This package does not apply freshness tests.

model	description
aws_cloud_cost__daily_overview	Daily aggregation of the Standard Cost & Usage Report (2.0) exported from AWS. Includes slew of commonly analyzed dimensions related to billing, pricing, line item buckets, and products. Contains both high-level cost and usage metrics, along with all metrics related to reservations and savings plans. Also includes financial reporting fieds relating to invoices and billing periods.
aws_cloud_cost__daily_product_report	Daily view of each account's use of and associated costs from individual AWS products for each billing period. Built off of the daily overview model.
aws_cloud_cost__daily_instance_report	Daily view of each account's use of and associated costs from different Amazon Elastic Compute Cloud (EC2) instances for each billing period. Built off of the daily overview model.

Link to your package's repository: dbt_aws_cloud_cost

Checklist

This checklist is a cut down version of the best practices that we have identified as the package hub has grown. Although meeting these checklist items is not a prerequisite to being added to the Hub, we have found that packages which don't conform provide a worse user experience.

First run experience

• (Required): The package includes a licence file detectable by GitHub, such as the Apache 2.0 or MIT licence.
• The package includes a README which explains how to get started with the package and customise its behaviour
• The README indicates which data warehouses/platforms are expected to work with this package

Customisability

• The package uses ref or source, instead of hard-coding table references.

Packages for data transformation (delete if not relevant):

• provide a mechanism (such as variables) to customise the location of source tables.
• do not assume database/schema names in sources.

Dependencies

Dependencies on dbt Core

• The package has set a supported require-dbt-version range in dbt_project.yml. Example: A package which depends on functionality added in dbt Core 1.2 should set its require-dbt-version property to [">=1.2.0", "<2.0.0"].

Dependencies on other packages defined in packages.yml:

• Dependencies are imported from the dbt Package Hub when available, as opposed to a git installation.
• Dependencies contain the widest possible range of supported versions, to minimise issues in dependency resolution.
• In particular, dependencies are not pinned to a patch version unless there is a known incompatibility.

Interoperability

• The package does not override dbt Core behaviour in such a way as to impact other dbt resources (models, tests, etc) not provided by the package.
• The package uses the cross-database macros built into dbt Core where available, such as {{ dbt.except() }} and {{ dbt.type_string() }}.
• The package disambiguates its resource names to avoid clashes with nodes that are likely to already exist in a project. For example, packages should not provide a model simply called users.

Versioning

• (Required): The package's git tags validates against the regex defined in version.py
• The package's version follows the guidance of Semantic Versioning 2.0.0. (Note in particular the recommendation for production-ready packages to be version 1.0.0 or above)

Final Notes

This package is in the final stages of development (currently just applying some polishing and adding more customization options). This will likely be ready for an initial v0.1.0 release by the end of the week. Please let me know if you have any questions.