by『前処理大全』
- 内容
- 10-4 日時型の増減
- 10-5 季節への変換
- 10-6 時間帯への変換
- 10-7 平日／休日への変換
- BigQueryの日付型に関する参考サイト
BigQueryの復習も兼ねて、SQLはBigQuery上で実行。
元データは以下のgithub：
10-4 日時型の増減
分析において、日時型のデータを特定の期間だけずらしたい場合がよくある。たとえば、宿泊予約した日までの直近30日間に予約を何回したか調べるため、対象の日時データを予約した日から30日前までに絞り込み、予約回数をカウントする必要がある。
例）ホテルの予約レコードにおいて、予約テーブルの予約日時に１日間／１時間／１分間／１秒間を加える。
また、予約日にも１日間を加える
- 予約テーブル(reserve_tb)
- SQL
- SQLで日時型データを増減させる場合は、intervalを利用するのが便利。DATEADD関数は、日以上の単位しか利用できない。
- 結果
- Python
- Pythonでは、timedelta型という日時の間隔を表すデータが型があり、これを利用するのがベスト。datetime型同士の差分の結果だけでなく、datetime型に加えたり引いたりすることができる。
timedelta型は、datetime.timedelta関数で生成できる。
- コードと結果
10-5 季節への変換
分析対象によっては傾向が季節によって大きく異なるため、季節変動を分析したい場合がある。季節変動を分析したい場合に、すぐに日付型のデータを季節に変換せずに、まずは分析対象が季節の何に影響されているのかを深く考え、季節として扱うべきかを考えることが重要。なぜなら、適切なデータ要素を表現できれば、分析対象の傾向を正確に把握でき、さらには頑健性の高い予測モデルの構築が実現できる。
例えば、アイスクリームの売上と季節変動について考えると、アイスクリームが最も売れる季節は夏。ここで、さらに夏の何がアイスクリームの売上に影響しているかを考えてみると、夏の暑い気温が影響していると予想できる。この予想が正しいとすると、季節ではなく気温を分析要素として取り入れるほうが良いということになる。なぜなら、アイスクリームの売上を夏という要素だけで説明してしまうと、猛暑の夏と冷夏をデータ上で区別できなくなる。一方、気温という要素でアイスクリームの売上を説明できれば、冷夏や猛暑の夏といった違いを表現できるようになる。
また、春夏秋冬の４つの季節で表現することが良いわけでもない。たとえば、引っ越しの件数であれば、年度の変わり目となる春／秋の時期が最も多いだろうが、正確には４／１０月前の時期が多いだけで、春／秋が特別多いわけではない。無理に４つの季節で表現するのではなく、４月前の一定期間を「春の繁忙期」、１０月前の一定期間を「秋の繁忙期」、その他の時期を「閑散期」として表現するほうが、正確に引っ越しの件数の傾向について把握できるようになる。
以上のように、季節変動を考慮する際は、季節変動よりも直接的に影響を与えている要素を考えることが重要。
例）季節に変換
ホテルの予約レコードにおいて、予約テーブルのreserve_datetimeの月から、予約時の季節のデータを生成する。
3/4/5月は春、6/7/8月は夏、9/10/11月は秋、12/1/2は冬とする。
- 予約テーブル
- SQL
- SQLで日時型の変換を行う場合は、CASE文を利用する。
- 結果
- Python
- Pythonで日時型を変換する時は、apply関数に変換関数を指定すれば簡単。
10-6 時間帯への変換
時間帯ごとに分析したい場合もあるが、時刻をそのままカテゴリ値にしてしまうと２４種類のカテゴリ値になってしまうため、大量のデータが用意できていない場合は、時刻を時間帯に変化する必要がある。このとき、季節と同様に、分析対象が時間帯の何に影響されているのかを深く考え、時間帯として扱うべきかを考えることが重要。
例えば、コンビニのコーヒーの売上について考える。コーヒーは朝の時間帯に売れるが、内訳としては朝の出勤時間帯が売上を引っ張っている。出勤による売上効果を把握するには、朝といった時間帯を定義するのでなく、出勤前の時間帯を定義して分析したほうが良い。また、同じ時間帯だとしても日付の種類によって分けた方が良い場合もある。この例で考えると、出勤の時間帯でも平日と休日で大きく傾向が違うことが予想できる。「9-4 カテゴリ値の組み合わせ」でやったカテゴリ値の組み合わせによって、平日の朝、休日の朝、休日の夜などの分けたほうが良い。このように時間帯をどのように設定するか、仮説を立て、検証し、決定するプロセスを経て変換することが重要。
時刻データの時間帯への変換は「10-5 季節への変換」と同様なので省略。
10-7 平日／休日への変換
人々の生活パターンは平日と休日で大きく異なる。そのため、人の活動を対象としたデータ分析において、平日／休日を考慮することは重要。日付を平日／休日に分けるためには、土日を抽出する他に祝日を抽出する必要がある。ただし、祝日数は多くないので、手作業でマスタを作るのが簡単。
また、上記のやり方だけでは休日のすべての影響を考慮することはできない。たとえば、休日前の金曜日の夜は他の平日より居酒屋のお客さんは多いし、大型連休であれば旅行客は通常の休日より多い、また、連休の合間の平日であれば通常の平日より休みを取っている人は多くなっている。このような影響を考慮するためには、さらに休日前、連休や連休の合間の平日をさらに見分ける必要がある。
例）休日フラグの付与
ホテルの予約レコードを対象に、予約テーブルのcheckin_dateに対して、休日マスタ（休日フラグ、休日前フラグ）を付与する。
- 元データ
- 予約テーブル（reserve_tb）
- 休日マスタテーブル（holiday_mst）
- SQL
- 休日マスタ（日付、休日フラグ、休前日フラグを持つテーブル）と結合すれば休日フラグ、休前日フラグを付与できる。
- 結果
- Python
- Pythonでも、休日マスタと結合すれば休日フラグ、休前日フラグを付与できる。
0コメント