Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to サイエンス視点からのデータアーキテクト
Similar to サイエンス視点からのデータアーキテクト (20)
サイエンス視点からのデータアーキテクト
- 1. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. サイエンス視点からの データアーキテクト 2019/11/27 ヤフー株式会社 堀野 将晴
- 2. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 自己紹介 2013年：ヤフー株式会社へ入社 Yahoo!ダイニングでBE開発 2014年：サイエンス部へ Yahoo!ショッピング, GYAO! 主にデータエンジニアリング・分析業務 2018年：サイエンスチームのマネージャー データエンジニアリング・分析・モデリング 業務で扱うデータの幅が広がる ・Yahoo!ショッピング ・ヤフオク! ・Yahoo!トラベル ・YDN ・Yahoo!不動産 ・PayPayモール、PayPayフリマ…etc 2 堀野 将晴
- 3. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 3 本日は サイエンスの立場から見た データアーキテクトの話 ※データアーキテクト＝(データ整備人)とは、 「データエンジニア」と「アナリスト」「サイエンティスト」の間を埋める役割
- 4. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. • 営業改善 • マーケティング改善 4 • プロダクト改善 (機械学習を用いた) • 全社のデータ利活用 サービス 例)Y!ショッピング サイエンス 例)Y!ショッピング改善チーム 機械学習でレコメンド作成 データPF • 行動ログの整備・基盤 • Hive,Presto,Spark環境 • ダッシュボード 組織 データの活用対象 • MapReduce, Hive, Spark • Apache Airflow, oozie • Teradata • BI、レポートツールと Workfolowエンジンは サービスによって様々 組織とデータ活用目的の違い ※主にデータで関わっている組織を抜粋 環境
- 5. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 5 扱うデータ • 主に行動ログ,サービスのマスターログ • HDFS上のビックデータ 基本的なチーム構成 • モデリング・サービス実装までが１チーム • データPFや、サービス側の提供データを利用 サイエンスとデータ モデリング・分析のための前処理・可視化 データ活用の目的
- 6. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 6 データアーキテクトに焦点を当て 失敗や学びを“前向き”に話します
- 7. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 7
- 8. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 8
- 9. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. • 営業改善 • マーケティング改善 9 • 全社のデータ利活用 サービス データPF 組織 データの活用対象 データ整備は必要なのか？ サイエンスでは ・データPF ・サービス の提供データを利用 • プロダクト改善 (機械学習を用いた) サイエンス
- 10. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 10 データをサイエンスで使いたい サイエンス目的ではない データが 整っていない • 営業改善 • マーケティング改善 • 全社のデータ利活用 サービス データPF 組織 データの活用対象
- 11. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 11 データPFの提供データを活用 大きなデータなので サイエンスで使うには前処理必須 • 時間もCPリソースも無駄 • フィルタ条件が違う 共通データが必要 • 全社のデータ利活用データPF
- 12. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 12 サービスの提供データを活用 サービス側の データチームと 調整する人が必要 データの状況がわからない • そもそも何のデータが使えるのか不明 • HDFSにないので、 欲しいデータが欲しい時に使えない • 営業改善 • マーケティング改善 サービス
- 13. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 13 サイエンスのデータ窓口となった
- 14. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 14
- 15. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 15 各サービス • データレイク、DWH • 分散処理、ストレージ • データパイプライン • フォーマット • BI、分析基盤周り • コミュニケーション • サービスドメイン知識 • サイエンス内でどんな 改善が行われているか • KPI、レポートの現状 サイエンスの整備人に求められるスキル データエンジニアスキル その他
- 16. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 16 サイエンスの整備人に求められるスキル ビジネス価値を考えた動き ニーズに応じた • 開発 • 優先順位付け • コミュニケーション • サービスドメイン知識 • サイエンス内でどんな 改善が行われているか • KPI、レポートの現状 その他一番大切 多くのチームと関わる
- 17. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 17 各サービス • データレイク、DWH • 分散処理、ストレージ • データパイプライン • フォーマット • BI、分析基盤周り サイエンスの整備人に求められるスキル 各サービス データ開発運用を サービスにお願いするのはダメ 目標の違い・リソースが逼迫 サービスで本来やるべき事が別にある データ環境の違い サイエンスはHDFSにデータが欲しい サービス側にあまり知見がない サービス側のデータエンジニアとの 共同開発が鍵 データエンジニアスキル
- 18. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 18
- 19. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 19 各サービス ログを設計/実装する人は実際にデータを使わない • 一箇所の集計だけを想定した設計 • 他のログに影響を与える • 使って初めてバグに気付く • キャンペーン計測のためのログ実装 ▶︎キャンペーン後にデータを見たらログがなかった ログ設計のルールは絶対必要 設計・実装側と整備人が認識合わせ ログ管理の難しさ
- 20. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 20
- 21. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 21 サイエンス改善のKPIを見れるようにした ほとんど利用していない状態に 使われないKPIダッシュボード
- 22. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 22 利用されない理由 不要になった データを見る習慣がない どうしたか 運用コストの観点から 思い切って潰した （その時は自前のBIツールを作っていたので・・・） KPIは各々のPJで責任を持って追ってもらうことに サービス側とサイエンス側で共通の定義のKPI KPIダッシュボードの廃止
- 23. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 23 若手が持ち回りで、KPIをまとめて共有 数値を見る文化 データを見る習慣は大切
- 24. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 24
- 25. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 25 各サービス 意図通りに使われないデータ Joinを不要にする 中間テーブル 中間テーブル
- 26. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 26 各サービス 大元のテーブルと再Join 意図通りに使われないデータ Joinを不要にする 中間テーブル ユーザーの使い方 中間テーブル 各サービス
- 27. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 27 大元のテーブルと再Join 意図通りに使われないデータ ユーザーの使い方 各サービス 想定外の使われ方 ユーザーの利用方法は 定期的にヒアリング アフタフォーローが大事 設計して終わりではなく 改善を回せるようにする
- 28. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 28 意図通りに使われないデータ ドキュメントを残すだけでは不十分 利用者が気軽に相談できる仕組み •データの解釈を間違えて利用 •長期間改善が進まない
- 29. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □まとめ 29
- 30. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 30 サービス側の見たいデータを出すお仕事 最初は分析タスクとしてチームでやっていた サイエンスの新卒で持ち回りで担当 新卒はデータ集計を覚えられる 分析という名のデータ抽出係
- 31. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 31 サービス側は見たいデータが集計でき 新卒はデータ集計を覚えられる 疑問を感じていた 本質的には • BIで簡単に見れるようにするべき • サービス側でもデータ抽出できる人を増やすべき
- 32. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 32 各サービス Hive集計塾“堀野塾”をサービス向けに開催 • 社内のデータ環境の説明 • 基礎的なHiveQL • 課題を持ってきてもらい、一緒に分析から考える 社内評価について • 持ち込み課題を社内のポスターセッションに提出 • サービス内の改善にも繋がった • 期末にアンケートを取り、フィードバックを もらった 集計塾の開催
- 33. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 33 データ整備だけではなく 利活用促進の仕組みも考える
- 34. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 34
- 35. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 35 各サービス みんな積極的にやらないからこそ やる価値がある 皆から頼られ データに困ったら必ず相談される存在に 重宝される人材 必要性が認められてサイエンスに データアーキテクトとエンジニアリングを中心としたチームを結成
- 36. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 36 メディア面のコンテンツ最適化 ヤフオク! このユーザーには どのサービスをオススメするべきか メディアにアクセス サービス横断の • レコメンド開発 Yahoo!ショッピング Yahoo!トラベル
- 37. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 37 サービス横断の • レコメンド開発 • KPI設定 メディア面のコンテンツ最適化 ヤフオク! このユーザーには どのサービスをオススメするべきか メディアにアクセス 予算や意思決定に利用 各サービスがメディアに 掲載された時の価値を 同等に比較するため、 バラバラのKPIを統一 Yahoo!ショッピング Yahoo!トラベル
- 38. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 38 サービス横断の • レコメンド開発 • KPI設定 • データ整備、設計開発 • BIツール整備 メディア面のコンテンツ最適化 ヤフオク! Yahoo!ショッピング Yahoo!トラベル このユーザーには どのサービスをオススメするべきか メディアにアクセス データアーキテクトの 仕事が重要
- 39. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 39 サービス横断の • レコメンド開発 • KPI設定 • データ整備、設計開発 • BIツール整備 メディア面のコンテンツ最適化 ヤフオク! このユーザーには どのサービスをオススメするべきか メディアにアクセス データ整備人が中心にいるから成り立つ仕事 Yahoo!ショッピング Yahoo!トラベル
- 40. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. □データ整備の必要性 □データ整備人に求められるもの □データ整備人の仕事 1.ログ管理の難しさ 2.KPIダッシュボード 3.意図通りに使われないデータ 4.データ抽出業務 □データ整備人だからできる事 □価値を出すには 40
- 41. Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 41 データアーキテクトで価値を出すには 整備されたデータを用いて 意思決定や改善に繋がるをゴールとする コミュニケーション データエンジニアリング 開発運用まで携わる 設計して終わりではなく、 作って使ってもらい 改善を回すのが大事 能動的に動く 多くのチームと関わる 現場の課題を汲み取る 価値の高い課題を探す データ活用の仕組み作り
Editor's Notes
- 新卒でヤフー株式会社へ入社後、ヤフーダイニングに配属され予約データ等を扱うバックエンド開発をしていました。 その次の年に、自身の希望でヤフーショッピングのデータサイエンス部門の立ち上げに加わり、GYAO!のレコメンド改善で主にデータエンジニアリング、分析業務を経験しました。 現在は、サイエンスチームのマネージャーとして、たくさんのサービスのデータを取り扱う仕事をしています。
- 本日はサイエンスの立場から見たデータアーキテクトの話をします。 ここでのデータアーキテクトとは「データエンジニア」と「アナリスト」「サイエンティスト」の間を埋める役割を解釈して聞いてください。
- 本題に入る前に まず、組織とデータ活用の目的の違いについて説明します データに関わる部署は大きくサービスとサイエンス、データPFがあり組織が分かれています。 データ活用対象もそれぞれ違い、 サービスであれば営業やマーケ サイエンスは機械学習を用いたプロダクト改善を行います。 データPFは全社向けに行動ログの整備や分散処理基盤、ダッシュボード等を提供しています。
- サイエンス内では、主にモデリング分析のための前処理・可視化にデータが使われます。 主なデータは、行動ログとマスタログの２種類で、HDFS上のビックデータが対象になります。 基本的にはモデリング、サービス実装までが１チームになっており、データPFやサービス側の提供データを利用しています。
- 今日は、そんなサイエンスの中でデータアーキテクトに焦点を当てて前向きに話します。
- アジェンダはこんな感じです。
- サイエンスでデータ整備は必要なのかという話です。
- サイエンスは、データPFが提供するデータやサービスが提供するデータを使っていました。
- サービスとデータPFのデータ活用対象はサイエンス目的ではないため、サイエンスとしてはデータが整っていない状況でした
- データPFが提供している行動ログのデータは非常に大きく、 同じ前処理をみんなで好きに実施したり、条件が個々でずれるという課題があり、 共通のデータが欲しいニーズがありました。
- また、サービス側の使えるデータに何があるのかわからない、 欲しいサービスのデータが利用できる環境になくすぐ使えないという課題があり、 サービス側のデータチームと調整する人が必要でした。
- 今思うとこれがアーキテクト仕事のきっかけだったかもしれません。
- サイエンスのデータアーキテクトに必要だった事を紹介します。
- 大きく２つ、エンジニアスキルとその他に分けました。
- 一番大切なのは、コミュニケーションスキルです。 非常に多くのチームと関わります。 また、サービスドメイン知識、サイエンス内でどんな改善が行われているか、KPIの現状を知ることが大事です。 これは、ニーズに応じた開発や優先順位づけに必要です。 ビジネス価値を考えた動きが必要です。
- また、データエンジニアスキルも必要でした。 現場ではデータアーキテクト部分だけをやって、サービス側のデータエンジニアに開発をお願いするのはうまくいきませんでした。 サービス側では、他にやるべきことがあり、リソースも逼迫した状況でした。 また、サイエンスが欲しいデータ環境は、サービス側とは異なるためエンジニアリング知識も新たに必要です。 なので、サービス側のデータエンジニアと共同開発がカギとなりました
- 今の話を踏まえ、次はデータ整備人の仕事をしていく上で、実施にあった困ったことをいくつか紹介します。
- ログを管理するのは非常に難しいです。 ログを設計、実装する人は実際にデータを使いません。 よくあることとしては一箇所の集計だけを想定していて、他のログに影響を与えたり、 バグがあるのに気づかないで、使って初めて落ちていないことに気づくということです。 ログ設計のルールは最低限必要な上で、設計、実装側と整備人のような人たちが認識合わせする必要があります。
- 次はKPIダッシュボードでの失敗談です。
- 昔、KPIダッシュボードをサイエンス改善むけに作っていました。 しかし、しばらくすると全く利用されていない状況になりました。
- 利用されない理由としては、不要になったやデータをみる習慣がないということでした。 この時は、運用コストの観点から思い切って潰しました。 KPIは各々のPJで責任を持ってもらうことにして、最低限 サービスとサイエンスで共通の定義のKPIにすることにしました。
- ただし、データを見る習慣がないのは良くないことです。 今は、若手が持ち回りでKPIをまとめて共有する時間を作ることにしました。
- ３つ目はユーザーは意図通りにデータを使ってくれるとは限らないという話です。
- プロダクト改善や分析にに使いやすいように、複雑なjoinをした中間テーブルを作ったことがあります。
- しかし、半年くらい経ってからユーザーは大元のテーブルと再joinしている事を知りました。
- このように想定外の使われ方をするのはよくあることで、ユーザーの利用方法は定期的にヒアリングの必要があると思います。 また、設計して終わりではなく改善を回すフローが必要だと思います。
- また、データの解釈を間違えて居て、長期間改善が進まないこともありました。 ドキュメントを残すだけでは不十分な部分もあり、利用者が気軽に相談できる仕組みも大事だと思います。
- 最後は、データ抽出の仕事についてです
- 最初はチームのタスクとして、サービス側の見たいデータをだす仕事をしていました。この作業をチームで続ける事が問題になり、 しばらくして、データ集計を覚えるいい訓練になるとのことで、新卒で担当することになりました。
- これでいいのか自分は疑問に感じていました。 短期的に見ればこれでいいのかもしれません。 しかし本質的には、見れないデータをBIで簡単に見るようにすべき サービス側でもデータ抽出できる人を増やすべきだと思っていました。 （あと、そもそもこれ分析じゃないし）
- そこで、サービス向けに集計塾を開催することにしました。 ２年半くらいやったとお思います。 社内のデータ環境の説明や基本的なHiveQLの説明をして、課題を持ってきてもらい一緒に分析から考えました。 社内評価は、ポスターセッションに出してもらうことによってしっかりアウトプットをし、期末にアンケートを取ってフィードバックをもらい上長にアピールしたりました。
- データ整備だけではなく、利活用促進のための仕組みを考えるのは非常に大事です。
- 最後は、データ整備人だからできることをお話しします。
- みんなが積極的にやらないからこそ、やる価値があると思ってます。 皆から頼られ、データに困ったら必ず相談してくれる存在になります。 必要性が認められてチームを結成することになりました。
- 今のチームの仕事の一部を紹介します。 メディアにアクセスした時に、ユーザーにどのサービスをオススメするべきかという課題をやっています。 これは単にレコメンド開発だけではなく、
- 各サービスがメディアに掲載された時の価値を同等に比較するために サービスごとにバラバラのKPI計測を、同じ定義で統一する必要があります。
- その土台を整えるために、使うべきデータをサービスごとに整理しにいったり、 分析に使うためのデータウェアハウス、マート、BIツールで何を見るかを設計開発しなければなりません。 データアーキテクトの仕事が非常に重要です
- データ整備人が中心にいつからこそ成り立つ
- まとめです
- データアーキテクトで価値を出すには、コミュニケーションとエンジニアリングの２つが大事だと思います。 とにかく多くのチームと関わり、現場の課題を汲み取り、能動的に仕事をやることが大事です。要は貢献度が高い仕事を優先して取るべきということです。 それだけでなく、活用して価値を出してもらうところも考えるべきでしょう。 また、事業会社ではデータエンジニアリングとセットにして、仕事の価値を出しやすくすることも大事です。 設計して終わりではなく、改善も共に回すことができると思います。 整備して終わりではなく、意思決定や改善につながるというところをゴールとして働きましょう。