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 を作成していきます。
