ツイート分析でBigQueryのビックデータ分散処理を実地検証
樋口氏は、「BigQuery」を使ってビッグデータの分散処理を行い、それを同じくGoogle Cloud Platformで提供されているBIツール「Google Data Studio」で可視化するという、一連のプロセスを通じて、データ分析基盤の構築・運用に関する検証を自ら行ったと話す。
BigQueryによるビッグデータの分散処理で特徴的なのは、Apache HadoopやApache Sparkといった大規模な分散処理のための分析基盤をあらかじめ構築しなくても済む点だ。
「BigQueryのバックエンドには数百～数千台規模の分散処理用サーバーが稼働しており、クエリに分析のロジックを埋め込めるのであればリソースはこれで十分です。またQueryはUDF（ユーザー定義関数）にJavaScriptが使用できるので、JavaScriptが書けるユーザーならば、サーバーレスでこの分析環境を実現できます」
今回実際の検証として行ったのは、Twitterのツイートを収集して、数の多いものを「流行ワード」として分析する作業だ。
具体的には、あるゲームのハッシュタグがついているツイートを1週間分、API経由で取得してBigQueryに集積。一方でツイート内容からワードを抽出するUDFを作成してクエリを実行し、集計結果の中から数の多いワードを見える化する。
今回の検証では約89万3000行のレコード数、テーブルサイズ0.2GBに当たるツイートを収集・分析した。クエリの実行にかかった時間は20秒弱。かかった料金はわずか0.11円だったという。
約3億1000万レコードの生データを3秒弱で分析・グラフ化
次にトライしたのは、ビッグデータの可視化だ。検証の課題として、生のビッグデータをGoogle Data Studioでグラフ化し「見える化」した。
Google Data StudioはGoogle Cloud Platform上で提供されており、もちろんGoogle Data Studioとシームレスに連携しながら、さまざまなデータの分析・可視化が可能だ。操作も容易で、誰でも簡単にダッシュボードやレポートを作成できる。樋口氏は「Google Data Studioの魅力は、ビックデータを可視化できて共有できる『無料の』BIツールである点だ」と強調する。
今回使ったデータソースはBigQueryの公開データセットで、Wikipediaから取得している。約3億1000万レコード、データサイズ約38GBのテーブルに対して、Wikipediaの改訂履歴の投稿数を日別に集計するクエリを実行した。グラフの描画速度をChromeのDeveloper Toolsで計測したところ、ブラウザのページリロードからグラフ描画までは3秒弱。レポートのリロードだけならば約1.5秒と、非常に速いことがわかる。なおコストは2.03円と、こちらも実に安い。
「これほど大きな、しかも生のビッグデータからの集計・データ生成でも、この程度の描画速度とコストで済んでしまいます。データ量によっては、レポート用の集計すら必要ないでしょう。これだけ見てもGoogle Data Studioのパフォーマンスのすごさがわかります。もっとも描画速度と省コストは、BigQueryの実力による部分が大きいです」
樋口氏は、「BigQueryはこれだけの速さとコストの安さを備えているのだから、BIツールがクエリを自動的にキャッシュして再利用してくれれば、描画速度とコスト双方の面で大きなメリットがある」と指摘する。そのためにGoogle Data Studioには、以下の2つのキャッシュ機能が提供されている。
クエリキャッシュ
レポートで使用されたクエリの結果をキャッシュして、同じクエリが発行されたら再利用する。
プリフェッチ キャッシュ
レポートからユーザーの行う操作を予測して、操作前にクエリを発行し、そのクエリと結果をキャッシュする。
なお、これらのキャッシュは、ユーザーがいつレポートを開いても迅速に描画できるように、いずれも自動更新される仕組みになっている。
まだまだ課題も多く発展途上だが急速に進化中で今後に期待
では、Google Data Studioを使うべきなのはどのような人なのだろうか？ つまり、このBIツールの恩恵をもっとも効果的に享受できるケースは何か。樋口氏は2つの具体例を挙げる。
「ひとつはGoogleのクラウド向けグループウェアツールである『G Suite』を使っている人。当然ですが、レポートの管理・共有が楽に行えます。もうひとつは、BIツールにあまりコストをかけたくないと考えている人。有料BIツールに毎月何千円も払うのが難しく、低コストでビッグデータの可視化やレポート共有を実現したいと考えている方には、ぜひオススメしたいと思います」
もちろん長い歴史を持つ有料のBIツールに比べるとまだ課題は多く、発展途上であることも事実だ。だが毎月機能追加・改善がリリースされており、動きの活発さからも今後の改善・進化が十分に期待できる。またリリースノートは、日本語版と英語版の両方があるが、更新の速さを考慮すると英語版の参照が必須だという。
設計のツボを押さえればパワフルな分析基盤が安価に実現
樋口氏は「BigQueryを使用したデータ分析基盤を構築・運用で学んだこと」として、いくつかのポイントを紹介する。その中でも特に設計段階で気をつけておくべきこととして、以下の2つを挙げる。
- Streaming Insertは計画的に行う。
- パーティションテーブルを選択しよう。
BigQueryに分析のソースとなるデータを取り込む方法は2種類ある。「Streaming Insert」と「Load」だ。Streaming Insertとは、データ管理ツールのメモリバッファから直接データをBigQueryに取り込める機能で、通常のバッチ処理のようなタイムラグを気にせず、必要に応じたタイミングで分析のデータソースを取得できるメリットがある。このためリアルタイムの分析基盤を構築する場合は、必然的にStreaming Insertを使用することになる。
だがここで一点注意すべきなのは、Streaming Insertにはデータサイズなどの割り当て制限があるということだ。この割当量は拡張できないため、想定されるデータ送信量や、データ送信量の伸び代を考慮しながら、割り当てに抵触しない設計をしないと、後に思ったような分析環境を維持できなくなる恐れがある。
「データ発生からBigQueryに入れて可視化・分析できるまで、どの程度の間隔まで許容されるのか。行いたいデータ分析の要件と、割り当て制限のバランスを設計段階でよく考えておかないと、せっかく分析基盤を構築しても使えない、となりかねません」
またStreaming Insertを利用した場合、ストレージ料金は通常の2.5倍とコストが高く、数万件～数十万件に1件の頻度でデータが欠損するといわれている。こうしたデメリットについてもあらかじめ考慮しておくことが必要だが、これはStreaming InsertとLoadの処理を組み合わせることで解消できる。
例えば料金については、例えばリアルタイム性が重視される分析基盤の場合、ひとまずStreaming Insertで最新のデータを取り込んでおく。そのデータを深夜の1日1回のLoadで上書きすれば、そのデータ分については通常のLoad料金に下げられる。
またStreaming Insert時にデータの欠損が生じた場合も、後からLoadによる上書きで補完することが可能だ。
「この他、日付テーブルの管理についてもポイントがあります。日付別テーブルとパーティーション（分割）テーブルの2種類がありますが、Google Cloud Platformが推奨していること、またパフォーマンスにかなりの差があることから、当社ではパーティーション（分割）テーブルを選択しています」
「こうした細かなポイントをていねいに押さえていくことで、BigQueryを活用した安価かつ高パフォーマンスな分析基盤を実現することは十分に可能だ」と樋口氏は語り、セッションを終えた。
お問い合わせ
株式会社grasys
