トレジャーデータ（Treasure Data）ブログ

トレジャーデータ（Treasure Data）ブログです。

本サイトは移転しました。新サイトにリダイレクトします。

"); // リダイレクト 　　setTimeout("redirect()", 0);　// 0 sec 　　function redirect(){ 　　 　location.href = url; 　　} 　 　// canonical の書き換え 　　var link = document.getElementsByTagName("link")[0]; 　　link.href = url; -->

Treasure Data Service と Redshift のハイブリッドアーキテクチャ

アドホッククエリ（TQA） 技術アーキテクチャ Data Mart プラットフォーム紹介

本記事は移転しました。新サイトにリダイレクトします。

"); // リダイレクト 　　setTimeout("redirect()", 0);　// 0 sec 　　function redirect(){ 　　 　location.href = url; 　　} 　 　// canonical の書き換え 　　var link = document.getElementsByTagName("link")[0]; 　　link.href = url; -->

*トレジャーデータはデータ収集、保存、分析のためのエンドツーエンドでサポートされたクラウドサービスです。

Treasure Data Service はそれ自身がデータの収集から可視化までの一気通貫したサービスですが，他の様々なサービスと連携することによって各々の分析ニーズにマッチしたアーキテクチャを構成することができます。今回は Amazon Redshift とのハイブリッドアーキテクチャ等の具体的なケースを見て，視野を広めていきましょう。

バッチ処理

Treasure Data Service は標準ではHiveQLによってクラウドストレージに集計処理を実行することができるのですがこれはいわゆる「バッチ処理」という分類で，スケジューリングされたクエリが定時的にバックエンドで集計されるものです。

f:id:treasure-data:20140501161331p:plain

以前紹介したダッシュボード（上図）：MetricInsights などでは独立したウィジェットの中にクエリと集計インターバルを指定する事によって自動的にバッチ処理を行って結果をダッシュボードに反映してくれるもので，トレジャーデータの提供する大規模バッチ処理集計と非常に相性の良いツールとなっています。

アドホック処理

一方で，例えばTableauなどのBIツールからのクリックアクション，またはCSVファイルとしてローカルに書き出す場合には，その場でアドホックにクエリが実行され，結果を待つことが必要になります。Treasure Data Serviceではバッチ処理に対してこの「アドホック処理」を，Treasure Query Accelarator (TQA) というクエリエンジンでそれを可能にしています。

TQA

TQAの何よりのメリットは参照するデータが大規模な生データに対してアドホック処理を実現できることにあります。これによって分析者が様々な集計/分析クエリと試行錯誤しながら見いだしていく場合や，BIからの様々なドリルダウンなどのインタラクティブな処理がストレス無く遂行できるようになりました。

f:id:treasure-data:20140501152440p:plain

Amazon Redshift

一方でアドホックな要請に答えるもう一つの手段として，生データからある程度事前集計した中間データ（データマート）を作成しておくことによって，分析者やBIは生データではなく，そこからシェイプアップされた中間データにアクセスすることによってアドホックな処理に対応してくれます。この中間データストレージとしては，RDBMSやNoSQL，またはオンプレ製品の独自ツールが用意されていました。

しかしこの中間データといっても，その量が大量になる場合も多々あります。例えばユニークユーザー数を日/月/年ごとに計算するのには，全てのユーザーIDリストを中間データとして保持しなければなりません。毎日1000万UUをたたき上げるサービスについては中間データベースが肥大化して容量不足または処理能力の低下を引き起こしてしまいます。

Amazon Redshift はそういった中間データの悩みを解決する非常に強力なサービスです。非常に低価格で大容量のデータを保持しておけるのに加えて，PostgresのインターフェースをもっていますのでRDBMSと同じクエリで集計を高速に行うことができます。つまり従来中間データストレージとしてRDBMSを使っていた場合には，Redshiftに置き換えることで大規模なデータを低コストで保持していくことができるようになったのです。

f:id:treasure-data:20140501152455p:plain

Treasure Data Service & Redshift のハイブリッドアーキテクチャ

このように，TQA と Redshiftは「高速なアドホック処理」の要請を満たすものとしては同じ役割を果たしますが，前者は生データに対して処理を行うのに対して，後者はデータマートに対して処理を行うという点で大きく異なっています。

そして，その両者のハイブリッドな構成を持つことによってより強力な大規模集計アーキテクチャを作り上げることが可能になるのです。

f:id:treasure-data:20140502142511p:plain

上図はどのような場合にどのようなアーキテクチャを構築すべきかの簡易シートです。

  • 生データのみを扱うのか，中間データストレージを挟むのか
  • 中間データベースはクラウド上にデータがおけるのか，またどれくらいの規模を見込むのか

そして重要な点は，Amazon RedshiftとTQAは同じレイヤーに無いということです。Amazon Redshiftがデータ自身を保持するデータウェアハウスに対して，TQAはTreasure Data Serviceに対するクエリエンジンで Impara や Presto と同じレイヤーのものです。

f:id:treasure-data:20140501152513p:plain

さて，上図と共にもう少し詳細に主に中間データストレージを採用するアーキテクチャを考えていきましょう。Treasure Data Service における Cloud Storage に蓄積されていくDB1, DB2, DB3 が生データにあたる部分です。

Treasure Data Service の Cloud Storage の思想は「とにかくデータを貯めよ」ということであるので，

  • スキーマの異なったレコードが共存している
  • 細かくテーブルが分かれている
  • エラーレコードを含んでいる

といった理由で，分析の負担を軽減するための前処理を必要とする場合があります。「Joined Data」「集計・フィルタ済データ」などがその例ですが，フロントエンドからはこの前処理済のデータに対してアクセスを行います。

前処理済データに対してHiveクエリを実行した中間データは「Result Push」機能によって様々なタイプのデータストレージ（RDBMS, NoSQL, Redshift, etc...）に書き出すことになります。

f:id:treasure-data:20140501152529p:plain

さて，どのような場合にどの中間データストレージを使うべきなのかを上図にまとめてみました。重要なのは

  • 元データに対してどの程度データがシェイプアップされたのか
  • 中間データストレージをクラウドにおけるか？

という2点です。元データに対して1/100程度しか削減されなければ，中間といえど大規模なストレージが必要となりますので（クラウド上に置けるなら）RedShiftが有効になってきます。そうで無い場合はAmazon RDS（クラウド上に置けて管理コストを減らせる）やMySQL，NoSQL（ローカル環境）を採用します。

f:id:treasure-data:20140501152550p:plain

RedshiftとTQAを用いたハイブリッドなアーキテクチャは上図のようになっています。

TQAは，大規模な元データに対してアナリストが様々な分析クエリを試行錯誤していく状況や，元データに対してBIを繋ぐ場合のドリルダウンなどのUIを通じてのインタラクティブな操作に順応する場合に使用します。

Redshiftは分析軸（KPI）が定まり，以降は集計ジョブを指定時間に実行するだけでよくなった場合や，BIなどのUIを通じて（TQAのケースより高速に）参照する場合に使用します。

これら2つは共存させる事が可能で，それによりあらゆる分析フェーズの，あらゆるフロントエンドからのアクセスをカバーすることが可能になります。

またTreasure Data Service もAmazon Redshiftも使用リソースによる課金体系ですので，ハイブリッドアーキテクチャを構成したからといってコストが跳ね上がるといった事もありません。

このようにそれぞれの用途・フェーズに応じて柔軟に分析アーキテクチャを変えていけるようになれば，ビッグデータ分析がより手軽で身近なものとなっていくでしょう。

トレジャーデータに関するお問い合わせは [email protected] まで。

Â