コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第114回　Napa：ストリーミングデータのデータウェアハウスシステム（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第114回　Napa：ストリーミングデータのデータウェアハウスシステム（パート1） (中井悦司) 2021年10月

はじめに

　今回からは、2021年に公開された論文「Napa: Powering Scalable Data Warehousing with Robust Query Performance at Google」を元にして、Google社内で利用されている、Napaと呼ばれるデータウェアハウスシステムを紹介していきます。Napaは、さまざまなアプリケーションがリアルタイムに生成するデータをストリーミングで受け取り、SQLで分析可能にするためのデータウェアハウスシステムです。前身となるシステムからの置き換えを経て、2021年時点で、数年間の利用実績があるシステムです。

Napaの役割と基本構成

　Napaは、Google社内のさまざまなアプリケーションチームが共有で利用するデータウェアハウスシステムです。アプリケーションがリアルタイムに生成するログデータをストリーミングで保存して、最新のデータをなるべく短時間で分析できるようにすることがその目的です。Napaもまた、その他のGoogleのデータ処理システムと同様に、並列分散処理システムとして設計されていますので、処理に使用するリソースを増やす事で、次の時間を短縮することができます。

(1) 最新のデータが利用可能になるまでの待ち時間
(2) クエリーの応答時間

　しかしながら、使用するリソースを増やせば、そのために必要なリソースのコストも増加します。Napaを利用するそれぞれのプロジェクトチームは、リソースコストとのトレードオフを考えながら、(1)(2)に対する性能要求をカスタマイズできるように設計されています。Napaは、このようなカスタマイズを可能にするために、図1の3つの段階に分けてストリーミングデータを処理します。

fig01

図1 Napaを構成するコンポーネント（論文より抜粋）

　1つ目の「Ingestion」は、まずは、アプリケーションから受け取ったデータを一時的なテーブルに記録します。これは受け取ったデータを失わないように保存することが目的で、高速な書き込みに特化した設計が行われています。2つ目の「Storage」は、保存したデータを検索用のテーブルに書き写します。ここでは、検索に適したデータ形式への変換（インデックスの更新）や、ユーザーが事前に定義した「ビュー」の更新が行われます。最後の「Query Serving」は、検索用のテーブル、もしくは、ビューに保存したデータをSQLで検索するための検索エンジンです。「Storage」と「Query Serving」のそれぞれの処理に割り当てるリソース量を変更することで、(1)(2)の性能を調整することが可能になります。
　また、Napaが管理するテーブルは、冗長化のために複数のデータセンターへのレプリケーションが行われます。Spannerなどのトランザクショナルデータベースでは、このようなレプリケーションは、データの整合性を保つために同期的に行われますが、Napaは、同期処理と非同期処理のハイブリッドな仕組みを採用しています。「Ingestion」によって複数のデータセンターにデータが複製された後、「Storage」以降の処理は、それぞれのデータセンターで並列に非同期で行われます。そして、定期的に処理の進捗状況をチェックして、「どの時刻までのデータが検索可能になっているか」というタイムスタンプの情報を同期的にアップデートします。処理が遅れているレプリカについては、この同期処理のタイミングで、処理が追いつくのを待ち、すべてのレプリカの状態が揃うように調整されます。上記のタイムスタンプを含むメタデータは、Spannerのテーブルに保存されるので、Spannerの機能によって複数のデータセンターにおける整合性が担保されます。

Napaのアーキテクチャー

　図1の3つのコンポーネントの処理をもう少し詳しく表したものが、図2になります。左側の「Control Plane」は、前述のメタデータの更新処理を行う部分で、検索可能なデータの最新時刻の情報（QT: Queryable Timestamp）を検索エンジンに受け渡しています。中央上部にある「Ingestion Framework」が、アプリケーションから受け取ったデータを一時テーブルに保存する部分、そして、その下の「Compaction and View Maintenance」が一時テーブルのデータを検索可能な状態に変換する処理を表します。

fig02

図2 Napaのアーキテクチャー概要（論文より抜粋）

　Napaにデータを送信するクライアントは、「Ingestion Framework」が提供するETLパイプラインを用いて一時テーブルにデータを書き込みます。この部分は、特に大量のデータを高速に書き込めるように設計されており、1秒あたり数十GBのデータを受け取る事が可能です。複数のデータセンターに配置されたレプリカの任意の1つにデータが書き込まれると、その後のレプリケーションとメタデータ（どの時点のデータまでレプリケーションが完了したかなどの情報）の更新は、Napaによって自動的に行われます（図3）。

fig03

図3 データの書き込みとレプリケーション処理（論文より抜粋）

次回予告

　今回は、2021年に公開された論文「Napa: Powering Scalable Data Warehousing with Robust Query Performance at Google」を元にして、Google社内で利用されている、Napaと呼ばれるデータウェアハウスシステムについて、その役割とアーキテクチャーの概要を説明しました。次回は、受け取ったデータを検索可能な形に変換する、図1の「Storage」部分の詳細を解説します。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡