blue_field

技術的なメモとか読書記録とかいろいろ（の予定

'An Inside Look at Google BigQuery'を読んだ

Google BigQueryを使ってみようと思って、最近少し勉強している。Googleがホワイトペーパーを出していたので、読んでみた。（※2012年の文献）

BigQuery についてのホワイトペーパーを公開しました - Google Developer Relations Japan Blog

以下、内容の簡単なメモ。

もともとGoogle社内で利用されていた

Google社内で利用されてきた'Dremel'というサービスがある。巨大なデータに対してSQLライクなクエリを実行すると、数秒で結果が返ってくる。Googleでは、エンジニアだけでなくアナリストなど非エンジニアの人も利用している。

Dremelがベースとなり、外部に公開されたのがBig Query。フルマネージドなクラウドサービス。サードパーティの開発者は、REST APIやCLI, Web UIなどを利用してこのサービスにアクセスすることができる。DremelとBigQueryの根幹のアーキテクチャは同じであり、Dremelのパワーをそのまま享受できる。

とにかく速い

Googleのクラウドプラットフォームを使って、SQLを分散処理してる。数万のサーバー上で同時実行。

どれくらい速いか

具体例。以下のようなSQLを実行

  • 3億行のレコード (35GB) の入ったテーブル (Wikipediaの記事) を特定条件で絞り込み、カウント
  • 条件には正規表現を利用 (記事のタイトルに数字の含まれるもの)
  • テーブルにはインデックスなし

このクエリを10秒で実行 (COUNTの結果は、約2億)。フルスキャンなのに。

スケーラビリティーが高いので、ほとんどのクエリの実行結果を数秒 ~ 数十秒で返す。

なぜ速いのか

下記の2つがその答。

カラム型のデータストア

1行のレコードごとにデータを格納するのではなく、それぞれのレコードの列（カラム）ごとにまとめてデータを格納する。この方法には、以下のメリットがある。

  • トラフィック最小化
    • クエリの対象となるカラムにしかアクセスしないので、トラフィックが最小化できる。SELECT top(title) FROM fooというクエリであれば、titleカラムにしかアクセスしない。
  • 高圧縮率
    • 通常のデータベース (not カラム型) でのデータ圧縮率が1/3なのに対し、カラム型は1/10、という研究結果が出ている。同じカラムに入っている値は似ているケースが多く、ばらつきが小さいため。

一方で、デメリットもある。既に格納済のデータの更新には向いていない。Dremel (BigQuery) でもUPDATEの操作は用意されていない。カラム型のデータストアはread-onlyの用途が向いている。

ツリーアーキテクチャ

root serverがクライアントからクエリを受け取り、その下の多数のleaf serverが処理を実際に実行する。クエリがツリー構造に広がっていくことで、分散処理を実現。

カラム型ストレージとツリー構造については、Dremel: Interactive Analysis of Web-Scale Datasets に詳細な説明があるらしいので、ヒマなときに読む

Google社内でのDremel活用例

2006年から活用している。

  • クロールしたWebドキュメントの分析
  • Androidマーケット (Google Play) でインストールされたアプリのトラッキング
  • Google製品のクラッシュレポート
  • Googleのデータセンターのジョブのモニタリング
  • スパム分析

などなど、様々な用途で利用されている。

BigQuery vs MapReduce

Googleでは長い間、巨大なデータ処理にMapReduceも使っている。（2004年には研究論文も出している）

MapReduceとDremel (BigQuery) の違いは何か。それぞれ以下のようにデザインされている。

MapReduceのメリット

MapReduceでは、'mapper'と'reducer'を実装して分散処理を行い、数百 ~ 数千のサーバ上で同時にバッチ処理を実行できる。スケーラビリティが高く、コスト効率も良い。オープンソース実装であるHadoopは、ログ解析、ユーザー行動分析、レコメンドエンジンやデータマイニングなど様々なケースで利用されている。

MapReduceの制約

巨大なデータの格納されたtableをJOINしてフィルタリング、のような処理を、ある程度の時間で終わらせることのできるMapReduce。従来のRDBで、高いコスト+膨大な実行時間のかかっていた（or そもそも処理できなかった）クエリを、実行可能にした。

しかし、「すぐに実行結果が欲しい」といったユースケースには向いていない。長い処理は数日かかるものもあるし、書いた処理が間違っていたら、それを初めからやり直すことになる。先にも書いたとおり、バッチ処理などに適した形でデザインされているので、アドホックにトライアンドエラーしながらクエリを書いていくのには適していない。

MapReduceとDremel (BigQuery) は同じ分散処理を用いた技術ではあるが、同じ処理でも実行時間に数桁の差異が生まれることがある。

BigQuery, MapReduceそれぞれに適したユースケース

p.8-9の表参照。

BigQueryは、構造化データをSQLを用いて操作するようにデザインされている。カラムの定義や、Google Cloud Storage経由でBigQueryへのデータインポートが必要。SQLの文法が利用でき、シンプルなクエリを実行するのに適している。

MapReduceは、非構造化データをプログラムで処理する際のベターチョイス。どんな種類のデータも扱え、複雑なロジックも適用できる。データマイニングなどに向いてる。

BigQueryに適したユースケース

  • 特定条件のレコード抽出（特定IDユーザーのリクエストログなど）
  • 動的な条件下における統計の素早い集計（サイトの昨晩のトラフィックをサッと出してそれをグラフ化、みたいな使い方）
  • トライアンドエラーを前提としたデータ分析（トラブルの分析や、日次や月次など様々な条件でのデータ集計）

MapReduceに適したユースケース

BigQueryはフルスキャンでがんばる

従来のROLAPやMOLAPと比較して、BigQueryは扱いが楽。インデックスを利用してチューニングをする必要もないし、多次元データベースの設計も不要なので、アドホックにクエリを実行できる。フルスキャンで基本頑張る。

フルスキャンのパフォーマンスは、ディスクI/Oのスループットがキーとなる。スループットの向上にはディスクI/Oの並列化が必要となるが、Googleは、所有するクラウドプラットフォームの規模の経済を効かせて、これを実現している。（身も蓋もない。。。）

例えば、1TBのデータのフルスキャンを1秒以内に終わらせるには、10,000のディスクドライブと5,000のプロセッサが必要だが、Googleさんが持ってるデータセンター使えばそういうのも可能やで、とのこと

値段が安い

クエリ単位の課金 + ストレージの料金。 詳細は公式ページで。

フルマネージドなサービス

Google Cloud Platformを利用するので、運用面はGoogleにお任せ。利用者は、データのインポートだけして、あとは本質的な部分（データの解析etc.）に集中できる。

メモは以上。

おわり

読んでみて、Googleの力技が半端ないことを思い知らされた。完全な力押しサービスである。クエリごとに課金されるので利用料金が予想しにくい点はあるが、相当大きなサービス（データ量）でなければ破産しないはず。。。アクセスログとかアプリケーションのログの解析は、これ使うと楽そうだなと思った。

fluentdのプラグインもあるみたい。
kaizenplatform/fluent-plugin-bigquery

あとは、MapReduceとのユースケースの違いが書かれていて良かった。Hadoop周りも仕事で利用する可能性ありなので、もう少し理解深めねば。Amazon Redshiftも含むユースケースの違いに関しては、以下のブログでまとめてくれていて分かりやすい。
MPP on Hadoop, Redshift, BigQuery - Go ahead!