Treasure Data利用でデータ受付サーバをなくせるか!?

Treasure Data利用でデータ受付サーバをなくせるか!?

一般的なDMPサービスでは、データの素となる情報をクラウド上サーバで受付し、そのデータを別のクラウド型データマネジメントサービスに飛ばすことによって、実際に“使えるデータ”に仕立ててあげる必要があります。

これをクラウド型データマネジメントサービスに直接データを送り込み、その場で“使えるデータ”に仕立てることができないものかと常日頃考えていました。

今回はクラウド型データマネジメントサービスの雄、『Treasure Data』にある「Javascript SDK」を用いて、“直接登録・そのまま運用”作戦を実行すべく、リサーチをしてみることにしました。

結論から先に言ってしまうと、Treasure Data上のHiveのバージョンが対応していなかったため、「直接登録不可」いう結果に至ってしまいましたが、今回の調査を無駄にしないためにも、共有がてらにご報告いたします。

今回の課題

現在考えられる課題は以下の2点です。

  • クエリパラメータの暗号化
  • どの程度受けられるのか?

クエリパラメータの暗号化

httpからのリクエストもあることを想定し、クエリパラメータの一部を暗号化に。
できれば現在の水準であるAESを導入したい。

どの程度受けられるのか?

気にはなりますが、これは受付側であるTreasure Dataの仕様依存のため、
今回の調査からは除外。

クエリパラメータについては、javascriptでの暗号化データをTreasure Dataで復号化することが可能なのであれば、本課題は問題ないものと考えています。

確認方法とその調査結果

javascriptの暗号化については「crypto-js」を用いてみました。
下記はWEB上にあったサンプルで調査確認したものです。

まずは『js -> js』は確認ができたので、下記コードを入れることでTeasure Dataに登録してみました。

しかし、ここで先にお伝えしたとおり、Hiveのバージョンに「aes_decrypt」が無いことが発覚。
泣く泣く断念した次第です……。

自身の失敗すらDMP化! 未来の資源にすべく、失敗を繰り返そう!!

WEBサーバのアクセスログで取得できるような情報は一通り入っている仕様だったので、『Treasure Date』単体での運用は現実的なものと捉えていました。実際、そういったアタリがあったからこそ今回の検証はスタートしたわけです。

『Treasure Data』のみで取得できるログではユーザエージェントデータは取得されていませんでしたが、ブラウザ情報などは存在しているため、併せてJavascriptも取得してしまえば、欠落したユーザエージェント情報は補完できる状態でした。あと一歩、「おしい!」といったところです。

今回はあくまでも『Treasure Data』を用いた場合の実験に留まりましたが、DMPに限らず色々な実験と検証を繰り返し、今後のサービス展開に活かしたいところですね!

コメント