典型的な前処理の流れを記録しておく。
1.1. 変数の意味確認
1.2. 変数の種類(データ型)と尺度の確認
1.3. ユニークキーの確認
ここまで(1.1~1.3)の確認は、データの内容よりもデータの意味に焦点を当てた確認である。
1.1.については、カラム名さえ明確であれば自明なようにも思えるが、実際の業務では更に深い理解が必要である場合がほとんど。例えば、"sales_amount"というカラムがあったとして、売上の額であろうが、実際にその値がどのように記録されたのか理解する必要があったりする。例えばクーポンで購入された場合の値は含まれるのか？税込なのか税抜なのか(消費増税前後で修正が必要な可能性がある)？など。
1.2.についても自明なケースは多いが、1,2,3という値のカラムを名義尺度で扱うべきなのか、順序尺度で扱うべきなのか、といった点はデータの意味から考える必要がある。
1.3.については、例えば「あるチェーンレストランの各店舗における各日の売り上げデータ」というデータセットであれば、「店舗ID」「日付」がユニークキーになっていると想定できるが、実際にそうなっているか、等の確認。
1.4. ユニークキーに重複が無いか確認
1.5. 欠損値の確認
1.6. 変数の分布 & 外れ値の確認
1.7. 変数間の相関の確認
1.4.~1.6.までは、データの内容を見ていく確認である。
1.4.は、1.3.で確認したユニークキーについて実際に重複なくユニークキーとして機能しているかの確認である。ここで重複があった場合、例えば上の例で言えば、店舗ID003の2019-02-08のレコードが二つ見つかったらデータ分析の際には何らかの方法で一つにしなければならない。これは色々な原因が考えられて、それぞれ対処法も異なる。例えば単純にデータログのエラーで同じレコードが二つ作られてしまった、というケースでは単純にどちらかを消せばよい。あるいは、一度データをログした後に記帳漏れが見つかって値を変えて入れ直した、というケースであれば古い方を決して新しい方のレコードだけを使えばよい。あるいは、実は店舗003には店舗内にパンの専門店が入っていて売上を別で計上していた、という場合もありえる。その場合、例えば店舗IDの他にサブ店舗IDというのがあって、実はユニークキーは店舗ID+サブ店舗ID+日付であった、となったり。
1.5. については読んで字のごとくで、各カラムごとにどの程度欠損があるのかを調べる。
1.6. についてはデータの分布を確認して外れ値が無いかを見る。基本的にまず最初に簡単な統計量(平均、中央値、四分位、分散、最大値、最小値など)で記述してみて、特に重要なものについて分布を可視化することが多い。
1.7. については読んで字のごとくで、変数間の相関を見る。多重共線性が問題になるようなモデルを使う際などは特に重要になる。
2.1. 欠損値の処理 (1.5.に対応)
2.2. 非数値変数の数値への変換 (1.2.に対応)
2.3. その他の変数変換 (1.2.と1.6.に対応)
2.4. 外れ値の処理 (1.6.に対応)
2.5. アグリゲーション
ここでは、データ確認の結果に基づいて実際にデータを分析に適した形へと変換していく。
2.1. では欠損値の処理を行う。必ずしも埋めなければならないわけではなくて、欠損値を許容するモデルを用いるのであればそのまま残しておくという選択もある。一般的なのは0埋めや平均値埋め、あるいは時系列データなどでは直前のデータの値や直前と直後のデータの平均値などで埋められたりもする。
より複雑な欠損値処理も考えれらるので、これについては別でまとめて記事にしたい。
2.2. では非数値変数の数値への変換を行う。これはいろいろあって、例えばカテゴリ変数であればダミー変数化だったり、テキスト型の変数であればBoWへの変換だったり、などなど。これも別記事で書きたい。
2.3. では、「非数値変数を数値化してモデルで扱えるようにする」以外の目的の変換を行う。例えば数値変数であってもある区間ごとに区切ってあえて順序尺度化する、といった変換を行いたいケースなどがある。これも別記事で詳しく。
2.4. では外れ値の処理を行う。外れ値レコードを除いたり、ある値でキャップしたり、場合によっていろいろな処理が考えられる。別記事で詳しく。
2.5. では必要に応じてデータのアグリゲーションを行う。例えば上の例で言うと、分析の目的が「店舗の週次の売上予測」であるとすると、手元にある日単位のデータを週単位に集計してモデルの入力にする必要がある。