Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

BigQuery と Google の Big Data Stack 2.0

先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。

BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。

それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。

BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており、更に Google 内部ではとっくに Big Data Stack 3.0 に移行してる (しつつある?) みたいな話に強く興味を持った。(まあ、3.0 は論文にも何にも発表されてないので、そういうニュアンスのみしか嗅ぎ取れないのではあるが)

Google BigQuery

Google BigQuery は、一言でいうと「超でかいデータをSQLで数秒で解析できるクラウドサービス」。

例えば fluentd なんかで毎日ログを送りつけておいて、溜まった 数百GB とか数TB、あるいは数PB とかになったデータに SQL を投げるとちゃんと結果が返ってくる、そういうもの。いわゆるビッグデータ基盤である。裏側では当然分散処理が行われていて、Google の持つ大量のコンピュータとディスク、それから高速なネットワークによってそれが処理されている。

もっと知りたいという方は Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita あたりを参照すべし。

なぜ大きなデータを秒単位で処理できるかというと、それがまさに BigQuery Analytics の本題なのだがざっくりは

  • SQL は高度に並列化できる言語 (基本、シーケンシャルに処理するしね)
  • RDBMS のようにインデックスを作るわけではなく、基本フルスキャンする
  • そのフルスキャンに伴う I/O を分散処理するために大量の HDD を用意して、それを大量のサーバーに接続してクラスタリング (もちろん、スケールアウトの発想で)
  • データをそのクラスタ内でカラムナー形式で保持しつつ分散させて保存しておき、SQL が来たらそれを並列処理化して I/O を散らす

みたいな感じである。より詳しくは･･･とそこが書籍の本題でありその理解は今後の読書会を通じて行われる予定、といって誤魔化す。

こういうアーキテクチャになってるので、BigQuery に対するクエリのレスポンス速度はデータサイズに比例しない。例えば 100GB のデータに対して 3sec かかったクエリが、対象が 1TB になっても 5sec で収まるとか、そういう特性を持っている。

Google BigQuery の製品ポジション / MPP の盛り上がり

この、SQL を並列分散処理してビッグデータを数秒で解析しましょう、という製品は何も BigQuery だけではない。

OSS の実装であれば Facebook が開発して OSS になった Presto、それから Cloudera Impala などがある。この辺は、Hadoop クラスタにアドオンする形で利用すると、Hadoop クラスタに溜め込んだデータを SQL 並列処理できるようになってる。クラウドサービスでいえば (自分は詳しくないし、結構特性には違うらしいが) Amazon Redshift なども同様のカテゴリのサービスのようだ。それから、以前にこのブログでも紹介した TreasureData はもともと Hive + Hadoop を基礎にしたサービスだったがその後 Presto をアドオンすることで同カテゴリのサービスにバージョンアップしている。

この辺の話は Hadoop Conference Japan 2014 での tagomoris さんの発表スライド Batch processing and Stream processing by SQL が詳しい。

資料の内容を軽くサマリする。

SQL ベースのビッグデータ解析基盤は大きく分類すると

  • Large Batch
  • Short Batch
  • Stream Processing

の3に分類される。それぞれ

  • Large Batch : 安定して巨大なデータをバッチ処理できるが、実行時オーバーヘッド大きい (そのためちょいちょいクエリを変えては投げる目的 ･･･ アドホッック クエリには向いてない)
  • Short Batch : Large Batch の安定性と規模性を多少犠牲にしつつ、実行時オーバーヘッドが数秒 (つまりアドホック クエリに向いている)
  • Stream Processing : ストリームに流れるデータをリアルタイム処理。バッチではない

というもの。対応する代表的な実装は

  • Large Batch ･･･ Hive + Hadoop
  • Short Batch ･･･ Presto / Impala etc.
  • Stream Processing ･･･ Twitter Storm / Norikra

などとなってる。この Short Batch のユースケースに含まれる実装は昨今 MPP (Massively Parallel Processing) 系クエリエンジンと呼ばれていて、ビッグデータ界隈では今もっともホットなトピック･･･であると、Hadoop Conference に出てみて自分はそう感じた。

そして、Google の BigQuery は元々 Google 内部で開発された Dremel というクエリエンジンが基になっている。その Dremel がまさにこの MPP 系クエリエンジンに相当する類で、BigQuery はそれにストレージを加えて公開サービスにしたものだと現時点では理解している。(BigQuery は背後にそびえるクラスタ群が超大規模なので、Short Batch に分類されるとはいえ Large Batch も包含するようなサービスではある。)

OSS 系の流れからいくと、Hadooop + Hive で SQL でビッグデータを解析するというソリューションが盛り上がったが、MapReduce はタスク起動時のオーバーヘッドが大きくアドホッククエリの分析には向いてない、そこをカバーするために Presto や Impala が出てきてみたいな流れだと思う。

Big Data Stack 2.0

それで、冒頭の Big Data Stack 2.0 である。BigQuery は Google の Big Data Stack 2.0 の上に構築されている、らしい。書籍によれば。

そもそも Big Data Stack 1.0 とは、GFS, MapReduce, BigTable などの「Google を支える技術」のことである。MapReduce などが論文で発表されたのが 2004 年とかだった。あれから 10 年経った結果、Google 内部は書籍を読む限りは Big Data Stack 2.0 にまで進化している 。(そして現在進行系では 3.0 に至っているようなこともチラホラ見える。)

その Big Data Stack 2.0 の主要コンポーネントは以下である。説明文は読書会で hakobera さんがサマリしてくれたテキストから引用する。

  • Colossus
  • Megastore
    • Paxos アルゴリズムにより、複数データセンターでの一貫性のある Read/Write を実現した NoSQL DB。Bigtable 上に構築されている。
  • Spanner
    • Megastore + データに地域制約（どのデータセンターに所属するか）を付与することができる。
  • FlumeJava
  • Dremel
    • 分散 SQL クエリエンジン。BigQuery の核となるアーキテクチャ。ストレージに依存しない。

これらの実装は概ね Big Data Stack 1.0 の上に構築されているらしい。そしてこれも hakobera さんテキストからの引用なのだが

  • Big Data Stack 1.0 は、Datacenter を1つのサーバとして扱う技術群
  • Big Data Stack 2.0 は、複数 Datacenter を1つのサーバとして扱う技術群

という風に (乱暴には) まとめられる。こうして世界に分散しているデータセンターを、プログラマからみた場合は 1つのサーバーとして扱えるような形で抽象化したのが Google の Big Data Stack 2.0 だそうだ。

ご存知のように Big Data Stack 1.0 をリファレンスにでてきた OSS が Hadoop や HDFS、HBase 等々だったように、この Big Data Stack 2.0 を参考にしたと思われる OSS 実装も当然出てきていて、それらが Apache Crunch や Presto、Impala ･･･というのが昨今の状況。Google が論文などでそのあらましを発表するころには、Google 内部は次の世代の実装に移行しているというのが過去のパターンなので、そこから Google 内部はもはや Big Data Stack 3.0 なのでは? と推測される ─ といった具合である。

自分はこの分野を見てまわるのはそれこそ Google を支える技術から初期の Hadoop ぐらい、Big Data Stack 1.0 の頃で止まっていたので、それからしばらく時間が経ってこんな状況になっていたとは、改めて Google はすごい企業だという感想を抱くにいたったのは当然のこと、とても面白く読めた。ずっとこの分野を追っていた人にとっては何を今更という話なのかもしれないが、面白さあまってブログにまとめるイマココである。

ま、人の会社の話なんだけどね。Google の威を借る naoya。

8/30 の YAPC::Asia では、BigQuery Analytics をもう少し読み進めた後のサマリと、実際に BigQuery をプロダクションで利用してみてのユースケースや感想などを含めて発表できたらと思っている。

急ぎで書いたので誤字脱字や乱暴な解説がいつも以上に多いと思うが、ご勘弁を。

余談

ちなみにこの辺をみて『Google を支える技術II』の出版が待たれる! と声を大にして言おうとおもったら『サーバー/インフラを支える技術』もなんとかしろ、という神の声が聞こえてきた。編集さん、アジェンダなかなか書かなくてごめんなさい･･･。

追記

BigQuery について、#gcpja で話しました。スライドを以下に公開しています。