コラム

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

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

CTC 教育サービス

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

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

はじめに

　前回に続いて、2021年に公開された論文「Napa: Powering Scalable Data Warehousing with Robust Query Performance at Google」を元にして、Google社内で利用されている、Napaと呼ばれるデータウェアハウスシステムを紹介します。今回は、検索を含むさまざまな処理を高速化するための工夫、および、プロダクション環境における性能データを紹介します。

ユーザー定義ビューのアップデート

　前々回の記事で少し触れたように、Napaは「ユーザー定義ビュー」をサポートしています。既存のテーブルから新しいテーブル（ビュー）を作るためのSQLを登録しておくと、テーブルのデータが更新されるごとに、ビューの内容もそれに応じて自動的に更新されるという仕組みです。Napaの場合は、前回説明したように、差分データのマージ処理が進むにつれて、検索可能な最新データのタイムスタンプ（QT）が更新されていきます。このため、QTを更新するタイミングで、対応するビューも同時にアップデートする必要があります。Napaが扱うテーブルのデータ量、および、新規データの追加速度を考えると、ビューのアップデートはかなり高速に行う必要があります。Napaが管理するテーブル、および、ビューのデータは、それぞれのキーによってソートされた状態で複数のノードに分散配置されており、この特徴を生かした実装がなされています。詳しい内容は論文に譲りますが、本質的には、複数のテーブルのデータをマージして再ソートするという処理になっており、論文内には「最先端（state-of-the-art）のソートライブラリーの開発に相当な労力をかけた」という記述があります。
　また、Napaのデータは複数のデータセンターにレプリケーションされているので、この部分の処理は、複数のデータセンターで分散して実施することができます。データセンターごとのこれまでの処理速度に基づいて、処理を割り当てるデータセンターを決定するなどの工夫も行われています。
　Napaの場合、ユーザー定義ビューを利用する主な目的は、検索処理を高速化することにあります。Napaが管理するテーブルは、ペタバイト規模のサイズになるものも少なくありませんが、必要なデータのみを取り出したユーザー定義ビューを作っておけば、ビューに含まれるデータ量はずっと少なくなります。このため、ユーザー定義ビューに対する検索処理は、元のテーブルに対する検索処理よりも高速化されると期待できます。図1は、特定のユースケースにおいて、利用するビューの数と検索処理のレイテンシーの関係を調べた結果になります。「50p」のグラフは、50パーセンタイル、すなわち、半数の検索処理のレイテンシーがこの値以下になっていることを示します。同様に、「90p」「99p」は、90パーセンタイル、および、99パーセンタイルの結果を示します。この結果を見ると、ビューの利用は、「テイルレイテンシー」、すなわち、例外的に処理が遅延したケースのレイテンシーを大きく改善することがわかります。

fig01

図1 ビューの利用による検索処理の高速化（論文より抜粋）

検索処理の高速化

　検索処理を高速化するその他の工夫としては、メモリーキャッシュの積極的な活用があります。まず、メタデータについては、すべてのデータが分散キャッシュにロードされている状態を保持して、メタデータの検索時にディスクストレージへのアクセスが発生しないようにします。分散キャッシュへのデータロードは定期的に実行されるようになっており、新しいデータを受け取ることでメタデータの更新が発生した場合は、更新後のメタデータがロードされたことを確認してから、対応するデータが検索対象となるようにQTの更新を行います。
　また、検索対象のデータ本体については、専用のキャッシングシステムが用意されており、検索対象のデータにアクセスする際は、このキャッシングシステムのAPIを介してデータを取得します。このキャッシングシステムでは、複数のアクセスリクエストをマージして、ディスクストレージへのアクセス回数を最小限に抑えるように動作します。さらに、前回説明した「差分データ」は、Napa専用に設計された列指向のストレージフォーマットで保存されています。この際、差分データのサイズ（差分データに含まれるデータの時間幅）に応じて、異なるストレージフォーマットを採用するという最適化が行われています。

プロダクション環境における性能データ

　前々回の図1に示したように、Napaは、「Ingestion（データの挿入）」「Storage（差分データとビューの更新）」、そして、「Query Serving（検索の実行）」という3つの処理を独立して行います。このため、検索処理の性能が、前段の処理の負荷状況に影響されないという特徴があります。図2は、この事実を示す実環境のデータになります。

fig02

図2 前段の処理の検索処理への影響（論文より抜粋）

　それぞれのグラフは横軸を共通の時刻とした時系列のデータを表しており、何らかの原因により、「X」と「Y」の時刻の間に「Storage」処理を行うシステムに性能上の問題が発生しています。このため、XとYの間は、ビューの更新処理（上から2段目のグラフ）の性能が低下しており、また、差分データの更新（上から3段目のグラフ）にも遅れが生じています。しかしながら、この間も検索処理の性能（上から4段目のグラフ）には、目立った影響が現れていないことがわかります。

次回予告

　今回は、2021年に公開された論文「Napa: Powering Scalable Data Warehousing with Robust Query Performance at Google」を元にして、Google社内で利用されている、Napaと呼ばれるデータウェアハウスシステムについて、検索を含むさまざまな処理を高速化するための工夫、および、プロダクション環境における性能データを紹介しました。
　次回は、Linuxカーネルのプロセス・スケジューラに関する話題をお届けします。

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