IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

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

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  OpenStack  システムトラブルシュート 

第36回 社内横断データセット検索システム「Goods」(パート2) (中井悦司) 2018年4月

はじめに

 前回に引き続き、2016年に公開された論文「Goods: Organizing Google's Datasets」をもとにして、Google社内のデータストアを横断的に検索可能にするツール「Goods(Google Dataset Search)」を紹介します。

 前回説明したように、すべてのデータセットからカタログ情報を抽出するのは、データ量の観点から現実的ではありません。そこで、類似のデータセットをクラスタリングした上で、各クラスターからのサンプリングにより、カタログ情報の抽出を行います。また、カタログ情報の中には、データセットのスキーマやデータセット間の依存関係など、データそのものだけを見ても判断が付かない情報があります。今回は、データセットのクラスタリングの手法、および、カタログ情報の生成方法について解説を進めます。

データセットのクラスタリング

 データセットをクラスタリングする目的は、カタログ情報を抽出する対象となるデータセット、すなわち、実際にデータの中身を分析するデータセットの数を削減することです。したがって、ここでは、データの詳細に踏み込まずに高速にクラスタリングを行う手法が必要となります。そこで、Goodsの開発チームが着目したのは、ファイルのパス名でした。たとえば、GFS(Google File System)上のあるデータセットには、"/dataset/2015-10-10/daily_scan" というファイルパスが割り当てられていたとします。まず、「daily_scan」というキーワードから、日次のバッチ処理に関連したファイルだと予想が付きます。さらに、「年・月・日」というタイムスタンプが含まれており、タイムスタンプの部分だけが異なるデータセットは、同一のバッチジョブからの出力と期待することができます。したがって、"/dataset/2015-*-*/daily_scan" というワイルドカードを適用すれば、2015年のすべての出力をまとめることができます。

 GFSに出力するファイルのパス名については、特に標準的なルールが定められているわけではありませんが、多くのプロジェクトで共通に、タイムスタンプやデータセンター名などの文字列が使用されています。そこで、図1のような情報をファイルパスから自動抽出するアルゴリズムを適用することで、クラスタリングに必要な情報が収集できる仕組みが実装されました。

fig01

図1 データセットのクラスタリングに使用するファイルパス情報(論文より抜粋)

 実際にどのような粒度でクラスタリングするのか、つまり、年単位でまとめるのか、月単位でまとまるのか、あるいは、データセンター単位でまとめるのかという点には任意性があります。現状では、なるべく大きな粒度でクラスターをまとめるという処理が行われているそうです。これには、クラスター数を減らすという効果の他に、利用者に対して、長期的に一貫した情報を提供するという目的があります。たとえば、月単位でデータセットをクラスタリングした場合、利用者から見ると、毎月、新しいデータセットが生成されているように見えてしまい、過去のデータセットとの関連がわからなくなる恐れがあります。

データセットのスキーマ情報

 クラスタリングによって、メタデータを抽出する対象のデータセットが選ばれたら、次は、実際にデータセットの中身を解析していきます。この際、Goodsでは、そのデータがどのようなフォーマットに従っているのかというスキーマ情報の抽出も行います。Webコンテンツの検索と異なり、バイナリーデータも検索対象とするGoodsでは、これは重要な機能となります。

 バイナリーデータに対して、その内部フォーマットを調べるというのはなかなか困難な処理に思われますが、ここには、Googleならでは特徴があります。まず、Googleが開発するアプリケーションでは、データフォーマットとして、標準的にProtocol Buffersが使用されています。これは、事前にデータのフォーマット(スキーマ)を定義しておけば、一定のルールに従ってシリアライゼーション(バイナリー形式への変換)が自動的に行われるという仕組みです。アプリケーションプログラムからは、専用のライブラリを通じて、標準化された手順でデータを操作することができて、複数の言語/プラットフォームで透過的にバイナリーデータの共有ができるようになります。それぞれのアプリケーションが定義したスキーマは、アプリケーションのソースコードを見れば確認することができます。

 そして、もう1つの特徴は、第20回の記事で紹介したように、Googleでは、すべてのソフトウェアのソースコードが単一のリポジトリで管理されているという点です。そこで、Goodsのクローリングシステムは、ソースコードリポジトリから、さまざまなアプリケーションが定義した、あらゆるProtocol Buffersのスキーマ定義情報を収集します。その後、検索対象のバイナリーデータの構造を解析して、データ構造とマッチするスキーマ定義を発見します。これにより、このデータセットがどのProtocol Buffersのメッセージに対応するデータなのかがわかるというわけです。

データセットの依存関係

 Goodsが収集するメタデータで、もう1つ特徴的と言えるのがデータセットの依存関係です。これは、あるバイナリーデータがどのアプリケーションから出力されたもので、さらにこのデータを入力に使用するアプリケーションにはどのようなものがあるのか、という情報です。これは、データそのものだけを見ていてもわかるものではありません。Goodsでは、アプリケーションのログファイルを解析することで、このような依存関係を発見しています。

 これもまた、Googleならでは特徴と言えるかもしれませんが、Googleの社内には、専用のログ収集システムがあり、すべてのアプリケーションは、このシステムに対してログを出力するように作られています。Google Cloud Platform(GCP)の環境で言えば、Satckdriver Loggingに相当する仕組みが、すべてのプロジェクトから共同利用できるように準備されているわけです。そこで、Goodsのクローリングシステムは、ログ管理システムに蓄積されたログを分析することで、どのアプリケーションがどのデータセットにアクセスしているのかを把握します。原理的には、すべてのアプリケーションについてのデータを介した依存関係、すなわち、依存関係の有向グラフを生成することもできますが、ログファイルの量を考えるとこれは現実的ではありません。Goodsでは、一定のルールでサンプリングしたログを解析して、直接の依存関係のみをカタログ情報として収集しています。

クローリングジョブのスケジュール管理

 最後に、カタログ情報を生成するバッチジョブのスケジュール管理について触れておきます。これまでの説明からも想像できるように、データセットに対するカタログ情報を生成するには、何段階かのバッチ処理が必要となります。しかしながら、クローリング対象のデータセットの総量、あるいは、新規データが追加される頻度を考えると、これらの処理をシーケンシャルに実行するのは現実的ではありません。特定の処理がボトルネックとなって、全体の処理が遅延しないための工夫が必要となります。

 そこで、Goodsでは、複数の段階の処理をすべて並列に実行します。ジョブ同士の依存関係は、個々のデータセットに対して、ジョブの実行状況をBigtableに記録することで対応します。つまり、処理対象の1つのデータセットに対して、Bigtableの1つの行を割り当てておき、どのジョブがいつ完了したかのを記録しておきます。一方、ある特定のジョブは、Bigtableのデータを確認して、自身の実行に必要な前提ジョブの実行が完了していれば、該当のデータセットに対する処理を実施します。前提ジョブが完了していなければ、このデータセットに対する処理はスキップします。これにより、すべてのジョブを並列に繰り返し実行しつづけることで、すべてのデータセットに対して、定期的にカタログ情報の更新が行われるというわけです。それぞれのジョブは、原則として、24時間ごとに再実行されるようになっています。

 また、スキーマ情報の抽出など、特に処理量の多いジョブについては、重要度の高いデータセットを優先的に処理するジョブを追加で実行しています。たとえば、新規のデータセットが大量に追加された場合などは、処理量の多いジョブが大きく遅延する恐れがあります。このような遅延によって、既存のデータセットに対するカタログ情報の更新が遅延することを防ぐことが目的となります。Webの検索システムでは、検索対象データのカバー範囲(Coverage)と検索結果の鮮度(Freshness)のバランスを取ることが重要となりますが、同じ考え方がここにも適用されているわけです。

次回予告

 今回は、論文「Goods: Organizing Google's Datasets 」をもとにして、Googleの社内横断的なデータセット検索システム「Goods」の仕組みを解説しました。バイナリーデータの解析など、一般的なWeb検索システムとは異なる特性を持つ一方、検索結果の鮮度を保つための工夫など、Web検索システムの知見も同時に活かされていることがわかります。

 次回は、Google社内のソフトウェアのテストシステム、いわゆる、CI(Continuous Integration)システムについての話題をお届けしたいと思います。

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

 


 

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  OpenStack  システムトラブルシュート