Downloaded 11 times
Uploaded byYu Yamada
リクルートライフスタイルのデータを支える技術
リクルートライフスタイルでは、飲食店や美容室の予約、旅行の予約や観光情報、ECなどみなさまの日常に密接した情報を提供し、それらから生まれる様々なデータを活用し、よりよいサービスを提供しています。 それらのデータを収集する基盤をTreasureDataなどのクラウドサービスを使用して構築しました。なぜこれらのプロダクトを選び、どのようにデータを収集しているのか、社内では収集したデータをどのように活用しているのか紹介致します。 また、現在取り組んでいるリアルタイムデータ集計処理基盤とこれからについてもお話させて頂けたらと思います。 山田 雄（株式会社リクルートライフスタイル）
More Related Content
![[よくわかるクラウドデータベース] リクルートにおけるRedshift導入・活用事例](https://cdn.slidesharecdn.com/ss_thumbnails/20140117aws-140128175458-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
リクルートライフスタイルのデータを支える技術
- 1. リクルートライフスタイルの データを支える技術 〜TreasureDataとAWSと私〜 Treasure Data TechTalk 03/30 2016 山田 雄 ネットビジネス本部 データ基盤チーム
- 2.
- 3.
- 4. ■山田 雄（ヤマダ ユウ） 株式会社リクルートライフスタイル ネットビジネス本部 データ基盤T Twitter:@nii_yan Blog:イクジニアブログ ・以前はフリーランスエンジニア 縁があってリクルートライフスタイルにお世話になることになった。 ビックデータ、Ruby、ビールが好き。 自己紹介
- 5.
- 6. Engineering for data Business with data 技術でビジネスを ドライブする StableInfrastructure Continual Innovation+ リクルートライフスタイルにおけるエンジニアの役割
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. About Presto • inmemoryのクエリエンジンでとにかく早い • クエリによってはHiveの１００倍とか • with句やwindow関数使えて便利 • ANSI基準のSQL書けるがお作法がある • count(distinct)ダメ絶対 • order_byダメ絶対 • joinは大きいテーブルを最初に
- 26. Prestoを自力で運用しようとすると・・・ • アップデートが早い • coordinatorがSPOF •１つのクエリでクラスタ全体を殺せる • アップデートにより突如クエリが動かなくなる • Bug?デグレ？ • とあるアップデートでMySQLのDB見えなく なったことあり なかなか辛い・・・
- 27.
- 28. Treasureに今後期待すること • UDF • HBase •SqoopなどのHadoopエコシステム • PrestoでHive以外のデータソースへの連携
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
Editor's Notes
- #6 １年前のデータなので少し古いです じゃらんやホットペッパーなどのサービスを持っていて、そこそこ売り上げあって３０００人くらい従業員いて、かわいいお姉さんのいる会社です。 弊社のサービス使ったことある方？ 我々のミッションは赤枠で囲われたことです。 これを叶えるためのデータ基盤を構築しています。
- #7 弊社の特徴として、エンジニアがビジネスのとても近くにいるというのがあります。 図のようにエンジニアの役割は技術によってビジネスをドライブさせることになります。 エンジニアからビジネス側へ提案することが多くある。 あとは、毎年エンジニアがビジネスプランを発表するコンテストもありますし、技術とビジネス両方学べる良い環境だと思います。 リクルートライフスタイルとエンジニアが結びつかない人も多数いるとは思いますが、技術でビジネスをドライブしてる実績が認められ最近はエンジニアを増やすことに注力しています。
- #8 ----- 会議メモ (16/03/24 19:38) ----- 弊社のデータ基盤を紹介します
- #9 こちらが、現在の共通分析基盤となります。 RawデータをTreasureに入れている サイカタのデータはでかすぎて入らないのでHadoopに入れていた。 全てのデータをredshiftに入れるとコスト的に辛い Tresureのデータは現在２０００億件以上。毎月１００億件増えている
- #10 ETLフレームワークを独自実装
- #11 様々な部署からの要望に応えられるよう構築
- #12 OneToOneメールの配信 サイト表示順の最適化 検索結果の最適化 BIツールでのvisualization、営業レポート
- #14 オンプレのMapRで運用していた
- #15 EMRも考えたが、コスト的にTREASUREだった
- #28 Zip,シーケンスファイルなので、TDにcopyできず オンプレのデータをdistcpでS3にコピー EMRでファイルフォーマット修正 TDへbulkimport PrestoでHive以外のデータソースへの連携
- #29 Hadoopに対する知見は付かないので、Treasureも一つの選択肢として、オンプレ、EMRなどとも比較して選ぶと良いと思います。
- #30 トレジャーで防御を固めつつ、攻めをする準備が整った KinesisじゃなくてkafkaやEMRじゃなくてEC2は色々知れるために。基礎を知るために。 荒野に投げ出されても大丈夫なように
- #32 突然の荒野なのですが、弊社でストリーム基盤を構築するにあたっての選定基準として、荒野でも生き抜ける技術力というのがありました。 弊社ではAWSを使用しています。 AWSと言うとkinesis使えばすぐストリーム処理出来るとは思うのですが、先ほどオンプレとの比較でもあったようにありものを使いすぎると楽なのですが、ですがその環境でないと生き延びれなくなってしまいます。 なので、あえてkinesisではなくてkafkaを選択しました。 また、Sparkの環境はEMRじゃなくてEC2を選択しています。
- #33 Waterプロジェクトで実現したいことをグランドデザインとして検討しました 作らない技術 構成管理にはANSIBLE SparkなどのmonitoringにはGrafana InfluxDB
- #34 まず、データハブ基盤です。 オンプレミス環境にあるデータはFluentdを介してAWSクラウド上に送られます。 Fluentdから送られたデータはKafkaに保存され、ここがデータハブとして機能しています。 Kafka 0.8 SSL対応してないため、publisherとaggrigator用意 今後は0.9を使ってsslで通信
- #35 次にKafkaに保存されたデータを、Spark Streamingが取り出し、データを加工・集計します。 ここがストリーム処理基盤として機能しています。
- #36 Spark-Streamingが加工・集計したデータは、DynamoDBに保存され、Key-Valueの形で保存されます。 エンドユーザーとなるデータ利用者は、APIゲートウェイ・Lambdaを介して取得することで リクエストに対するキャパシティを担保した状態でデータを提供することが可能となります。
- #39 Sdk使用してiOSのデータをほぼリアルタイムに取得しています。
- #40 Iphoneのログはsdk使ってリアルタイムで取れてきている。 データハブをkafkaに集中させる ----- 会議メモ (16/03/23 15:00) ----- スライドを時系列に分ける。 リアルタイムと、バッチを分けれるように ユーザが自由にアドホックとリアルを選べる環境に
- #43 弊社のエンジニアのコンセプト