トレジャーデータの新機能「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エンジニア採用情報

  関連記事

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

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

Tableauを利用してMySQLとRedshiftのクロスDBジョインを実現する

はじめに RedshiftやTreasureDataなどのデータマート用のDBにはID単位の解析結果が格納され、ローカルのMySQLにはIDに紐づいた名称マスタが管理されている構成の場合、データマートのクロス集計結果に対してIDに紐づいた名称を付与したいことがあります。 データマート用に用意したDB …

GoogleスプレッドシートからTreasureDataへデータを取り込む

AudienceOneの開発を担当しています。skryoです。 またまたTreasureDataネタですが、今回はGoogleスプレッドシートからGoogleAppsScriptを使ってTreasureDataへデータを取り込む手順を紹介したいと思います。 なぜ? Googleスプレッドシート上でマ …

Amazon Redshiftのパフォーマンスチューニング #1 アーキテクチャ概要

ご挨拶 こんにちは。システム開発部の中村です。 現在新卒入社2年目で、普段は受託開発の要件定義等の業務が主担当だったりします。 このブログの発起人というか、まあ言い出しっぺという事で初稿を上げさせて頂きます。 今回はAmazon Web ServiceのDWHサービス、Redshiftのパフォーマン …

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

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

HyperLoglogでcount distinctを速くする

こんにちは。俺やで。 HyperLoglogについて書きます。おもしろいです。名前が。 ■1. HyperLoglogとは? count distinctを速くするアルゴリズム 以前、Minhashについて書きました。 (Treasure Dataさんのブログにも載せていただきました。ありがとうござ …

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

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

ディープラーニングで「顔が似ているAKB48のメンバーを教えてくれるbot」を構築

概要 こんにちは、システム開発部の中村です。 今回は、Facebook Messenger APIを利用して、 画像をアップロードすると、似ているAKB48のメンバーを教えてくれるbotを実装しました。 尚、ディープラーニングやTensorFlowそのものの解説というより、 「エンジンとしてディープ …

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

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

no image
いま必要なのは「アナリティクスアプローチ」

こんにちは。 ビッグデータ解析部のakiです。 解析部で、Markezineでの連載をはじめましたのでご紹介です。 いま必要なのは「アナリティクスアプローチ」、ビッグデータ活用の課題とこれから (http://markezine.jp/article/detail/21293) マーケターのかた向け …