Treasure Data Platform で始めるデータ分析入門
〜5. Data Processing〜

この記事は最終更新から3年以上が経過しています。最新情報は担当のカスタマーサクセスにご確認ください。

本シリーズではデータ分析を以下の7つのレイヤーに分解し，各々について解説していくものとします。（Slide Shareの資料は常時更新されます。）

1. Introduction(この記事)
2. Data Collection
3. Data Storage
4. Data Management
5. Data Processing
6. Data Processing Design
   Part.1
   Part.2
   Part.3
   Part.4
   Part.5
   Part.6
7. Data Visualization
   Treasure Viewer
   MetricInsights
   Tableau
8. Data Visualization Patterns
   Part.1
   Part.2
   Part.3

本日は「5. Data Processing」にフォーカスを当てます。

”Data Processing”と聞いて，多くの人は具体的な集計クエリの内容に言及するものだと期待されていたかもしれませんが，本章ではその内容は次回に譲り，もっと大枠の Processing から Visualization に繋げるためのアーキテクチャについて考えて行きたいと思います。

Hadoop ファミリーを初めとした様々なオープンソースまたは MapR などの製品によって構築される Big Data Infrastructure は上図のように非常に複雑であり，相応のスキルおよび人材リソースが必要になります。

上図は先ほどと少し切り口を変え， Hadoop ファミリーの Batch Aggregator 達（MapReduce, Hive, Pig）または Ad-hoc Aggregator（Impala） を用いた集計プロセスを経て Business Goal（Visualization やレポーティング）に持って行くためのフローとなっています。Batch Aggregator は大規模で無数のカラムを持った複雑なローデータに対するバッチ集計なので，大がかりで時間がかかるものになってしまいます。

一方で Business Goal フェーズに求められるのは，インタラクティブなデータ操作であり，前述の大規模集計では時間がかかりすぎて（分単位以上）そのニーズを充足させる事はできません。よってこれらを結びつけるためには Intermediate Data（中間データ）を挟ませないといけません。バッチ処理によってある程度スマートになったデータをデータベースやメモリに保存しておき，Dashboad や BI からはその中間データを参照することでインタラクティブな操作が可能になるのです。

近年登場した Impala は特定の条件の下でこのバッチ処理を数秒単位で終えてしまうことで，中間データをすっとばして直接 Dashboard や BI と結びつくことを可能にしました。つまり巨大で複雑なローデータに対してUI側からインタラクティブな操作を行う事ができるようになったのです。

しかしながら，ケースによって Hive, Pig と Impala を使い分けるためには，各々の運用・管理が必要であり，これは骨の折れるところでありました。Treasure Data Platform では，処理の実行時にこの Batch 処理と Ad-hoc 処理を簡単に切り替えることができるメリットがあります。

前回紹介した Management Console から各種クエリの実行が可能です。データベース名を選択し，どの処理（Hive, Pig, Impala）を行うかを選択し，クエリを記述してSubmitボタンを押すだけで処理が走ります。

Treasure Data の提供するアドホック型のクエリエンジンは最近のアップデートによって実装されました。その性能はバッチ型に比べて10〜50倍の高速化を可能にします。

各々の Business Goal におけるバッチ型とアドホック型の使い分けは上の表のようになります。

また， 各業界におけるバッチ型とアドホック型の使い分けは上の表のようになります。

最後に改めて Treasure Data Processing のまとめた図になります。

次回は数回にわたって Data Processing Design を紹介します。サンプルデータを用いながら Data Process の基本パターンを理解しましよう。