【再検証】CROSS2016:Google BigQuery × Amazon Redshift

川崎照夫

2016.05.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、Redshiftを本格的に使い始めて2か月の川崎です。

先日、下記のタイトルで記事を書いたのですが、その時に引用させていただいたのが、今回取り上げるCROSS2016の「Google BigQuery × Amazon Redshift」というセッションでした。

Redshiftのルーツを紐解く

そもそもCROSSは「@nifty エンジニアサポート」がルーツだそうです。私も、大森時代を含めて、主にTokyo.RやTokyo.Webminingといった、データ分析系の勉強会の参加者として、何度も利用させていただきました。

改めてここで書くまでもないかもしれませんが、現在でこそIT系勉強会の会場提供をされている企業は多数ありますが、その先駆的存在が「@nifty エンジニアサポート」だと思います。

エンジニアサポート CROSS2016 実行委員会について

「エンジニアサポートCROSS 2016」は、「@nifty エンジニアサポート」※を活用して勉強会を開催した勉強会主催者や参加者、および各企業の有志により構成された「エンジニアサポートCROSS 2016 実行委員会」が企画/運営をいたします。 ※ @nifty エンジニアサポートニフティが2010年8月から正式運用。『日本のウェブエンジニアリングをもっと活発にしていきたい』という思いのもと、技術者の勉強会を主催する技術者に対して、会場の提供や動画配信協力などを実施している。これまで100回以上の勉強会をサポート。勉強会主催者数は40団体以上、「@nifty エンジニアサポート」を活用した勉強会の参加者は約5,000名以上。

このセッションのビデオを３か月前に最初に見たときには、RedshiftもBigQueryも使ったことがありませんでした。

Redshiftを使い始めて、Redshiftに対する理解も多少なりとも深まった今、改めてセッションの内容をまとめてみたいと思います。特にRedshiftとBigQueryの、それぞれの使い所について確認していきたいと思います。

「Google BigQuery × Amazon Redshift」
 http://2016.cross-party.com/program/d1

CROSS 2016 で話してきました
 http://adtech.cyberagent.io/techblog/archives/487

セッション概要

企業の中でも重要視されるビッグデータ解析だが、まだ「データウェアハウス」に絞り込んだサービス間交流や勉強会は、頻繁には行われていません。

この場では「データウェアハウス」の代表的なサービスであるGoogle BigQuery × Amazon Redshiftをクロスさせることで、導入した各社の共通の課題や解決方法をあぶり出し、参加頂いたエンジニアに対して、「データウェアハウス」に対する最新情報を持ち帰って頂きます。それぞれの会社の課題を自ら解決していく「きっかけ」の時間にすることを目的にしたセッションになります。

すべてのWebサービスを展開しているインフラエンジニア、マーケティング担当者、マネジメントクラスのエンジニアの方は必ず参加すべきセッションです。

以下では、CA成尾さん、Google佐藤さんの発言について、まとめていきます。

CA成尾さん

5:55頃〜自己紹介
- アドテク本部エンジニア200名以上
- アドテクのスペシャリスト集団として活動
8:00頃〜 BigQueryについて
- fluentdを使ってログをBigQueryにストリーミングでインサート
- ほぼリアルタイムでデータの確認ができる
- 他のDWHからの移行ではなく、BigQueryを使うという前提からスタート
- データの構造やデータの持ち方を新規に考えて作っている
- 使う上で気にしたこと
  - スキーマの変更がなくJOINが少ない
  - サブクエリを複雑にしない
- 多角度、定常的な分析ではなく、必要に応じて分析する場合
- 日次で同じような集計をする場合
- アンチパターン select *
- テーブルデコレータで、検索範囲を絞るような使い方
9:55頃〜 Redshiftについて
- Redshift 100ノード以上
- 多角度で定常的な分析
- SQLが書けるので、エンジニアだけでなく分析をしたい人が直接SQLを投げる
- BIツールと連携、管理画面を出す
- Redshiftは複数のノードでデータを分散して持つ
- 全体スキャンが発生するクエリ
  - DISTSTYLE ALL（＝全ノードにすべてのデータを持つ）
11:00頃〜 Spark
- DWH、分析用途
- Sparkは、エンジニアがいないとジョブが書けない
- 作り込む必要がある
- 日々集計、バッチ処理とかでSparkを使っている
11:45〜 Matrix
- Redshiftの元になるプロダクト
- Redshift100ノード以上の大規模環境になると
- インスタンスのタイプ選んでしまう所もあるので、
- それだったら、自前でHW買って運用

Google佐藤さん

13:00頃〜自己紹介
13:40頃〜Google Cloud Platform (GCP)の特徴
- The Datacenter as a Computer
- 何万台というコンピュータを1台の巨大な分散計算機として使うための仕掛けが随所に施されている
- BigQueryは、その特徴をフルに活かした、うってつけのサービス
- 自社でサーバ、ネットワークを製造。ネットワークが速い
- JupyterNetwork
  - 10Gb 10万本収容
  - 1.2PB/sec
  - ネットワークファブリック
- BigQueryやMachineLearningの基盤
- コンテナ技術(Borg)
  - 10年以上前から（後出しじゃんけんみたいだけど、、、）
  - Googleのあらゆるサービスは、仮想マシン一切使わず、コンテナ技術
  - 何百のアプリケーションを1台のマシンの上にデプロイメント
  - Dockerと違うのは、１つのマスターで、１万台〜２万台の物理マシンを管理
  - BigQueryチームの人が、2000台の上で動かしたい
  - コマンド１発で2000台、5000台
- BigQueryの礎になっている
- BigQuery → Dremel（社内コード）
  - 2006年から社内で
  - ログ分析
  - ビッグデータ解析の主流、BigQuery
  - ログがTBクラスになっている
  - BigQueryがあるから、ビジネスが成り立っている
    - 何十TBというログがあったときに
    - お客さんから電話があって、
    - モバイル広告が出てないんだけど何が起こってるの？
    - １つのログを見つけ出す
  - 社員は全員BigQueryを使いまくって、
  - ビジネスが成り立っている
18:50頃〜デモ
- 100億行のデータを検索して10秒以下
- 正規表現を使用＝フルスキャン
- フルスキャンでこのスピード
- 速さの理由は「The Datacenter as a Computer」
- fluentdのBigQueryプラグインでログをインサート
  - １分かからずにクエリ結果に乗ってくる
  - 今のKPIがすぐに見れてしまう