Google Cloudデータエンジニアのはんざわです。
前回に引き続き、BigLakeテーブルを紹介したいと思います。
今回の記事では、従来の外部テーブルとBigLakeテーブルを比較し、BigLakeテーブルが従来の外部テーブルより優れている点を簡単に紹介したいと思います。
前提条件
- Cloud StorageをデータストアとしたBigLakeテーブルと外部テーブルを比較します
- BigQuery Omniを使用した他クラウドのBigLakeテーブルやCloud Bigtableなどをデータストアとする外部テーブルは検証の対象外です
そもそもBigLakeテーブルとは？
BigLakeテーブルは、従来の外部テーブルと同様に外部のデータストアのデータにアクセス可能なテーブルです。
従来の外部テーブルと比較するとアクセス権の委任により、「ユーザーがBigLakeテーブルにアクセスする権限」と「BigLakeテーブルがデータストアを参照する権限」が分離されている点で異なります。
具体的な使用方法などは、前回の記事で紹介しているので興味ある方は是非確認してみてください。
- 前回の記事
BigLakeテーブルの強み
従来の外部テーブルの代わりにBigLakeテーブルを使用するメリットは以下の通りです。
- テーブルの参照に必要な権限が減る
- アクセス制御によるセキュリティの向上
- メタデータキャッシュによるパフォーマンスの向上
- 対応しているフォーマットが豊富
それぞれ確認してみましょう
1. テーブルの参照に必要な権限が減る
前述したようにBigLakeテーブルは、「ユーザーがBigLakeテーブルへのアクセス権限」と「BigLakeテーブルがデータストアを参照する権限」が分離されています。
これにより、テーブルを参照するユーザーに割り当てる権限が減り、管理が容易になります。
従来の外部テーブルを参照するためには、最低でも以下の事前定義ロールをユーザーに割り当てる必要がありました。
- Storage オブジェクト閲覧者
- BigQuery データ閲覧者
- BigQuery ジョブユーザー
一方でBigLakeテーブルを参照するためには、以下の権限をユーザーに割り当てるだけで十分になりました。
- BigQuery データ閲覧者
- BigQuery ジョブユーザー
それぞれを比較すると、BigLakeテーブルを参照する場合は、Cloud Storageの権限が必要ありません。 これは、BigLakeテーブルを構成するBigQuery ConnectionがCloud Storageのオブジェクトを参照する権限を持っているためです。 したがって、テーブルを参照するユーザーにはCloud Storageの権限を割り当てる必要がありません。
これにより、誤った権限付与による本来不要なCloud Storageバケットへのアクセスを防ぐことが可能になります。
2. アクセス制御によるセキュリティの向上
BigLakeテーブルでは、権限が分離されていることで、以下の設定を適用することか可能です。
- 列・行レベルのアクセス制御
- 動的データマスキング（データストアがCloud Storageの場合のみ）
以下は、ポリシータグの設定画面です。
BigLakeテーブルでは、ADD POLICT TAGからアクセス制御の設定が可能ですが、従来の外部テーブルではそれができません。
- BigLakeテーブル
- 従来の外部テーブル
このようにBigLakeテーブルでは、上記の設定を適用することで特定のカラムのアクセス制御やマスキングが可能になります。
BigLakeテーブルのアクセス制御ポリシーの設定方法は、以下のドキュメントから確認してください。
アクセス制御ポリシーの設定
3. メタデータキャッシュによるパフォーマンスの向上
BigLakeテーブルでは、メタデータのキャッシュ保存し、クエリのパフォーマンスを向上させることが可能です。
実際にメタデータキャッシュを有効にしているテーブルとそうでないテーブルでのパフォーマンスを簡単に確認してみます。
3.1. メタデータキャッシュのパフォーマンス検証
3.1.1. 検証の準備
検証用のデータには、一般公開データセットのtrigramsを利用します。
このデータをgs://test-data-hanzawaにエクスポートします。
EXPORT DATA OPTIONS (
uri = 'gs://test-data-hanzawa/trigrams/*.json',
format = 'JSON'
) AS
SELECT
* EXCEPT(cell)
FROM
bigquery-public-data.samples.trigrams
> 68051509 個の行を 886 ファイルに正常にエクスポートしました。また、BigLakeテーブルを作成するのに必要なBigQuery Connectionは前回使用したbiglake_testを再利用します。
3.1.2. BigLakeテーブルを作成
メタデータキャッシュを有効にしているテーブルとそうでないテーブルの2つを作成します。
- メタデータキャッシュを有効にしているテーブル
以下のクエリでメタデータキャッシュを有効にしているテーブルを作成します。
CREATE OR REPLACE EXTERNAL TABLE `biglake.biglake_cache`
WITH CONNECTION `us-central1.biglake_test `
OPTIONS (
format ='JSON',
uris = ['gs://test-data-hanzawa/trigrams/*.json'],
max_staleness = INTERVAL 1 DAY,
metadata_cache_mode = 'MANUAL'
);6行目と7行目でメタデータキャッシュの更新を有効にしています。
引き数の詳細は以下の公式ドキュメントを確認してください。
パーティション分割されていないデータに対して BigLake テーブルを作成する
この例では、メタデータキャッシュの更新を手動で行う設定にしています。
以下のクエリを実行して、キャッシュを更新します。
CALL BQ.REFRESH_EXTERNAL_METADATA_CACHE('biglake.biglake_cache')- メタデータキャッシュを無効にしているテーブル
以下のクエリでメタデータキャッシュを無効にしているテーブルを作成します。
CREATE OR REPLACE EXTERNAL TABLE `biglake.biglake_no_cache`
WITH CONNECTION `us-central1.biglake_test `
OPTIONS (
format ='JSON',
uris = ['gs://test-data-hanzawa/trigrams/*.json']
);3.1.3. パフォーマンス検証
それぞれのテーブルから全件のデータを取得した結果は以下の通りです。
- メタデータキャッシュを有効にしているテーブル
- メタデータキャッシュを無効にしているテーブル
このようにメタデータキャッシュを有効にしているテーブルの方が若干パフォーマンスが良いことがわかります。
今回のケースでは、扱っているデータの量が4.84GBと比較的少なかったため、パフォーマンスにそれほど大きな差はありませんでした。
しかし、データ量が増えたり、Hiveパーティションを有効にすることで、より大きなパフォーマンスの改善が期待できます。
一方でメタデータのキャッシュは、キャッシュの更新タイミング次第で逆に処理が遅くなったりする可能性があり、適切に利用する必要があります。
（メタデータのキャッシュは複雑な機能だと思うので、別途、メタデータのキャッシュに関する検証のブログを執筆したいと考えています）
4. 対応しているフォーマットが豊富
Cloud Storageの外部テーブルでは、以下のフォーマットをサポートしています。
- CSV
- JSON
- Avro
- ORC
- Parquet
一方でBigLakeテーブルでは、以下のフォーマットをサポートしています。
- CSV
- JSON
- Avro
- ORC
- Parquet
- Delta Lake（プレビュー）
- Iceberg
このようにBigLakeテーブルでは、Delta LakeとIcebergのフォーマットを追加でサポートしています。
また、それぞれのフォーマットに制限事項があります。利用する際には以下のリンクから事前に制限事項を確認してください。
BigLakeテーブルの費用
最後にBigLakeテーブルの費用を確認します。
BigLakeテーブルでは、以下のオペレーションで費用が発生します。
- テーブルに対するクエリの実行
- メタデータキャッシュの更新
それぞれのオペレーションにおけるオンデマンドとエディションの料金は以下の表の通りです。
| オンデマンド | エディション | |
|---|---|---|
| テーブルに対するクエリ | 処理されたバイト数、従来の外部テーブルと同じ | スロットを消費、従来の外部テーブルと同じ |
| メタデータキャッシュの更新 | 処理されたバイト数 | スロットを消費 |
テーブルに対するクエリで発生する費用は、従来の外部テーブルと同じです。
追加でメタデータキャッシュを利用する場合は、メタデータキャッシュの更新費用が発生するようになります。
参考元: BigLakeテーブルの費用
まとめ
この記事では、BigLakeテーブルと従来の外部テーブルを比較しました。
紹介したように、BigLakeテーブルを使用することには多くのメリットがあります。
加えて、現在では、従来の外部テーブルよりもBigLakeテーブルを使用することが推奨されています。
可能であれば、BigLake テーブルを使用することをおすすめします。BigLake テーブルではアクセス権の委任が可能であるため、Cloud Storage データのクエリには BigLake テーブルに対する権限のみが必要です。
参考元： Cloud Storage 外部テーブルを作成する
今後、Cloud StorageのデータをBigQueryで扱いたい場合は、是非BigLakeテーブルを検討してみてください。
また、既存の外部テーブルをBigLakeテーブルにアップデートする方法も公式ドキュメントで紹介されているので併せて確認してください。
13
