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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשמזינים שאילתה ב 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

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי 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))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

  1. בQuery editor (עורך השאילתות), לוחצים על More > Query settings > Advanced options (עוד > הגדרות של שאילתות > אפשרויות מתקדמות).
  2. בשדה מספר הבייטים המקסימלי שיחויבו, מזינים מספר שלם.
  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 קורא את כל הנתונים שנדרשים בשאילתה. תחויבו על כל הנתונים שנקראים בכל פעם שהשאילתה מופעלת.

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

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

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

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

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

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

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

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

על פי דרישה

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

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

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

מהדורות

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

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

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

שימוש בהזמנות ובחיובים מראש

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

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

שימוש בכלי להערכת יחידות קיבולת

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

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

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

ביטול עבודות מיותרות לטווח ארוך

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת מודל החיוב של האחסון

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

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

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

הימנעו מדריסת טבלאות

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

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

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

הקטנת החלון של האפשרות לחזור אחורה בזמן

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

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

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

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

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

יש עלות לאחסון של קבוצות גדולות של תוצאות ב-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), ומשתנה בהתאם לשעון הקיץ בארצות הברית. לכן, צריך להתאים את החישובים ואת צבירת הנתונים כך שיתאימו לאותן מסגרות זמן.

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

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

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

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

הודעת השגיאה 

Your project exceeded quota for free query bytes scanned

רזולוציה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חיובים לא צפויים על משבצות בתשלום לפי שימוש (PAYG) במהדורת BigQuery Standard

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

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

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

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

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

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

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

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

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

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

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

העלויות של האחסון יורדות בלי שצריך לבצע שינויים בנתונים

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

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

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