From 823430613f9dbd0aac5aa47ed8870c4297279946 Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Wed, 20 Sep 2023 15:30:53 -0400 Subject: [PATCH 01/11] Adding cost optimization to billing page --- website/docs/docs/cloud/billing.md | 84 ++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/website/docs/docs/cloud/billing.md b/website/docs/docs/cloud/billing.md index fcdbaf28bc2..7245a77fa58 100644 --- a/website/docs/docs/cloud/billing.md +++ b/website/docs/docs/cloud/billing.md @@ -94,6 +94,90 @@ There are 2 options to disable models from being built and charged: 2. Alternatively, you can delete some or all of your dbt Cloud jobs. This will ensure that no runs are kicked off, but you will permanently lose your job(s). +## Optimizing Costs within dbt Cloud + +dbt Cloud offers ways to optimize your model’s built usage and warehouse costs. + +### Best practices for optimizing successful models built + +When thinking of ways to optimize your costs from successful models built, there are simple methods to reducing those costs while still adhering to best practices. To ensure that you are still utilizing tests and rebuilding views when logic is changed, it is best to implement a combination of the best practices that best suit your needs. More specifically, if you decide to exclude views from your regularly scheduled dbt Cloud job runs, it is imperative that you set up a merge job (with a link to the section) to deploy updated view logic when changes are detected. + +#### Excluding views in a dbt Cloud job + +Many dbt Cloud users are utilizing views, which don’t always need to be rebuilt every time you run a job. For any jobs that contain views that _do not_ include macros that dynamically generate code (for example, case statements) based on upstream tables and _do not_ have tests, you can implement the following steps: + +1. Go to your current production deployment job in dbt Cloud. +2. Modify your command to include: `-exclude config.materialized:view`. +3. Save your job changes. + +If you have views that contain macros with case statements based on upstream tables, these will need to be run each time to account for new values. If you still need to test your views with each run, please use the documentation in the next section to create a custom selector. + +#### Excluding views while still running tests + +Running tests for views in every job run can help keep data quality intact and save you from the need to rerun failed jobs. To exclude views from your job run while running tests, you can follow these steps to create a custom [selector](https://docs.getdbt.com/reference/node-selection/yaml-selectors) for your job command. + +1. Open your dbt project in the dbt Cloud IDE. +2. add a file called `selectors.yml` in your top-level project folder. +3. In the file, put the following code: + + ```yaml + `selectors: + - name: skip_views_but_test_views + description: > + A default selector that will exclude materializing views + without skipping tests on views. + default: true + definition: + union: + - union: + - method: path + value: "*" + - exclude: + - method: config.materialized + value: view + - method: resource_type + value: test` + + ``` + +4. Save the file and commit it to your project. +5. Modify your dbt Cloud jobs to include `--selector skip_views_but_test_views`. + +#### Building only changed views + +If you would like to ensure that you are building views whenever the logic is changed, create a merge job that gets triggered when code is merged into main: + +1. Ensure you have a Slim CI job setup in your environment. +2. Create a new [dbt Cloud job](https://docs.getdbt.com/docs/deploy/deploy-jobs#create-and-schedule-jobs) and call it “Merge Job." +3. Set the [environment](https://docs.getdbt.com/docs/deploy/deploy-environments#types-of-environments) to your CI environment. +4. Set Commands to: `dbt run -s state:modified+`. + - Note: It's not using dbt build because it already used Slim CI to both run and test the code that just got merged into main, so executing a build command in this context is unnecessary. +5. Under the execution settings, select the default production job to compare changes against: + - Defer to a previous run state — Select the “Merge Job” you created so the job compares and identifies what has changed since the last merge. +6. In your dbt project, follow the steps in this [guide](https://docs.getdbt.com/guides/orchestration/custom-cicd-pipelines/3-dbt-cloud-job-on-merge) to create a script to trigger the dbt Cloud API to run your job after a merge happens within your git repository or watch this [video](https://www.loom.com/share/e7035c61dbed47d2b9b36b5effd5ee78?sid=bcf4dd2e-b249-4e5d-b173-8ca204d9becb). + +The purpose of the merge job is to: + +- Immediately deploy any changes from PRs to production. +- Ensure your production views remain up-to-date with how they’re defined in your codebase while remaining cost-efficient when running jobs in production. + +The merge action will optimize your cloud data platform spend and shorten job times, but you’ll need to decide if making the change is right for your dbt project. + +### Reworking inefficient models + +#### Job Insights Tab + +To reduce your warehouse spend, you can identify what models, on average, are taking the longest to build in the Job page under the **Insights** tab. This chart looks at the average run time for each model based on its last 20 runs. Any models that are taking longer than anticipated to build may be prime candidates for optimization, which will ultimately reduce cloud warehouse spending. + +#### Model Timing Tab + +If you would like to understand better how long each model takes to run within the context of a specific run, you can look at our **Model Timing** tab. Select the run of interest on the **Run History** page to find the Model Timing tab. Within that Run page, click **Model Timing**. + +Once you have identified which models could be optimized, be sure to check out some of our other resources that walk through how to optimize your work: +* [Build scalable and trustworthy data pipelines with dbt and BigQuery](https://services.google.com/fh/files/misc/dbt_bigquery_whitepaper.pdf) +* [Best Practices for Optimizing Your dbt and Snowflake Deployment](https://www.snowflake.com/wp-content/uploads/2021/10/Best-Practices-for-Optimizing-Your-dbt-and-Snowflake-Deployment.pdf) +* [How to optimize and troubleshoot dbt models on Databricks](https://docs.getdbt.com/guides/dbt-ecosystem/databricks-guides/how_to_optimize_dbt_models_on_databricks). + ## FAQs * What happens if I need more than 8 seats on the Team plan? From 0f3d8aeabbf93c15436b0578b13a68e4877de18a Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Thu, 21 Sep 2023 14:58:44 -0400 Subject: [PATCH 02/11] Apply suggestions from code review Co-authored-by: Ly Nguyen <107218380+nghi-ly@users.noreply.github.com> --- website/docs/docs/cloud/billing.md | 52 +++++++++++++++--------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/website/docs/docs/cloud/billing.md b/website/docs/docs/cloud/billing.md index 7245a77fa58..e09d4371d88 100644 --- a/website/docs/docs/cloud/billing.md +++ b/website/docs/docs/cloud/billing.md @@ -94,34 +94,34 @@ There are 2 options to disable models from being built and charged: 2. Alternatively, you can delete some or all of your dbt Cloud jobs. This will ensure that no runs are kicked off, but you will permanently lose your job(s). -## Optimizing Costs within dbt Cloud +## Optimize costs in dbt Cloud dbt Cloud offers ways to optimize your model’s built usage and warehouse costs. ### Best practices for optimizing successful models built -When thinking of ways to optimize your costs from successful models built, there are simple methods to reducing those costs while still adhering to best practices. To ensure that you are still utilizing tests and rebuilding views when logic is changed, it is best to implement a combination of the best practices that best suit your needs. More specifically, if you decide to exclude views from your regularly scheduled dbt Cloud job runs, it is imperative that you set up a merge job (with a link to the section) to deploy updated view logic when changes are detected. +When thinking of ways to optimize your costs from successful models built, there are methods to reduce those costs while still adhering to best practices. To ensure that you are still utilizing tests and rebuilding views when logic is changed, it's recommended to implement a combination of the best practices that fit your needs. More specifically, if you decide to exclude views from your regularly scheduled dbt Cloud job runs, it's imperative that you set up a merge job (with a link to the section) to deploy updated view logic when changes are detected. -#### Excluding views in a dbt Cloud job +#### Exclude views in a dbt Cloud job -Many dbt Cloud users are utilizing views, which don’t always need to be rebuilt every time you run a job. For any jobs that contain views that _do not_ include macros that dynamically generate code (for example, case statements) based on upstream tables and _do not_ have tests, you can implement the following steps: +Many dbt Cloud users utilize views, which don’t always need to be rebuilt every time you run a job. For any jobs that contain views that _do not_ include macros that dynamically generate code (for example, case statements) based on upstream tables and also _do not_ have tests, you can implement these steps: 1. Go to your current production deployment job in dbt Cloud. 2. Modify your command to include: `-exclude config.materialized:view`. 3. Save your job changes. -If you have views that contain macros with case statements based on upstream tables, these will need to be run each time to account for new values. If you still need to test your views with each run, please use the documentation in the next section to create a custom selector. +If you have views that contain macros with case statements based on upstream tables, these will need to be run each time to account for new values. If you still need to test your views with each run, follow the [Exclude views while still running tests](#exclude-views-while-running-tests) best practice to create a custom selector. #### Excluding views while still running tests Running tests for views in every job run can help keep data quality intact and save you from the need to rerun failed jobs. To exclude views from your job run while running tests, you can follow these steps to create a custom [selector](https://docs.getdbt.com/reference/node-selection/yaml-selectors) for your job command. 1. Open your dbt project in the dbt Cloud IDE. -2. add a file called `selectors.yml` in your top-level project folder. -3. In the file, put the following code: +2. Add a file called `selectors.yml` in your top-level project folder. +3. In the file, add the following code: ```yaml - `selectors: + selectors: - name: skip_views_but_test_views description: > A default selector that will exclude materializing views @@ -136,25 +136,25 @@ Running tests for views in every job run can help keep data quality intact and s - method: config.materialized value: view - method: resource_type - value: test` + value: test ``` 4. Save the file and commit it to your project. 5. Modify your dbt Cloud jobs to include `--selector skip_views_but_test_views`. -#### Building only changed views +#### Build only changed views -If you would like to ensure that you are building views whenever the logic is changed, create a merge job that gets triggered when code is merged into main: +If you want to ensure that you're building views whenever the logic is changed, create a merge job that gets triggered when code is merged into main: -1. Ensure you have a Slim CI job setup in your environment. -2. Create a new [dbt Cloud job](https://docs.getdbt.com/docs/deploy/deploy-jobs#create-and-schedule-jobs) and call it “Merge Job." -3. Set the [environment](https://docs.getdbt.com/docs/deploy/deploy-environments#types-of-environments) to your CI environment. -4. Set Commands to: `dbt run -s state:modified+`. - - Note: It's not using dbt build because it already used Slim CI to both run and test the code that just got merged into main, so executing a build command in this context is unnecessary. -5. Under the execution settings, select the default production job to compare changes against: - - Defer to a previous run state — Select the “Merge Job” you created so the job compares and identifies what has changed since the last merge. -6. In your dbt project, follow the steps in this [guide](https://docs.getdbt.com/guides/orchestration/custom-cicd-pipelines/3-dbt-cloud-job-on-merge) to create a script to trigger the dbt Cloud API to run your job after a merge happens within your git repository or watch this [video](https://www.loom.com/share/e7035c61dbed47d2b9b36b5effd5ee78?sid=bcf4dd2e-b249-4e5d-b173-8ca204d9becb). +1. Ensure you have a [CI job setup](/docs/deploy/ci-jobs) in your environment. +2. Create a new [deploy job](/docs/deploy/deploy-jobs#create-and-schedule-jobs) and call it “Merge Job". +3. Set the  **Environment** to your CI environment. Refer to [Types of environments](/docs/deploy/deploy-environments#types-of-environments) for more details. +4. Set **Commands** to: `dbt run -s state:modified+`. + Executing `dbt build` in this context is unnecessary because the CI job was used to both run and test the code that just got merged into main. +5. Under the **Execution Settings**, select the default production job to compare changes against: + - **Defer to a previous run state** — Select the “Merge Job” you created so the job compares and identifies what has changed since the last merge. +6. In your dbt project, follow the steps in [Run a dbt Cloud job on merge](/guides/orchestration/custom-cicd-pipelines/3-dbt-cloud-job-on-merge) to create a script to trigger the dbt Cloud API to run your job after a merge happens within your git repository or watch this [video](https://www.loom.com/share/e7035c61dbed47d2b9b36b5effd5ee78?sid=bcf4dd2e-b249-4e5d-b173-8ca204d9becb). The purpose of the merge job is to: @@ -163,20 +163,20 @@ The purpose of the merge job is to: The merge action will optimize your cloud data platform spend and shorten job times, but you’ll need to decide if making the change is right for your dbt project. -### Reworking inefficient models +### Rework inefficient models -#### Job Insights Tab +#### Job Insights tab -To reduce your warehouse spend, you can identify what models, on average, are taking the longest to build in the Job page under the **Insights** tab. This chart looks at the average run time for each model based on its last 20 runs. Any models that are taking longer than anticipated to build may be prime candidates for optimization, which will ultimately reduce cloud warehouse spending. +To reduce your warehouse spend, you can identify what models, on average, are taking the longest to build in the Job page under the **Insights** tab. This chart looks at the average run time for each model based on its last 20 runs. Any models that are taking longer than anticipated to build might be prime candidates for optimization, which will ultimately reduce cloud warehouse spending. -#### Model Timing Tab +#### Model Timing tab -If you would like to understand better how long each model takes to run within the context of a specific run, you can look at our **Model Timing** tab. Select the run of interest on the **Run History** page to find the Model Timing tab. Within that Run page, click **Model Timing**. +To understand better how long each model takes to run within the context of a specific run, you can look at the **Model Timing** tab. Select the run of interest on the **Run History** page to find the tab. On that **Run** page, click **Model Timing**. -Once you have identified which models could be optimized, be sure to check out some of our other resources that walk through how to optimize your work: +Once you have identified which models could be optimized, check out these other resources that walk through how to optimize your work: * [Build scalable and trustworthy data pipelines with dbt and BigQuery](https://services.google.com/fh/files/misc/dbt_bigquery_whitepaper.pdf) * [Best Practices for Optimizing Your dbt and Snowflake Deployment](https://www.snowflake.com/wp-content/uploads/2021/10/Best-Practices-for-Optimizing-Your-dbt-and-Snowflake-Deployment.pdf) -* [How to optimize and troubleshoot dbt models on Databricks](https://docs.getdbt.com/guides/dbt-ecosystem/databricks-guides/how_to_optimize_dbt_models_on_databricks). +* [How to optimize and troubleshoot dbt models on Databricks](/guides/dbt-ecosystem/databricks-guides/how_to_optimize_dbt_models_on_databricks). ## FAQs From cb655d406904cbcc7c0e8b937cfed4ef0ff6313c Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Thu, 21 Sep 2023 14:59:58 -0400 Subject: [PATCH 03/11] Update website/docs/docs/cloud/billing.md --- website/docs/docs/cloud/billing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud/billing.md b/website/docs/docs/cloud/billing.md index e09d4371d88..78845ac30e4 100644 --- a/website/docs/docs/cloud/billing.md +++ b/website/docs/docs/cloud/billing.md @@ -112,7 +112,7 @@ Many dbt Cloud users utilize views, which don’t always need to be rebuilt ever If you have views that contain macros with case statements based on upstream tables, these will need to be run each time to account for new values. If you still need to test your views with each run, follow the [Exclude views while still running tests](#exclude-views-while-running-tests) best practice to create a custom selector. -#### Excluding views while still running tests +#### Exclude views while running tests Running tests for views in every job run can help keep data quality intact and save you from the need to rerun failed jobs. To exclude views from your job run while running tests, you can follow these steps to create a custom [selector](https://docs.getdbt.com/reference/node-selection/yaml-selectors) for your job command. From eb731a12a5094b13b688ff5302732dcacff7634b Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Thu, 21 Sep 2023 19:53:11 -0600 Subject: [PATCH 04/11] Update dbt-project-yml-context.md --- .../dbt-jinja-functions/dbt-project-yml-context.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md b/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md index e0701e5d091..7a311c6140d 100644 --- a/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md +++ b/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md @@ -1,5 +1,5 @@ --- -title: " About dbt_project.yml context variables" +title: " About dbt_project.yml context" sidebar_label: "dbt_project.yml context" id: "dbt-project-yml-context" description: "The context variables and methods are available when configuring resources in the dbt_project.yml file." @@ -11,11 +11,13 @@ and `snapshots:` keys in the `dbt_project.yml` file. **Available context variables:** - [target](/reference/dbt-jinja-functions/target) -- [env_var](/reference/dbt-jinja-functions/env_var) -- [vars](/reference/dbt-jinja-functions/var) (_Note: only variables defined with `--vars` are available_) - [builtins](/reference/dbt-jinja-functions/builtins) - [dbt_version](/reference/dbt-jinja-functions/dbt_version) +**Available context methods:** +- [env_var](/reference/dbt-jinja-functions/env_var) +- [var](/reference/dbt-jinja-functions/var) (_Note: only variables defined with `--vars` are available_) + ### Example configuration From 2d15910e01d1ed79b0c380e1f90f7268c0093bc5 Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Thu, 21 Sep 2023 20:04:06 -0600 Subject: [PATCH 05/11] Swap the order of context methods and variables --- .../dbt-jinja-functions/dbt-project-yml-context.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md b/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md index 7a311c6140d..8ad228f7780 100644 --- a/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md +++ b/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md @@ -2,22 +2,21 @@ title: " About dbt_project.yml context" sidebar_label: "dbt_project.yml context" id: "dbt-project-yml-context" -description: "The context variables and methods are available when configuring resources in the dbt_project.yml file." +description: "The context methods and variables available when configuring resources in the dbt_project.yml file." --- The following context variables and methods are available when configuring resources in the `dbt_project.yml` file. This applies to the `models:`, `seeds:`, and `snapshots:` keys in the `dbt_project.yml` file. -**Available context variables:** -- [target](/reference/dbt-jinja-functions/target) -- [builtins](/reference/dbt-jinja-functions/builtins) -- [dbt_version](/reference/dbt-jinja-functions/dbt_version) - **Available context methods:** - [env_var](/reference/dbt-jinja-functions/env_var) - [var](/reference/dbt-jinja-functions/var) (_Note: only variables defined with `--vars` are available_) +**Available context variables:** +- [target](/reference/dbt-jinja-functions/target) +- [builtins](/reference/dbt-jinja-functions/builtins) +- [dbt_version](/reference/dbt-jinja-functions/dbt_version) ### Example configuration From e8c86b66d4119bbc397e64012dd6a7346957a245 Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Fri, 22 Sep 2023 07:13:59 -0600 Subject: [PATCH 06/11] Swap the order of context methods and variables --- .../reference/dbt-jinja-functions/dbt-project-yml-context.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md b/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md index 8ad228f7780..0d377d29cef 100644 --- a/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md +++ b/website/docs/reference/dbt-jinja-functions/dbt-project-yml-context.md @@ -5,7 +5,7 @@ id: "dbt-project-yml-context" description: "The context methods and variables available when configuring resources in the dbt_project.yml file." --- -The following context variables and methods are available when configuring +The following context methods and variables are available when configuring resources in the `dbt_project.yml` file. This applies to the `models:`, `seeds:`, and `snapshots:` keys in the `dbt_project.yml` file. From c51321f7db16cf7323aa8ae4840bc422a5ea75a5 Mon Sep 17 00:00:00 2001 From: Doug Beatty <44704949+dbeatty10@users.noreply.github.com> Date: Fri, 22 Sep 2023 09:33:43 -0600 Subject: [PATCH 07/11] Document the `is_integer` method --- website/docs/reference/dbt-classes.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/website/docs/reference/dbt-classes.md b/website/docs/reference/dbt-classes.md index 5bd8a4f5ef0..72e11b98ed4 100644 --- a/website/docs/reference/dbt-classes.md +++ b/website/docs/reference/dbt-classes.md @@ -86,6 +86,7 @@ col = Column('name', 'varchar', 255) col.is_string() # True col.is_numeric() # False col.is_number() # False +col.is_integer() # False col.is_float() # False col.string_type() # character varying(255) col.numeric_type('numeric', 12, 4) # numeric(12,4) @@ -112,6 +113,7 @@ col.numeric_type('numeric', 12, 4) # numeric(12,4) - **is_string()**: Returns True if the column is a String type (eg. text, varchar), else False - **is_numeric()**: Returns True if the column is a fixed-precision Numeric type (eg. `numeric`), else False - **is_number()**: Returns True if the column is a number-y type (eg. `numeric`, `int`, `float`, or similar), else False +- **is_integer()**: Returns True if the column is an integer (eg. `int`, `bigint`, `serial` or similar), else False - **is_float()**: Returns True if the column is a float type (eg. `float`, `float64`, or similar), else False - **string_size()**: Returns the width of the column if it is a string type, else, an exception is raised @@ -136,6 +138,9 @@ col.numeric_type('numeric', 12, 4) # numeric(12,4) -- Return true if the column is a number {{ string_column.is_number() }} +-- Return true if the column is an integer +{{ string_column.is_integer() }} + -- Return true if the column is a float {{ string_column.is_float() }} @@ -151,6 +156,9 @@ col.numeric_type('numeric', 12, 4) # numeric(12,4) -- Return true if the column is a number {{ numeric_column.is_number() }} +-- Return true if the column is an integer +{{ numeric_column.is_integer() }} + -- Return true if the column is a float {{ numeric_column.is_float() }} From c49afb1bb7e0a29e8d6372cfa5cf40be6b1ce463 Mon Sep 17 00:00:00 2001 From: Ly Nguyen <107218380+nghi-ly@users.noreply.github.com> Date: Fri, 22 Sep 2023 12:05:50 -0700 Subject: [PATCH 08/11] Update website/docs/docs/cloud/billing.md --- website/docs/docs/cloud/billing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud/billing.md b/website/docs/docs/cloud/billing.md index 78845ac30e4..d63cd43b47c 100644 --- a/website/docs/docs/cloud/billing.md +++ b/website/docs/docs/cloud/billing.md @@ -167,7 +167,7 @@ The merge action will optimize your cloud data platform spend and shorten job ti #### Job Insights tab -To reduce your warehouse spend, you can identify what models, on average, are taking the longest to build in the Job page under the **Insights** tab. This chart looks at the average run time for each model based on its last 20 runs. Any models that are taking longer than anticipated to build might be prime candidates for optimization, which will ultimately reduce cloud warehouse spending. +To reduce your warehouse spend, you can identify what models, on average, are taking the longest to build in the **Job** page under the **Insights** tab. This chart looks at the average run time for each model based on its last 20 runs. Any models that are taking longer than anticipated to build might be prime candidates for optimization, which will ultimately reduce cloud warehouse spending. #### Model Timing tab From 9f5b4812903317c7bae037132a7607d8999670f5 Mon Sep 17 00:00:00 2001 From: Ly Nguyen <107218380+nghi-ly@users.noreply.github.com> Date: Fri, 22 Sep 2023 12:06:04 -0700 Subject: [PATCH 09/11] Update website/docs/docs/cloud/billing.md --- website/docs/docs/cloud/billing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud/billing.md b/website/docs/docs/cloud/billing.md index d63cd43b47c..b1d0adc7da7 100644 --- a/website/docs/docs/cloud/billing.md +++ b/website/docs/docs/cloud/billing.md @@ -176,7 +176,7 @@ To understand better how long each model takes to run within the context of a sp Once you have identified which models could be optimized, check out these other resources that walk through how to optimize your work: * [Build scalable and trustworthy data pipelines with dbt and BigQuery](https://services.google.com/fh/files/misc/dbt_bigquery_whitepaper.pdf) * [Best Practices for Optimizing Your dbt and Snowflake Deployment](https://www.snowflake.com/wp-content/uploads/2021/10/Best-Practices-for-Optimizing-Your-dbt-and-Snowflake-Deployment.pdf) -* [How to optimize and troubleshoot dbt models on Databricks](/guides/dbt-ecosystem/databricks-guides/how_to_optimize_dbt_models_on_databricks). +* [How to optimize and troubleshoot dbt models on Databricks](/guides/dbt-ecosystem/databricks-guides/how_to_optimize_dbt_models_on_databricks) ## FAQs From 554007af0dbb8fd00db68042785ee37caf819988 Mon Sep 17 00:00:00 2001 From: Ly Nguyen <107218380+nghi-ly@users.noreply.github.com> Date: Fri, 22 Sep 2023 12:06:33 -0700 Subject: [PATCH 10/11] Update website/docs/docs/cloud/billing.md --- website/docs/docs/cloud/billing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/cloud/billing.md b/website/docs/docs/cloud/billing.md index b1d0adc7da7..61251f6e41d 100644 --- a/website/docs/docs/cloud/billing.md +++ b/website/docs/docs/cloud/billing.md @@ -173,7 +173,7 @@ To reduce your warehouse spend, you can identify what models, on average, are ta To understand better how long each model takes to run within the context of a specific run, you can look at the **Model Timing** tab. Select the run of interest on the **Run History** page to find the tab. On that **Run** page, click **Model Timing**. -Once you have identified which models could be optimized, check out these other resources that walk through how to optimize your work: +Once you've identified which models could be optimized, check out these other resources that walk through how to optimize your work: * [Build scalable and trustworthy data pipelines with dbt and BigQuery](https://services.google.com/fh/files/misc/dbt_bigquery_whitepaper.pdf) * [Best Practices for Optimizing Your dbt and Snowflake Deployment](https://www.snowflake.com/wp-content/uploads/2021/10/Best-Practices-for-Optimizing-Your-dbt-and-Snowflake-Deployment.pdf) * [How to optimize and troubleshoot dbt models on Databricks](/guides/dbt-ecosystem/databricks-guides/how_to_optimize_dbt_models_on_databricks) From db134a0f0595e702ca1843416eab029be8407779 Mon Sep 17 00:00:00 2001 From: Kevin Deggelman Date: Fri, 22 Sep 2023 15:02:59 -0700 Subject: [PATCH 11/11] Update broken blog link The old link redirects to https://www.getdbt.com/blog --- .../best-practices/how-we-style/2-how-we-style-our-sql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/guides/best-practices/how-we-style/2-how-we-style-our-sql.md b/website/docs/guides/best-practices/how-we-style/2-how-we-style-our-sql.md index 9684a498bce..8c61e63b888 100644 --- a/website/docs/guides/best-practices/how-we-style/2-how-we-style-our-sql.md +++ b/website/docs/guides/best-practices/how-we-style/2-how-we-style-our-sql.md @@ -25,7 +25,7 @@ id: 2-how-we-style-our-sql - 🔙 Fields should be stated before aggregates and window functions. - 🤏🏻 Aggregations should be executed as early as possible (on the smallest data set possible) before joining to another table to improve performance. -- 🔢 Ordering and grouping by a number (eg. group by 1, 2) is preferred over listing the column names (see [this classic rant](https://blog.getdbt.com/write-better-sql-a-defense-of-group-by-1/) for why). Note that if you are grouping by more than a few columns, it may be worth revisiting your model design. +- 🔢 Ordering and grouping by a number (eg. group by 1, 2) is preferred over listing the column names (see [this classic rant](https://www.getdbt.com/blog/write-better-sql-a-defense-of-group-by-1) for why). Note that if you are grouping by more than a few columns, it may be worth revisiting your model design. ## Joins