狠狠撸

狠狠撸Share a Scribd company logo

[Gree] DataEngConf NYC’18 セッションサマリー #1

?
?
Takashi Suzuki
Takashi Suzuki

グリー開発本部 Meetup #1 DataEngConf NYC報告会で発表された資料です。 https://gree.connpass.com/event/107057/

1 of 63
Download to read offline
DataEngConf NYC’18 セッションサマリー #1 グリー開発本部 Meetup #1 2018/11/22 グリー株式会社 開発本部 DataEngineeringGroup 鈴木 隆史
自己紹介 ■氏名：鈴木隆史 (@t24kc) ■所属：開発本部 データエンジニアチーム 応用人工知能チーム ■業務：GCP/AWS環境のデータ基盤開発 直近ではVTuberデータ基盤開発、社内BIツール開発、 機械学習ツール開発、チャットボット開発などを担当 2
1. DataEngConfについて 2. セッション紹介#1 3. セッション紹介#2 4. 感想 DataEngConfについて 3
DataEngConf NYC’18について 4 https://www.dataengconf.com/nyc-event-2018
■概要 ?データ基盤構築のツールやノウハウを共有するコミュニティイベント ?Facebook、Netflix、Lyftなど40以上の企業がスピーカー ?Hakka Labsがコミュニティベース ■日程 ?2018/11/08(木) - 09(金) ?コロンビア大学@NYC, USA ■参加者 ?400人近くの人が参加 DataEngConf NYC’18について 5
イベント風景 6
■カテゴリ ?Data Engineering ?Data Science?Analytics ?AI Products ?Hero Engineering（少人数?低工数で大影響を与えたデータシステム） Sessionについて 7
■ETTLプロセス @Datadog ?これまでのETLの課題について ?拡張したETTLプロセスについて ?Datadogで採用しているワークフローエンジンについて ■機械学習におけるデータリーク @Salesforce ?データリークとその問題点について ?データリークの検出判断基準と抑える方法について 本日のテーマ 8
ETTLプロセス @Datadog 1. DataEngConfについて 2. ETTLプロセス @Datadog 3. 機械学習におけるデータリーク @Salesforce 4. 感想 9
Datadogについて 10（ETTL, J.M.Saponaro, p5）
■一元的な監視 ?マルチクラウドのスタック全体のサービス状態の一元的な監視 ■豊富な描画機能 ?多彩なビジュアライゼーションと、探索的なグラフ描画 ■機械学習ロジック ?複数のトリガーから検出された異常値を通知可能 主な特徴 11
システム概要 12（ETTL, J.M.Saponaro, p13）
対応データソース 13（ETTL, J.M.Saponaro, p11）
これまでのETL 14 データソース データウェアハウス Extract Transform Load
■データソース対応 ?常に変化し続け、複数のデータソースに対応する必要がある ■backfill ?過去データを楽にbackfillできること ■信頼性、堅牢性 ?長期間データ保持するにあたって必要 ■機密性 ?セキュリティ、コンプライアンスなどの要件 ETLで必要な基盤機能 15
■データソース対応コスト ?データソースが増えたり、スキーマが変更された際のコスト高 ■タスク依存関係 ?特定のタスクが、別のタスクに強く依存している ?1つの障害がパイプライン全体の障害に繋がる ■backfillコスト ?1から計算し直すため、backfillの実行が長時間かかる ■定義configの肥大化 ?データ変換を定義する関数が、システムの拡大に伴って肥大化する これまでのETLの問題点 16
■データソース対応コスト ?データソースが増えたり、スキーマが変更された際のコスト高 ■タスク依存関係 ?特定のタスクが、別のタスクに強く依存している ?1つの障害がパイプライン全体の障害に繋がる ■backfillコスト ?1から計算し直すため、backfillの実行が長時間かかる ■定義configの肥大化 ?データ変換を定義する関数が、システムの拡大に伴って肥大化する これまでのETLの問題点 17 これらの課題を解決する ETTLプロセスとワークフローについて
ETTLプロセスとは 18（ETTL, J.M.Saponaro, p19）
■役割 ?すべてのデータソースから1つの場所に生データを集めること ?ここではフィルター、変換、名前変更は実行しない ?単純に構造化データとして集計するだけ ■メリット ?各データソースでタスク実行できるように抽象化 ?新しいデータセットを簡単に追加できる ?データを保持しているため、途中から再処理が可能 Bronze 19
Bronze 20（ETTL, J.M.Saponaro, p22）
■役割 ?オブジェクトを1:1にマッピングできるように正規化 ?フィルター、クリーニング、列の選択?操作、名前変更、型キャストを サポートしている ■メリット ?新しいデータソースの追加のコストを緩和できる ?変換が階層化しているため、Pipeline全体を修正する必要はない ?影響があるタスクからbackfillするだけで良い ?他のタスクでSilverを再利用することも可能 Silver 21
Silver 22（ETTL, J.M.Saponaro, p25）
■役割 ?Sparkを利用してDWHにロードする ?複数Silverデータの集計?変換にはSparkで分散処理 ?ここでの出力が最終的なオブジェクトとなる ?用途に応じた使い分け （truncate&insert, only insert, replace, upsert） Gold 23
Gold 24（ETTL, J.M.Saponaro, p27）
■データソース対応コスト ?Bronzeでデータソースごとのタスクが抽象化し、追加が簡略化 ?スキーマ変更に対して、階層化した対象レイヤーのみの修正で完結 ■backfillコスト ?影響がある階層レイヤーからのbackfillで完結 ■信頼性、堅牢性 ?Bronzeで生データ保持しているため、長期間のデータ信頼性や、再処理も 可能 ETTLによるこれまでの課題解決 25
■タスク依存関係 ?タスク分解しても依存関係問題は存在する ?Datadogでは30以上の依存関係上で、370程度のタスクが存在する ?依存関係が深くなるほど運用コストは肥大化する ETTLで解決できない課題 26
■タスク依存関係 ?タスク分解しても依存関係問題は存在する ?Datadogでは30以上の依存関係上で、370程度のタスクが存在する ?依存関係が深くなるほど運用コストは肥大化する ETTLで解決できない課題 27 タスク依存関係解決に用いられた ワークフローエンジンについて
■概要 ?Python製のスクリプト型ワークフローエンジン ?タスク間のロジック定義で依存関係を解決 ?エラー発生で処理停止、途中から再実行可能 ?出力の有無で冪等性を担保 ?Hadoop、BigQuery、各クエリエンジンと連携可能 Luigiについて 28
■Task ?処理の最小単位 ■Target ?Taskの出力対象のこと （S3、HDFSなど） ■Parameter ?Taskの引数として与えることができる情報 （日付や期間など） Luigi内部用語 29
Luigiコード例 30（ETTL, J.M.Saponaro, p34）
Luigi利用例 31（ETTL, J.M.Saponaro, p35）
■タスク依存関係 ?Luigiを利用することで、データの冪等性や依存関係をサポート Luigiによるこれまでの課題解決 32
■ETTLについて ?弊社では、データソースが複数に跨ることが少なく データソースに適した少数のDWHを構築 ?一元的なDWHやBIツール開発には ETTLのような階層タスク管理が必要 所感#1 33
■ワーフクローについて ?宣言型ワークフローについて ?DigdagやAzkabanを利用し、SQLでETLすることが多い ?SQLの場合は非ENも対応でき、日付変刻した定形クエリを再実行でき るので対応工数低いのがメリット ?スクリプト型ワークフローについて ?タスク間の依存関係が複雑な場合にメリット ?変換も柔軟に対応できる ?場所によって宣言型とスクリプト型の使い分けが有効 所感#2 34
■スピーカー Jean-Mathieu Saponaro Data Engineer & Internal Analytics Team Lead ■セッション https://www.dataengconf.com/speaker/extract-tiered-transform-load-a-pipeline-for-a-modular-scalable- and-observable-internal-analytics-platform 出典 35
機械学習におけるデータリーク @Salesforce 1. DataEngConfについて 2. ETTLプロセス @Datadog 3. 機械学習におけるデータリーク @Salesforce 4. 感想 36
Salesforceについて 37（Hindsight Bias,Till Bergmann, 辫2）
一般的な機械学習Pipeline 38（Hindsight Bias,Till Bergmann, 辫3）
Pipelineの肥大化 39（Hindsight Bias,Till Bergmann, 辫4）
Pipelineの肥大化 40（Hindsight Bias,Till Bergmann, 辫4） 全体での共通モデルの必要性 = 共通パラメータ?フォーマット
■データサイエンティスト不足 ?各ビジネスモデルに対して深い知見不足 ■異常値を含んだデータ ?手入力によるラベリングミス ?途中でカラム変更することも ■過去データ不足 ?各カラムの潜在価値の変化に対応できない ?コールドスタート問題 共通モデル（BtoB）での機械学習課題 41
■データサイエンティスト不足 ?各ビジネスモデルに対して深い知見不足 ■異常値を含んだデータ ?手入力によるラベリングミス ?途中でカラム変更することも ■過去データ不足 ?各カラムの潜在価値の変化に対応できない ?コールドスタート問題 共通モデル（BtoB）での機械学習課題 42 入力データを そのまま利用すると 機械学習における データリーク問題 につながる
■予測時に利用できるデータ、できないデータ ?予測時に知りえない情報を学習すると、モデル性能が悪化 機械学習におけるデータリーク 43
タイタニック事例#1 44（Hindsight Bias,Till Bergmann, 辫8）
タイタニック事例#1 45（Hindsight Bias,Till Bergmann, 辫8） 予測時に利用できる
タイタニック事例#2 46（Hindsight Bias,Till Bergmann, 辫9）
タイタニック事例#2 47（Hindsight Bias,Till Bergmann, 辫9） 予測時に利用できない
コンバージョン事例#1 48（Hindsight Bias,Till Bergmann, 辫17）
コンバージョン事例#1 49（Hindsight Bias,Till Bergmann, 辫17） ReasonLost = no Conversion
コンバージョン事例#1 50（Hindsight Bias,Till Bergmann, 辫17） Amount = Conversion
コンバージョン事例#1 51（Hindsight Bias,Till Bergmann, 辫17） ClosedBy ≒ Conversion
■精度問題 ?データリークの特徴量を訓練時に利用してしまうと、訓練時には高い精度 が出るが、予測時には精度が全く出ない ■問題となるケース ?企業データなどの過去データがなかったり、時系列情報がない場合 ?マスターテーブルの値が特定トリガーで途中変更がある場合 ?データセット全体で標準化、正規化を実施した場合 データリークの問題点 52
■分割クロスバリデーション、ホールドアウト ?原則的に訓練、テスト、検証データを分割して保持 ?分割データごとにパラメータは再計算する必要あり ?外れ値除去、次元削減、特殊選択も再処理 データリークを抑える方法 53
■全体のNULL率判定 ?訓練データで非NULLでも、検証時にNULLのデータが多いときは削除 ■精度の差 ?訓練精度と検証精度の差が大きいときは、意図しない特徴量が含まれてい る可能性あり ■日付パラメータ ?学習データの日付に乖離がある場合は、モデル精度がずれる可能性がある データリーク特徴量の削除基準 54
■全体のNULL率判定 ?訓練データで非NULLでも、検証時にNULLのデータが多いときは削除 ■精度の差 ?訓練精度と検証精度の差が大きいときは、意図しない特徴量が含まれてい る可能性あり ■日付パラメータ ?学習データの日付に乖離がある場合は、モデル精度がずれる可能性がある データリーク特徴量の削除基準 55 削除閾値を設ける必要性
AutoML vs Hand Tuning 56（Hindsight Bias,Till Bergmann, p30）
■全体のモデル最適化を優先 ?1つのモデルに特化して最適化をするのでく、 数千の全体の精度を悪化させない閾値を設ける ■閾値選択 ?残すべき特徴量と、除去するべき特徴量の閾値判断が難しくなる ■多くの試行錯誤 ?アルゴリズムに変換できるヒューリスティックな手法も時には必要 共通モデル利用時の方針 57
■時系列データの重要性 ?自社に時系列のデータを保持している場合は、素直にデータリーク特徴量 を削除できる ?企業データのような過去?時系列データがない場合には、データリーク特 徴量の除去に試行錯誤しそう ■共通モデルの難しさ ?全体のモデル最適化の特徴選択には、経験則が必要になりそう 所感 58
■スピーカー Till Bergmann Data Scientist ■セッション https://www.dataengconf.com/speaker/hindsight-bias-how-to-deal-with-label-leakage-at-scale 出典 59
感想 1. DataEngConfについて 2. ETTLプロセス @Datadog 3. 機械学習におけるデータリーク @Salesforce 4. 感想 60
■変化し続けるデータ ?データの急成長?多様化の共通メッセージが強調されていた ?データ基盤やデータサイエンスや機械学習の分野でも データの変化に柔軟に対応していく必要性がある 感想 61
Thank you 62
[Gree] DataEngConf NYC’18 セッションサマリー #1

More Related Content

[Gree] DataEngConf NYC’18 セッションサマリー #1