LogServiceのETL機能を試してみた

はじめに

こんにちは。エンジニアの石井です。

今回は前回に引き続きLogServiceの話題で、DataTransformation機能について試してみたので、共有させていただこうと思います。

データのアップロード等で前回のブログに記載の関数(put_logsとその周辺)を使うので、必要に応じて以下もご参照ください。

 

www.sbcloud.co.jp

 

構成

今回最終的な構成は以下のようになります。

f:id:sbc_ishii:20200213094952p:plain

何らかのストリームデータがあって、それを一旦LogStoreで受け取ります。

その後DataTransformationでETL処理をしたあとで別のLogStoreに書き込んでいく感じです。

順番に見ていきましょう。

テーマ設定

今回は使うデータは、時系列かつ、多少ETLできそうなものということで、以下を使うことにしました。

archive.ics.uci.edu

ファイルが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側はこんな感じです。

f:id:sbc_ishii:20200212174317p:plain

 

一方のbike-sharing-output側は以下のようになります(カラム数が多く2ページになっています)

f:id:sbc_ishii:20200212174702p:plain

f:id:sbc_ishii:20200212174713p:plain

 DataTransformationスクリプトを作成する

DataTransformationはLogStoreがデータを受け取ったのをトリガに起動し、設定したETL処理を実行します。

つまり、bike-sharing側にDataTransformationを設定して、出力先をbike-sharing-outputにします。

 

対象のLogStoreを選択して、以下からDataTransformationの画面に移ります。

f:id:sbc_ishii:20200212175412p:plain

 

コードエディタの画面が表示されますので、ここでは以下のようなコードを設定します。

gist79a09394e8e955c6005cb5516130a415

独自のDSLで記述していきます。最初は面食らいますがそんなにムズカシイものではありません。ここで書き方については特に解説しませんので、詳細については以下公式ドキュメントを参考にしてください。

www.alibabacloud.com

詳しい動きについては、以下の中段あたりの絵を見ると、コードと含めてやり方が分かるかと思います。

www.alibabacloud.com

データを流してテストする

それではデータを投入していきます。今回も前回に引き続きpython経由で投入します。

アップロードの関数(put_logs)そのものは前回の記事をご参照頂くとして、今回は以下のように記載しています。

gist1f8d91be2270fb422b94f229be36ab26

 

うまくいくと、まずDataTransformation側のダッシュボードが以下のように反応します。

f:id:sbc_ishii:20200212180719p:plain

2回ほど試しているのでちょっとわかりにくくなってしまていますが、緑の線が転送に成功した数(per second)を表しています。

 

続いて、ターゲット側のLogStoreの様子です。

このように指定したルールに基づいて、元のデータにはなかった列が追加されたり、不要な列が削除されていることがわかるかと思います。

f:id:sbc_ishii:20200212180815p:plain

 

おわりに

今回はLogServiceのETL機能であるDataTransformationについて紹介しました。

ここで書いたことはほんの一部ですが、とりあえずデータを投げ込めばLogServiceの機能を駆使することで、分析しやすい形に変換できることがなんとなく理解いただけたのではないかと思います。

ぜひこれらの便利な機能をご活用頂き、データ収集から分析前の前処理までを楽をしてください!!