トレジャーデータの新機能「Data Connector」でクライアントレスなビッグデータ連携を実現する


トレジャーデータは、スキーマレスな大量のデータ(ビッグデータ)をパブリッククラウド上に保管して集計や抽出をするためのサービスなのですが、他システムからの連携データをトレジャーデータのテーブルに格納するまでが一苦労でした。

他システムとの外部連携を行う場合、一般的にローカルサーバー内のストレージを外部に公開するわけにはいかないので、Amazon S3などのパブリッククラウド上のストレージ基盤サービスを利用することが多いのですが、クラウドストレージ上のデータをトレジャーデータに格納するためには、いったんローカルサーバーにデータをダウンロードし、ローカルサーバーからトレジャーデータへのバルクロードを実行する必要があり、通信・処理・保存容量といったリソースをローカルサーバー側でも負担していました。

連携元システム → クラウドストレージ → 連携先システム(ローカルサーバー) → トレジャーデータ

しかし、連携データは既にパブリッククラウド上に保存されており、トレジャーデータもパブリッククラウド上に存在するのに、わざわざクライアント上に連携データをダウンロードするのは無駄であるし、SPOF(単一障害点)を増やすことにつながっていました。

この状況を解決するため、トレジャーデータでは、クライアントレスで連携データをサーバーからサーバーへバルクロードする処理を「Data Connector」として実装するという発表を行いました。

連携元システム → クラウドストレージ → トレジャーデータ

まずは Amazon S3 に対応したものがリリースされましたが、AWS に限らないクラウドストレージやCRM、NoSQL、DBMS、ログファイルなどへのプラグイン対応も今後のロードマップに含まれています。

今回紹介する「Data Connector for Amazon S3」はその名の通り,Amazon S3上のデータをトレジャーデータに設定のみで「バルクデータロード」する機能です。この機能は先日オープンソースとしてリリースされた Embulk をベースにしたものです。

(新機能)「Data Connector for Amazon S3」によるデータロード革命

「Data Connector for Amazon S3」の具体的な利用方法としては、yml形式で定義ファイルを作成して、コマンドラインで実行するという流れになります。具体例については「Data Connector for Amazon S3」にありますので、ご参照ください。。

トレジャーデータでは、既存機能としてクエリ実行結果を AWS のカラムナーデータベースである Amazon Redshift に出力したり、別ユーザーのトレジャーデータ内のテーブルに出力するといったデータ連携機能に対応しており、「出力」という観点ではクライアントレスでの連携を実現していました。今回の新機能で「入力」においてもクライアントレスで実現できるようになるため、ビッグデータの連携をパブリッククラウド基盤上で完結しやすくなります。

オンプレミスなビッグデータ基盤を自社所有するのは大きな費用がかかるし、性能の陳腐化やキャパシティなどの問題が発生しがちなのですが、それらをパブリッククラウド基盤上で処理させることで、コストを抑えながら柔軟にビッグデータを扱いやすくなります。

その一方で、個人情報などのセンシティブな情報を除去・暗号化を行ったうえでパブリッククラウド上にデータを格納する仕組みや、ビッグデータの処理結果をローカルシステムに戻して個人情報と結合するといったセキュリティを確保するための処理設計も重要になっていきます。パブリッククラウド基盤の技術革新や充実するほどに、処理を委譲するメリットが大きくなるため、パブリッククラウドに委譲可能な部分を切り分けて、費用対効果やリスク低減をトータルに勘案したアーキテクチャ設計が企業としての競争力につながっていくものと考えています。


DACエンジニア採用情報

  関連記事

【入門編】TreasureDataでWEBログ分析をしてみた

この記事は Treasure Data Advent Calendar 2015 – Qiita の24日目の記事です。 こんにちは。 今回はWEBログの集計や解析をする際によく使うHiveQLのクエリと、UDF(User Defined Functions)について実際の集計クエリを使 …

Treasure Dataの新機能(Data Tank)をAudienceOneのレポート機能で利用した話

Data Tankとは? Treasure Dataの新機能でTreasure Dataのプラットフォーム上に構築されたデータマートです。 Tableau等のBIツールとの接続を想定されており、AWSでいうところのRedshift的なものだと考えるとわかりやすいかと。 Data TankはPostg …

最強のSQLクライアント(GUIツール)「TeamSQL」を使ってみた!

はじめに みなさんこんにちは、プロダクト開発本部の亀梨です。 普段はXmediaOneというメディアプランニング・広告運用管理・トラッキング・マーケティング分析を行う 統合プラットフォームの開発を担当しています。 エンジニアの皆さん、SQLクライアント(GUIツール)って何使ってます? わたくしはこ …

Treasure Dataで大規模なマスタデータを扱う際にはtimeカラムインデックスを活用しよう

DACではTreasure Dataを利用して各種データの蓄積や集計を行っています。Treasure Dataは時系列のデータを扱うのに特にすぐれたアーキテクチャなのですが、セグメントIDとユーザーIDの組み合わせといった大量のマスタデータを利用した計算にも利用することもできます。そのような場合にt …

【入門編】TreasureDataでサイトのアクセス解析をしてみた~第2弾!~

今回もやります、集計クエリ解説シリーズ第2弾!! 前回は、Webログからセッション単位のデータを作成するだけでした。 第2弾では作成したテーブルを元に、より実践的なアクセス解析、サイト分析で使えるHiveQLについて、実際に使用したクエリとともに解説していきたいと思います。 今回やったこと 利用した …

HivemallでMinhash!〜似てる記事を探し出そう。〜

こんにちは。俺やで。 前回の投稿に続き(間が空きましたが)、 ビッグデータに対応したHiveで使える機械学習ライブラリ、 「Hivemall」の使い方、第2弾となります。 今回はMinhashという手法について書きたいと思います。 ※前回 【超入門】Hivemallで機械学習 〜Treasure D …

Amazon ElastiCache/Redisのパフォーマンス確認

はじめに こんにちは、AudienceOne開発部です。AudienceOne開発部ではいわゆるビッグデータと呼ばれる大量のデータをアドホックあるいは定常的に日々ETLだの集合演算だのをする一方で、様々な大規模データ処理ソリューションを継続的に検証しております。 本記事は、その中でもユーザが保持して …

巨大データベースのスケールアップと引越作業

はじめに ビッグデータ解析部でオーディエンスデータ解析基盤の開発、運用を担当している Mike です。 弊社ではインターネット広告配信ログをはじめとする「ビッグデータ」と呼ぶにふさわしいデータボリュームを扱うオーディエンスデータ解析基盤を構築しています。今秋、そのうちの1構成要素である、データサイズ …

気象予報士とビッグデータ解析の意外な関係

DACから気象予報士が誕生しました ビッグデータ解析部のMikeです。 2015年1月の気象予報士試験に合格し、めでたく4月からアドテク業界ただ一人(本当?)の気象予報士となりました 。 そんなわけで、今回は気象予報士とビッグデータ解析の関係についてお話したいと思います。 なぜ気象予報士を目指したか …

【クラウド初心者向け】Google Cloud Platform(GCP)でWebサイトを公開してみよう!

はじめに みなさんこんにちは、プロダクト開発本部の亀梨です。 普段はXmediaOneというメディアプランニング・広告運用管理・トラッキング・マーケティング分析を行う 統合プラットフォームの開発を担当しています。 背景 わたくしは最近プライベートで開発したWebサービスをインターネット上に公開しまし …