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

1. DataEngConf NYC’18
セッションサマリー #1
グリー開発本部 Meetup #1
2018/11/22
グリー株式会社
開発本部 DataEngineeringGroup
鈴木 隆史

2. 自己紹介
■氏名：鈴木隆史 (@t24kc)
■所属：開発本部 データエンジニアチーム
応用人工知能チーム
■業務：GCP/AWS環境のデータ基盤開発
直近ではVTuberデータ基盤開発、社内BIツール開発、
機械学習ツール開発、チャットボット開発などを担当
2

3. 1. DataEngConfについて
2. セッション紹介#1
3. セッション紹介#2
4. 感想
DataEngConfについて
3

4. DataEngConf NYC’18について
4
https://www.dataengconf.com/nyc-event-2018

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

8. ■ETTLプロセス @Datadog
・これまでのETLの課題について
・拡張したETTLプロセスについて
・Datadogで採用しているワークフローエンジンについて
■機械学習におけるデータリーク @Salesforce
・データリークとその問題点について
・データリークの検出判断基準と抑える方法について
本日のテーマ
8

9. ETTLプロセス @Datadog
1. DataEngConfについて
2. ETTLプロセス @Datadog
3. 機械学習におけるデータリーク @Salesforce
4. 感想
9

10. Datadogについて
10（ETTL, J.M.Saponaro, p5）

11. ■一元的な監視
・マルチクラウドのスタック全体のサービス状態の一元的な監視
■豊富な描画機能
・多彩なビジュアライゼーションと、探索的なグラフ描画
■機械学習ロジック
・複数のトリガーから検出された異常値を通知可能
主な特徴
11

12. システム概要
12（ETTL, J.M.Saponaro, p13）

13. 対応データソース
13（ETTL, J.M.Saponaro, p11）

14. これまでのETL
14
データソース データウェアハウス
Extract Transform Load

15. ■データソース対応
・常に変化し続け、複数のデータソースに対応する必要がある
■backfill
・過去データを楽にbackfillできること
■信頼性、堅牢性
・長期間データ保持するにあたって必要
■機密性
・セキュリティ、コンプライアンスなどの要件
ETLで必要な基盤機能
15

16. ■データソース対応コスト
・データソースが増えたり、スキーマが変更された際のコスト高
■タスク依存関係
・特定のタスクが、別のタスクに強く依存している
・1つの障害がパイプライン全体の障害に繋がる
■backfillコスト
・1から計算し直すため、backfillの実行が長時間かかる
■定義configの肥大化
・データ変換を定義する関数が、システムの拡大に伴って肥大化する
これまでのETLの問題点
16

17. ■データソース対応コスト
・データソースが増えたり、スキーマが変更された際のコスト高
■タスク依存関係
・特定のタスクが、別のタスクに強く依存している
・1つの障害がパイプライン全体の障害に繋がる
■backfillコスト
・1から計算し直すため、backfillの実行が長時間かかる
■定義configの肥大化
・データ変換を定義する関数が、システムの拡大に伴って肥大化する
これまでのETLの問題点
17
これらの課題を解決する
ETTLプロセスとワークフローについて

18. ETTLプロセスとは
18（ETTL, J.M.Saponaro, p19）

19. ■役割
・すべてのデータソースから1つの場所に生データを集めること
・ここではフィルター、変換、名前変更は実行しない
・単純に構造化データとして集計するだけ
■メリット
・各データソースでタスク実行できるように抽象化
・新しいデータセットを簡単に追加できる
・データを保持しているため、途中から再処理が可能
Bronze
19

20. Bronze
20（ETTL, J.M.Saponaro, p22）

21. ■役割
・オブジェクトを1:1にマッピングできるように正規化
・フィルター、クリーニング、列の選択・操作、名前変更、型キャストを
サポートしている
■メリット
・新しいデータソースの追加のコストを緩和できる
・変換が階層化しているため、Pipeline全体を修正する必要はない
・影響があるタスクからbackfillするだけで良い
・他のタスクでSilverを再利用することも可能
Silver
21

22. Silver
22（ETTL, J.M.Saponaro, p25）

23. ■役割
・Sparkを利用してDWHにロードする
・複数Silverデータの集計・変換にはSparkで分散処理
・ここでの出力が最終的なオブジェクトとなる
・用途に応じた使い分け
（truncate&insert, only insert, replace, upsert）
Gold
23

24. Gold
24（ETTL, J.M.Saponaro, p27）

25. ■データソース対応コスト
・Bronzeでデータソースごとのタスクが抽象化し、追加が簡略化
・スキーマ変更に対して、階層化した対象レイヤーのみの修正で完結
■backfillコスト
・影響がある階層レイヤーからのbackfillで完結
■信頼性、堅牢性
・Bronzeで生データ保持しているため、長期間のデータ信頼性や、再処理も
可能
ETTLによるこれまでの課題解決
25

26. ■タスク依存関係
・タスク分解しても依存関係問題は存在する
・Datadogでは30以上の依存関係上で、370程度のタスクが存在する
・依存関係が深くなるほど運用コストは肥大化する
ETTLで解決できない課題
26

27. ■タスク依存関係
・タスク分解しても依存関係問題は存在する
・Datadogでは30以上の依存関係上で、370程度のタスクが存在する
・依存関係が深くなるほど運用コストは肥大化する
ETTLで解決できない課題
27
タスク依存関係解決に用いられた
ワークフローエンジンについて

28. ■概要
・Python製のスクリプト型ワークフローエンジン
・タスク間のロジック定義で依存関係を解決
・エラー発生で処理停止、途中から再実行可能
・出力の有無で冪等性を担保
・Hadoop、BigQuery、各クエリエンジンと連携可能
Luigiについて
28

29. ■Task
・処理の最小単位
■Target
・Taskの出力対象のこと
（S3、HDFSなど）
■Parameter
・Taskの引数として与えることができる情報
（日付や期間など）
Luigi内部用語
29

30. Luigiコード例
30（ETTL, J.M.Saponaro, p34）

31. Luigi利用例
31（ETTL, J.M.Saponaro, p35）

32. ■タスク依存関係
・Luigiを利用することで、データの冪等性や依存関係をサポート
Luigiによるこれまでの課題解決
32

33. ■ETTLについて
・弊社では、データソースが複数に跨ることが少なく
データソースに適した少数のDWHを構築
・一元的なDWHやBIツール開発には
ETTLのような階層タスク管理が必要
所感#1
33

34. ■ワーフクローについて
・宣言型ワークフローについて
・DigdagやAzkabanを利用し、SQLでETLすることが多い
・SQLの場合は非ENも対応でき、日付変刻した定形クエリを再実行でき
るので対応工数低いのがメリット
・スクリプト型ワークフローについて
・タスク間の依存関係が複雑な場合にメリット
・変換も柔軟に対応できる
・場所によって宣言型とスクリプト型の使い分けが有効
所感#2
34

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

37. Salesforceについて
37（Hindsight Bias,Till Bergmann, p2）

38. 一般的な機械学習Pipeline
38（Hindsight Bias,Till Bergmann, p3）

39. Pipelineの肥大化
39（Hindsight Bias,Till Bergmann, p4）

40. Pipelineの肥大化
40（Hindsight Bias,Till Bergmann, p4）
全体での共通モデルの必要性
=
共通パラメータ・フォーマット

41. ■データサイエンティスト不足
・各ビジネスモデルに対して深い知見不足
■異常値を含んだデータ
・手入力によるラベリングミス
・途中でカラム変更することも
■過去データ不足
・各カラムの潜在価値の変化に対応できない
・コールドスタート問題
共通モデル（BtoB）での機械学習課題
41

42. ■データサイエンティスト不足
・各ビジネスモデルに対して深い知見不足
■異常値を含んだデータ
・手入力によるラベリングミス
・途中でカラム変更することも
■過去データ不足
・各カラムの潜在価値の変化に対応できない
・コールドスタート問題
共通モデル（BtoB）での機械学習課題
42
入力データを
そのまま利用すると
機械学習における
データリーク問題
につながる

43. ■予測時に利用できるデータ、できないデータ
・予測時に知りえない情報を学習すると、モデル性能が悪化
機械学習におけるデータリーク
43

44. タイタニック事例#1
44（Hindsight Bias,Till Bergmann, p8）

45. タイタニック事例#1
45（Hindsight Bias,Till Bergmann, p8）
予測時に利用できる

46. タイタニック事例#2
46（Hindsight Bias,Till Bergmann, p9）

47. タイタニック事例#2
47（Hindsight Bias,Till Bergmann, p9）
予測時に利用できない

48. コンバージョン事例#1
48（Hindsight Bias,Till Bergmann, p17）

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

52. ■精度問題
・データリークの特徴量を訓練時に利用してしまうと、訓練時には高い精度
が出るが、予測時には精度が全く出ない
■問題となるケース
・企業データなどの過去データがなかったり、時系列情報がない場合
・マスターテーブルの値が特定トリガーで途中変更がある場合
・データセット全体で標準化、正規化を実施した場合
データリークの問題点
52

53. ■分割クロスバリデーション、ホールドアウト
・原則的に訓練、テスト、検証データを分割して保持
・分割データごとにパラメータは再計算する必要あり
・外れ値除去、次元削減、特殊選択も再処理
データリークを抑える方法
53

54. ■全体のNULL率判定
・訓練データで非NULLでも、検証時にNULLのデータが多いときは削除
■精度の差
・訓練精度と検証精度の差が大きいときは、意図しない特徴量が含まれてい
る可能性あり
■日付パラメータ
・学習データの日付に乖離がある場合は、モデル精度がずれる可能性がある
データリーク特徴量の削除基準
54

55. ■全体のNULL率判定
・訓練データで非NULLでも、検証時にNULLのデータが多いときは削除
■精度の差
・訓練精度と検証精度の差が大きいときは、意図しない特徴量が含まれてい
る可能性あり
■日付パラメータ
・学習データの日付に乖離がある場合は、モデル精度がずれる可能性がある
データリーク特徴量の削除基準
55
削除閾値を設ける必要性

56. AutoML vs Hand Tuning
56（Hindsight Bias,Till Bergmann, p30）

57. ■全体のモデル最適化を優先
・1つのモデルに特化して最適化をするのでく、
数千の全体の精度を悪化させない閾値を設ける
■閾値選択
・残すべき特徴量と、除去するべき特徴量の閾値判断が難しくなる
■多くの試行錯誤
・アルゴリズムに変換できるヒューリスティックな手法も時には必要
共通モデル利用時の方針
57

58. ■時系列データの重要性
・自社に時系列のデータを保持している場合は、素直にデータリーク特徴量
を削除できる
・企業データのような過去・時系列データがない場合には、データリーク特
徴量の除去に試行錯誤しそう
■共通モデルの難しさ
・全体のモデル最適化の特徴選択には、経験則が必要になりそう
所感
58

59. ■スピーカー
Till Bergmann
Data Scientist
■セッション
https://www.dataengconf.com/speaker/hindsight-bias-how-to-deal-with-label-leakage-at-scale
出典
59

60. 感想
1. DataEngConfについて
2. ETTLプロセス @Datadog
3. 機械学習におけるデータリーク @Salesforce
4. 感想
60

61. ■変化し続けるデータ
・データの急成長・多様化の共通メッセージが強調されていた
・データ基盤やデータサイエンスや機械学習の分野でも
データの変化に柔軟に対応していく必要性がある
感想
61

62. Thank you
62