ビッグデータ分析・活用のためのSQLレシピ Chapter2

システム

PostgresSQL

Apatch Hive

メリットとデメリット

  • RDBがレコードに対して処理するのに対し、Hiveはファイルに対して処理をする。
  • そのため、クエリ発行 = ファイルの全件走査になる
  • スループットは高いものの、内部的に複数の手順を踏んで処理を実現しているため低レイテンシを求められるときつい

Amazon Redshift

  • 分散データベースだが、Hiveと異なりRDBに分類される

メリットとデメリット

  • AWSなのでスケールアウトが可能
  • 利用時間で課金なのでインスタンスの起動・終了を意識する必要がある

Google BigQuery

  • こちらは読み込んだデータ量で課金
  • データ量が少ない間は低コスト運用可
  • Googleサービスとの連携も魅力

特徴とデメリット

  • 利用できるSQLは 「レガシーSQL」と「スタンダードSQL」がある
  • クエリが短くても読み込むデータ量が多いと爆死する
  • テーブルやカラムを絞り込む工夫が必要

SparkSQL

  • ApatchSparkの機能の一つ

メリットと特徴

  • ビッグデータの関する機能を一通り揃えているのがSparkのメリット
  • 通常複雑な工程を経て分析するが、SparkはSQLだけでなく各PG言語も対応していて実行できる
  • DataFramesと呼ばれるAPIが豊富でどの言語でも同様の記述で実装できる

データ

データの種類

  • 業務データはトランザクションデータとマスタデータに分類れる
  • いわゆるログだけでなく、サイトに埋め込んだタグデータやサーバ側で意図的に出力したデータもログデータとして扱う
    • ログデータは基本更新せず、追記していく

業務データ

  • データ制度が高いが時期によって変更される可能性がある
  • テーブル数が多い
  • 蓄積方法
    • 全レコード
    • 日付ごとのスナップショット
    • 差分レコードの積み上げ
  • ログデータより正確性は高い
    • ログの場合は送信方法によっては欠損するので
  • サービスの回遊や訪問回数といったwebに関する分析は苦手

ログデータ

  • 業務データでは保存しないIPやcookieといったデータも保存する
  • 集計対象を意識しておかないと制度がブレる
  • 過去データを更新せずに残っている
  • 蓄積方法
    • タグやSDKなど、専用の機能を利用したビーコン型
    • サーバ側で実装した処理で出力するサーバ型
      • サーバ型はクローラの影響を受けやすい事を意識しておく
  • 業務データで分析できないPVや回遊状況の分析に使用する

2つのデータを利用することで生まれる価値

業務データ単体

  • 売れ筋商品の解析

ログデータ単体

  • 専用のタグやSDKを使用することで、ツールのレポートを確認できる
  • ただし、汎用的なフォーマットに対応していることが多いため、カバーしていない独自のレポートは確認できない

2つのデータを利用することで生まれる価値

  • ユーザの流入元の違いが与える売上の違いの調査など

データの利用価値

  • 目標管理
    • 目標に対する進捗を把握できれば、今後の活動を検討、実施を促すことにつながる
  • サービス改善
    • ユーザインタビューではコストや母数の少なさが問題になるが、サンプル数が多いデータを活用することで傾向をつかめる
  • 未来予測
    • データの分析でネガティブな傾向に対して対策が打てたり、レコメンドもできたりする

ビッグデータ分析・活用のためのSQLレシピ Chapter1

データを取り巻く環境の変化

  • 2005年にGAが登場して、分析・解析する仕事が認知されてきた
  • その後GA以外のツールも出てきたので集まるデータが増え、保存場所も一箇所ではなく複数の場所に点在することとなった
  • ビッグデータが注目され始め、活用する動きが出てきた

様々な課題

分析担当者の課題

  • 従来はGAなどGUIで解析できるツールがありそれで仕事を出来ていたが、まとまっていないデータを集計するためにSQLの習得が必須になった
    • BIツールを使うことでGUIで頑張れなくもないが、細かい制御はSQLが必要になる
  • 何を指標とするか、これまではツールが教えてくれていた。これからは指標も自分で決める必要がある。
  • そもそもデータ構造の理解がないと何を集計できるのかがわからない

エンジニアの課題

  • 分析・集積のノウハウがないので解決したい課題がわからない
  • システム開発とデータ分析で使用するSQLが異なる

職種を超える横断的な分析力を身につける

  • データを作るまでがエンジニア、レポートを作るのが分析担当者の仕事として分断してしまうと、レポート用のデータを作るところでつまづく
    • アウトプットとするデータの認識合わせの工数
    • データができるまでの分析担当者の待ち時間
  • 互いが互いの領域の理解をすすめることで、積極的にデータを見に行ける分析担当者やデータ活用をできるエンジニアになることをめざす