Treasure Data Platform で始めるデータ分析入門〜6. Data Processing Design 〜 Part.2
この記事は最終更新から3年以上が経過しています。最新情報は担当のカスタマーサクセスにご確認ください。
本シリーズではデータ分析を以下の7つのレイヤーに分解し,各々について解説していくものとします。(Slide Shareの資料は常時更新されます。)
- Introduction(この記事)
- Data Collection
- Data Storage
- Data Management
- Data Processing
- Data Processing Design
Part.1
Part.2
Part.3
Part.4
Part.5
Part.6 - Data Visualization
Treasure Viewer
MetricInsights
Tableau - Data Visualization Patterns
Part.1
Part.2
Part.3
本日は「6. Data Processing Design」の第2回目です。
前回紹介した Cube Design の中で,本日は 前処理 & Big Cube 作成のところを紹介します。このフェーズはローログを参照する上に,面倒な前処理が多数必要となる可能性があります。前処理の話はそれだけで非常に長くなってしまいますので,今回はその部分は省略させて頂きます。また別シリーズで書きます。
Making Big Cube
Big Cube 作成は上図の 5 つのステップを踏んでいきます。(ちなみに前処理は 1. およびその前のステップで行います。)
0. Source Data
実際の処理を具体的に進んでリクルート様が公開してくれているカーセンサーの中古車相場データを使います。(データを提供して頂いたリクルート様,ありがとうございます!)
- TD へのインポート方法:https://plazma.red/user_engagement/howto/9893
1. Join ステップ
システム的に最適化されたテーブル構造と分析者に最適化されたテーブル構造は異なります。後者では,複数のテーブルに分かれている場合はデータの同時参照やクエリがややこしくなるということで,ここでは大いに割り切ってそれを全部 Join しちゃえという戦略で行きます。しかしこのステップでは項目の取捨選択は深く考えません。後で必要となりそうな項目はとにかく残していきます。なぜならこの Big Cube を作成した後は,二度と Source Table にアクセスしないようにしたいためです。
ここまでポイントをまとめます。
- 全てのテーブルを Join する。
- 今後使えそうな項目は全て削らず残しておく。
- Big Cube 作成後はそれ以前の Source Data にアクセスしない。
Car Sensor のデータは,メインの”carsensor”, ”catalog” テーブルと id と name のマッピングテーブルがいくつかあり,上記のように紐付いています。ただし, carsensor と catalog テーブルは 1対1 の対応ではなく,同じ code, grade, model でも catalog の方では年式(period)などにより複数のレコードが存在してしまいます。そこで今回は catalog テーブルは join の対象外とします。
join.sql
上記のクエリファイルをローカルに join.sql 名でダウンロードし,そのディレクトリ内で以下のコマンドで実行します。
$ td query -w -d carsensor -q “join.sql” –result ‘td://@/carsensor/usedcar_cube_with_catalog?mode=replace’
query コマンドに関してはドキュメント:Presto Queries/Hive Queriesを参照して下さい。
”usedcar_cube_with_catalog” テーブルが新しく作成(既存なら書き換え)されます。これが Big Cube になります。また,catalog も join した”usedcar_cube_without_catalog” テーブルも以下のクエリで作成できます。
$ td query -w -d carsensor -q “join2.sql” –result ‘td://@/carsensor/usedcar_cube_without_catalog?mode=replace’
2. メジャー,ディメンジョン分類ステップ
つぎに,”carsensor_cube_without_catalog” のカラムをメジャー・ディメンジョンに分類します。
- メジャー:集計できる定量化可能なデータ (通常は数値データ) を含んでいる項目で,SQL ではSUM や COUNT などの集計計算の対象となる項目
- ディメンジョン:集計の切り口・セグメントとなる項目
このメジャーとディメンジョンで分類できさえすれば,後の集計は下記のクエリテンプレートに従って組み合わせを考えるだけで集計を行う事ができます。
SELECT SUM( #measure ), COUNT( 1 ) {, ANOTHER_MATH_UDF( #measure ), COUNT( DISTINCT( %dimension ) }
FROM table
WHERE condition
GROUP BY %dimension1, %dimension2
次回はこのクエリテンプレートを用いて Mini Cube を作成していきます。