『 データ分析基盤Night #1 』に参加してきた #データ分析基盤Night

ビッグデータ分析及び環境構築に携わっているものとして、タイトルと中身を一目見て『これは！』と思い抽選に申し込み。晴れて当選する事出来たので、2017/02/28の仕事上がりで参加してきました。

当エントリは『WebサービスやiOS/Androidアプリを対象とした、インハウスのデータ分析基盤を開発しているエンジニアが、どんな基盤を作り、運用し、利用者に広めるためにどんな取り組みをしているのか、苦労を分かち合いながらノウハウを共有する場』(※connpassイベントページより抜粋)として設けられた当イベントに関する参加メモです。

• データ分析基盤Night #1 - connpass
• 2017/02/28 データ分析基盤Night #1 #データ分析基盤Night - Togetterまとめ

会場は株式会社オールアバウト＠恵比寿。JR恵比寿駅から程無く近い場所にあり、とても綺麗なフロアでした。

• オールアバウトグループのコーポレートサイト – アクセスマップ

「リブセンスのデータ分析基盤の全貌」

• 発表者：taise(@_eurk)氏

発表資料

聴講メモ

• リブセンスアナリティクス(データ分析基盤)

  • データ収集：ログデータ／データ同期／外部データ
  • データ分析・活用：アドホック分析／KPIチェック／データソース

• 基盤の規模感

  • テーブル数：400
  • レコード数：95億
  • 利用容量：2TB
  • アクティブユーザー：80名
  • アドホッククエリ：800/day

• 構成図：今回はストリーム処理に於けるブラウザログからデータを連携するところについて解説。

• Redshiftのデータ設計

  • 基本的にはアクセスログに紐付く形。
  • 色々な種類があるが、独立していては意味を為さない。
  • データ設計に関する解説

• システム設計について：ログ・ストリーム処理編

• ログ収集JS(ブラウザ)
  • 取得データの内容はアクセスログ、イベントログ等を取り、useridや訪問情報をCookieに保存。
  • ビーコンにデータを詰めてAPサーバに飛ばしている。
• APサーバ
  • データ加工
  • fluentdでバッファリングしてログをs3に保存

• RIN(Reshift data importer)というツールを使っている

  • S3のputイベントがSQSにプッシュされる
  • RinがSQSメッセージを取り出し、Redshiftにログを保存 sfujiwara.hatenablog.com github.com

• アーキテクチャ再考

• 現状、DataLakeとDataMartを全てRedshiftに集約してしまっている。
• 利点
  • JSを読み込むだけで自動でログ収集出来る
  • ストレージ／コンピューティングを各クライアントに分散出来る
• 課題
  • データの定義変更が困難
  • cookieにデータを持ってしまっている
    • 例)セッション判定を途中で変えたい時にデータの一貫性を保証出来ない

• 再考

  • データの定義変更を容易にする：過去にさかのぼって全て修正したい。
  • 定義変更のあるデータと無いデータ
    • 定義変更無し：マスターデータ／URL、アクセス時間等
    • 定義変更あり：直前URL、アクセス時間から訪問(セッション)判定→マスターデータから再生成

• 進行形

• Spark on EMRでセッションデータを書き換えてRedshiftに入れる
• ここまで行くとLambdaアーキテクチャも見えてくる。
• 日次の正しいデータをSpark on EMRで再計算

• 速度層とバッチ層で分ければうまくいくのでは？と思っている(まだ思案中)

• 使われない分析基盤

  • ニーズが不明なままだった

• なぜ作られたか

  • ビジネスモデルに於ける必要性。リブセンスは成果報酬型
  • サイト内行動(アクセスログ)とCRMの突き合わせが必要。特に広告
  • ないとまずい、という明らかなニーズがあった

• 使われる分析基盤にするために

  • 組織を踏まえた設計・体制
    • エンジニアはサービス開発で忙しい：開発エンジニアを専任で置く
    • 複数のサービスを提供：共通部分とカスタマイズのバランス、簡単にログ収集が出来る設計に
    • エンジニアはデータ設計のノウハウが不十分：アナリストにデータ設計レビューをしてもらう、集まったデータで分析出来るように
  • 企業文化を理解し支える
    • 文化：ディレクターから営業までSQLが書ける。自由に分析出来る状態が望ましい。(GUIは制約を与えるので作らない)
    • 支える：疑問を解消出来るサポートチャットの用意、エンジニアがいないチームのデータ処理のお手伝い
  • 機能追加の優先度
    • ログは過去に遡って収集する事は出来ない。取得開始日をできるだけ早く、（欲しい）と思った時に分析出来るようにする
    • ログだけあっても使われない。事業データが一緒にあってこそ。紐付く様になってからサービス分析が出来るようになる

• Redshiftクロスジョインは辛かったののでspectrometerというのを使って一部対処している。 github.com

Q&A

• 見えちゃいけないデータをどう管理しているか？
  • スキーマ毎に権限を与えて管理している。

「Rettyのデータ分析基盤について」

• 発表者：たく@社会復帰済み(@jp_taku2)氏

発表資料

聴講メモ

• Rettyの分析基盤の歴史：現在次のフェーズへの移行中。都合2つのフェーズを経て今の状態に。
• 要件
  • 分析者がストレス無く分析する事が可能な環境を構築
  • 各チームで共通のデータを使用
  • データとログを1つのDBに集約
  • 短時間での復元が可能な状態を保持

• それぞれフェーズでの課題

  • 1.Treasure Data
    • 利用用途・頻度・人が増えてしまった -データ量の爆増
    • クエリの実行時間がかかってしまうように
  • 2.Treasure Data + BigQuery
    • 統一した環境を構築しなかった
    • データ粒度が違うものを個々で利用していた
    • 金額をハンドルする人が居なかった
  • 3.現在の構成
    • AthenaとBigQueryを主に利用。
    • データを貯める
      • 蓄積の仕組み
        • TDの送信の理由：収益に関わるクエリが稼働中。現在も。
        • GCS：共通ログを送っている、DWHを汚さない為に一旦GCSに吐き出している。
        • 
    • DWHからDMへ
      • Athenaを利用したのはファイル形式で保存出来る形を取りたかったから。移行もし易いと判断。
      • 
    • 結果
      • S3をベースにした部分をDWHと呼ぶようににしている。

• 機械学習基盤

  • 全環境同じ、GPUのみ異なる環境にしている。
  • 各環境のDockerにsshログインして使う。共有ストレージを使っているためどの環境にアクセスしても同データを見れる。
  • Quadro GP100というものを検証。世界初NVLink対応、PCIe拡張カード

• まとめ

  • 分析基盤のリプレイスによりにより課題解決が出来た。
  • 今後はAPPサーバからのログ送信やデータの鮮度を上げていく事が課題。

「Gunosyのデータ分析/ログ基盤の全容」

• 発表者：もょもと(@moyomot_)氏

発表資料

聴講メモ

イベント終了時点で上記資料が公開されていた為、メモは割愛します。

まとめ

20分セッションx3と駆け足感のあるタイムスケジュールではありましたが、内容的にはどれも非常に充実したものだったと思います。それぞれもう少し時間枠を拡大＆深掘りした内容で聞いてみたい感も。各セッション内で紹介されていたOSSサービスの中には興味深いものも幾つかあったので個人的にも使ってみたいと思います。また当イベントは『#1』と銘打たれている様に今後も継続して開催していく意向との事。次回開催も楽しみですね。

(※開催時に参加者全員に振る舞われたビール。)