LoginSignup
5
4

More than 5 years have passed since last update.

デブサミ秋2015行ってきた

Posted at

行ってきたのでとりあえずメモまとめ

データを巡るテクノロジーの冒険

データドリブン開発時代の技術とその選びかた

TD @tagomoris さん

データのトピック

  • コレクション
  • ストレージ
  • データ処理
    • バッチ
    • ストリーム処理
    • 機械学習
  • データのビジュアライズ

自分たちで作ってサービスするのか、サービスとして提供されてるやつを使うのか

  • フルマネージドサービス
    • BigQuery & Dataflow
    • Treasure Data
    • お金はかかる
    • 運用負荷が減る
  • セルフマネージドサービス
    • Amazon EMR & Redshift
    • Cloud Dataproc
    • どれくらいのノードが必要なのかとかを考える
    • フルマネージドよりコストは低い
    • 運用負荷はけっこうかかる
  • あとはオンプレ

サービスを使え!

データドリブンなサービスをするのならば、データ処理の仕組みを運用することが主な関心事ではない。

  • データドリブン開発→分散システム使う

    • スケールアウトの効力がある
    • →スモールスタートが難しい
    • HA構成を取ろうとしたら最低でも5台は必要だったりする
    • 分散処理のプロフェッショナルを雇うのは難しい
  • データドリブンな開発

    • データを集めて保存するところから始まる
    • そこを自分たちで考えると本来やりたいことが遅れてしまう

どうやってサービスを選ぶか

何をしたいかで何を使うかが決まる

最終的に欲しいアウトプットが何かを考える。
どう言うタイプのデータを処理したいのか?

データを集める

すでにあるデータ→バッチ処理
Embulk

随時データ→ストリーム処理
Fluentd, Logstash, Flume

Fluentd Support Service Released!!!

  • ストレージ
  • ビジュアライズ
  • 分散キュー
    • Apache Kafka
    • Amazon Kinesis
    • 一瞬来たスパイクは分散キューで受け止める。
    • クッションみたいなもん

さいごに

これらのツールに対する知識は必要。
だけど、やりたいことはツールを使うことじゃない。
データを使って何するかが大事!

楽しい創作活動を加速するトラフィック処理での工夫と技と頼れる仲間

Pixiv 小芝さん

インフラ→一騎当千

Pixivのトラフィック

  • 画像トラフィック
  • 広告インプレッション
  • ユーザーアクティビティ

最大使用帯域18GBps

4本の10GBps回線

自前の画像配信クラスタで配信している

クラウドにしないのか?
→その予定はない。コストが見合わない。長年の改善による安定性を重視。

go-thumbar
サムネイルサーバー

ちょっとパラメータいじって画質に影響があるととユーザーに言われるらしい。

分散アプリケーションアーキテクチャ 2015

Kaizen Platform @naoyaito さん

大量トラフィックとデータ

かつて…RDBにデータ入れて処理しきれずに苦戦してた

昨今

  • バッチ
    • Hadoop, BigQueryとか
    • 悩まなくなった
  • ストリーム処理
    • まだ力業な部分が大きい
    • これからここらへんがどうなっていくのか

Realtime Web

最近は聞かなくなった→コモディティ化した

TypesafeのReactive Platform

Reactive System

Microservices

MSAに通信手段の定義はない

JSON over HTTP使ってればMSAと言い張ることはできる…

とはいえ…

リトライとか障害起きたと起動するかとか考えることはいっぱいある
コンポーネント毎にやるのはやりたくない

そこでFinagle、Colossus

Finagle
どのサービスにアクセスするときも同じようにアクセスできるようにする

全てのサーバーはリクエストを受け取ってレスポンスを返す、というのに抽象化できる

Microsoft データプラットフォームを使い倒せ

Azure新機能増えてます

Cortana Analytics Suite

リクルートのアドテク

Perl自作フレームワークで作るアジャイルな開発

リクルートコミュニケーションズ

アドテクサービス開発の特徴

コードを書く力がそのままビジネス価値の向上に繋がる

エンジニアはモチベーションでパフォーマンスに影響されやすい生き物
エンジニアを評価しやすくなる
評価できれば給与が上げやすい
技術的チャレンジがし安い

エンジニアが長く定着

良いスパイラル!

アドテクやろう!

エンジニア評価基準のアップデート
- データ/コンピュータサイエンスのスキル評価
- エンジニア力の影響力を明確に評価
- スキル獲得を促進
- コーディング試験をアルゴリズム重視に変更
- コードに落とせる力を重視

自発的なイベントが発生

ボンバーマンの機械学習大会やったりしてる。
白熱しすぎて業務影響が…

すげえ!!!

エンジニア目線で見たデジタルマーケティング業界のこれまでとこれから

ブレインパッド 下田さん

「コマンドラインから始めるデータサイエンス」

エンジニアの素養がけっこう必要

データの観点は2点のみ

デジタルマーケティングとは?

マーケティングって曖昧な概念
デジタル上でモノ/サービスを普及させるための手段

目的→ 企業の売上げアップ

アドテク?

No。含まれるけどもっと広義のモノ

マーケティングファネル
One to Oneマーケティング→ デジタルマーケティングの理想型
究極的にやりたいこと

事業者のリソースやノウハウが足りなくて代理店へ

媒体としてのメディア。
顧客に集まってもらう魅力的なコンテンツを作る

ベンダーは実現するための技術的なモノを提供

認知系の広告→知ってもらう型
獲得系の広告→知ってもらったあとにどう書く得するか

アドテクは獲得系

アドテクの功罪

データに基づいて色々やることに効果があることが認知された
PDCAサイクルを回せるようになった

大量データを精緻にセグメントしたくなる
データ収集に貪欲になっていく
→ セグメントが増える → 業務がすごい大変なことになっていく

しかし、成果が出るので続く…

行き過ぎた試作に顧客がイヤになってくる

セグメントを細かくしてしまうと、母数に達しなくなって投資対効果に見合わなくなってくる

特微量化することで無理矢理類似ユーザーを出し始める

突然ターゲティングされ始める…

広告分野に偏ってる
→獲得系にフォーカスが当たっているので広告一緒になってる世に見える

今後どうなっていくのか

アドブロック

マーケティングオートメーション

オンラインとオフラインの統合 O2O
最近また動きが出始めた

アドブロック、マーケティングオートメーション、ネイティブアドの次くらいに来そう

SSP = Single Source Pannel
リサーチデータの一種
ビデオリサーチとかのデータと統合する

勝手に取ってるわけじゃなく協力者

データが少数なので機械学習とかしてもまだイマイチ
そのうちデータ取得コストが劇的に低下すればオフラインも変わる。

認知系の広告は予算としては取りやすい。
獲得系は効率重視なので予算の桁が違うことが多い。

何故テスラを買う人は43日前に一人旅をするのか

マイクロアド 青井さん

多次元データベース

テスラを買う人=特徴的な人

どういった人なのか?を分析する方法

多層/多面的データを統合することによって誰も知らない新たな知見を得る

データ活用の可能性

限られたデータでは分析対象の特徴を十分に知ることができない

わからないこと
- 何故テスラを買ったのか
- 何が心を動かしたのか
- どのようなユーザーなのかを本質的に理解することができない

たようなデータを結びつけることで、対象の特徴を深く理解する

  • 多面的な分析
    • 行動分析
    • 属性分析
    • 次駅列分析
  • 多層的な分析
    • メディア

実現したいこと

  • 新たな地券の発券
  • 未来予測
  • 広告やマーケティング分野 以外 への活用

多次元データベースのデータ活用

概要

様々な入力データをゲットする
独自開発のDWH
ユーザーI/Fで確認する

  1. 高速検索
  2. 時系列分析
  3. 価値観分析

データ

  • オンラインデータ群
    • Webアクセスログ
    • 購買データ
    • 位置情報
    • ネット接触時間
    • 接触コンテンツ
    • デモグラフィックデータ
  • オフラインデータ群(調査/統計データ)

分析機能

自由な組み合わせで分析

高速検索
時系列分析
- 特徴的な行動を取るタイミングを見つける
- 時系列を基にした予測分析

高速検索

ユーザー入力→検索→データ→出力(道の行動、特徴敵な嗜好性)

広告、マーケティングにおけるターゲティング設計

位置情報→居住性

ログ取得→Storm→Hadoop→機械学習→KVS→検索エンジン→UI

Stormでストリーム処理

  • 行動ログの統合
  • ID共通化
  • サマリ

Hadoop=PivotalHD
KVS=AeroSpike

行動ログ検索エンジン

  • インメモリデータベース
  • インデキシング
  • 時系列データの検索

共起解析エンジンを用いて特徴量の計算もリアルタイムで実行

  • ユーザー行動の時系列分析をUIからリアルタイム実行
  • 行動毎の特ちょうどを時系列で可視化

価値観・ライフスタイル分析

やんケロビッチの価値観ヒエラルキー

ライフスタイルクラスタ

データファースト開発

現状把握に何分かかるのか?

  • 非別/週別アクティブユーザー数など…

アドホックな分析だと1週間以上かかることも…

時間がかかることは罪。
本当に困るまで調査しなくなる

データ分析の専用ログを出力するようにする

結果が出るかどうか分からない調査をすぐに出力できるんなら多少遊びがあってもできる。
早いは正義。

フィーリングが重要。

データを巡るテクノロジーの冒険

LT大会

業務に活かすデータサイエンスとは?

リクルートコミュニケーションズ 丸山さん

  • よく分からないんだけど一体何ができるの?
  • 何でも自動で完璧に予測してくれるんでしょ?

→ カチン

Jリーグのデータを使って特微量抽出
Redshift使った

価値/負け/引き分けを予測する

言いたかったこと

何ができるかじゃない、何がしたいか!
機械学習を使うべきではないケースもある。

Stream processing in Mercari

メルカリ かぜぶろさん

Monitoring

  • その場にあるデータを取る
    • ロードアベレージとか
  • 積み上がってるデータを取る
    • CPU Usage、トラフィック
  • ログとか


シェル使ってた


Fluentd + datacounter

複雑なこと野郎とすると設定ファイルが肥大化する
プラグイン書く必要がある
追加時にFluentdの再起動が必要になる

じゃあどうするか
Norikra

巨大な設定ファイル不要
スキーマレス
SQL使える

グラフ・アラート
- Zabibx
- Nagios
- Growthforecast
- Datadog
- などなど

データを活用したコンテンツ最適化のいろは

インティメート・マージャー 梁島さん

BtoBのアドテクの会社

新卒2年でFluentdみたこと

グリー 山田さん

サービス毎に数台のアグリゲーターを用意して内製Hadoopとかで回してる

Webサーバの設定変更は少ない形にする
複雑な処理はアグリゲーターに集中させる

ログは基本JSONで出力する

プラグインをForkして改造しないこと!
Forkしてしまうと保守コストが高くなりがち。
Fluentdのバージョンアップが滞ったりする
歴史的な経緯とかもわからん

E2D3

UZABASE たけうちさん

データ可視化はデータ分析とは切っても切れない関係

Excelの上にデータ可視化してくれるツール
E2D3

すげえ

NewsPicksの仕組み

NewsPicks 桐畑

複数タイプのストレージを利用

  • DynamoDB → ニュースデータ
  • ElasticCache → 高速アクセス
  • RDS

SQSを使った分散処理

大渋滞が起きるのでSQSを使う

重要度のタイムラインは同期、それ以外はSQS

データ特性に合ったストレージを使う
処理量が多い場合は優先度を決めて分散させる

ディスプレイ広告

Sonetの人

残念なUX

広告エコシステムの危機!!!

メディア・広告主に変調してしまっている

Logicad
機械学習によりよりよい広告

Yahooのデータ利用

日比野さん

3000台クラスタ
常にリソース使用率は90%

ミッション

大量データを低コストで高速に処理できるようにする

Hortonworksと提携

OSS共同開発

Hiveの高速化

失敗から学ぶデータ分析グループのチームマネジメント変遷

ところてんさん

失敗
マネジメントなし
データ分析の人はなんでもできるので雑用係になってしまう
そればっかしてたら前に進めない

ペイオフマトリクスでタスクは消化できた
研究開発タスクの優先度が下がってそればっか残った

イノベーションのジレンマ
合理的な意思決定でイノベーションができなくなる話

要ブレークダウンが肥大化していった
しかもそこが会社のコア

タスクをこなすことが仕事じゃない
問題を解決することが仕事だ

Github Issueにしてみた
バイク小屋の議論に陥る

名前が悪い!

エンジニアとの連携が加速した結果、追いつけなくなった

エンジニアは合理的に動こうとするからギャップが発生する

問題はIssueを特人がいなかった


11/17 Sparkと機械学習をテーマにしたいベンとやります。

2/18,19 デブサミ2016

5
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
4