タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

Treasure Dataとfluentdに関するkzkのブックマーク (2)

  • ビッグデータ分析の勘所─Treasure Dataイベントで見えたデータサイエンスのノウハウ | gihyo.jp

    その中からTreasure Data(以下、TD)のデータ分析ノウハウについて語った田村氏、柄沢氏の発表をピックアップしてレポートします。 データを集めるのはたいへん 1つめに挙げた課題はデータ収集の問題です。田村氏は、いざデータ分析を始めてみると、集めたデータに間違いがあって、正しく集計、分析ができないということがよく起きると言います。 その原因の1つは、アプリケーションを修正した結果、出力するログが変わっていたというものです。データ分析の現場では、「⁠業務でデータを集める人」と「データを分析する人」が異なるというのはよくあるそうです。そのため、前述のようにほかの担当者がログを分析していることをあまり意識せずに、アプリケーション開発担当者がログの内容を変更してしまうということが起こるのです。 また、データを集めるしくみが複雑過ぎる、というのも一因です。一般的にどんなサービスでも、複数のデ

    ビッグデータ分析の勘所─Treasure Dataイベントで見えたデータサイエンスのノウハウ | gihyo.jp
  • 開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー

    開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この

    開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
  • 1