まとめ Google BigQuery × Amazon Redshift #cross2016 #cross2016d

各セッション

森崎 泰弘(エンジニアをクラウドで幸せにする) 佐藤 一憲(Google エバンジェリスト) なかむら さとる(某ECサイト GoogleAnalyticsのデータ分析のさわり) 佐長 康久(ビッグローブでRedshiftを一部組み込んだシステムの紹介) 成尾 文秀(アドテク本部)

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

データウェアハウスサービスに触れる様々なきっかけを持ち帰っていただきたい

" Google/Amazonなどを使って欲しい(ユーザーとしてのベネフィット) " 基本情報は今すぐググる " ぐぐっても出ない情報をここで出す

" CAはGoogle Big QueryもRedshiftも両方使っている

CA 成尾さん

Google BigQuery Amazon Redshift

CAについて

" SAP(ソシャゲのほう)のインフラ " アドテク本部のインフラ データ分析基盤、ミドルウェアなど

" CAはゲーム/インターネット広告がかなり強い(広告にもどんどん力を入れている) " アドテク本部(アドテクスタジオ) 子会社を20位上集めた集合体 " 200人以上いる " アドテクのスペシャリスト集団

BigQuery

" オンプレだけじゃない " OpenStack→fluentd→big query(リアルタイムでデータを確認) " 気にしたこと " スキーマの変更が少なくJOINが少ない " 必要に応じた分析 時間のかかる分析に使っている

アンチパターン

以下のSQLは使わない

select " from hogetale

Redshift

" 100ノード以上 " 多角度からの分析を定常的に行う環境(エンジニア以外も使っている) ” OpenStack→fluentd→redshift " 全件スキャン(distを使ったりしている)

" テーマとしてはbigqueryとredshift だけど、データウェアハウス以外も使っている

Spark

• 日々集計
• 定常的な処理で使っている ” OpenStack→fluentd→redshift

Matrix

" redshiftのもと(国内ではCAのみが契約してる) ” OpenStack→mapr→matrix " インスタンスタイプに縛られないハードウェアの選定

Google 佐藤さん

What is Google BigQuery

@kazunori_279

機械学習などのエバンジェリスト(テックリード)

AWSとGCPのちがい

" The Datacenter as a computer " 何万台をホスティングするだけではなく分散器としての利用 " BigQueryはそれをフル活用してる

" すべて自社でハードウェアもネットワークも作っている " Jupiter network ネットワークが超早い ethernet tcp/ipではないトラフィックを扱っている(詳しいことは言えないけど) " Bigqueryの速さの原因 " 40GbEports 1 Pbps " この速さがないと機械学習も出来ない

• コンテナ技術(Borg)を発表
  • Dockerに対抗
  • Gmail Youtube GCPもすべて仮想技術！ " ものすごい数のコンテナがある
  • コマンド一発で2000台などのマシンを扱える
• BigQuery(2006-) " ありとあらゆるプロジェクトのログ分析に使っている
  • 10奥ユーザー(Gmail Andorid)
  • もうMapReduceは使っていなくて、BigQueryを使っている
  • BigQueryをずっと使っており、テラバイトレベルのログ検索も一瞬(Hadoopとかだと遅すぎる)

デモ

• 100億行のWikipediaのアクセスログ(タイトルにcloudが含まれているページ + 正規表現のPV)の検索
  • 検索に正規表現をつかうとメチャオソなのに、100億行でも10秒以下
  • メモリをたっぷり乗せればいけるけど
  • datacenter as a computer すべてのサーバはただ連番で振られているけども、数千台のサーバで分散処理しているから、総なめ検索でも速い
  • Networkとコンテナ技術があるがための速さ

BigQuery

• fluentdのBigQueryプラグインがある " fluentdから直接BigQueryに叩き込んでいる " 今のKPIがすぐ見れる！
• EC2からBigQueryを使わない理由がない " BigQueryを使うのが基本 S3よりも安い

" IoTもそうだけど、いろいろなデータ分析が必要になってくる(物理的に真似できない領域になってきてる)

ビッグローブ 佐長さん

" OS ミドルウェアの領域でインフラエンジニア * Redshiftを入れる設計 " AWSを触っていることが多い

Redshift

• 2016から東京リージョンでも使っている
• スケールアウト可能な分散並列RDB
• 列指向型データベース
• 規模の小さいところから始められる(東京はちょっと高い)

ビッグローブが使っているところ

• データSIMのところで使っている
  • SIMごとにデータ通信量を集計している(分析ではない)

オンプレミス時代

• MySQLサーバで処理
• MySQLにデータをつっこんで、集計システムで制御
  • 1時間毎のバッチ処理が1時間で終わらなくなる
  • DBチューニングも限界
  • 自前の分散システムもしんどい
• もうオンプレでやる必要なくないか

Redshift自体

• そんなにノウハウ 事例がないので、Redshift(触りたかっただけっていうのはあるかも)
  • 必要に応じてスケールアウトできる
  • 基本的なバッチ処理(SIMのデータをgroup byするだけ)
  • 基盤の運用はおまかせ

• 2015/1から導入決定、3月に並行稼動、4月からスタート

• S3→Redshift " オンデマンドでクラスタを建てられる

• dc1.largeノード2台
• レコード数はそこそこ 51億
• ディスク容量は260GB
• オンプレだと1時間かけても終わらなかったのが数分で終わる

実際に開発した人たちは

• 分散キーとソートキーの選択は慎重に(ここの設計は重要)
• SIMのIDを分散キー/日時をソートキー(UNIX時間)
• 日本語混じっていたらきちんと検証しないといけないっぽい(今回日本語データはなかった)

設計 運用

• 定期的にメンテナンスが入るので、そこを考慮した設計にする
  • リトライ処理を長めにして、リカバリできるように
  • オンライントランザクションにも対応するためにオンプレDBも使う
  • 特殊な運用も準備しないと
  • リージョンごとにメンテナンス時間が違うので、起きている時間にメンテナンスできるように
• AWS CloudWatch/CouudTrail/SNS/Lambdaなどで自動通知出来そう

まとめ

• Redshift
  • 高速で完全マネージド型
  • ペタバイト規模のデータウェアハウス
  • 小さいところからでも始められるよ
  • 月数万くらいのコストで運用出来ている
  • 処理時間が1時間 7-8分
  • トラブルがなかった…と思ったら、ディスク使用量が8割を超えていた
  • 何百台という使い方でもOKだし、集計用途でも分析用途でも使えるから、とりあえず使ってみては

BigquryとGAPを2年使ってみた感想

なかむらさとる 運用部門(社名は出さないで)→開発部門の統括

BQとGAPとの出会い

• 社長命令でBQを検証し続ける
• GAP Google Analytic Pleminum(プレミアムあった 月1000万ヒットだったのが有料だと月10億ヒットまで面倒見れて、BQに生データを吐き出せるけど、月135万くらい)
• アクセスをHadoopで集計などするとめんどいから月130万x12x5=7800
  • 償却とか運用費用とか考えると別に高くない
  • 自前で作るとあちこちから文句言われるし
• ユーザーの行動遷移をBQで追えるので非常に楽
  • スキーマの説明も丁寧なので一読したらいいです
• BQはJSON形式でデータが入っているけど入れ子になっているので曲者
• BQはカラム単位のデータ容量に対して課金
• 1レコード全部取りしたら高い
• BQの一番いいところはView
• BQだとViewを使えばクソクエリも分解してメンテナンスできる
  • 長いクエリはそれだけでメンテナンスコストがかかる
• 何十億行のデータをJOINしても変わらない

まとめ

• BQ + GAP最強だと思っている
• BQはCSVを突っ込めばさくっとデータが入るので、本当にカジュアルに使える
  • GUIの画面でペコペコできるので。

本題

ググったら出てくるものはあまりおもしろくないので、利用者の本音を語っていただきましょう

• ポイント
• ハマりどころ

ポイント

CA本部

• データ量が多い(テラレベル)
• 検索対象が多すぎるので、いろいろな分析にコストがかかる
• 多角度な分析はRedshiftとか、っていう組み合わせ
  • JOINの数が多すぎるとBQは使えない
  • 移行の難しい物はRedshiftのまま
  • JOINの数で使い分けているので

Google

" BQユーザーの多くはRedshift/Oracle/IBMのデータウェアハウス(1台数千万)を使っていた " 物理的データウェアハウスはスケールアウトしにくい * 社長の鶴の一声でそういうのを導入してみても、いざ使ってみるととかく遅いので、事業部ごとに使える時間帯を分けるという良くわからないアンチパターン * それと同じようなパフォーマンスを安く提供できる

ビッグローブ

• 使ってみないと分からない
• さあ行こうってなったときに、小さいところから始められるのがRedshiftの良い所
• web上にはノウハウがあって、同じ所でハマっているひとは情報共有しているのでアンテナをはっていく
• 基本はググッて、あとは使いませう
• 試行錯誤、重要

なかむらさとる

• どちらもライトに使えるので、試しでいいから使ってみよう
• アウトプットをどうしているか
  • アウトプットはすごい重要なので、皆どうしているんだろう？
  • ExcelにSQL結果を吐き出して、それを現場/営業/コンサルに見せる
  • 検索結果が早くてもどういうふうにアウトプットしているのか気になる
    • たぶろーを導入してBIツールと連携している(CA)
    • 集計メインだけどログデータをサマライズしてCSVとして吐き出し、BIツールを担当している人に直接渡している 直接連携は今後の課題(ビッグローブ)
    • ビジネス寄りの人がいちばんとっかかりやすいのはGoogleスプレッドシートかExcelなので、それをベースしている あとはBIツールを使って、運用コストを減らすとかしてるので、ユーザーによって違う(Google) " GCPにジュピターを導入してる(Google)
  • BQ単体ではそこまでパフォーマンス落ちたイメージはなく、基盤の運用はGoogleにやってもらっている 億レベルなので、普通(なかむら)

アンチパターン(これだけには使ってくれるな)

• BQの使い始めの頃は、アップデートできない(要望は多いはず)
• BQで触ったデータは別の所に保存したほうがいいかも
  • クソクエリの可視化ができるようになった
• BQはコスト管理大変？
  • 青天井じゃなくなった 依頼すると上限を設定できるようになった 将来的には自分で設定できるようにしたい
  • 青天井じゃなくなった 従量課金ではなく固定料金もサポートできるようになったらいいね
• データ量が多いのでインスタンスは絞る
• 為替の影響で料金が変わる時がある
• クラスタを使っていない時は止めるけど、止めづらいものはある
  • 一回落とすと上げづらいクラスタもある/本番クラスタはなかなか落とせない

まとめ/感想

• BQもRSもいい面がある ミニマムからスタートできる(CA本体)
• 2010のBQのデモを見てサーバの物量で押し切っていることに衝撃を受けた 太客がBQを実運用しているのを見て、コミュニティのエコシステムもでき始めているので、自分の役割は終わった(Google)
• 自身も参考になる情報をもらった わかりやすい使い方の事例(ビッグローブ)
• とにかく使ってみたらいい 実データをボコンと入れるだけでも使いやすいと思う(なかむら)

実際に使ってみるときに、このセッションを参考にしたらいいと思います。