Developer's Summit 2013 参加メモ（１）

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

600億件を数十秒で検索するクラウド検索クエリサービスBigQuery / 佐藤一憲氏@google

導入

BigQueryのプレゼン

自己紹介

• @kazunori_279/#gaeja/#gcloudja
• クラウドソリューションチーム ソリューションズアーキテクト
• appengine ja night管理人(23回くらい)
  • AppEngine技術者のための情報交換イベント

Agenda

• ビッグデータをGoogleスピードで
  • 「Googleスピード」は社内用語、すごく早い
• デモ＆事例紹介
  • WhitePaper
• なぜ早い？
• MapReduceとGoogleBigQueryの適材適所

ビッグデータをGoogleスピードで

• Googleではコードを書く時に最初にスケーラビリティを考える
• アベイラビリティを持つデータ構造
• Googleのサービスはビッグデータ
  • Youtubeは72h/1min
  • Googleの検索インデックスは100PB
  • Gmailのアクティブユーザー数は4.25億ユーザー
• もともとはAdwords 、結果をすぐに知りたがる
  • すぐデータ分析したい、どうする？MapReduce？DWH？

MRもDWHも使わない

• DWHはメモリ・SSDをたっぷり積んだアプライアンスが多い
• 数千万〜数億円規模のハイコスト
• ad-hocなデータ分析には対応しにくい
  • インデックス・ディメンジョンの事前設計がないとフルスキャン/テーブルスキャンしか無い
• データ量に比例して性能向上はハイコストすぎて無理！

so, whatabout Hadoop?

• DWHより安価
• RDBMSよりスケールする
• けど、レスポンスが遅い。簡単なクエリでも数分かかる。長ければ数時間
• やはりad-hocな分析には向かない

Dremelという虎の子

• 大規模並列クエリインフラ
• 数百億件のフルスキャンが数十秒で完了。
• 検索は全てフルスキャン
• Webコンテンツの分析、スパム解析、トラッキング、デバッグ、解析、全部Dremel
• で、そのDremelの公開版がGoogle BigQuery

Google BigQuery

• 2012年5月公開
• 1クエリ、35ct/GB、月額120ct/GB
• デモは無償で一般公開（2TBまで）
• Dremelのサブセット
  • ProtocolBufferのツリー構造には未対応
• 使い方としてはGAE/CSVインポート⇒Cloud上のエンジン⇒Googleスプレッドシート/etc

デモ＆事例

• Wikipediaの全ページの全更新履歴から、ページ更新TOP10を検索して表示
  • select top(title), count(*) from publicdata:samples.wikipedia where wp_namespace = 0;
• Wikipediaの全ページからタイトルに数字が含まれるものを抽出
  • 正規表現の文字列マッチングが速い⇒非構造化データのクエリも速い

• サブクエリも普通に書ける。従来ではスケーラビリティを上げるために制限が多かった

• 3rdPartyのERPパッケージからインポートした4.5億件の売上データを分析
  • bime / cloud上のBIツール
  • ちょっと時間かかったけど

• Crystalloidsの事例：リアルタイム意思決定支援ツール

なぜ速い？

• カラム志向
• 数万台での並列処理
  • Google DCの「規模の経済」
  • ディスクI/Oを極限まで並列化
  • 圧倒的なフルスキャン性能
• 階層アーキテクチャ
  • クエリの分配

得手不得手

• MapReduceも無くならない
• MapReduceは大規模バッチ処理
  • アドホックには向かない
  • レスポンスも遅い
  • 技術がややこしい（Tenzing/Hive）
• BigQueryは巨大なデータのエクスポートが出来ない
  • 複雑なロジック、データ生成、更新、データマイニングには向かない
  • マージ処理なんかには向かない

なので

• BigQuery
  • Try&Errorな分析、トラブルシューティング、あたりをつける、特性をつかむ
• MapReduce
  • しっかり分析（駆け足でメモ取れず、、）