トレジャーデータはクラウドでデータマネージメントサービスを提供しています。 トレジャーデータが生きるベストフィットケースを7つ紹介します。前回までは1と2について紹介しましたが、今回は、3.について解説します。 何から始めればよいか迷っている 現場から「即答」を求められる 単調な定型レポーティング業務はもうたくさんだと思っている データが散在していて管理できていない パフォーマンス低下を恐れ、古いデータやテンポラリデータを消している わかりやすくて視覚にも訴えるレポートを要求されている 分析の用途以外に、異常を検知する仕組みを導入したい 3. 単調な定型レポーティング業務はもうたくさんだと思っている 毎月の定型レポーティング作りにうんざりしている分析者は今でもたくさんいると思います。 ここでは、すでにTreasure Data Serviceを利用していて、集計のためのデータソースは一元管

はじめに トレジャーデータはクラウドでデータマネージメントサービスを提供しています。 2015年1月，Fluentd のコミッター（弊社エンジニア）が中心となった「Embulk」というOSSが公開されました。このツールは大規模なデータセットのバルクインポートを行えるデータ収集ツールの1つに大別されるものです。 ↑ メインコミッターである当社エンジニア：古橋は Fluentd や MessagePack といったOSSを生み出してきました。そして，トレジャーデータのプラットフォームの根幹を作り上げたのも彼なのです。 Embulk とは何か？ Embulkとはどのようなものなのでしょうか？　バルクインポートを行うためのツールは，はるか以前からたくさん存在しますが，その中においてEmbulk の位置付けはどこにあるのでしょうか？　少しずつ紐といていきましょう。 「簡単に言うとFluentdのバッ

データ分析で大切な４つのこと トレジャーデータはクラウドでデータマネージメントサービスを提供しています。 ここ数年，データの大量な蓄積とそれに対する分散並列処理が可能な環境が成熟してきました。元々はデータの蓄積やバッチの効率化といった分析バックエンド（プラットフォーム）の方にフォーカスがあてられてきましたが，やっとその先のデータ」「分析」というところ，そしてその役割を果たすデータ分析者の重要性が理解されるようになってきているように感じています。 このブームは分析者にとって非常に喜ばしいことでもあると同時に，大きなプレッシャーにもなっているような気がします。 そのプレッシャーの１つに，企画者や経営者・あるいは顧客といった結果を活用する人々（＝意志決定者）の，「これだけ材料（データ）が揃っているのだから多くの課題が解決できるはずだ」という期待に応えないといけないというプレッシャーがあると思いま

トレジャーデータはクラウドでデータマネージメントサービスを提供しています。 本シリーズではトレジャーデータのクエリエンジンについて紹介します。無尽蔵のトレジャークラウドストレージに対する集計方法は，HiveベースのバッチクエリとPrestoベースのアドホッククエリがあります。 これら2つはお互いを補完しあうような存在であり，ケースによって使い分ける事が肝要です。 トレジャーデータのバッチクエリとアドホッククエリを理解する１，２，３ 1. バッチクエリ v.s. アドホッククエリ 今回はバッチ型・アドホック型クエリの特徴を紹介します。 バッチ型もアドホック型も共にSQLライクのクエリによってデータ処理が可能になっています。大きな違いは，バッチクエリはデータソースに対して大規模な並列分散処理を行うのに対し，アドホッククエリは小規模の結果が得られる処理に対して高速にレスポンスを返すところです。