Queryは廃止されました。Queryは廃止されました。Queryは2017年11月に廃止になったので、この記事は過去の思い出です。https://cloud.google.com/bigquery/docs/release-notes?hl=en#november_14_2017今後はBillingTierが100を超えない限りは、特に料金が変わることはありません。BillingTier100超えはかなりの無茶をしないと出てこないので、滅多に気にすることはありません。単純なパフォーマンスチューニングとして、以下のノウハウはまだ役に立ちます。Queryに備える!Dremelの気持ちになって考えるパフォーマンスチューニング以下、過去の思い出話となった内容BigQueryのQuery料金は今までどんな複雑なクエリを書いても、データを読み込んだ容量に対して料金が決定されていました。2017/01/01より、Queryの処理量によってクエリ料金が変動するようになります。QueryのためにBillingTierという新しいパラメータが追加されました。これはQueryの処理量を表すもので、1以上の整数値が入ります。現状、BillingTierはクエリを実行してみないと分かりません。これは対象のデータの容量や偏りなどによって、BillingTierの値を算出しているからではないかと思われます。BillingTierが上がる要因としては、JOINや複雑なユーザ定義関数などがあります。TBBillingTierの値が2だと料金が倍になる計算です。これは2017/01/01から適用される予定です。今から備えておくこと既存のクエリのBillingTierを確認するBillingTierは料金には反映されていませんが、すでにクエリの結果に含まれています。Historyを確認すれば、BillingTierの値が分かります。logをBigQueryにExportしている場合、以下のような感じでクエリを実行すれば、BillingTierの高いクエリを探すことができます。DESCBilligTierの値が高いクエリを探してチューニングを行い、BillingTierの値を低く保つようにしましょう。クエリ実行時にmaximum_billing_tierを指定することを考えるbillingTierはクエリ実行時に分かるため、事前に把握することはできません。Developerはクエリ実行時にmaximum_billing_tierの値を指定することで、BillingTierの上限値を決めます。Optionを指定します。commandだと以下のように指定します。2shellなどで自動で実行しているクエリのBillingTierが1を超えていて、それでも実行したい場合は、maximum_billing_tierを明示的に指定しましょう。デフォルトは1になっているため、実行したクエリに必要なBillingTierが1を超えている場合、billingTierLimitExceededが返ってきます。Project単位でデフォルトのmaximum_billing_tierの値を変更することもできます。Formただし、maximum_billing_tierのデフォルト値を上げると、思わぬ課金が発生する可能性もあるので、注意してください。さいごに今までどんなに無茶なクエリを書いても料金が変わらなかったBigQueryですが、UDFも登場して流石に計算量を料金にフィードバックしないといけなくなったみたいです。値下げもあるので、ある程度は相殺されてるんじゃないでしょうか。因みに僕はクエリの複雑さとデータ容量が足らないのか、現状BillingTierは1で収まっています。次は、BillingTierの値を下げるために、BigQueryのクエリのチューニングについても書いていきたいと思います。BillingTierの値を下げるために、発表したスライドのLinkを貼っておきます。upLoginユーザーは見つかりませんでした。