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

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

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

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

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

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

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

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

הזמנות כוללות את התכונות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• משתמשים בכלי לבדיקת תקינות שאילתות במסוף Cloud de Confiance .
• הרצת סימולציה לשאילתות.

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

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

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

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

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

  This query will process 623.1 KiB when 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.

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
}

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());
    }
  }
}

// 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);
}

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']);

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))

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

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

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

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

• פקודות DML
• הצהרות DDL
• טבלאות מסודרות באשכולות

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

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

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

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

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

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

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

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

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

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

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

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

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

הימנעו משימוש ב-LIMIT בטבלאות לא מקובצות

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

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

יצירת תוצאות של שאילתות בשלבים

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

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

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

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

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

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

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

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

שימוש ב Cloud de Confiance by S3NS מחשבון העלויות

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

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

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

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

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

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

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

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

ביטול עבודות מיותרות שפועלות לאורך זמן

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

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

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

אתם יכולים לייצא את נתוני החיוב ל-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.

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

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

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

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

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

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

יש עלות לאחסון של מערכי תוצאות גדולים ב-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 כדי לזהות את המשאבים הספציפיים שמשויכים לחיובים האלה, למשל:

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

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

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

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

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

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

חיובים לא צפויים שקשורים לשאילתות, להזמנות ולהתחייבויות

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

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

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

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

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

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

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

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

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

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

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

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

• ביצוע פעולות של ML ב-BigQuery

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

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

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

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

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

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

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

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

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

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

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

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

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

ב-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).

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

• מידע נוסף על התמחור של BigQuery
• איך מבצעים אופטימיזציה של שאילתות
• איך מבצעים אופטימיזציה של האחסון

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

  • יצירה, עריכה ומחיקה של תקציבים והתראות תקציב
  • ייצוא נתוני החיוב ב-Cloud ל-BigQuery