BigQueryでPreviewになったテーブルスナップショットを試す

BigQueryでPreviewになったテーブルスナップショットを試す

BigQueryのテーブルスナップショット(table snapshots)作成し、そこからテーブルを復元する。
Clock Icon2021.06.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

データアナリティクス事業本部、池田です。
2021/06/25のリリースでBigQueryテーブルのスナップショットの作成が Preview (執筆時点)となりましたので、動かしてみました。
Release notes

以下の内容は執筆時点のプレビューのものになります。 変更があったら追記などする予定です。たぶん。


(2022/02/15追記)
2021/10/28のリリースgenerally available(GA) になっています。


スナップショットの作成~復元

公式のドキュメントは↓以下です。 ※執筆時点では日本語は未対応
Introduction to table snapshots

スナップショットのメリットは以下とのこと。

・Keep a record for longer than seven days. With BigQuery time travel, you can only access a table's data from seven days ago or more recently. With table snapshots, you can preserve a table's data from a specified point in time for as long as you want.
・Minimize storage cost. BigQuery only stores bytes that are different between a snapshot and its base table, so a table snapshot typically uses less storage than a full copy of the table.

ずっと保存できて割安なんだそうです。

ちなみにタイムトラベルについてはこちら↓

タイムトラベルで BigQuery の削除済みデータにアクセス&復元してみた

テーブルのスナップショットの制限や課金など、 詳細は前述の公式ドキュメントをご覧下さい。

作成元のテーブル

スナップショットの作成元にするテーブル( base table と呼ぶそうです)のサンプルとして、 source データセット内に↓以下ようなの5カラムの my_table を準備しました。


↑コンソール上で確認すると、この時点で、4.93KB、30行あります。

テーブルのスナップショットの作成

さっそく スナップショットを作成 します。

ですが…

・The table snapshot dataset must reside in the same location as the dataset that contains the table you are taking a snapshot of.


Best practice is to create a table snapshot in a different dataset from the original table. This practice allows the table to be restored from its table snapshot even if the table's dataset is accidentally deleted.

らしいので、同じリージョンに別データセットを作成します。
今回はUSリージョンを設定して CREATE SCHEMA my_snapshots; を実行しました。


↓以下のSQLで作成したデータセット内にスナップショットを作成します。

CREATE SNAPSHOT TABLE
    my_snapshots.my_table_20210628
CLONE
    source.my_table
OPTIONS(
    expiration_timestamp = TIMESTAMP "2021-06-29 00:00:00.00-00:00"
);


OPTIONSexpiration_timestamp有効期限を指定して、 my_table_20210628 という名前のスナップショットを作成しました。

↓作成したスナップショットをコンソールから確認すると、 作成元のテーブルと同じサイズ・行数が表示されました。



試しに、作成元のテーブルに対して、 UPDATE文で特定のカラムをNULLにしてみたり、 DELETE文で数行消してみたりしたのですが…
↓スナップショットの方の情報は変更ありませんでした。

作成元のテーブルとの変更分、スナップショットは課金されるとのことだったので、 何か変化があるかと思ったのですが、予想が外れました。 ( {データセット}.__TABLES__ でメタ情報も確認したのですが、変化無く…)
スナップショットのストレージ費用の確認の仕方が分かったら追記します。たぶん。


テーブルのスナップショットの中を参照する

↓こんな感じでスナップショット自体にSQLを発行できました。

SELECT * 
FROM my_snapshots.my_table_20210628;


データに対する可能な操作は参照のみとのこと。 スナップショットの更新 もできるそうですが、こちらはメタ情報(有効期限やdescriptionなど)のことを指すようです。

スナップショットからテーブルを復元する

スナップショットといえば当然 テーブルの復元 がつきものですよね。

今回は CREATE SCHEMA my_restore_tbls; で新たにデータセットを作成して、 テーブルを作成します。

やや余談ですが、復元のドキュメントにはリージョンについての制限の記載がたぶん無かったので、 別リージョン(東京(スナップショットはUS))に対して復元を試みましたが、 ↓エラーになりました…


同じリージョン(US)に復元先のデータセットを作り直して、 ↓以下のSQLで復元することができました!

CREATE TABLE
    my_restore_tbls.my_table_restored
CLONE
    my_snapshots.my_table_20210628;


(↑なぜか画面上の結果はエラーになりました…プレビューだからかな…)

無事、作成元の取得時点のテーブルを復元できました。

(スナップショットの削除は、コンソールからできました。)

おわりに

タイムトラベル機能と組み合わせて運用することで、 やらかしちまった的な惨事に備えることができそうです。

関連情報/参考にさせていただいたページ

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.