struggle against crossdomain data complexity in recruit group

Struggle against cross-domain data complexity in Recruit

group

リクルートテクノロジーズ松遥﨑 (Haruka Matsuzaki)

2(C) Recruit Technologies Co.,Ltd. All rights reserved.

アジェンダ

1. リクルート運営サービスのご紹介

2. 横断データと技術的負債

3. フレームワークプロジェクト

4.HDP2.5 ・ Kafka ・ Spark5. 結論 “ On Happiness”


話者紹介

職務

学歴

~ 前職

所属

氏名

Recruit Technologies ITS 統括部ビッグデータ部 IDPoint 領域 FrameworkTL ( 兼務：Holdings)

松　遥﨑

東京大学大学院広域科学研究科　複雑系科学

assembler→c++/qt→ObjC/tclTk→php/js→iOS→Java/js/css/Haskell→Lucene/Hadoop→Spark/Scala

開発：リコメンデーションジョブ自動生成 ETL

(C) Recruit Technologies Co.,Ltd. All rights reserved.

ライフイベント領域

進学

就職

結婚

転職

住宅購入

車購入

出産 / 育児

旅行

IT/ トレンド

生活 / 地域情報

グルメ・美容

ライフスタイル領域

選択・意思決定を支援する情報サービスの提供「まだ、ここにない、出会い。」を実現する

リクルート運営サービスのご紹介


リクルート ID一人ひとりにあった最適な情報を提供し、皆様の選択や行動を支える存在となることを目指す


リクルート ID とは


リクルート ID が使えるサービス①


リクルート ID が使えるサービス②


「リクルートポイント」の「 Ponta ポイント」へ


アジェンダ

1. 弊社と運営サービスのご紹介


3. 「フレームワークプロジェクト」



横断データ活用：フェーズ

ID 基盤が整いデータが増加し、我々は成長期の真っ只中爆発的な成長を目指すが・・・技術的負債が顕在化

黎明期成長期

・効果額・施策数・利用者数

貢献価値


黎明期：基本戦略

各サービスから各種データを収集、 DWH/Datalake に蓄積し活用

DWH 横断データ活用施策


黎明期：データ統合

サイト毎の仕様差異の吸収　個人情報のマスキング　重複や欠損のクリーニング…

DWH

0001

0002

0003

0004


黎明期：経営戦略指標

横断データ活用への最初の要求は、経営陣からの「経営指標」の集計

Query

DWH


黎明期：定常化運用

有用なものは日次 / 月次実行する”資産”となり、加速度的に増加

≒1000 Queriesrun everyday

Query

DWH


黎明期：機械学習の開始

DMT を機械学習の学習データとして転用

AnotherData

DWH


黎明期：機械学習の加速

DWH

PreparedData1

PreparedData2

MLlib

次々と機械学習アルゴリズムを変えるため、データ間の依存度が加速


Source

DWH DMT APP

黎明期：出来上がったシステム

“DMT”

users


黎明期〜成長期：システム運用

Change

predictioncorrupt

Change Change

moreusers

BiggerDMT

moredata

source

We changedlog spec!

bugmismatch

halt

mismatch

rerun!

morework


考察

なぜ仕事が増えるのか？

DWH DMT APP

開発業務の増加・クエリ複雑化・依存性複雑化・再発明・リカバリ・仕様変更対応

運用業務の増加・ Hadoop等バグ調査・各サイト繁忙期のデータ負荷対応・リソース不足・データ転送

待ちの増加・機械学習用 DMT 開発における低再利用性・ DMT処理時間待ち・アルゴリズム変更に伴う入力仕様変更


技術的負債の溜まり場

黎明期に描かれた古典モデルの破綻 ?

DWH DMT APP


構造的問題への対処：シフト

合理的な判断の結果、問題が生まれている

DMTへの投資システム成長DMTへの投資DMTへの投資DMTへの投資期待・投資

① 黎明期：急成長　　・利用者の増加　　・投資金額 etc…

技術的負債

外部要因：プレッシャー

etc…

② 成長期：鈍化　・ムダな業務の増加　・運用負荷 etc…

歯止め


アジェンダ






フレームワークプロジェクト (var/log)技術的負債を徹底的に排除するためのコードベース (jar)

Integrate software resources & unlocktheir full potential

“Absolute DRY”common process

auto generated

DSL for processing typically structured

data of Recruit

Codebase


哲学 = 「ありものは使わない」

外部ソリューションや、オープンソースフレームワークへの導入を試すも・・・

• 視野が狭まる• 機能不足・バグ /オーバースペック• ジョブ移行コストの膨大さ• 「リクルートだけの問題」

方針1. 長い道のりだけど、自分で作ろう。2. 本当にあらゆる面で優れた製品があったら、道を譲ろう。


技術的負債のブレークダウンとソリューション：

• 最適なMW

• 隠蔽• 制約

• DI• AOP

• 共通化• Code 生成

DRY Plugin

SpeedSimple

重複コードが多い再利用の属人化・不徹底

1つの MW 上での無理な実装設計の不在・無秩序


DRY(Don’t repeat yourself)• コンポーネント + コード生成

補完前

Loading

Mahout

Saving

xml 補完後

RecommendUser (Int)Item (Int)

DictionaryUserId (Int)

User (String)

DictionaryItemId(Int)

Item(String)

InputUserId (Int)ItemId(Int)

Loading

Mahout

Saving

Indexing

Format


Simple• DASE ”MVC for Data Science”• それ以外は極力隠蔽

<data/> <algorithm/> <serving/> <evaluation/>

xml .Jar

Loading

Query

Query

RDD+Scala

Jar内部で判定• 次の Algorithmは何？• データ量はどのくらい？• 過去の判定結果は？

MR

ParallelQuery

Hdfs+External


.Jar

PluginDI コンポーネントの Autowire/AOP により以下の機能は自動実行

• 件数カウント• メール送信• ログ + グラフ化• クエリ解析+ ステップ補完• クエリセッション設定・ヒント


Speed

• JDBC, Hive, Hbase, MapReduce, Elasticsearch…• 普通の Javaで HDFS に Read/Write• Pojo を渡せば Avro 実装• Templates & Callbacks• Spring Batch - スレッド標準実装• Spring Boot + Maven - 既存知識の活用

各 MW の特性を理解する + 最適な MW を利用するハードル ( 転送・学習 ) を 0 に

HiveServer

• Debugability on local machine• No Need to move jars on cluster (v.v UDFs)


プロジェクト完了 !?半年後、 var/log は完成し、最初の var/log ジョブをリリース

その後、新規ジョブは var/log 上に実装


アジェンダ






フレームワークプロジェクト　第 2章半年後 var/log は完成し、運用に乗ったが、２通りの社内顧客を発見

1. [High-end Customers]ニーズ : 速度・定常運用・生産性

2. [Early Adopters]ニーズ : 最新論文・実験・ Lean

２分割開発体制への移行を決定

Business Engineer

Scientist Engineer

コードは使い捨てデータがあり動けばいい

最適化・リファクタは

とりあえずあとで・・・


Move onto Agility

DWH DMT APP

DWH DMT Production

pubsub

Sandbox

Business

Engineer

Scientist

Everyone


Early Adopter向け機能とは何か

ニーズ：さあ、実験をしよう。

1. 秒単位の応答性能2. その場の思いつきを実データに適用

• 新しいライブラリ・・・• 新しい特徴量・・・• 新しい数式・・・• 新しい自作関数・・・

3. そのままリリース

→　 jar + xml configuration ではない


import varlog.jar on Zeppelin

.Jar

その場で作った自作関数 ( 動作確認後 varlog.jar にコミット )

データ抜きだし・加工


back to xml

.scala File

<scala> xml-tag

autodeploy

Release Notes as a Job

.Jar

Zeppelinで動作すれば、 xml にコピーして自動リリースも可能


PUBSUB システム構成

Pub-sub

DAORDD

xml

DWH

Another

Data

Hadoop

elastic

Job

Powered by hdp2.5WhyKafka?


Background Data Store: KafkaKafka とは？• publish & subscribe方式の分散データストア

利点1. ビッグデータシステム間のトポロジー構造の単純化2. 高速なスループット3. Spark との接続性


Kafka 1) トポロジー構造の単純化

Jay Kreps(the original author of Kafka) によれば・・・

<<

トポロジーが複雑＝システム間のデータ転送が多い状況ex) HBase→Hive, Hive→Oracle, Oracle→Hive, Oracle→Elastic, Prod→Sand…

Before


Kafka 2) 高いスループット性能

put=4000件 /秒=11.0MB 〜 14000件 /秒get=10000件 /秒=31.7MB (no OS pagecache)MessageSize=3kB, Broker=1で上記性能。チューニング・スケールアウトも可開発環境をローカル VM に構築


狙い：最適なシステムの統合による高速化

通常 ETL ジョブ：全ての SQL が Load/Join/Function/Persist処理を全部実行。役割分担無し

L J F PL J F P L J F P

L/J処理を集約後 Sparkで F/P処理を実行。明確な役割分担• DWH ： Join,GroupBy のみ• Kafka ： Spark のメモリへのロードのみ• Spark ： ScalaFunction再利用のみ

DWH

EXA

elastic

Hadoop

L

LJ J J

F

P

P

P

L


Kafka 3) Spark との接続

Oracle や Hive内のデータ加工関数のモジュラリティは低い。 scala の関数を jar からExport

.Jar

Before ：

After ：

select case when t.name in (‘a’) then 1

SQLid numu1 1

u2 2

u3 3

DMT

publicfunctions

def func

implict class A(RDD)

mapRow

hiveUdf

scala

Reusablily


“秒”レスポンスの検証

特徴量加工+ データを 1件覗く1秒

特徴量加工+Reduce53秒

特徴量加工+train+predict169秒 (50万件 )

さらに負荷306秒 (Depth = 30)

ある画面の 1週間の Impression が約 50万件。 Task 「 RandomForestでクリック予測」• overhead: spark=5sec Mllib=120sec• Spark Memory: 6G/192G• Kafka Bytes Out: 5G (Throughput: 100M/sec)

Total 300 sec

Kafka 50 ML min 120 ML ext 140〜

Graphana


インタラクティブ： MobProgramming にも最適

チーム全体が同じことを、同じ時に、同じ場所で、　　　　　　同じコンピュータ上で作業するソフトウェア開発アプローチ

Agile原則 (抜粋 )• フェース・トゥ・フェース　”ワイガヤ環境”• 動くコードの 2週間でのリリース• 難しい判断を要する設計の自己組織的決定• 動くコードでデモすることによる活発な議論

を促進


アジェンダ






我々が今目指している環境について

Analysis Ops

Engineering

Study

Idea

tryScientist


Workflow Change : Happy AnalyticsBefore ：

After ：

.Jar

Scientist

Scientist

HBase Hive Oracle

sqoop

“accessible data”• 実験• 生産性• 共同作業• 即時性 / インタラクティブ性

Java

・・・


最後に

Join,

facebook

是非、データサイエンティストの働きやすい環境へ !

struggle against crossdomain data complexity in recruit group

Technology