2018/03/14 Kichijojipm-mini #012 の資料

1. ETLやデータ分析で扱うスクリプトにおける
設計面で気をつけているあれやこれや。
2018/3/14 Kichijojipm-mini #012
やっさん @yassan168

2. 非常に特殊な環境での話です。

3. 前提
制約
• データソースが遅延と欠損を含む種々のcsv
• 相性の悪いインフラ構成の為、RDB側で重たいSQLを流せない
→複数のCSVをスクリプトで時間をかけてETL処理を実施する
（kuroko2で制御して、最終的にはembulk使ってロードしている）
対象
• 複数のcsvを組み合わせたETL(Extract / Transform / Load)処理
• 分析する際にデータをいじるために作成するコード
：Cookpad製のジョブスケジューラ＆ワークフローエンジン (https://github.com/cookpad/kuroko2)
：Treasure Data製のバルクデータローダ (https://github.com/embulk/embulk)

4. 気をつけている事
•コードを可能な限り書かない
•実装はシンプルに
•Perl力をあまり必要とさせない

5. コードを可能な限り書かない
コードがあればある程バグるし、メンテも大変。
書かないで済むなら書きたくない（＝もっと別の事やりたい）
→ 同じ処理はまとめて、違う部分だけ書く
例：特定のCSVの抽出処理について、用途に応じて利用する列だけ違う
取得と加工する処理を共通化。
抽出する箇所だけ無名サブルーチンとして実装して、その無名サブルーチ
ンのリファレンスを変数に入れて、加工処理に渡す

6. シンプルであること
• １つのモジュールに何でもかんでも詰め込んだUtilを作らない
• モノリシックにしない。分ける。
• ETLを１つでやるモジュールにしない。少なくともEとTとLは分ける。
役割を複数持たない。
→１つにすると集計の仕方だけ換えたい場合に集計処理が肥大化して複雑になる
（日次、月次、四半期etc）
→個別に同じ抽出処理をやってしまうと、辻褄が合わなくなるので、同じ情報ソース
なら抽出処理から出すデータは同じもの使い、見せ方だけを替えるモジュールを複
数作る

7. Perl力をあまり必要とさせない
コードゴルフは必要無いので多少冗長でも簡易的な記述に寄せる。
黒魔術ダメ！絶対！
• ただでさえエンジニア探すのが難しいのに、さらにPerl書ける人となる
ともっと大変
• 凝った記述にしない事で、他の言語が出来る人でもとっかかりやすい

8. 結局の所。。。
上手く回っているスクリプトは、以下を無意識下でやってた。
そして、これを言語化した しんぺいさん パないッス。
https://speakerdeck.com/shinpeim/jin-aetedryyuan-ze-nixiang-kihe-u

9. 以上です。