グーグルのクラウドを支えるテクノロジー　＞　第177回　Vortex: BigQueryのStorage APIを支えるStorageエンジン（パート2） (中井悦司)

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー　＞　第177回　Vortex: BigQueryのStorage APIを支えるStorageエンジン（パート2） (中井悦司)」を公開しまし

＃＃＃

はじめに
　前回に続いて、2024年に公開された論文「Vortex: A Stream-oriented Storage Engine For Big Data Analytics」に基づいて、BigQueryのStorage APIを支えるストレージエンジンであるVortexのアーキテクチャーを解説します。今回は、アーキテクチャーの全体像とデータ書き込み処理の流れを説明します。

Vortexのアーキテクチャー全体像
　Vortexのアーキテクチャー全体は、図1のようにまとめられます。前回の記事の図2にあるように、BigQueryが扱うデータは、標準的には「BigQuery Managed Storage Tables」に保存されます。これは、Dremelなどのクエリーエンジンによる検索処理に最適化されたテーブルで、図1の「Read Optimized Storage（ROS）」に当たります。

図1 Vortexのアーキテクチャー全体像（論文より抜粋）

　図1から分かるように、VortexはWrite APIで受け取ったデータをROSに直接保存するわけではありません。大量のデータを高速に受け取れるように、はじめは、書き込み処理に最適化された形式で「Write Optimized Storage（WOS）」に保存します。この部分の処理は、図1の「Vortex Write API」の直下にあるVortex Client Libraryが行います。ここでいうClient Libraryは、Vortexのシステム内部で利用されるライブラリーで、外部のアプリケーションが使用するライブラリーではないので注意してください。そして、クエリーエンジンや外部アプリケーションがRead APIでデータを読み出す際は、ROSに保存されたデータとWOSに保存されたデータの両方から必要なデータをマージして取り出します。この部分の処理は、「Vortex Read API」の直下にあるVortex Client Libraryが行います。
　この際、容易に想像されるように、WOSに保存されたデータが多くなると、高速なデータの読み出しが困難になります。そこで、バックグラウンドで動作するStorage Optimization ServiceがWOSのデータをROSに移動していきます。この部分の処理については、次回に改めて説明します。

この続きは以下をご覧ください
(リンク »)