DataEngConf NYC’18 セッションサマリー #1
•Descargar como PPTX, PDF•
0 recomendaciones•8,161 vistas
グリー開発本部 Meetup #1 DataEngConf NYC報告会で発表された資料です。 https://gree.connpass.com/event/107057/
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a DataEngConf NYC’18 セッションサマリー #1
Similar a DataEngConf NYC’18 セッションサマリー #1 (20)
Más de gree_tech
Más de gree_tech (20)
DataEngConf NYC’18 セッションサマリー #1
- 1. DataEngConf NYC’18 セッションサマリー #1 グリー開発本部 Meetup #1 2018/11/22 グリー株式会社 開発本部 DataEngineeringGroup 鈴木 隆史
- 3. 1. DataEngConfについて 2. セッション紹介#1 3. セッション紹介#2 4. 感想 DataEngConfについて 3
- 5. ■概要 ・データ基盤構築のツールやノウハウを共有するコミュニティイベント ・Facebook、Netflix、Lyftなど40以上の企業がスピーカー ・Hakka Labsがコミュニティベース ■日程 ・2018/11/08(木) - 09(金) ・コロンビア大学@NYC, USA ■参加者 ・400人近くの人が参加 DataEngConf NYC’18について 5
- 6. イベント風景 6
- 7. ■カテゴリ ・Data Engineering ・Data Science・Analytics ・AI Products ・Hero Engineering（少人数・低工数で大影響を与えたデータシステム） Sessionについて 7
- 9. ETTLプロセス @Datadog 1. DataEngConfについて 2. ETTLプロセス @Datadog 3. 機械学習におけるデータリーク @Salesforce 4. 感想 9
- 23. ■役割 ・Sparkを利用してDWHにロードする ・複数Silverデータの集計・変換にはSparkで分散処理 ・ここでの出力が最終的なオブジェクトとなる ・用途に応じた使い分け （truncate&insert, only insert, replace, upsert） Gold 23
- 33. ■ETTLについて ・弊社では、データソースが複数に跨ることが少なく データソースに適した少数のDWHを構築 ・一元的なDWHやBIツール開発には ETTLのような階層タスク管理が必要 所感#1 33
- 35. ■スピーカー 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
- 36. 機械学習におけるデータリーク @Salesforce 1. DataEngConfについて 2. ETTLプロセス @Datadog 3. 機械学習におけるデータリーク @Salesforce 4. 感想 36
- 40. Pipelineの肥大化 40（Hindsight Bias,Till Bergmann, p4） 全体での共通モデルの必要性 = 共通パラメータ・フォーマット
- 45. タイタニック事例#1 45（Hindsight Bias,Till Bergmann, p8） 予測時に利用できる
- 47. タイタニック事例#2 47（Hindsight Bias,Till Bergmann, p9） 予測時に利用できない
- 49. コンバージョン事例#1 49（Hindsight Bias,Till Bergmann, p17） ReasonLost = no Conversion
- 50. コンバージョン事例#1 50（Hindsight Bias,Till Bergmann, p17） Amount = Conversion
- 51. コンバージョン事例#1 51（Hindsight Bias,Till Bergmann, p17） ClosedBy ≒ Conversion
- 56. AutoML vs Hand Tuning 56（Hindsight Bias,Till Bergmann, p30）
- 60. 感想 1. DataEngConfについて 2. ETTLプロセス @Datadog 3. 機械学習におけるデータリーク @Salesforce 4. 感想 60
- 62. Thank you 62
Notas del editor
- ・日本人は殆どいなく、日本コミュニティは見た限りなかった
- ・コロンビア大学やイベントの写真 ・イベント中は宇宙食という名のケータリングを食べられた
- ・1日あたり8回のKeynote/Sessionの公演があった ・大枠でDataEngineering、DataScience・Analytics、AI Products、Hero Trackという4つのSessionに分かれている ・Hero Engineeringとは、少人数・低工数で多くの影響を与えたデータシステムの紹介 ・大規模なカンファレンスとは異なり、1企業のメインスピーカーがあるのではなく、各企業からスピーカーが選出されている ・そのため、Keynoteはサマリな内容ではなくでは、他Sessionと同様に1つの企業からの取り組みの紹介がされていた
- ・データエンジニアリング系から1つ、機械学習系から1つピックアップして紹介する ・その中で企業の知名度があり、セッション難易度がほど良い感じのものを選んだ
- ・スタック全体からリアルタイムに詳細なメトリック監視を行うことができる運用監視クラウドサービス
- ・データフローにはLuigi、分散処理にはSpark、DWHにはRedshift、BIツールにはLookerを利用 ・1日あたり1兆を超えるシステムログやリクエストを捌いている
- ・40を超えるデータソースから取得することができる ・インフラデータ、サービストラフィック、売上情報、インフラコストなど
- ・ほとんどの企業では、オペレータがDataを取り出し巨大なコードに変換してDWHに出力するETLプロセスを保持している
- ・DatadogではETLを拡張したETTL（Extract Tiered Transform Load）プロセスを採用している ・Tiered Transformとはデータの階層化変換のことで、一度にデータの変換をするのではなく、いくつかのステップに分けてデータの変換を行う ・ブロンズ、シルバー、ゴールドの3つのステップに分解している ・原則的に各ステップの中間データはS3に保存される ・途中のパイプラインのデータは保持して、繰り返しジョブが実行できるようになっている
- ・すべてのデータソースから1つの場所に生データを集めること（主にS3に保存） ・ここではフィルター、変換、名前の変更などは実施しない ・単純に構造化データとして集計するだけ ・メリット ・データソースごとに1つの基本タスクを実行するように抽象化しているため、新しいデータセットを簡単に追加できる ・データを保持しているため、それ以降の処理に問題がある場合、ブロンズから処理をやり直すことができる
- ・各データソースから、データを構造化して保存している
- ・オブジェクトを1:1にマッピングできるように正規化する ・フィルター、データクリーニング、列の選択・操作、名前の変更、型キャストをサポートしている ・メリット ・新しいデータソースのカラム変更に対して、同じフォーマットになるようにオブジェクトを変換する ・データが変化した場合は、変換を階層化しているため、影響があるジョブからbackfillするだけで済む ・パイプライン全体を修正する必要はなく、新しいデータソースの変更による問題を緩和できる ・他タスクでシルバー関数を再利用することもできる
- ・Bronzeで構造化したデータを型キャストや名前変更など、正規化しているのが分かる
- ・Sparkを利用してSilverのデータを集計してDWHにロードする ・ここの複数レイヤーからデータ集計・変換にマシンパワーが必要なのでSparkを利用して分散処理 ・ここでの出力が最終的にDWHで利用するオブジェクトを含んでいる ・import方針として、truncate&insert、insert only、replace、upsertをサポートしている
- ・Silverデータを集計・変換してGoldに出力している
- ・複数の変化するデータソースへの対応 ・データソースごとに1つの基本タスクを実行するように抽象化しているため、新しいデータセットを簡単に追加できる ・新しいデータソースのカラム変更に対して、同じフォーマットになるようにオブジェクトを変換する ・パイプライン全体を修正する必要はなく、新しいデータソースの変更による問題を緩和できる ・過去データのbackfillのしやすさ ・変換を階層化しているため、影響があるジョブからbackfillするだけで済む ・長期間データの信頼性、堅牢性 ・各レイヤーでデータを保持しているため、それ以降の処理に問題がある場合、ブロンズから処理をやり直すことができる ・セキュリティ、コンプライアンスなどの要件をクリアできる機密性 ・クラウドではIAMソリューション設定、BIツールでは権限設定をすればコントロールすることができる
- ・このようにTransformを階層化し、タスク分解しているが、依存関係の問題は依然として存在する ・Datadogでは30以上の依存関係の中に、370程度のタスクによってDWHを構築している ・依存関係が深くなるほど、システムのメンテナンスコストが上がってしまう
- ・そのため、ワーフフローエンジンを利用してタスク依存関係を解決する
- ・Spotifyが開発したデータフロー制御のワークフローエンジンがOSS化したもの ・Luigiの利用によりタスクの依存関係の問題を緩和させることができる ・特徴 ・Pythonで定義され、複数のバッチ処理を組み合わせたジョブを制御できる ・タスク間のロジックを定義することで依存関係を解決できる ・エラーが発生したら処理を停止し、失敗したところから再開できる ・出力の有無で冪等性を担保できる ・プラットフォームに依存しないため、HadoopやBigQuery、各種クエリエンジンとの連携が可能 ・範囲外（記載しない） ・リアルタイム処理、分散処理、スケジュール起動、トリガ起動 ・あくまでも司令塔としての役割
- ・OtherTaskを親に持つ ・hello worldを出力して（ここでデータの変換などが可能） ・s3のbucketにアウトプット ・Datadogでの使い方 ・Datadogでは1データソースに1基盤クラス ・各Task特有のパラメータで定義できるライブラリを開発して利用している
- ・このように複雑な依存関係もLuigiを利用することで簡易管理できる
- ・弊社でも、生データから中間テーブルを作成して、その後に再度集計してデータマート用のテーブルを作成することはある ・とはいえ、データソースが複数に跨ることは少なく、各データソースごとに最適なDWHを利用している ・DWHを一元管理するためには、ETTLのような管理が必要になってくるだろう
- ・弊社では、DigdagやAzkabanなどの宣言型のワークフローエンジンを利用している ・特にSQLでETL対応していることが多い ・SQLの場合は、日付パラメータを変更した定形クエリを何度も実行することが多いため、宣言型のほうが対応工数は小さくなることが多い ・クエリの場合は、非ENであっても対応できるのもメリット ・Luigiなどのスクリプト型のワークフローは、状態処理やスクリプト中の変換などが容易 ・スクリプト定義ができるので、タスク間の依存関係が複雑な場合も有効 ・クエリではない、ETLプロセスの場合はスクリプト型のワークフローだと柔軟に対応できる ・場所によってワーフフローを使い分けるのも良さそう
- ・クラウド型の顧客管理や営業管理などのビジネスアプリケーションを提供するSaaS
- ・ETLでデータを集計して、前処理で外れ値の除去、次元削減、特徴選択をし、訓練データと検証データに分けてモデルを作成して、精度を検証して、本番にdeployして精度を確認して、またモデルを更新する
- ・15万社以上の企業が、Salesforceのアプリケーションを利用している ・そのため、各企業ごとのユースケースにあったモデルを作成しようと思うと、非常に工数がかかる ・1つ1つに専用のモデルを作成するのではなく、全体で共通のモデル作成する必要性が出てきている ・共通モデルを利用するためには、共通のデータフォーマットやパラメータを利用する必要がある
- ・15万社以上の企業が、Salesforceのアプリケーションを利用している ・そのため、各企業ごとのユースケースにあったモデルを作成しようと思うと、非常に工数がかかる ・1つ1つに専用のモデルを作成するのではなく、全体で共通のモデル作成する必要性が出てきている ・共通モデルを利用するためには、共通のデータフォーマットやパラメータを利用する必要がある
- ・全体で共通モデルを利用したいが、企業によってデータはバラバラ ・データサイエンティスト不足 ・各ビジネスモデルの深い知見の不足 ・各パイプラインの自動化ができていない ・常に変化し、異常値を含んだデータ ・手入力によるラベリングミス ・途中でカラム変更することがある ・過去のデータがない ・各カラムの潜在価値の変化を把握できない ・コールドスタート問題
- ・かといって、入力されているデータをそのまま学習データに利用すると問題が発生する ・それは、時系列ではないため答えとなるカラムが存在するデータを学習に利用してしまっているから ・このような問題をデータリーク問題という
- ・予測時に利用できるデータ、できないデータが存在する ・予測時には知りえない情報を学習に利用してしまうと、モデルの性能が著しく悪くなってしまう ・企業データのように、時系列でなかったり、急にマスターデータとして登録される場合に発生しやすい ・一つ一つ別のモデルにする場合は、データを確認すればデータリークのカラムを判断できるが、共通モデルで何千もの予測をするモデルであると確認が困難になる
- ・性別と生存率、客室クラスと生存率の関係のヒートマップグラフ
- ・性別と生存率、客室クラスと生存率の関係のヒートマップグラフ
- ・身体識別番号と生存率、救命艇番号と生存率の関係 ・一見、生存率と非常に高い因果関係があるように見えるが、これらの番号は、亡くなった後や救助船に乗った後に決まったデータ ・データとして見るのは問題ないが、これらのデータは事前には分からない ・事後にしか確認できないデータを訓練データとして利用すると、トレーニング時に高い精度が出たとしても、予測時には精度が出ない
- ・身体識別番号と生存率、救命艇番号と生存率の関係 ・一見、生存率と非常に高い因果関係があるように見えるが、これらの番号は、亡くなった後や救助船に乗った後に決まったデータ ・データとして見るのは問題ないが、これらのデータは事前には分からない ・事後にしか確認できないデータを訓練データとして利用すると、トレーニング時に高い精度が出たとしても、予測時には精度が出ない
- ・一見関係ないようなデータもデータリークに繋がっていることがある、その例を紹介する
- ・ReasonLostはコンバージョンしなかったと同意
- ・Amountはコンバージョンしたと同意
- ・ClosedByはコンバージョンしたと類似
- ・企業データの共通モデル作成時に、時系列の情報がなかったり過去データがなかったりする場合は、どこに正解に紐付いたデータが潜んでいるか分からない ・訓練時には高い精度が出ても、予測時には全く精度が出ない ・overfittingと似ているが微妙に違っている 問題となるのは、 ・企業データなどの過去データがなかったり、時系列情報がない場合 ・マスターテーブルの値が、特定トリガーで途中で変更がある場合 ・データセット全体を正規化・標準化してクロスバリデーションを実施すると、データリークしたことになる（意外と陥りやすい） ・平均値、最大値、標準偏差などのスケーリング係数が、訓練データの全体分布が共有されてしまう
- まず一般的な方法だが ・分割クロスバリデーションでデータ準備をする ・全体で標準化しないように、分割データごとにパラメータを計算して、テストデータを準備するのもOK ・外れ値の除去、次元削減、特徴選択などのタスクを含むクロスバリデーション内では、パラメータを再計算するのがよい ・全データの特殊選択を行った値でクロスバリデーションをすると、検証データにもその特殊選択が利用されてパフォーマンス分析に偏りが発生する ・検証データセットを保持する ・訓練データとテストデータと検証データに分割し、検証データセットを保持する方法もある ・モデル作成には訓練データとテストデータを利用して、最終モデルは検証データを利用する
- 次に特徴選択について エンタープライズデータなどの過去データや時系列判定ができない場合 ・全体のNULL率が高い ・訓練データで非NULLでも検証時にNULLデータが多いカラムは削除する ・訓練精度と検証精度の差が激しい ・精度の差があるときは意図しないカラムが含まれている可能性が高い ・確率分布に変換して比較すると判定しやすい ・日付が大幅にずれているもの ・学習データの日付が離れている場合、モデルがずれる可能性があるので、日付データはまとめる
- ・全体で共通のモデルを利用しているため、個別に敷地を設けるのではなく、全体で共通の閾値を設ける必要がある ・Salesforceではこのような閾値定めた動的特徴選択エンジンを動かしている
- ・これまでの特徴量基準による特徴選択を実施した動的特徴量削除モデルと、人が手動で特徴選択したモデルのカラムについてのグラフ ・AutoMLでもHand Tuningでも共通のカラムが多く、実サービスでも十分に利用できる ・必ずしもAutoMLの選択したカラムが正しいわけではないが、AutoMLで選択したカラムを見て人が気づきを得ることも多い
- ・全体でのモデル最適化を優先 ・1つのモデルでの最適化ではなく、数千の精度を悪くするような閾値を選ばない ・閾値選択は難しい ・良い特徴量と、除去するべき特徴量の閾値判定 ・多くの試行錯誤 ・アルゴリズムに変換できるヒューリスティックな手法が必要となることもある
- ・時系列データの重要性 ・Salesforceのように企業データを利用する場合は、データリークカラムの除去に試行錯誤している ・弊社でモデルを作成する際は、基本的に多くのログを保持しているため、素直に予測時に利用できないカラム除去が重要 ・共通モデルの難しさ ・1つのモデルでの最適化は決して難しくないが、全体で共通のモデルの精度を向上させる場合のデータリークは問題になる ・時系列判断が難しい場合の、不要カラム削除の閾値判断はヒューリスティックな判断も必要になりそう