はじめに
こんにちは。エンジニアの石井です。
今回は前回に引き続きLogServiceの話題で、DataTransformation機能について試してみたので、共有させていただこうと思います。
データのアップロード等で前回のブログに記載の関数(put_logsとその周辺)を使うので、必要に応じて以下もご参照ください。
構成
今回最終的な構成は以下のようになります。
何らかのストリームデータがあって、それを一旦LogStoreで受け取ります。
その後DataTransformationでETL処理をしたあとで別のLogStoreに書き込んでいく感じです。
順番に見ていきましょう。
テーマ設定
今回は使うデータは、時系列かつ、多少ETLできそうなものということで、以下を使うことにしました。
ファイルが2つありますが、今回はday.csvを利用することにします。
中身は以下のようになっています。
# | カラム名 | 型 | 大まかな意味 |
---|---|---|---|
1 | instant | 整数 | index |
2 | dteday | 整数 | そのデータを観測した年月日時 |
3 | season | 整数 | 季節。1が冬、2が春、3が夏、4が秋 |
4 | yr | 整数 | 観測した年。2011年が0, 2012年が1 |
5 | mnth | 整数 | 観測した月 |
6 | holiday | 整数 | 休みなら1, 平日なら0 |
7 | weekday | 整数 | 月曜〜日曜までを0~7で表現 |
8 | workingday | 整数 | holidayでも土日でもなければ1 |
9 | weathersit | 整数 | 天気。1は概ね晴れ、2は曇り系、3は雪、4は強い雨 |
10 | temp | 浮動小数点 | 標準化した気温 |
11 | atemp | 浮動小数点 | 標準化した体感気温 |
12 | hum | 浮動小数点 | 湿度 |
13 | windspeed | 浮動小数点 |
風速 |
14 | casual | 整数 | レンタルサイクルの観光者利用数 |
15 | registered | 整数 | レンタルサイクルの登録利用者数 |
16 | cnt | 整数 |
トータルのレンタルサイクルの利用者数 |
このデータを変換し、以下のようなデータに変換します。
# | カラム名 | 方針 |
---|---|---|
1 | instant | そのまま残す |
2 | dteday | 別特徴量に変換(#17) |
3 | season | 別特徴量に変換(#18~#21) |
4 | yr | 削除 |
5 | mnth | 削除 |
6 | holiday | そのまま残す |
7 | weekday | 別特徴量に変換(#22~#28) |
8 | workingday | そのまま残す |
9 | weathersit | 別特徴量に変換(#29~#32) |
10 | temp | そのまま残す |
11 | atemp | そのまま残す |
12 | hum | そのまま残す |
13 | windspeed | そのまま残す |
14 | casual | そのまま残す |
15 | registered | そのまま残す |
16 | cnt | そのまま残す |
17 | timestamp | (新設)dtedayをtimestamp形式に変換したもの。 |
18 | winter | (新設)seasonが1のとき1、それ以外のときは0 |
19 | spring | (新設)seasonが2のとき1、それ以外のときは0 |
20 | summer | (新設)seasonが3のとき1、それ以外のときは0 |
21 | autom | (新設)seasonが4のとき1、それ以外のときは0 |
22 | sunday | (新設)weekdayが0のとき1、それ以外のときは0 |
23 | monday | (新設)weekdayが1のとき1、それ以外のときは0 |
24 | tuesday | (新設)weekdayが2のとき1、それ以外のときは0 |
25 | wednesday | (新設)weekdayが3のとき1、それ以外のときは0 |
26 | thursday | (新設)weekdayが4のとき1、それ以外のときは0 |
27 | friday>/td> | (新設)weekdayが5のとき1、それ以外のときは0 |
28 | saturday | (新設)weekdayが6のとき1、それ以外のときは0 |
29 | good | (新設)weathersitが1のとき1、それ以外のときは0 |
30 | normal | (新設)weathersitが2のとき2、それ以外のときは0 |
31 | bad | (新設)weathersitが3のとき3、それ以外のときは0 |
32 | terrible | (新設)weathersitが4のとき4、それ以外のときは0 |
LogStoreの用意
LogStoreは元データの受け手用と変換後の保管用で2つ必要です。
今回は、以下2つを作りました。
# | LogStore名 | 役割 |
---|---|---|
1 | bike-sharing | 元データ投入用 |
2 | bike-sharing-output | ETL後データ用 |
それぞれに対して、上記の通りのIndexを設定しておきます。
bike-sharing側はこんな感じです。
一方のbike-sharing-output側は以下のようになります(カラム数が多く2ページになっています)
DataTransformationスクリプトを作成する
DataTransformationはLogStoreがデータを受け取ったのをトリガに起動し、設定したETL処理を実行します。
つまり、bike-sharing側にDataTransformationを設定して、出力先をbike-sharing-outputにします。
対象のLogStoreを選択して、以下からDataTransformationの画面に移ります。
コードエディタの画面が表示されますので、ここでは以下のようなコードを設定します。
gist79a09394e8e955c6005cb5516130a415
独自のDSLで記述していきます。最初は面食らいますがそんなにムズカシイものではありません。ここで書き方については特に解説しませんので、詳細については以下公式ドキュメントを参考にしてください。
詳しい動きについては、以下の中段あたりの絵を見ると、コードと含めてやり方が分かるかと思います。
データを流してテストする
それではデータを投入していきます。今回も前回に引き続きpython経由で投入します。
アップロードの関数(put_logs)そのものは前回の記事をご参照頂くとして、今回は以下のように記載しています。
gist1f8d91be2270fb422b94f229be36ab26
うまくいくと、まずDataTransformation側のダッシュボードが以下のように反応します。
2回ほど試しているのでちょっとわかりにくくなってしまていますが、緑の線が転送に成功した数(per second)を表しています。
続いて、ターゲット側のLogStoreの様子です。
このように指定したルールに基づいて、元のデータにはなかった列が追加されたり、不要な列が削除されていることがわかるかと思います。
おわりに
今回はLogServiceのETL機能であるDataTransformationについて紹介しました。
ここで書いたことはほんの一部ですが、とりあえずデータを投げ込めばLogServiceの機能を駆使することで、分析しやすい形に変換できることがなんとなく理解いただけたのではないかと思います。
ぜひこれらの便利な機能をご活用頂き、データ収集から分析前の前処理までを楽をしてください!!