big data入門に見せかけたfluentd入門

Big Data入門に見せかけたFluentd入門

June 5th, 2013 Authored by Keisuke Takahashi (a.k.a. @keithseahus)

• ご案内 – このドキュメントの想定読者層

•  Big DataやFluentdのプロでない方。Big Data関連の仕事をしていない方や、Fluentdに触ったことが無い方。

•  Fluentdが注目される理由を、背景から理解したい方。 •  Fluentdの開発者向け公式ドキュメント（現行）が日本語に翻訳されたら本気を出そ

うと思っているソフトウェア開発者。

– 間違いに気づいたら… •  著者にそっとご連絡頂けると嬉しいです。ベストエフォートで直します。

– ライセンスについて •  クリエイティブ・コモンズ・ゼロです。再利用にあたって、著者の表示を削除するこ

とを含め、著作権上の制約は一切ありません。居住地における法規及び国際法の範囲内で、ご自由にお使い下さい。

– 免責 •  本ドキュメントにより生じた一切の事象について、著者は一切の責任を負わないも

のとします。

Big Data is 何？

各自がBig Dataの定義を持っており、唯一の正しい定義というものは無いはずです。みなさんはどう捉えていますか？

多くの文献が、Gartnerの発表を引用しています。

データの容量(volume) データの種類(variety)

データが増加する速度(velocity) それぞれが飛躍的に増大するため

活用することが難しいと考えられていたデータ

ここでは、これをベースに話を進めます。

ビジネス面での課題

データの容量 -‐ volume -‐

IDCによれば、世界のデータ量は、2015年には7.9ゼタバイトまで増大するとのことです。

データの種類 -‐ variety -‐

ユーザはインターネット上の多様なサービスを利用してデータを生成し、サービスもまた増え続けています。

データを生成するのは人間だけではありません。デバイスが生成するデータもあります。

Webサイトのマウストラッキングデータも活用可能なデータです。

データの解像度も増えています。

データが増加する速度 -‐ velocity -‐

モバイルで常時接続の高速インターネットが可能になり、ユーザが膨大なデータをインプット・アウトプットできる時代になりました。

近距離無線やセンサーデバイスが発達し、データを生成しインターネットへ出力する主体は、飛躍的に増加しています。

結果、データは加速度的に増加し、データの総量は指数関数的に増加しています。

技術によるアプローチ

容量・種類・速度の課題に対する、技術的なアプローチを見てみましょう。

大量データの検索を高速化するための技術

volumeに対するアプローチです。

• インメモリデータベース • 列指向データベース • 超並列データベース • ハイブリッド型データベース

HBase, Hypertable, Cloudataなどは列指向データベースにカテゴライズされます。

大量データの取扱いを簡易にするための技術

varietyに対するアプローチです。

• キーバリューストア • ドキュメント指向データベース • グラフデータベース

例えばKVSはCassandra, Kyoto Cabinet, Couchbase, Redis, Riak、ドキュメント指向DBはMongoDB, CouchDB、グラフDBはNeo4jが有名です。

大量データの処理を高速化するための技術

velocityに対するアプローチです。

• 並列分散処理 • 複合イベント処理 • イベントストリーム処理

並列分散処理はHadoopのMapReduceが有名。データを蓄積せずに、流れるデータに対して解析処理をかける技術もあります。

何が変わるのか？

分析手法

従来のデータ分析 Big Dataの分析

生成元企業の基幹システムアクセスログソーシャルデータセンサー ...

構造構造化データ半構造化データ非構造化データ

保管方式リレーショナルデータベースデータウェアハウス

分散ストレージキーバリューストア ...

分析手法定型レポートデータマイニング

視覚化ビジネスインテリジェンスビジネスインテリジェンス

分析の対象が質的にも量的にも異なるため、従来とは異なるアプローチで分析する必要があります。

従来のデータ分析 Big Dataの分析

生成元企業の基幹システムアクセスログソーシャルデータセンサー ...

構造構造化データ半構造化データ非構造化データ

保管方式リレーショナルデータベースデータウェアハウス

分散ストレージキーバリューストア ...

分析手法定型レポートデータマイニング

視覚化ビジネスインテリジェンスビジネスインテリジェンス

まさにゴミの山から宝物を探すような分析になります。データマイニングについて少し深堀りしましょう。

データサイエンティストと呼ばれる人たちが、統計的手法を用いてBig Dataの分析を行います。そのため、統計分析が可能な形にBig Dataをクレンジングする必要があります。

Big Data 活用までの道のり

Big Dataが活用されるまでのシーケンスを追ってみましょう。

• 監視やレポート（ゴール）

Big Data活用のゴールは、主に監視やその予測に役立てたり、ビジネスを先見するレポートを出力することです。

• 監視やレポート（ゴール） • データマイニングと可視化

予測や予見など、未来を推し量ることができるのは、統計分析を行うためです。

• 監視やレポート（ゴール） • データマイニングと可視化 • 蓄積と処理

基本的に、材料となるデータはストレージに蓄積します。それらに対して、データマイニングが可能となるよう、必要な処理を行います。

• 監視やレポート（ゴール） • データマイニングと可視化 • 蓄積と処理

• データの生成

蓄積されるデータは、世界中の不特定な場所で常に生成されています。

• 監視やレポート（ゴール） • データマイニングと可視化 • 蓄積と処理 • ？？？ • データの生成

重要なシーケンスが一つ抜けています。何でしょう？

データ収集

不特定の場所で生成されるデータを集め、ストレージへと集約する処理です。

従来

従来のデータ分析での収集方法を見てみましょう。ここではログデータを例にします。

最もポピュラーなデータ収集方法は、syslogではないでしょうか。

問題点

従来的な手法であるsyslogををBig Dataに対しても使用することは、無理があります。なぜでしょう？

構造の観点で、データには大きく2つに分類されます。統計分析を行うためには、データは構造化されている必要があります。

ログは非構造化データ

である（Big Data解析の観点から）

各種ログにも構造はありますが、それはアプリケーションごとに異なる独自の構造で、そのまま集約して分析することはできません。

Big Data時代には様々なイベントログが分析対象となります。従来のログ同様、これらは非構造化データです。

分析をするためには構造化処理が必要

ログを構造化するには？

非構造化データを構造化データに変換するためには、どうすればよいでしょう？

世の中には、さまざまな非構造化データがあります。

バラバラなフォーマットを

共通化

これらを、構造化データに変換するためには、まずフォーマットを統一する必要があります。

共通のフォーマット？

そのフォーマットの要件は何でしょう？

 ASCIIである

現在のBig Data分析の対象は、バイナリではなくASCIIデータです。

 ASCIIである  値の意味が明示的である

数値やテキストだけがあっても分析できません。それが何の値なのか、システムにとって明示的である必要があります。

 ASCIIである  値の意味が明示的である  柔軟である

データの種類は不特定です。スキーマレスであることが必要です。

それ何て　　　　　？

※まぁ、　　　　　でもいいですけど…

そんなログコレクタ

不特定多数の非構造化データを収集し、構造化データに変換する、ログコレクタがあります。

他のログコレクタとの比較

ログコレクタは他にもあります。比較してみましょう。

Scribe

Fluentd

設定は後述のincludeディレクティブで、HTTPでコンフィグのURLを指定して読み込むことができ、これで一元管理が可能です。

そんなログコレクタ

重要なことなので２回言います。

重要なことなので２回言います。

Log everything in JSON.

Sponsored by

ちなみに、Treasure Dataは、Fluentdを使用してBig Dataソリューションを展開する注目のベンチャーです。

先ほど、Fluentdのメリットを挙げました。

これらの特徴について、詳しく追ってみましょう。

インストール

インストールが容易という特徴です。

　　の環境がある場合

　　の環境が無い場合

Rubyがインストールされていなくても、Fluentdは利用可能です。

td-‐agent

td-agentをインストールします。

td-agentのインストールも、非常に簡単です。

gem版はtrunkに近い、所謂オープンソース版。 td-‐agentの方が十分テストされているとのこと。

一応、留意点です。

gem版とtd-‐agentとで標準プラグインの種類が若干異なるらしい…

一応、留意点です。

インストール前に必要な、ちょっとした準備があります。

hOp://docs.fluentd.org/ja/arTcles/before-‐install

NTPの設定、ファイルディスクリプタの最大値増加、ネットワーク関係のカーネルパラメータの最適化。設定後、OSの再起動が必要です。

セットアップ

セットアップが容易という特徴です。

コンフィグファイル

セットアップは単一のコンフィグファイルを編集することで行います。

場所

コンフィグファイルは以下の場所にあります。

gemでインストールした場合は、コマンドでパスを指定します。td-agentを利用する場合は、特定のパスにコンフィグファイルがあります。

形式

コンフィグファイルの形式を見てみましょう。

Apacheのコンフィグに近い、構造化テキストです。

風味

構成

XMLの構成を見てみましょう。

Fluentdのコンフィグファイルは、3つのディレクティブから成り立っています。シンプルですね。

構造化ログ

ログが構造化されているという特徴についてです。

{ “Time”:”2013-‐07-‐05 09:00:00”, ”Tag”:”apache.log”, ”Record”:{“host”:”127.0.0.1”,”method”:”GET”,”path”:”/”} }

Fluentdが出力するイベントログは、先述の通り、JSONで構造化されています。例えばApacheのログを読み込み、このように出力することができます。

入力ソース

入力ソースを自由に選べることが特徴の一つです。どれくらい自由なのでしょう？

プラグインで自由に定義可能

定義できさえすれば、何でも入力ソースにできます。

出力先

出力先を自由に選べることも特徴の一つです。どれくらい自由なのでしょう？

プラグインで自由に定義可能

こちらも、扱える範囲であれば、どこへでも出力できます。

機能拡張

機能拡張が容易であることも特徴の一つです。

Rubyで自由に拡張可能

Rubyでプラグインを作ることができます。

速度

FluentdはRubyで書かれていますが、速度が必要な部分はCで書かれています。それによる高速さを示す事例を紹介します。

事例1 Cookpad

hOp://www.slideshare.net/hotchpotch/20120204fluent-‐logging

合計100台弱からtd-agentでログを収集し、ほとんどのロギングはfluentdに移行。中央のfluentdは1台で、1スレッドで十分処理できているとのことです。

事例2 NHN Japan

hOp://www.slideshare.net/tagomoris/log-‐analysis-‐with-‐hadoop-‐in-‐livedoor-‐2013

16ノードからログの収集を行い、毎秒120,000+行の転送量、最高400Mbpsを記録し、毎日1.5+TBのログを集めいているとのことです。

メンテナンス

Fluentdはもちろんメンテナンスされているソフトウェアです。

オープンソースコミュニティ

本体は開発者である古橋氏を中心に、33名のコントリビューターがいます。膨大なプラグインはコミュニティの各メンバーが開発・メンテしています。

使用例

簡単な使用例を紹介します。

192.168.0.3

← あえて混在環境を　作り出すため　gemでインストール

← 商用を想定し　td-‐agentでインストール

GlusterFSのクラスタで各ノードに出力されるログを集めてみましょう。

<source> type tail path /var/log/glusterfs/usr-local-glusterfs-3.4.0beta2-etc-glusterfs-glusterd.vol.log pos_file /var/log/td-agent/usr-local-glusterfs-3.4.0beta2-etc-glusterfs-glusterd.vol.log.pos tag glusterd format /^(?:\[(?<date_ymd>[0-9]{4}-[01][0-9]-[0-3][0-9]) (?<time_hms>[0-2][0-9]\:[0-5][0-9]\:[0-6][0-9])\.(?<time_usec>[0-9]{6})\]) (?<log_level>[TDINWECA]) (?:\[(?<source_file_name>[^\[\]:/ ]*):(?<source_line>[0-9]*):(?<function_name>[^\[\]:/ ]*)\]) (?<component>[^\[\]:/ ]*)\: *(?<message>.*)$/ rotate_wait 5 </source>

/etc/td-‐agent/td-‐agent.conf (GlusterFS側)

GlusterFS側のtd-agentには、glusterdのログファイルをtailさせます。sourceディレクティブにはこのように記述します。

<match glusterd.**> type hostname key_name host add_prefix filtered </match> <match filtered.glusterd.**> type forward send_timeout 60s recover_wait 10s heartbeat_interval 1s phi_threshold 8 hard_timeout 60s <server> name dev-centos host 192.168.0.3 port 24224 weight 60 </server> <secondary> type file path /var/log/td-agent/forward-failed </secondary> </match>

/etc/td-‐agent/td-‐agent.conf (GlusterFS側)

matchディレクティブでは、hostnameプラグインを使用し、イベントログの中にノード名を挿入するようにしました。

# wget https://raw.github.com/fukata/fluent-plugin-hostname/master/lib/fluent/plugin/out_hostname.rb

/etc/td-‐agent/plugin にプラグインをインストール (GlusterFS側)

<source> type forward port 24224 bind 0.0.0.0 </source> <match filtered.glusterd.**> type file path /home/keith/var/log/fluent/glusterd </match>

$HOME/fluent/fluent.conf (192.168.0.3側)

ログ収集を行うノードには、出力先のディレクトリパスを指定します。

[root@dev-centos ~]# gluster volume info dist Volume Name: dist Type: Distribute Volume ID: a62edcc6-23c9-46d8-bf6d-f0682ac08c64 Status: Stopped Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: glusterfs-unstable-01:/mnt/lv0/dist Brick2: glusterfs-unstable-02:/mnt/lv0/dist

192.168.0.3側でGlusterFSのvolumeをstart

[root@dev-centos ~]# gluster volume start dist volume start: dist: success

では、ログを出すために、GlusterFSのvolumeをstartしてみましょう。

Fluentdでログの構造化と転送が行われたことを、192.168.0.3側で確認。

[root@dev-centos ~]# grep glusterfs-unstable-01 /home/keith/var/log/fluent/glusterd.20130708.b4e0ed6e32655d35f | tail -3 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"778961","log_level":"I","source_file_name":"socket.c","source_line":"3495","function_name":"socket_init","component":"0-management","message":"using system polling thread","host":"glusterfs-unstable-01.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"779397","log_level":"W","source_file_name":"socket.c","source_line":"514","function_name":"__socket_rwv","component":"0-management","message":"readv failed (No data available)","host":"glusterfs-unstable-01.localdomain"} 2013-07-08T00:52:43+09:00 filtered.glusterd {"date_ymd":"2013-07-07","time_hms":"15:52:43","time_usec":"779668","log_level":"I","source_file_name":"socket.c","source_line":"2236","function_name":"socket_event_handler","component":"0-transport","message":"disconnecting now","host":"glusterfs-unstable-01.localdomain"}

formatで指定した正規表現の通りにログをパースし、JSONで転送できていることが確認できました。


Fluentdでログの構造化と転送が行われたことを、192.168.0.3側で確認。


上がFluentdで構造化したログ、下がオリジナルのログです。

[root@glusterfs-unstable-01 plugin]# tail -3 /var/log/glusterfs/usr-local-glusterfs-3.4.0beta2-etc-glusterfs-glusterd.vol.log [2013-07-07 15:52:43.778961] I [socket.c:3495:socket_init] 0-management: using system polling thread [2013-07-07 15:52:43.779397] W [socket.c:514:__socket_rwv] 0-management: readv failed (No data available) [2013-07-07 15:52:43.779668] I [socket.c:2236:socket_event_handler] 0-transport: disconnecting now

Fluentdのアーキテクチャ

Fluentdのアーキテクチャについて追ってみましょう。

出典：hOp://www.slideshare.net/treasure-‐data/the-‐basics-‐of-‐fluentd

Fluentdの本体は3,000-4,000行の小さなソフトウェアで、それはプラガブルな作りとなっており、3つのパートにプラグインを適用して動作させます。

Fluentdのプラグイン

どのようなプラグインがあるか、見てみましょう。

•  Inputプラグイン

–  in_forward •  他のfluentd等からイベントログを受け取る

–  in_hOp •  HTTP POSTのURLをtag、bodyをrecordとしてイベントログを受け取る。

–  in_tail •  イベントログをファイルから読み込む

•  ApacheとSyslogのパーサ付き

•  カスタムパーサも書ける

–  in_exec •  外部プログラムから標準出力経由でTSV形式のイベントログを受け取る

–  in_syslog •  syslogプロトコルでイベントログを受け取る

–  in_scribe •  Scribeからイベントログを受け取る

–  ... Inputプラグインは、外部ソースからイベントログを受け取るインタフェースです。thread socketとlisten socketを生成するためノンブロッキングです。

•  Bufferプラグイン

– buf_memory •  メモリ上にバッファすることで速度を高める

– buf_file •  ファイルにバッファすることで信頼性を高める

Bufferプラグインは2種類です。パフォーマンスを向上させるか、信頼性を向上させるかを選ぶことができます。一連の処理をスレッドセーフにする作用もあります。

•  Outputプラグイン

– out_file •  イベントログをファイルに書き出す

•  ファイルは日ごとに生成する

– out_forward •  イベントログを他のFluentdに転送する

•  ロードバランシングとフェイルオーバ機能を提供

– out_exec •  TSV形式のイベントログを標準入力経由で外部プログラムへ渡す

– out_exec_filter •  out_execにイベントログを渡す前に、他の外部プログラムに対するTSV形式イベン

トログの標準入出力を実行する。

– out_copy •  イベントログを複製して複数のOutputプラグインに渡す

– out_roundrobin •  複数のOutputプラグインに対してラウンドロビンでイベントログを渡す

Outputプラグインによって、イベントログの書き出し又は送信を行います。

•  Outputプラグイン(続き)– out_stdout

•  イベントログを標準出力に書き出す

– out_null•  イベントログを捨てる

– out_s3•  Amazon S3にイベントログを出力する

– out_mongo•  イベントログをMongoDBへ書き出す

– out_mongo_replset•  出力先のMongoDBでReplicaSetを使用する場合はこちらを利用する

– out_webhdfs•  イベントログをHDFSへ書き出す

– …

Outputプラグインによって、イベントログの書き出し又は送信を行います。

多彩なコミュニティ製

プラグイン

コミュニティでは、様々な開発者がプラグインを開発・公開しています。膨大な中から、ピックアップしてみました。

•  flowcounter –  一定期間中に流れるイベントログの数とデータ量をカウントする

•  dstat –  dstat用Inputプラグイン

•  ping-‐message –  fluentdプロセスをpingで死活監視する

•  munin –  munin-‐nodeのメトリックデータを取得するInputプラグイン

•  map –  あるイベントログを異なるイベントログに変換する

•  noTfier –  イベントログのマッチングとアラートメッセージの送信を行う

•  sampling-‐filter –  イベントログからサンプリングを行う

•  mysql –  JSONのままMySQLにINSERTを行う

•  amplifier-‐filter–  イベントログ中の数値の加減を行う

•  flaOen–  ネストされたkey/valueをフラットにする

•  tail-‐asis –  パーサを使わずに行全体をイベントログに格納する

•  cassandra –  Cassandra用Outputプラグイン

•  mysqlslowquery –  MySQLのスロークエリログ用Inputプラグイン

•  twiOer –  TwiOer Streaming API用Input/Outputプラグイン

•  zabbix –  Zabbix用Outputプラグイン

•  mail –  イベントログをメールに出力する

•  amqp –  AMQP用Input/Outputプラグイン

•  serialport –  シリアルポート用Inputプラグイン

•  extract_query_params –  URLのクエリパラメータからkey/valueを取り出す

•  Tme_parser –  時刻パラメタ用パーサ

•  irc –  IRC用Outputプラグイン

•  dbi –  DBとの接続にRubyのDBIモジュールを使うOutputプラグイン

•  tagfile –  イベントタグを利用してソースのホスト毎に異なるディレクトリへイベントログをファイル

出力するOutputプラグイン

•  hostname –  ホスト名をイベントログに挿入する

•  df –  dfコマンド用Inputプラグイン

•  jvmwatcher –  Java VMの情報を収集するInputプラグイン

•  websocket –  websocketサーバとして機能し、JSON文字列又はMessagePackバイナリを、接続された

全てのクライアントにブロードキャストするOutputプラグイン。

•  resolv –  IPアドレスの名前解決をして上書きをする

Fluentd プラグインの

開発

プラグインの開発も簡単にできるようになっています。詳しく見てみましょう。

•  カスタムプラグインのインストール

–  rubygemsで配布しない場合

•  /etc/fluent/plugin にスクリプトを配置する

–  rubygemsで配布する場合

•  lib/fluent/plugin に<TYPE>_<NAME>.rb の名前でインストールされるようにする

まず、開発したプラグインをFluentdに読み込むための方法です。RailsのようにCoC(設定よりも規約)なスタイルです。

•  Inputプラグインを書く

– Fluent::Input クラスを継承

– 規定のメソッドを実装

•  configure(conf) •  start •  shutdown

– イベントログを生成する

•  Fluent::Engine.emit(tag, Tme, record) –  tag: String –  Tme: UNIX Tme in integer –  record: Hash

Inputプラグインの開発の仕方です。クラスを継承して規定のメソッドを実装し、受け取ったログからFluentdのデータ構造に合わせたイベントログを生成するだけです。

•  Bufferd Outputプラグインを書く

– Fluent::BufferedOutput クラスを継承

– 規定のメソッドを実装•  configure(conf) •  start •  shutdown •  format(tag, Tme, record) •  write(chunk)

–  data = chunk.read –  print data

– オプション

Outputプラグインは3種類が開発可能です。大筋はInputプラグインと同様です。

•  Time Sliced Outputプラグインを書く

– Fluent::TimeSlicedOutput クラスを継承


•  configure(conf) •  start •  shutdown •  format(tag, Tme, record) •  write(chunk)

–  day = chunk.key –  data = chunk.read –  print data

例えば1日ごとに出力先ファイルを変更するようなOutputプラグインを書く場合、開発するのはTime Sliced Outputプラグインになります。

•  Non-‐bufferd Outputプラグインを書く

– Fluent::Output クラスを継承


•  configure(conf) •  start •  shutdown •  emit(tag, es, chain)

–  Fluentdがイベントを受け取ったらコールされる。

– 各イベントを処理するために、es.each イテレータを使用する。

BufferプラグインをスルーするようなOutputプラグインも作れます。

•  Tail Inputプラグインでパーサをカスタマイズする方法

– Fluent::TailInput クラスを継承

– メソッドをオーバーライド

•  configure_parser(conf) •  parse_line(line)

ファイルをtailして読み込むようなInputプラグインを作る場合は、TailInputクラスを拡張して簡単に書けるようになっています。

•  プラグインのデバッグ方法

– デバッグメッセージの表示

•  fluentd -‐vv で起動

•  match **ディレクティブにtype stdoutを指定

– out_copy でstoreディレクティブの一つにtype stdoutを指定

Rubyのpデバッグのような方法でデバッグする方法があります。また、out_copyを使用することで、デバッグ用のOutputプラグインにデータを流し込むことも可能です。

•  テストケースを書く

– Unitテスト・フレームワーク

•  Fluent::Test::InputTestDriver •  Fluent::Test::OutputTestDriver •  Fluent::Test::BufferedOutputTestDriver

Unitテスト用のクラスも用意されています。

作ってみた

TailInputを利用してGlusterFSの各ノードからログを収集するInputプラグインを書いてみました。ログコレクタ・フレームワークと言って良いくらい楽に作れます。

Class呼び出し時にセットしたいパラメタは、RubyのiniTalizeメソッド内で定義することも、独自のconfig_paramメソッドを使うこともできます。

parse_lineメソッドの引数にログが1行ずつ代入されているので、このメソッド内でパースしていきます。

TailInputでメインとなる作業は、parse_lineメソッドの拡張です。

最終的に、Fixnum型のunixTmeと、Hash型のレコードを、配列で返します。

簡単ですね。

まとめ

•  Big Dataを処理するには、前段階として「処理を前提とした収集」が必要。

•  ログコレクタの中で最も注目を集めているのがFluentd。

•  Fluentdはシンプルでプラガブル。柔軟でカスタマイズしやすい。デベロッパ・フレンドリー。

•  今まで個別に存在していたデータも、Fluentdで集約すればBig Data分析の対象になり得る。レッツトライ。

参考文献

1.  Christy PeOey, "Gartner Says Solving 'Big Data' Challenge Involves More Than Just Managing Volumes of Data" hOp://www.gartner.com/newsroom/id/1731916 (2013/06/30)

2.  2012 Big Data Now: 2012 EdiFon, O'Reilly Media, Inc. 3.  Noreen Burlingame & Lars Nielsen, 2012 A Simple IntroducFon To DATA SCIENCE, New Street

CommunicaTons, LLC 4.  三木大知 2013 『パターンでわかるHadoop MapReduce -‐ ビッグデータの処理入門』翔泳社

368pp 5.  John Gantz and David Reinsel, "ExtracTng Value from Chaos" hOp://www.emc.com/

collateral/analyst-‐reports/idc-‐extracTng-‐value-‐from-‐chaos-‐ar.pdf (2013/06/30) 6.  Pramod J. Sadalage, MarTn Fowler, 2012 NoSQL DisFlled -‐ A Brief Guide to the Emerging

World of Polyglot Persistence, Addison-‐Wesley Professional 7.  Guido Schmutz, 2012 Welcome NoSQL for Data Services, Data VirtualizaFon & Big

Data hOp://www.servicetechsymposium.com/dl/presentaTons/nosql_for_data_services_data_virtualizaTon_and_big_data.pdf (2013/06/30)

8.  Shashan Tiwari 2012『NoSQLプログラミング実践活用技法』翔泳社 432pp 9.  Publickey 「NoSQLの現状。これまでの成功と失敗」 hOp://www.publickey1.jp/blog/13/

nosql_2.html (2013/06/30) 10.  Pete Warden, 2011 Big Data Glossary -‐ A Guide to the New GeneraFon of Data Tools, O'Reilly

Media, Inc. 11.  Tom White, 2012 Hadoop: The DefiniFve Guide, 3rd EdiFon -‐ Storage and Analysis at Internet

Scale, O'Reilly Media, Inc. 12.  舘野祐一「fluentd を利用した大規模ウェブサービスのロギング」 hOp://

www.slideshare.net/hotchpotch/20120204fluent-‐logging (2013/06/30)

13.  TAGOMORI Satoshi, "Log analysis system with Hadoop in livedoor 2013 Winter" hOp://www.slideshare.net/tagomoris/log-‐analysis-‐with-‐hadoop-‐in-‐livedoor-‐2013 (2013/06/30)

14.  "Fluentd DocumentaFon" hOp://docs.fluentd.org/ (2013/06/29) 15.  @johtani 「Fluentd Meetup Japanに参加しました。」 hOp://johtani.jugem.jp/?eid=60

(2013/07/07) 16.  Sadayuki Furuhashi, "Fluentd meetup in Japan -‐ Fluentd, The Event Collector Service" hOp://

www.slideshare.net/treasure-‐data/fluentd-‐meetup-‐in-‐japan-‐11410514 (2013/06/29) 17.  Sadayuki Furuhashi, "Fluentd meetup #2 -‐ fluentd, Log everything in JSON" hOp://

www.slideshare.net/treasure-‐data/fluentd-‐meetup-‐2 (2013/06/29) 18.  Sadayuki Furuhashi, "Fluentd meetup #3 -‐ CollecFng app metrics in decentralized systems -‐

Decision making based on facts" hOp://www.slideshare.net/treasure-‐data/fluentd-‐meetup-‐3 (2013/06/29)

19.  Masahiro Nakagawa, "The basics of fluentd" hOp://www.slideshare.net/treasure-‐data/the-‐basics-‐of-‐fluentd (2013/06/29)

20.  "Fluentd plugins" hOp://fluentd.org/plugin/ (2013/06/29) 21.  "Treasure Data: Big Data as a Service" hOp://www.treasure-‐data.com/ (2013/06/30)

Thank you.

big data入門に見せかけたfluentd入門

Technology