הערכה ובקרה של עלויות

בדף הזה מתוארות שיטות מומלצות להערכה ולניהול של העלויות ב-BigQuery.

העלויות העיקריות ב-BigQuery הן עלויות המחשוב, שמשמשות לעיבוד שאילתות, ועלויות האחסון, לנתונים שמאוחסנים ב-BigQuery. ב-BigQuery יש שני סוגים של מודלים לתמחור של עיבוד שאילתות: תמחור על פי דרישה ותמחור מבוסס-קיבולת. לכל מודל יש שיטות מומלצות שונות לשליטה בעלויות. בנתונים שמאוחסנים ב-BigQuery, העלויות תלויות במודל החיוב על אחסון שמוגדר לכל מערך נתונים.

הסבר על תמחור המחשוב ב-BigQuery

יש הבדלים קלים בתמחור של המחשוב ב-BigQuery שמשפיעים על תכנון הקיבולת ועל ניהול העלויות.

מודלים של תמחור

ב-BigQuery, על מחשוב על פי דרישה אתם מחויבים לפי TiB לשאילתות ב-BigQuery.

לחלופין, אם אתם משתמשים ב-BigQuery עם תמחור מבוסס-קיבולת, אתם מחויבים על משאבי המחשוב (יחידות ה-slot) שמשמשים לעיבוד השאילתה. כדי להשתמש במודל הזה, מגדירים הזמנות ל-slots.

התכונות של ההזמנות:

  • הם מוקצים במאגרים של משבצות, ומאפשרים לכם לנהל את הקיבולת ולבודד עומסי עבודה בדרכים שמתאימות לארגון שלכם.
  • הם חייבים להיות בפרויקט ניהול אחד, והם כפופים למכסות ולמגבלות.

מודל התמחור לפי קיבולת מציע כמה מהדורות, ובכולן יש אפשרות לתשלום על השימוש בפועל, שבו החיוב הוא לפי שעות חריצים. במהדורות Enterprise ו-Enterprise Plus אפשר גם להתחייב לשנה או לשלוש שנים, וכך לחסוך כסף בהשוואה לתעריף של תשלום על השימוש.

אתם יכולים גם להגדיר הזמנות עם התאמה אוטומטית לעומס באמצעות האפשרות "תשלום לפי שימוש". למידע נוסף, קראו את המאמרים הבאים:

הגבלת העלויות לכל מודל

כשמשתמשים במודל התמחור על פי דרישה, הדרך היחידה להגביל את העלויות היא להגדיר מכסות יומיות ברמת הפרויקט או ברמת המשתמש. עם זאת, המכסות האלה אוכפות מגבלה קשיחה שמונעת מהמשתמשים להריץ שאילתות מעבר למגבלת המכסה. כדי להגדיר מכסות, קראו את המאמר יצירת מכסות בהתאמה אישית לשאילתות.

כשמשתמשים במודל התמחור לפי קיבולת באמצעות הזמנת משבצות, מציינים את המספר המקסימלי של משבצות שזמינות להזמנה. אתם יכולים גם לרכוש התחייבויות ל-slots, שמספקות מחירים מוזלים לתקופת התחייבות.

כדי להשתמש במהדורות באופן מלא על פי דרישה, אתם יכולים להגדיר את ערך הבסיס של ההזמנה ל-0 ואת הערך המקסימלי להגדרה שעונה על צורכי עומס העבודה שלכם. ‫BigQuery מגדיל באופן אוטומטי את מספר ה-slots בהתאם לעומס העבודה, בלי לחרוג מהמספר המקסימלי שהגדרתם. מידע נוסף מופיע במאמר ניהול עומסי עבודה באמצעות הזמנות.

שליטה בעלויות של שאילתות

כדי לשלוט בעלויות של שאילתות ספציפיות, מומלץ קודם לפעול לפי השיטות המומלצות לאופטימיזציה של חישוב שאילתות ולאופטימיזציה של אחסון.

בקטעים הבאים מפורטות שיטות מומלצות נוספות שיעזרו לכם לשלוט בעלויות של השאילתות.

יצירת מכסות לשאילתות בהתאמה אישית

שיטה מומלצת: השתמשו במכסות יומיות מותאמות אישית של שאילתות כדי להגביל את כמות הנתונים שעוברים עיבוד ביום.

כדי לנהל את העלויות, אתם יכולים להגדיר מכסה בהתאמה אישית שמגבילה את כמות הנתונים שעוברים עיבוד בכל יום, לכל פרויקט או לכל משתמש. המשתמשים לא יכולים להריץ שאילתות אחרי שהם מגיעים למכסה.

כדי להגדיר מכסה בהתאמה אישית, צריך תפקידים או הרשאות ספציפיים. במאמר מכסות ומגבלות מפורטות המכסות שאפשר להגדיר.

מידע נוסף זמין במאמר הגבלת העלויות לכל מודל תמחור.

בדיקת העלות המשוערת לפני הרצת שאילתה

שיטה מומלצת: לפני שמריצים שאילתות, כדאי להציג אותן בתצוגה מקדימה כדי להעריך את העלויות.

כשמשתמשים במודל התמחור על פי דרישה, השאילתות מחויבות לפי מספר הבייטים שנקראו. כדי להעריך את העלויות לפני שמריצים שאילתה:

שימוש בכלי לתיקוף שאילתות

כשמזינים שאילתה במסוף Google Cloud , הכלי לתיקוף שאילתות מאמת את התחביר של השאילתה ומספק אומדן של מספר הבייטים שנקראו. אתם יכולים להשתמש בהערכה הזו כדי לחשב את עלות השאילתה במחשבון עלויות.

  • אם השאילתה לא תקינה, הכלי לתיקוף שאילתות יציג הודעת שגיאה. לדוגמה:

    Not found: Table myProject:myDataset.myTable was not found in location US

  • אם השאילתה תקינה, הכלי לתיקוף שאילתות מספק אומדן של מספר הבייטים שנדרשים כדי לעבד את השאילתה. לדוגמה:

    This query will process 623.1 KiB when run.

הרצת בדיקה

כדי לבצע הרצת בדיקה, בצע את הפעולות הבאות:

המסוף

  1. נכנסים לדף BigQuery.

    כניסה ל-BigQuery

  2. מזינים את השאילתה בעורך השאילתות.

    אם השאילתה תקינה, מופיע סימן וי באופן אוטומטי, וגם כמות הנתונים שהשאילתה תעבד. אם השאילתה לא תקינה, יופיע סימן קריאה עם הודעת שגיאה.

BQ

מזינים שאילתה כמו זו שבהמשך באמצעות הדגל --dry_run.

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'

אם השאילתה תקינה, הפקודה יוצרת את התגובה הבאה:

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

API

כדי לבצע הרצת בדיקה באמצעות ה-API, שולחים משימת שאילתה עם dryRun שמוגדר כ-true בסוג JobConfiguration.

המשך

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Go במדריך למתחילים של BigQuery באמצעות ספריות לקוח. למידע נוסף, קראו את מאמרי העזרה של BigQuery Go API.

כדי לבצע אימות ב-BigQuery, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לספריות לקוח. 

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

Java

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Java במדריך למתחילים של BigQuery באמצעות ספריות לקוח. למידע נוסף, קראו את מאמרי העזרה של BigQuery Java API.

כדי לבצע אימות ב-BigQuery, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לספריות לקוח. 

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

Node.js

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Node.js במדריך למתחילים של BigQuery באמצעות ספריות לקוח. למידע נוסף, קראו את מאמרי העזרה של BigQuery Node.js API.

כדי לבצע אימות ב-BigQuery, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לספריות לקוח. 

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

PHP

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של PHP במדריך למתחילים של BigQuery באמצעות ספריות לקוח. למידע נוסף, קראו את מאמרי העזרה של BigQuery PHP API.

כדי לבצע אימות ב-BigQuery, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לספריות לקוח. 

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
    'projectId' => $projectId,
]);

// Set job configs
$jobConfig = $bigQuery->query($query);
$jobConfig->useQueryCache(false);
$jobConfig->dryRun(true);

// Extract query results
$queryJob = $bigQuery->startJob($jobConfig);
$info = $queryJob->info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

Python

מגדירים את המאפיין QueryJobConfig.dry_run כ-True. הפונקציה Client.query() תמיד מחזירה QueryJob שהושלם כשמספקים הגדרת שאילתה להרצה יבשה.

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Python במדריך למתחילים של BigQuery באמצעות ספריות לקוח. למידע נוסף, קראו את מאמרי העזרה של BigQuery Python API.

כדי לבצע אימות ב-BigQuery, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לספריות לקוח. 

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

הערכת עלויות של שאילתות

השיטה להערכת עלויות השאילתות משתנה בהתאם למודל התמחור של המחשוב.

אומדן עלויות של שאילתות על פי דרישה

כשמשתמשים במודל התמחור על פי דרישה, אפשר להעריך את עלות הרצת השאילתה על ידי חישוב מספר הבייטים שעובדו.

אומדן עלויות של שאילתות לפי קיבולת

כשמשתמשים בתמחור מבוסס-קיבולת, אי אפשר להעריך במדויק את העלות של שאילתה ספציפית לפני שמריצים אותה. העלויות שמבוססות על קיבולת מחושבות לפי הקיבולת הכוללת של ה-slots שהוקצו או הותאמו אוטומטית לאורך זמן, ולא לפי כמות הנתונים שנסרקו על ידי שאילתה ספציפית.

קשה להעריך את העלויות של שאילתות ספציפיות לפני ההרצה, בגלל גורמים דינמיים בזמן הריצה, כולל:

  • הקצאת משבצות דינמית: מספר המשבצות שמוקצות לשאילתה תלוי במורכבות השאילתה, באופטימיזציה של זמן הריצה ובזמינות המשאבים.
  • בו-זמניות: כמה שאילתות חולקות באופן דינמי את המשבצות הזמינות בהזמנה.
  • התנהגות של התאמה אוטומטית לעומס: אם מופעלת התאמה אוטומטית לעומס של משבצות, המערכת מגדילה ומקטינה את ההזמנה על סמך הביקוש המצטבר של עומס העבודה, ולא על סמך הפעלה של שאילתה אחת.

אחרי הרצת השאילתה, אפשר לראות את משאבי המחשוב בפועל שהשאילתה צרכה באלפיות השנייה של שימוש ב-slot (total_slot_ms) על ידי בדיקת פרטי הרצת השאילתה או שליחת שאילתה לתצוגה INFORMATION_SCHEMA.JOBS.

שיוך עלויות לפי קיבולת

שיוך עלויות הוא תהליך של חלוקה ושיוך של עלויות המחשוב של ההזמנה בין פרויקטים, צוותים או שאילתות אחרי שעומסי העבודה הופעלו.

כדי להבין את העלויות הכוללות ולהקצות אותן, אתם יכולים לשייך את עמלות ההזמנה לשאילתות ולפרויקטים ספציפיים באמצעות שיוך עלויות ההזמנה בנתוני החיוב ב-Cloud. בנתונים ובדוחות של החיוב ב-Cloud, חפשו את הפריט Analysis Slots Attribution, שבו מתבצע מעקב אחרי שעות ה-slot שבהן השתמשתם בכל פרויקט, בלי עלות נוספת או השפעה על הסכומים הכוללים בחשבונית.

מידע נוסף מופיע במאמר שיוך עלויות של הזמנות.

חישוב גודל השאילתה על פי דרישה

כדי לחשב את מספר הבייטים שעובדו על ידי סוגי השאילתות השונים, עיינו בקטעים הבאים:

הימנעו מהרצת שאילתות כדי לעיין בנתוני טבלה

שיטה מומלצת: אל תריצו שאילתות כדי לבחון או להציג תצוגה מקדימה של נתוני טבלה.

אם אתם מתנסים בנתונים או בודקים אותם, אתם יכולים להשתמש באפשרויות של תצוגה מקדימה של טבלאות כדי להציג נתונים ללא תשלום ובלי להשפיע על המכסות.

ב-BigQuery יש תמיכה באפשרויות הבאות לתצוגה מקדימה של נתונים:

  • במסוף Google Cloud , בדף פרטי הטבלה, לוחצים על הכרטיסייה Preview כדי לדגום את הנתונים.
  • בכלי שורת הפקודה של BigQuery, משתמשים בפקודה bq head ומציינים את מספר השורות שרוצים לראות בתצוגה המקדימה.
  • ב-API, משתמשים ב-tabledata.list כדי לאחזר נתוני טבלה מקבוצת שורות מסוימת.
  • הימנעו משימוש ב-LIMIT בטבלאות שלא מסודרות באשכולות. בטבלאות שלא מסודרות באשכולות, סעיף LIMIT לא יפחית את עלויות המחשוב.

הגבלת מספר הבייטים לחיוב בכל שאילתה

שיטה מומלצת: כשמשתמשים במודל התמחור על פי דרישה, כדאי להשתמש בהגדרה "מספר הבייטים המקסימלי לחיוב" כדי להגביל את עלויות השאילתות.

אתם יכולים להגביל את מספר הבייטים לחיוב בשאילתה באמצעות ההגדרה "מספר הבייטים המקסימלי לחיוב". כשמגדירים את מספר הבייטים המקסימלי לחיוב, מספר הבייטים שהשאילתה קוראת מוערך לפני ביצוע השאילתה. אם מספר הבייטים המשוער חורג מהמגבלה, השאילתה נכשלת בלי לחייב את החשבון.

בטבלאות מסודרות באשכולות, ההערכה של מספר הבייטים שיחויבו עבור שאילתה היא הגבול העליון, והיא יכולה להיות גבוהה ממספר הבייטים בפועל שיחויבו אחרי הרצת השאילתה. לכן, במקרים מסוימים, אם מגדירים את מספר הבייטים המקסימלי לחיוב, שאילתה בטבלה מסודרת באשכולות עלולה להיכשל, גם אם מספר הבייטים בפועל לחיוב לא חורג מההגדרה של מספר הבייטים המקסימלי לחיוב.

אם שאילתה נכשלת בגלל ההגדרה של מספר הבייטים המקסימלי לחיוב, תוחזר שגיאה דומה לזו:

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

כדי להגדיר את מספר הבייטים המקסימלי שיחויבו:

המסוף

  1. בעורך השאילתות, לוחצים על Edit > Query settings > Advanced options.
  2. בשדה Maximum bytes billed, מזינים מספר שלם.
  3. לוחצים על Save.

BQ

משתמשים בפקודה bq query עם הדגל --maximum_bytes_billed.

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

API

מגדירים את המאפיין maximumBytesBilled ב-JobConfigurationQuery או ב-QueryRequest.

הימנעו משימוש ב-LIMIT בטבלאות שלא מסודרות באשכולות

שיטה מומלצת: בטבלאות שאינן טבלאות מסודרות באשכולות, אל תשתמשו בסעיף LIMIT כשיטה לבקרת עלויות.

בטבלאות שלא מסודרות באשכולות, הוספת משפט LIMIT לשאילתה לא משפיעה על כמות הנתונים שנקראים. אתם מחויבים על קריאת כל הבייטים בטבלה כולה, כפי שצוין בשאילתה, למרות שהשאילתה מחזירה רק קבוצת משנה. בטבלה מסודרת באשכולות, סעיף LIMIT יכול להפחית את מספר הבייטים שנסרקים, כי הסריקה נפסקת כשנסרקים מספיק בלוקים כדי לקבל את התוצאה. החיוב הוא רק על הבייטים שנסרקים.

התממשקות של תוצאות השאילתה בשלבים

שיטה מומלצת: אם אפשר, כדאי לבצע מטריאליזציה של תוצאות השאילתה בשלבים.

אם יוצרים שאילתה גדולה עם כמה שלבים, בכל פעם שמריצים אותה, BigQuery קורא את כל הנתונים שהשאילתה דורשת. אתם מחויבים על כל הנתונים שנקראים בכל פעם שהשאילתה מופעלת.

במקום זאת, פצלו את השאילתה לשלבים, כך שבכל שלב תוצאות השאילתה יתממשו על ידי כתיבה שלהן לטבלת יעד. השאילתה בטבלת היעד הקטנה יותר מפחיתה את כמות הנתונים שנקראים ומפחיתה את העלויות. עלות האחסון של התוצאות המגובשות נמוכה בהרבה מעלות העיבוד של כמויות גדולות של נתונים.

שימוש ב-Rapid Cache כדי לשלוח שאילתות ל-Cloud Storage באמצעות טבלאות חיצוניות

שיטה מומלצת: כדאי להפעיל את Rapid Cache כששולחים שאילתות לנתונים ב-Cloud Storage באמצעות טבלאות חיצוניות.

‫Rapid Cache מספק מטמון קריאה אזורי שמגובה ב-SSD לקטגוריות של Cloud Storage, שיכול לשפר את ביצועי השאילתות ולהפחית את העלויות של שאילתות על טבלאות חיצוניות. למידע נוסף, קראו את המאמר אופטימיזציה של שאילתות בטבלאות חיצוניות ב-Cloud Storage.

שליטה בעלויות של עומסי עבודה (workloads)

בקטע הזה מתוארות שיטות מומלצות לשליטה בעלויות של עומס עבודה. עומס עבודה הוא קבוצה של שאילתות קשורות. לדוגמה, עומס עבודה יכול להיות צינור עיבוד נתונים (pipeline) לטרנספורמציה של נתונים שפועל מדי יום, קבוצה של מרכזי בקרה שמופעלים על ידי קבוצה של מנתחי נתונים עסקיים, או כמה שאילתות אד-הוק שמופעלות על ידי קבוצה של מדעני נתונים.

שימוש ב Google Cloud מחשבון העלויות

שיטה מומלצת: כדי ליצור הערכת עלות חודשית כוללת ל-BigQuery על סמך השימוש הצפוי, השתמשו במחשבון עלויותGoogle Cloud . לאחר מכן תוכלו להשוות את האומדן הזה לעלויות בפועל כדי לזהות תחומים שבהם אפשר לבצע אופטימיזציה.

על פי דרישה

כדי להעריך את העלויות בGoogle Cloud מחשבון עלויות כשמשתמשים במודל התמחור על פי דרישה:

  1. פותחים את מחשבון העלויות שלGoogle Cloud .
  2. לוחצים על הוספה לאומדן.
  3. בוחרים באפשרות BigQuery.
  4. בקטע Service type, בוחרים באפשרות על פי דרישה.
  5. בוחרים את המיקום שבו השאילתות יפעלו.
  6. בשדה Amount of data queried, מזינים את מספר הבייטים המשוער שנקראו מההרצה היבשה או מהכלי לתיקוף שאילתות.
  7. מזינים את ההערכות של נפח האחסון הנדרש ל-Active storage, ל-Long-term storage, ל-הזנת זרם נתונים ול-Streaming reads. צריך להעריך רק את האחסון הפיזי או את האחסון הלוגי, בהתאם למודל החיוב על אחסון של מערך הנתונים.
  8. האומדן מופיע בחלונית Cost details. כדי לקבל מידע נוסף על העלות המשוערת, לוחצים על פתיחת התצוגה המפורטת. אתם יכולים גם להוריד ולשתף את הערכת העלות.

מידע נוסף זמין במאמר תמחור על פי דרישה.

מהדורות

כדי להעריך את העלויות בGoogle Cloud מחשבון התמחור כשמשתמשים במודל התמחור מבוסס-הקיבולת עם מהדורות BigQuery:

  1. פותחים את מחשבון העלויות שלGoogle Cloud .
  2. לוחצים על הוספה לאומדן.
  3. בוחרים באפשרות BigQuery.
  4. בקטע סוג השירות, בוחרים באפשרות "מהדורות".
  5. בוחרים את המיקום שבו משתמשים במשבצות.
  6. בוחרים את המהדורה.
  7. בוחרים את הערכים של Maximum slots,‏ Baseline slots,‏ Commitment (אופציונלי) ו-Estimated utilization of autoscaling.
  8. בוחרים את המיקום שבו הנתונים מאוחסנים.
  9. מזינים את ההערכות של נפח האחסון הנדרש ל-Active storage, ל-Long-term storage, ל-הזנת זרם נתונים ול-Streaming reads. צריך להעריך רק את האחסון הפיזי או את האחסון הלוגי, בהתאם למודל החיוב על אחסון של מערך הנתונים.
  10. האומדן מופיע בחלונית Cost details. כדי לקבל מידע נוסף על העלות המשוערת, לוחצים על פתיחת התצוגה המפורטת. אתם יכולים גם להוריד ולשתף את הערכת העלות.

מידע נוסף זמין במאמר תמחור מבוסס-קיבולת.

שימוש בהזמנות ובהתחייבויות

שיטה מומלצת: כדי לשלוט בעלויות, כדאי להשתמש בהזמנות ובהתחייבויות ב-BigQuery.

מידע נוסף זמין במאמר הגבלת העלויות לכל מודל תמחור.

שימוש בכלי להערכת משבצות

שיטה מומלצת: השתמשו בכלי להערכת מספר ה-slots כדי להעריך את מספר ה-slots שנדרשים לעומסי העבודה שלכם.

הכלי להערכת יחידות הקיבולת של BigQuery עוזר לנהל את יחידות הקיבולת (Slot) על סמך מדדי ביצועים היסטוריים.

בנוסף, לקוחות שמשתמשים במודל התמחור על פי דרישה יכולים לראות המלצות לגבי גודל ההתחייבויות וההזמנות להתאמה אוטומטית לעומס, עם ביצועים דומים, כשהם עוברים לתמחור מבוסס-קיבולת.

ביטול משימות ארוכות ומיותרות

כדי לפנות קיבולת, בודקים את המשימות שפועלות במשך זמן רב ומוודאים שהן צריכות להמשיך לפעול. אם לא, מבטלים אותן.

צפייה בעלויות באמצעות מרכז בקרה

שיטה מומלצת: צרו מרכז בקרה לניתוח נתוני החיוב ב-Cloud, כדי שתוכלו לעקוב אחרי השימוש ב-BigQuery ולבצע בו שינויים.

אתם יכולים לייצא את נתוני החיוב ל-BigQuery ולהציג אותם באופן חזותי בכלי כמו Data Studio. במדריך המחשה חזותית של החיוב ב- Google Cloud באמצעות BigQuery ו-Data Studio מוסבר איך יוצרים לוח בקרה לחיוב.

שימוש בתקציבים ובהתראות חיוב

שיטה מומלצת: השתמשו בתקציבים של חיוב ב-Cloud כדי לעקוב אחרי החיובים ב-BigQuery במקום אחד.

התקציבים בחיוב ב-Cloud מאפשרים לעקוב אחרי העלויות בפועל בהשוואה לעלויות המתוכננות. אחרי בחירת הסכום לתקציב, צריך להגדיר את כללי הסף להתראות לגבי התקציב. הכללים האלה יגרמו לשליחת ההתראות באימייל. בעזרת ההתראות באימייל תוכלו לעקוב אחרי ניצול התקציב ב-BigQuery.

שליטה בעלויות האחסון

כדאי להשתמש בשיטות המומלצות הבאות כדי לייעל את עלויות האחסון ב-BigQuery. אפשר גם לבצע אופטימיזציה של האחסון לביצועי שאילתות.

שימוש באחסון לטווח ארוך

שיטה מומלצת: השתמשו בתמחור של אחסון לטווח ארוך כדי להפחית את עלות הנתונים הישנים יותר.

כשאתם טוענים נתונים לאחסון ב-BigQuery, הנתונים כפופים למחירי האחסון ב-BigQuery. בנתונים ישנים יותר, אתם יכולים להשתמש באופן אוטומטי בתמחור של BigQuery לאחסון לטווח ארוך.

אם יש לכם טבלה שלא שונתה במשך 90 ימים רצופים, מחיר האחסון של הטבלה הזו יורד אוטומטית ב-50 אחוז. אם יש לכם טבלה מחולקת למחיצות, כל מחיצה נחשבת בנפרד לצורך זכאות לתמחור לטווח ארוך, בכפוף לאותם כללים כמו טבלאות שלא מחולקות למחיצות.

חשוב לדעת: אחרי שטבלאות ומחיצות של טבלאות מועברות לאחסון לטווח ארוך, כל שינוי בנתונים, במטא-נתונים או בחלוקה למחיצות עלול לגרום להעברה של המשאבים האלה בחזרה לאחסון הפעיל ב-BigQuery. הנה כמה דוגמאות לפעולות שעלולות לגרום להעברה כזו:

  • הצהרות הוספה, עדכון, חיתוך, מיזוג או מחיקה שמשנות את נתוני הטבלה

  • טעינה, הוספה או הזרמה של נתונים לטבלה

  • ALTER הצהרות שמשנות את סכימת הטבלה

  • הוספה או שינוי של מאפייני טבלה כמו תיאור, תוויות או תפוגה

  • שינוי המטא-נתונים של הטבלה

הגדרת מודל החיוב על נפח האחסון

שיטה מומלצת: כדאי לבצע אופטימיזציה של מודל החיוב על האחסון בהתאם לדפוסי השימוש שלכם.

ב-BigQuery אפשר לחייב על אחסון לפי בייטים לוגיים (לא דחוסים) או פיזיים (דחוסים), או שילוב של שניהם. מודל החיוב על אחסון שמוגדר לכל מערך נתונים קובע את מחיר האחסון, אבל לא משפיע על ביצועי השאילתות.

אתם יכולים להשתמש בתצוגות של INFORMATION_SCHEMA כדי לקבוע את מודל החיוב על אחסון שמתאים לכם, על סמך דפוסי השימוש שלכם.

הימנעו מהחלפת טבלאות

שיטה מומלצת: כשמשתמשים במודל החיוב על נפח אחסון פיזי, כדאי להימנע מכתיבה חוזרת של טבלאות.

כשאתם מחליפים טבלה, למשל באמצעות הפרמטר --replace במשימות טעינה באצווה או באמצעות הצהרת ה-SQL‏ TRUNCATE TABLE, הנתונים שהוחלפו נשמרים למשך חלונות הזמן של המסע בזמן ושל הגיבוי למקרה חירום. אם אתם מחליפים טבלה לעיתים קרובות, תחויבו בעלויות אחסון נוספות.

במקום זאת, אפשר לטעון נתונים לטבלה באופן מצטבר באמצעות הפרמטר WRITE_APPEND במשימות טעינה, הצהרת ה-SQL‏ MERGE או Storage Write API.

צמצום חלון הזמן של Time Travel

שיטה מומלצת: בהתאם לדרישות שלכם, אתם יכולים להקטין את חלון הזמן של Time Travel.

אם מקצרים את חלון המסע בזמן מערך ברירת המחדל של שבעה ימים, מקצרים את תקופת השמירה של נתונים שנמחקו או שונו בטבלה. אתם מחויבים על אחסון של נתונים היסטוריים רק כשאתם משתמשים במודל החיוב על אחסון פיזי (דחוס).

חלון הזמן של המסע בזמן מוגדר ברמת מערך הנתונים. אפשר גם להגדיר את חלון ברירת המחדל של "המסע בזמן" לקבוצות נתונים חדשות באמצעות הגדרות אישיות.

שימוש בתאריך תפוגה לטבלאות יעד

שיטה מומלצת: אם אתם כותבים תוצאות של שאילתות גדולות בטבלת יעד, השתמשו בזמן ברירת המחדל לתפוגת הטבלה כדי להסיר את הנתונים כשכבר לא תצטרכו אותם.

שמירה של קבוצות תוצאות גדולות באחסון של BigQuery כרוכה בעלות. אם אתם לא צריכים גישה קבועה לתוצאות, השתמשו בתפוגת ברירת המחדל של הטבלה כדי למחוק את הנתונים באופן אוטומטי.

העברת נתונים לארכיון ב-Cloud Storage

שיטה מומלצת: כדאי לשקול להעביר נתונים לארכיון ב-Cloud Storage.

אתם יכולים להעביר נתונים מ-BigQuery ל-Cloud Storage בהתאם לצורך העסקי שלכם בארכיון. לפני שמייצאים נתונים מ-BigQuery, מומלץ לבדוק את התמחור של אחסון לטווח ארוך ואת מודל החיוב של אחסון פיזי.

פתרון בעיות שקשורות לפערים בעלויות ולחיובים לא צפויים ב-BigQuery

כדי לפתור בעיות שקשורות לחיובים לא צפויים או לפערים בעלויות ב-BigQuery, בצעו את הפעולות הבאות:

  1. כדי להבין מה מקור החיובים של BigQuery כשמסתכלים על דוח החיוב ב-Cloud, ההמלצה הראשונה היא לקבץ את החיובים לפי מק"ט, כדי שיהיה קל יותר לראות את השימוש והחיובים בשירותי BigQuery המתאימים.

  2. אחרי זה, בודקים את התמחור של המק"טים התואמים ב דף התיעוד של המק"טים או בדף Pricing בממשק המשתמש של החיוב ב-Cloud, כדי להבין באיזו תכונה מדובר. לדוגמה, BigQuery Storage Read API, אחסון לטווח ארוך, תמחור על פי דרישה, מהדורת Standard.

  3. אחרי שמזהים את המק"טים המתאימים, משתמשים בתצוגות של INFORMATION_SCHEMA כדי לזהות את המשאבים הספציפיים שמשויכים לחיובים האלה, לדוגמה:

שיקולים חשובים בפתרון בעיות:

  • חשוב לזכור שתקופת הזמן באפשרות Daily בדוח החיוב ב-Cloud מתחילה בחצות לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8), ומשתנה בהתאם לשעון הקיץ בארצות הברית. לכן צריך להתאים את החישובים ואת צבירת הנתונים לאותן מסגרות זמן.

  • כשמשווים בין ממשק המשתמש של החיוב ב-Cloud לבין ייצוא נתוני החיוב ב-Cloud ל-BigQuery, חשוב לוודא שצוברים את הנתונים לפי usage_start_time ו-usage_end_time, ולא לפי export_time.

  • אם יש כמה פרויקטים שמקושרים לחשבון לחיוב ואתם רוצים לבדוק את החיובים שמגיעים מפרויקט ספציפי, אתם יכולים לסנן לפי פרויקט.

  • חשוב לבחור את האזור הנכון כשמבצעים חקירות.

הפרויקט שלך חרג מהמכסה של בייטים שנסרקו בשאילתות בחינם

הודעת השגיאה הזו מופיעה ב-BigQuery כשמריצים שאילתה במסגרת השימוש בחינם, והחשבון מגיע למגבלת השאילתות החודשית. למידע נוסף על תמחור שאילתות, ראו רמת שימוש בחינם.

הודעת שגיאה 

Your project exceeded quota for free query bytes scanned

רזולוציה

כדי להמשיך להשתמש ב-BigQuery, צריך לשדרג את החשבון לחשבון בתשלום לחיוב ב-Cloud.

הפתרון לבעיות של חיובים לא צפויים שקשורים להרצת משימות תלוי במקור של החיובים האלה:

  • אם אתם רואים עלייה בעלויות של ניתוח נתונים על פי דרישה, יכול להיות שהיא קשורה לעלייה במספר המשימות שהופעלו או לשינוי בכמות הנתונים שצריך לעבד במשימות. אפשר לבדוק את זה בתצוגה INFORMATION_SCHEMA.JOBS.
  • אם יש עלייה בחיובים על משבצות מחויבות, כדאי לבדוק את זה באמצעות שאילתה ב-INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES כדי לראות אם נרכשו או שונו התחייבויות חדשות.
  • אם העלייה בחיובים נובעת משימוש במקומות שמורים, כדאי לבדוק את השינויים במקומות השמורים שמתועדים ב-INFORMATION_SCHEMA.RESERVATION_CHANGES. כדי להתאים את השימוש במקומות שמורים עם התאמה אוטומטית לעומס לנתוני החיוב, פועלים לפי הדוגמה להתאמה אוטומטית לעומס.

מספר שעות ה-slot שחויבו גדול ממספר שעות ה-slot שחושבו בתצוגה INFORMATION_SCHEMA.JOBS

כשמשתמשים בהזמנה עם התאמה אוטומטית לעומס, החיוב מחושב לפי מספר המשבצות שהותאמו לעומס, ולא לפי מספר המשבצות שנעשה בהן שימוש. ב-BigQuery, ההתאמה לעומס מתבצעת בכפולות של 50 משבצות, ולכן החיוב הוא על הכפולה הקרובה ביותר, גם אם בפועל נעשה שימוש בפחות מהכמות שהותאמה לעומס. כברירת מחדל, למערכת המידרוג האוטומטי יש תקופת מינימום של דקה אחת לפני צמצום אנכי בהתאם לעומס. המשמעות היא שתחויבו על דקה אחת לפחות, גם אם השאילתה השתמשה ביחידות הקיבולת למשך פחות זמן, למשל רק למשך 10 שניות מתוך הדקה. כדי להימנע מהחיובים האלה, אתם יכולים להצטרף להתאמה גמישה לעומס ב-BigQuery ברמת המקום השמור, לחיוב לפי שנייה ללא משך זמן מינימלי. בדף "התאמה אוטומטית של מספר ה-slots" מוסבר איך לחשב נכון את החיובים על הזמנה של התאמה אוטומטית של מספר ה-slots. למידע נוסף על שימוש יעיל בהתאמה אוטומטית לעומס, קראו את השיטות המומלצות להתאמה אוטומטית לעומס.

תרחיש דומה יתרחש בהזמנות ללא התאמה אוטומטית לעומס – החיוב מחושב לפי מספר המשבצות שהוקצו, ולא לפי מספר המשבצות שנעשה בהן שימוש. אם אתם רוצים להעריך את החיובים של הזמנה ללא התאמה אוטומטית לעומס, אתם יכולים לשלוח שאילתה ישירות לתצוגה RESERVATIONS_TIMELINE.

החיוב נמוך מסך הבייטים לחיוב שחושבו באמצעות INFORMATION_SCHEMA.JOBS בפרויקט שבו פועלות שאילתות על פי דרישה

יכולות להיות כמה סיבות לכך שהחיוב בפועל נמוך מהחישוב של כמות הבייטים שעובדו:

  • כל פרויקט מקבל 1TB של שאילתות בתוכנית ללא תשלום בכל חודש, ללא חיוב נוסף.
  • משרות מסוג SCRIPT לא הוחרגו מהחישוב, ולכן יכול להיות שחלק מהערכים נספרו פעמיים.
  • סוגים שונים של חיסכון שחלים על החשבון לחיוב ב-Cloud, כמו הנחות מוסכמות, שוברי פרסום ועוד. אפשר לבדוק את הקטע Savings בדוח החיוב ב-Cloud. התוכנית בחינם כוללת גם 1TB של שאילתות לחודש.

החיוב גדול יותר ממספר הבייטים שעובדו, שחושב באמצעות INFORMATION_SCHEMA.JOBS בפרויקט שבו פועלות שאילתות על פי דרישה

אם סכום החיוב גדול מהערך שחישבתם באמצעות שאילתה בתצוגה INFORMATION_SCHEMA.JOBS, יכול להיות שהסיבה לכך היא אחד מהמצבים הבאים:

  • שאילתות על טבלאות עם אבטחה ברמת השורה

    • שאילתות בטבלאות עם אבטחה ברמת השורה לא מפיקות ערך ל-total_bytes_billed בתצוגה INFORMATION_SCHEMA.JOBS, ולכן החיוב שמחושב באמצעות total_bytes_billed מהתצוגה INFORMATION_SCHEMA.JOBS יהיה נמוך מהערך שחויב. בדף שיטות מומלצות לאבטחה ברמת השורה מוסבר למה המידע הזה לא מוצג.

  • ביצוע פעולות של למידת מכונה ב-BigQuery

    • התמחור של BigQuery ML לשאילתות על פי דרישה תלוי בסוג המודל שנוצר. חלק מהפעולות האלה במודלים מחויבות בתעריף גבוה יותר מאשר שאילתות שלא קשורות ללמידת מכונה. לכן, אם רק מחברים את כל ה-total_billed_bytes של הפרויקט ומשתמשים בתעריף הסטנדרטי של התמחור על פי דרישה לכל TB, זה לא יהיה צבירת תמחור נכונה – צריך להביא בחשבון את ההבדל בתמחור לכל TB.

  • סכומי תמחור שגויים

    • מוודאים שבחישובים נעשה שימוש בערכי התמחור הנכונים לכל טרה-בייט – חשוב לבחור את האזור הנכון כי המחירים תלויים במיקום. למידע על תמחור

ההמלצה הכללית היא לפעול לפי הדרך המומלצת לחישוב השימוש במשימות על פי דרישה לצורך חיוב, שמפורטת במסמכי התיעוד שזמינים לכולם.

חיוב על שימוש ב-BigQuery Reservations API למרות שה-API מושבת ולא נעשה שימוש במקומות שמורים או בהתחייבויות

בודקים את המק"ט כדי להבין טוב יותר על אילו שירותים חויבתם. אם המק"ט שחויב הוא BigQuery Governance SKU, החיובים מגיעים מ-Knowledge Catalog. חלק מהפונקציות של Knowledge Catalog מפעילות משימות באמצעות BigQuery. החיובים האלה מעובדים עכשיו במק"ט המתאים של BigQuery Reservations API. פרטים נוספים זמינים במאמר התמחור של Knowledge Catalog.

הפרויקט מוקצה להזמנה, אבל עדיין מופיעות עלויות של ניתוח נתונים על פי דרישה ב-BigQuery

כדאי לקרוא את הקטע פתרון בעיות שקשורות להזמנות כדי לזהות מאיפה החיובים של Analysis מגיעים.

חיובים לא צפויים על משבצות בתשלום לפי שימוש (PAYG) ב-BigQuery Standard Edition

בדוח החיוב ב-Cloud, מפעילים מסנן עם התווית goog-bq-feature-type והערך BQ_STUDIO_NOTEBOOK. השימוש שיוצג לכם נמדד כ-slots בתשלום לפי שימוש במהדורת BigQuery Standard. אלה חיובים על השימוש ב-BigQuery Studio notebook. מידע נוסף על התמחור של Notebook ב-BigQuery Studio

חיובים לא צפויים על משבצות בתשלום לפי שימוש (PAYG) ב-BigQuery Enterprise

בדוח החיוב ב-Cloud, מפעילים מסנן עם התווית goog-bq-feature-type והערך SPARK_PROCEDURE. השימוש שיוצג לכם נמדד כ-slots בתשלום לפי שימוש במהדורת BigQuery Enterprise. אלה חיובים על השימוש בפרוצדורות של BigQuery Apache Spark, והם מתבצעים באופן הזה בלי קשר למודל המחשוב שבו משתמשים בפרויקט.

חיובים של BigQuery Reservations API שמופיעים אחרי שהשבתתם את Reservations API

השבתת BigQuery לא תפסיק את החיובים על ההתחייבות. כדי להפסיק את החיובים על ההתחייבות, צריך למחוק את ההתחייבות. מגדירים את תוכנית החידוש ל-NONE, וההתחייבות תימחק באופן אוטומטי כשתוקפה יפוג.

שאילתות בטבלאות קטנות מאוד גורמות לעלות גבוהה באופן לא פרופורציונלי לפי דרישה

המינימום של "נתונים מעובדים לכל טבלה שאליה מפנים" שמחויבים עליהם בשאילתת BigQuery הוא 10MiB, בלי קשר לגודל הטבלה בפועל. באופן דומה, כמות הנתונים המינימלית לחיוב של "נתונים מעובדים לכל שאילתה" היא 10MiB. כשמריצים שאילתות בטבלאות קטנות, אפילו טבלה בגודל KB, החיוב הוא על לפחות 10MiB לכל שאילתה. כתוצאה מכך, החיובים יכולים להיות גבוהים בהרבה מההערכות של החיוב על פי דרישה, והם יקרים במיוחד בתמחור של מחשוב על פי דרישה.

חיובים לא צפויים על אחסון

תרחישים שיכולים להוביל לעלייה בחיובים על אחסון:

מחיקה של טבלאות או מערכי נתונים גרמה לעלויות גבוהות יותר של אחסון ב-BigQuery

התכונה "המסע בזמן" של BigQuery שומרת נתונים שנמחקו למשך חלון הזמן שהוגדר, ועוד 7 ימים לשחזור במקרה של כשל. במהלך חלון השמירה הזה, הנתונים שנמחקו במערכי הנתונים של מודל החיוב על נפח האחסון הפיזי תורמים לעלות של נפח האחסון הפיזי הפעיל, למרות שהטבלאות לא יופיעו יותר ב-INFORMATION_SCHEMA.TABLE_STORAGE או במסוף. אם נתוני הטבלה היו באחסון לטווח ארוך, המחיקה גורמת להעברת הנתונים האלה לאחסון פיזי פעיל. זה גורם לעלייה בעלות המתאימה, כי לפי דף התמחור של האחסון ב-BigQuery, החיוב על בייטים פיזיים פעילים גבוה פי 2 בערך מהחיוב על בייטים פיזיים לטווח ארוך. כדי לצמצם את העלויות שנגרמות ממחיקת נתונים בקבוצות נתונים במודל החיוב על נפח אחסון פיזי, מומלץ להקטין את חלון הזמן של המסע בזמן ליומיים.

עלויות האחסון מצטמצמות בלי לשנות את הנתונים

ב-BigQuery המשתמשים משלמים על אחסון פעיל ואחסון לטווח ארוך. חיובים על אחסון פעיל כוללים כל טבלה או מחיצת טבלה שלא שונתה במשך 90 ימים רצופים, ואילו חיובים על אחסון לטווח ארוך כוללים טבלאות ומחיצות שלא שונו במשך 90 ימים רצופים. אפשר לראות הפחתה בעלות האחסון הכוללת כשמעבירים נתונים לאחסון לטווח ארוך, שהוא זול בכ-50% מאחסון פעיל. לפרטים נוספים, קראו על מחירי האחסון.

עלות האחסון עלתה בלי עלייה משמעותית בנפח הנתונים

עלויות האחסון יכולות לעלות אם נתונים באחסון לטווח ארוך עוברים לאחסון פעיל ב-BigQuery כתוצאה מפעולות מסוימות בנתוני הטבלה, במטא-נתונים או במחיצות. לפרטים נוספים, קראו את המאמר שימוש באחסון לטווח ארוך.

חישובי האחסון של INFORMATION_SCHEMA לא תואמים לחיוב

  • משתמשים בתצוגה INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE במקום ב-INFORMATION_SCHEMA.TABLE_STORAGE – TABLE_STORAGE_USAGE_TIMELINE מספקת נתונים מדויקים ומפורטים יותר כדי לחשב נכון את עלויות האחסון
  • השאילתות שמופעלות בתצוגות של INFORMATION_SCHEMA לא כוללות מיסים, התאמות ושגיאות עיגול – צריך להביא אותם בחשבון כשמשווים בין הנתונים. בדף הזה תוכלו לקרוא מידע נוסף על דוחות בחיוב ב-Cloud.
  • הנתונים שמוצגים בתצוגות של INFORMATION_SCHEMA הם לפי זמן אוניברסלי מתואם (UTC), ואילו הנתונים בדוח החיוב מדווחים לפי שעון החוף המערבי בארה"ב ובקנדה (UTC-8).

המאמרים הבאים