J'ai dépensé sans le savoir 3 000 $ en 6 heures en une seule requête dans Google Cloud BigQuery. Voici pourquoi et 3 étapes faciles pour optimiser les coûts.  Dans cet article  🙈 Vous découvrirez ce qui contribue aux coûts de BigQuery.  🏛️ Nous allons plonger dans l'architecture de BigQuery.  💰 Vous apprendrez 3 étapes faciles pour économiser 99,97 % sur votre prochaine facture Google Cloud.  Allons-y.  Comment est-ce arrivé?  Je développais un script pour préparer des échantillons de données pour les clients qui demandaient des consultations. Les exemples ont 100 lignes dans chaque fichier, et ils sont divisés en 55 paramètres régionaux. Ma requête ressemble à ceci   SELECT * FROM `project.dataset.table` WHERE ts BETWEEN TIMESTAMP("2022-12-01") AND TIMESTAMP("2023-02-28") AND locale = "US" LIMIT 100;  Les données ont été stockées dans « europe-west-4 », et le   . Ainsi, en exécutant le script, j'ai traité : prix de l'interrogation est de 6 $ par To  500 To de données au total  3 To de données par pays en moyenne  54 $ par fichier d'échantillon de données en moyenne  Très cher.  Le script qui a coûté 3 000 $  Le script a été écrit en   . modules JavaScript   // bq-samples.mjs import { BigQuery } from "@google-cloud/bigquery"; import { Parser } from "@json2csv/plainjs"; import makeDir from "make-dir"; import { write } from "./write.mjs"; import { locales } from "./locales.mjs"; import { perf } from "./performance.mjs"; const q = (locale, start, end, limit) => `SELECT * FROM \`project.dataset.table\` WHERE ts BETWEEN TIMESTAMP("2022-12-01") AND TIMESTAMP("2023-02-28") AND locale = "${locale}" LIMIT ${limit}` async function main() { const timer = perf() const dir = await makeDir('samples') const bigquery = new BigQuery() const csvParser = new Parser({}) try { const jobs = locales.map((locale) => async () => { // get query result from BigQuery const [job] = await bigquery.createQueryJob({ query: q(locale, "2022-12-01", "2023-02-28", 100), }) const [rows] = await job.getQueryResults() // parse rows into csv format const csv = parse(csvParser, rows) // write data into csv files and store in the file system await write(csv, dir, locale, "2022-12-01", "2023-02-28", 100) }) await Promise.all(jobs.map((job) => job())) console.log(`✨ Done in ${timer.stop()} seconds.`) } catch (error) { console.error('❌ Failed to create sample file', error) } } await main()  Il génère un exemple de fichier au format   par locale. Le processus est simple : CSV  Interroger la table BigQuery avec une heure locale, une date de début, une date de fin et une limite.  Transformer le résultat de la requête au format CSV.  Ecriture du CSV dans le système de fichiers.  Répéter le processus pour tous les paramètres régionaux.  Quel est le problème?  Il s'avère que j'ai fait plusieurs erreurs dans ma requête. Si vous examinez à nouveau le modèle de tarification, vous remarquerez que le coût n'est lié qu'à la quantité de données que vous traitez. Il est donc clair que ma requête a recherché trop de données pour produire 100 lignes.  Avec cet aperçu, optimisons la requête étape par étape.  Ne sélectionnez pas *  C'est un peu contre-intuitif. Pourquoi mon instruction select a-t-elle quelque chose à voir avec la quantité de données qu'elle traite ? Quelles que soient les colonnes que je sélectionne, je devrais lire à partir des mêmes ressources et données, n'est-ce pas ?  Cela n'est vrai que pour les bases de données orientées lignes.  BigQuery est en fait une   . Il est orienté colonne, ce qui signifie que les données sont structurées en colonnes. BigQuery utilise   comme moteur de calcul sous-jacent. Lorsque les données sont déplacées du stockage à froid vers le stockage actif dans Dremel, il stocke les données dans une structure arborescente. base de données en colonnes Dremel  Chaque nœud feuille est un « enregistrement » orienté colonne au format   .  Protobuf  Dans BigQuery, chaque nœud est une VM. Une exécution de requête se propage depuis le serveur racine (nœud) via des serveurs intermédiaires vers les serveurs feuilles pour récupérer les colonnes sélectionnées.  Nous pouvons modifier la requête pour sélectionner des colonnes individuelles :   SELECT session_info_1, session_info_2, session_info_3, user_info_1, user_info_2, user_info_3, query_info_1, query_info_2, query_info_3, impression_info_1, impression_info_2, impression_info_3, ts FROM `project.dataset.table` WHERE ts BETWEEN TIMESTAMP("2022-12-01") AND TIMESTAMP("2023-02-28") AND locale = "US" LIMIT 100;  En sélectionnant explicitement toutes les colonnes, j'ai pu réduire les données traitées de 3,08 To à 2,94 To. C'est une   . réduction de 100 Go  Utiliser une table partitionnée et interroger uniquement des sous-ensembles de données  Google Cloud recommande de   . Il nous permet d'interroger uniquement un sous-ensemble de données. partitionner les tables par date  Pour optimiser davantage la requête, nous pouvons réduire la plage de dates dans l'instruction where, car la table est partitionnée par la colonne "ts".   SELECT session_info_1, session_info_2, session_info_3, user_info_1, user_info_2, user_info_3, query_info_1, query_info_2, query_info_3, impression_info_1, impression_info_2, impression_info_3, ts FROM `project.dataset.table` WHERE ts = TIMESTAMP("2022-12-01") AND locale = "US" LIMIT 100;  J'ai réduit la plage de dates à un jour au lieu de trois mois. J'ai pu réduire les données traitées à   . C'est juste une fraction de la requête d'origine. 37,43 Go  Utiliser les résultats de requête matérialisés par étapes  Une autre façon de réduire les coûts consiste à réduire le jeu de données à partir duquel vous interrogez. BigQuery propose   pour stocker les résultats des requêtes sous forme d'ensembles de données plus petits. Les tables de destination se présentent sous deux formes : temporaire et permanente. des tables de destination  Étant donné que les tables temporaires ont une durée de vie et qu'elles ne sont pas conçues pour être partagées et interrogées, j'ai créé une table de destination permanente pour matérialiser le résultat de la requête :   // bq-samples.mjs const dataset = bigquery.dataset('materialized_dataset') const materialzedTable = dataset.table('materialized_table') // ... const [job] = await bigquery.createQueryJob({ query: q(locale, '2022-12-01', '2023-02-28', 100), destination: materialzedTable, })  Les résultats de la requête seront stockés dans la table de destination. Il servira de référence pour les futures requêtes. Chaque fois qu'il est possible d'interroger à partir de la table de destination, BigQuery traite les données de la table. Cela réduira considérablement la taille des données que nous recherchons.  Dernières pensées  C'est une étude très intéressante pour réduire les coûts dans BigQuery. En seulement trois étapes faciles :  Ne pas utiliser *  Utiliser une table partitionnée et interroger uniquement des sous-ensembles de données  Utiliser les résultats de requête matérialisés par étapes  J'ai pu réduire la taille des données traitées   . Il réduit considérablement le coût total de 3 000 $ à 30 $. de 3 To à 37,5 Go  Si vous souhaitez en savoir plus sur l'architecture BigQuery, voici les références qui m'ont aidé :   BigQuery expliqué : présentation de l'architecture de BigQuery   Un regard sur Dremel   Colossus sous le capot : un aperçu du système de stockage évolutif de Google   Jupiter en évolution : réflexion sur la transformation du réseau de centres de données de Google  Vous pouvez en savoir plus sur   dans la documentation Google Cloud. les optimisations des coûts de BigQuery   Un merci spécial à   pour avoir collaboré avec moi sur l'étude de cas et fourni des informations précieuses qui m'ont aidé à comprendre l'architecture de BigQuery. Abu Nashir  Les références    — LinkedIn Abou Nashir    - Peter Goldsborough Un regard sur Dremel    – Google Cloud BigQuery    – Google Cloud BigQuery expliqué : présentation de l'architecture de BigQuery    — Google Cloud Colossus sous le capot : un aperçu du système de stockage évolutif de Google    — Wikipédia SGBD orienté colonne    — Wikipédia Valeurs séparées par des virgules    – Google Cloud Créer des tables partitionnées    — MDN Modules Javascript    – Google Cloud Jupiter évolue : réflexion sur la transformation du réseau des centres de données de Google    — Google Cloud Méthode : jobs.query    — Wikipédia Protocol_Buffers    – Google Cloud Exécutez des tâches de requête interactives et par lots    – Google Cloud Utiliser les résultats de requête mis en cache    – Google Cloud Écrire des résultats de requête   Vous voulez vous connecter ?  Cet article a été initialement publié sur   . le site Web de Daw-Chih

2022 - HackerNoon Contributor of the Year - Leadership

2022 - HackerNoon Contributor of the Year - Learning

2022 - HackerNoon Contributor of the Year - Product Management

2022 - HackerNoon Contributor of the Year - Software Engineering

2022 - HackerNoon Contributor of the Year - Typescript

Coding Guru of 2022

Check out my website!

Nominated for 2022 - HackerNoon Contributor of the Year - Product Management

Nominated for 2022 - HackerNoon Contributor of the Year - Typescript

Nominated for 2022 - HackerNoon Contributor of the Year - Leadership

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for Coding Guru of 2022

Nominated for 2022 - HackerNoon Contributor of the Year - Learning

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Comment optimiser Google Cloud BigQuery et contrôler les coûts ?

Comment optimiser Google Cloud BigQuery et contrôler les coûts ?

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Télégramme : le pont de Crypto Island vers le continent

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Télégramme : le pont de Crypto Island vers le continent

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps