#garagekidztweetz

読者です 読者をやめる 読者になる 読者になる

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

#linedevday 2015 に当選したので行ってきました 〜午後編〜

conference line lifelog

午前のメモにひきつづき linedevday 2015 の午後のメモを公開します。

linedevday 2015 の午後のセッションでは、わたしは以下の 3 つのセッションに参加してきました。

  • 13:30 - 14:10 A-5 HBaseとRedisを使った100億超/日 メッセージを処理するLINEのストレージ Shunsuke.N
  • 16:00 - 16:40 B-4 ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術〜 Taiichi.H
  • 16:50 - 17:30 B-5 ベイズ推定とDeep Learningを使用したレコメンドエンジン開発 Jun.N

では、以降、それぞれのセッションのメモ、および資料へのリンクを公開します。

13:30 - 14:10 A-5 HBaseとRedisを使った100億超/日 メッセージを処理するLINEのストレージ Shunsuke.N 氏

  • LINE Storage Team
    • Server Team の一部が担当
      • Redis
      • HBase
      • Log Aggregation
    • 物理的なインフラは別のチームが
  • Outline
    • LINE Storage
      • Need Storage
        • Asynchronous user-to-user messaging
          • それだけならば MQ でいいが次の理由から MQ では足りない
        • Capable of multiple devices and PC
      • Storage Requirement
        • Low latency
        • 0 downtime
      • for fullfill this requirement using OSS
        • for messaging
          • Redis
            • various datatypes
          • HBase
            • Persistent NoSQL
            • Fast write
      • LINE's Sharded Redis Cluster
        • self developped
        • Early phase Redis wasn't have cluster feature.
      • HBase
      • LINE's Data
        • Message / Message Box ops
          • Immutable
          • 100s of TBs (Redis+HBase)
        • User / Social Graph
          • 10s of TBs (Redis+HBase)
            • mainly Redis
          • Rundom access
        • Stats
          • 10PB
          • HBase+HDFS (queried by Hive)
    • Availability enhancement
      • Tune up Redis and HBase
        • Redis case
          • Single Theread
          • Fail Fast
            • ノード障害と遅いレスポンスを早く検知 (ZK)
            • 他のストレージにリクエストをリダイレクト
          • Use Redis Lua as Stored Procedure
            • IO overhead
          • Status of LINE's Redis
            • 30 Clusters
            • 4775 shareds
            • 48TB memory
          • self developped Redis monitoring tool - RedHand
            • Shard management
        • HBase case
          • Fail Fast
            • timeout tuning
              • ZK <-> RegionServer
              • API Server <-> RegionServer (RPC timeout)
          • Recover costtime
            • More HLogs, Longer recovery costtime (Hlog の蓄積問題)
              • Reduce archived HLogs
              • Use distributed log splitting/replay
          • Data Locality
            • Resion Server's failure caused.
              • using Major Compaction to keep data locality.
      • Dual HBase Cluster
        • Hadoop1 NN が単一障害点
        • 単一、複数サーバ障害に耐える
        • HBase やクライアントのバグに耐える
        • Human Error に耐える (like... hdfs fs -rmr)
        • to Prevent Above
          • Dual async read/write
      • Read HA with Redis + HBase
        • Redis と HBase でResponse が速かった方を返す
    • Details of HBase devops
      • LINE's HBase env
        • HBase 0.90 + Backport, 0.94 & 0.98
        • Own HBase replicator
          • Region Server とは独立したプロセスで動作
          • HLog を利用したレプリケーション
        • MR for batch
        • Local HBase with Docker
          • dev と Test 環境を簡単に構築できる
      • HBase Table Design
        • HBase is just a KVS
          • Multi dimentional and Sorted
          • but Just KV internally
        • General tipes of Table schema
          • アクセス単位で1つの Table, Row に収める
          • HBase の timestamp を活用
          • HBase の Scan, Filter を使用する
          • Hbase のカウンターを使わない
            • Disk base のストレージなので
            • Java の heap サイズ依存
        • Ex. Message Box (これは資料が詳しいのでそちらをみるのがよさそう: 問題点とその対処を話している)
          • Data Access
            • Put 多い
            • Get 少ない
          • ユーザがチャット別に送信した
            • メッセージ ID
            • メッセージ
          • 遭遇した問題点
          • 問題点を改善した Message Box v2.
            • 1 つの table と 2 つの CF
            • Filter と Scan をつかったページング
            • カウンターを使わない未読数
      • HBase Ops
        • Using Chef
        • Handles Daily Machine Failures
          • 統計クラスタは自動化
          • サービスクラスタは半自動化
        • HBase web viewer
          • monitoring tool - BlueHand
      • HBase Scalability
        • DC capacity issue
        • Higher frequency of HDD Failure
        • Scale out is not enough
          • Scale up
            • ioDrive
              • レスポンスと Compaction の性能改善
              • マシン障害頻度が数週に一度に
              • 台数を減らせた (半分とまではいけなかったが)
      • Hadoop Cluster Status
        • 1 large cluster
        • 10PB (snappy, FAST_DIFF)
  • Next Challenge
    • migrate to HBase 1.x + Hadoop2
      • recovery time improvement
        • distributed log replay
        • timeline read
      • NN not SPOF anymore because of Hadoop2
    • Others
      • Using multiple DCs
      • Enhance ops tools
      • OSS contributions

16:00 - 16:40 B-4 ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術〜 Taiichi.H 氏

  • データ分析について
    • データ分析とは?
      • Collecting - データ集約
        • reasonable
        • 大量データ保持
      • Reporting - サービス状況を報告
        • 柔軟なデータ集計
        • わかりやすいチャートでの可視化
      • Analyzing - サービスの問題点や改善点を分析する
        • 勘弁で高速な抽出
    • 異なるニーズ
      • Engineer
        • UI どうでもいい
        • 生データほしい
      • Planner
        • KPI
        • きれいなグラフみたい
        • Excel ダウンロード
  • 分析プラットフォームの構成
    • For Engineer
      • 凝ったことはしない
      • SQL などのクエリが柔軟に発行可能
      • API によるバッチ処理との連携ができる
      • その環境
        • Log collector
          • fluentd
        • Data Lake: Hadoop
          • Shib / Shib UI
            • Hive, Presto をサポート
            • API 連携
        • Streaming, Realtime Analytics
          • Norikra
          • Dashboard
    • For Plannner
      • データを可視化
      • データダウンロード
      • Not SQL
      • そのための環境
        • Hadoop: Web HDFS, HDFS, YARN (HDP2.1)
          • MR
          • Hive
        • Presto
          • Prestogres: BI との連携に
        • ETL
          • Azkaban
        • DWH
          • infiniDB
            • MySQL ベースのカラム志向 DB
            • Frontend からは MySQL として認識されるので、多くの BI tool やクライアントで利用可能
        • BI tool
          • IBM Cognos
            • KPI レポート画面
            • 認証、 DB 接続は独自対応 (Presto, InfiniDB)
          • Pentaho
            • OLAP
    • 非常に重要視していること
      • API 連携できること
      • OSS
        • できないことはできるだけ自己実装
      • データに関してはできるだけ隠蔽できるように
        • 認証しっかり
        • ユーザ情報はみせない
      • ユーザトラッキングはしない
  • グローバル化でみえてきた課題
    • 変化してきたこと
      • サービスの変化
        • グローバル化
        • 多様化
        • 長寿化
      • 人の変化
        • Planner の増加 (社員が増える)
    • 結果として起きること
      • KPI の増加
        • サービス x メジャー x ディメンジョン
          • 国別
          • カテゴリ
          • 訳の分からないフラグ
          • 訳の分からない要望
    • KPI が増えると忙しくなる
      • 結果 KPI はみられなくなる
      • 結論:
        KPI なんて人でみなくていい、 KPI の変化を伝える
        特徴的な変化を notify する
    • KPI モニタリングシステムの開発 - 現在進行中
      • すべての KPI トレンド分析を自動化
        • 時系列のトレンドを学習して予測値を算出
        • 異常値を検出してアラート
          • メール
          • Chat
      • 構成
        • Hadoop, DB
        • Data lake (dedicated)
        • KPI monitoring
          • kafka + Spark
            • nofify mail/chat
      • Timeseries producer
        • 各時系列データのトレンドを学習して、予測モデルを構築
        • 予測値と実測値を保存
      • Notification Monitor
        • 予測値よりも実測値が大幅に異なる場合、通知
          • Mail/Chat
  • まとめ
    • Hadoop を基本に
      • OSS base
      • 認証系はきちんと
      • ユーザ情報は隠蔽
    • KPI モニタリングを強化
      • 増え続ける KPI を自動的に処理

16:50 - 17:30 B-5 ベイズ推定とDeep Learningを使用したレコメンドエンジン開発 Jun.N 氏

  • Self Intro.
    • ニューラルネットワークを研究
      • Deep Learning と関連
    • 2014 joined to LINE
    • 機械学習を使ったサービス開発
  • Recommendation
    • Item 単位
      • この商品をかったひとはあれも
    • User 単位
      • あなたへのオススメ
  • 開発の動機
    • スタンプ数の急速な増加
      • ほしいスタンプがみつけられない
        • クリエンターズスタンプの導入以降加速度的に
  • Contents
    • 前提条件
      • ユーザ数 MAU 1 億 8,100 万
      • スタンプ数 9 万
      • 200 の地域で販売している
      • 公式スタンプとクリエイターズスタンプ
        • 公式とクリエイターズで売れ行きに開きがある
      • メタデータ不在
        • ネコスタンプにネコというメタデータはついていない
    • Algorithm
      • Flow
        先に item 間の近さを測定する (item のほうが user よりも圧倒的に少ない)
        • Purchase History
          • Simiarity among items -> Top-N items for user へも
          • Top-N items for item
        • User Activity
          • Preference
          • Top-N items for user
      • Top-N items for each item
        • 数式は資料を参照
          • 共起行列
          • y を買った人が x も持っている確率
            • 確率が 0 にならない Hack を使う
            • ベイズ推定
          • 売れ筋ばかりがでてきてしまう問題への対処
            • 公式とクリエイターズの売れ筋が乖離
            • フツーにレコメンデーションすると公式しか出てこない
            • ε での補正
              • ε = 1.0 ではでてこない
          • 地域ごとの好みの違いの反映
            • 全世界版で確率分布を計算したのち、 200 の地域について補正している
      • ユーザの選好
        • 仮定1: 好ましいスタンプをよく使う
        • 仮定2: 最近購入したものをより好む
        • その仮定を数式であらわす (資料参照)
        • すべてのアイテム x ユーザについてのスコアを計算するのは計算コストが大きすぎる
          • ではどうするか?
            • 所有する各スタンプに対するアイテムレコメンド Top-N を表にならべる
            • 図のルール(資料参照)のルールで順番にスタンプを n 個選ぶ -> これはスライドをみるべき
            • 選んだスタンプのみスコアを評価する
      • 実績
        • ランキング 1,000 以下の販売数が上昇
        • レコメンド枠にランキング上位スタンプを表示した場合と喰らえアイテムレコメンドを表示した場合の CTR は 9 倍
    • Architecture
      • Purchase History (HDFS) : Batch
        • Simiarity among items (Hive) -> Top-N items for user へも
        • Top-N items for item (HDFS)
      • User Activity (HDFS)
        • Preference (Python+C) : Streaming
        • Top-N items for user (Python+C)
      • 結果を MongoDB へ
    • 最近の改善について
      • 紹介した algorithm の問題
        • 新発売のスタンプについてレコメンデーションできない
        • コールドスタート問題として有名
      • 画像の類似度に基づくレコメンデーションの実装
        • Deep learnng による類似度判定
          • スタンプに含まれる複数の画像から特徴量を抽出
        • スタンプに購買履歴がない場合に適用
          • Naver Labs と共同研究開発
  • まとめ
    • アイテムの類似性を軸にしたレコメンデーションを LINE ではしている
      • そのほうが有利だから (item の方が User から計算するよりも)
    • 購買履歴が存在しないアイテムについては、画像の類似度にもとづいて類似度を判定

メモは以上です。

スライド資料

2015-05-02 時点で公式に公開されていないようなので、公開されたら貼らせてもらおうと思います。

linedevday に関連したメディアエントリ、他の方のブログへのリンク

2015-05-02 時点でわたしがはてブしていたものをリンクさせてもらっています。(他にもみつけたら追記する予定です)

メディア
Togetter
他の方のブログ

大変熱気のあるイベントでした。当選して参加できてよかった!
では、今回はこんなところで。

あわせて読まれたい