TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます． Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります． Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えて

Fluentd，最近だと海外でも露出が増えてきていて，軽量・柔軟・ロバストという所で， 新規の他，既存のログコレクタのリプレース含め，採用する所が増えてたりします． より改善するため色々とユーザにヒアリングした結果，「フィルタ機能が欲しい」というのが一番多い意見でした． Fluentdは元々Treasure Dataへロバストにデータを転送するためのミドルウェアで，「ETLとかはTreasure Dataで」 というのもあり，組み込みでフィルタ機能はありませんでした． 今現在のOutputプラグインによるフィルタ実装は，タグの書き換えが必要だったりして少し慣れが必要で，初心者にはちと難しい． ということで，より簡単に効率よくデータストリームを扱えるフィルタ機能を入れることにしました！ 前置きが長くなりましたが，次のバージョンであるv0.12ではFilterとLabelの導入が目玉機能になり

「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末

Twitterで「早く今流行のMPPの大まかな使い方の違い書けよ！」というプレッシャーが半端ないのでてきとうに書きます．この記事は俺の経験と勉強会などでユーザから聞いた話をもとに書いているので，すべてが俺の経験ではありません(特にBigQuery)．各社のSAの人とかに聞けば，もっと良いアプローチとか詳細を教えてくれるかもしれません． オンプレミスの商用MPPは使ったことないのでノーコメントです． MPP on HadoopでPrestoがメインなのは今一番使っているからで，Impalaなど他のMPP on Hadoop的なものも似たような感じかなと思っています． もちろん実装の違いなどがあるので，その辺は適宜自分で補間してください． 前提 アプリケーションを開発していて，そのための解析基盤を一から作る． 簡単なまとめ データを貯める所が作れるのであれば，そこに直接クエリを投げられるPre

Presto ソースコードリーディング #4 いつものようにLINEでやりました！ @frsyukiが帰国する前に，という流れで開催決定・募集が1週間前というタイトなスケジュールでしたが， 無茶ぶりにつきあってくれた@ueshinさんに感謝． 当日の内容 togetterのまとめを見れば，なんとなく大まかな流れは把握できるはず…！ ueshinさんが第二回のashigeruさんの論理計画実行の後を継いで， 物理計画実行周りの話をしてくれました(資料のgist)． バイトコード生成しての高速化の話とか，Presto以外でも有用な話が出てました． frsyukiが現在のPrestoの開発体制の話，Treasure Dataでハックしている所の紹介， CREATE VIEWなどの実装がなぜこうなっているのか(これはfrsyuki案が通ったらしい)， 今後Prestoチームがやろうとしていることな

今回の発表は，今までのv11やv1に関してのまとめ的な発表になっています． 以下のリンク集を見れば，発表内容の大抵はカバー出来ると思います． また，他の方もまとめ記事とかを書かれているので，そちらも参照してください． そろそろFluentd v11についてひとこと言っておくか Plan for v1 release #251 Support JRuby #317 FluentdのWindowsブランチ Add –use-v1-config option to enable new configuration format #293 td-agent2のパッケージリポジトリ 俺の方から言えることは，Fluentd v0.10.46以降を使っている方は， 積極的に--use-v1-configオプションを使ってくださいということです． 既存のフォーマットとの違いはドキュメントを参照してください

リリースは永遠にされません！ 日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！ 以下まじめな話になります． v11が生まれた背景と現状 v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました． しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました． 当たり前ですが，ユーザからの

Presto ソースコードリーディング #1のATND @tagomorisさんに場所を確保してもらって，LINEで第一回をやりました． 開催の流れ CROSS辺りでPrestoのソースコードリーディングしたいね，という話が出て， じゃあ俺が立てるので場所はLINE辺りで〜というその場のノリで決まった． どうせ10人前後だろうということでかなり適当な感じで募集とかやってたんだけど， 応募人数が40人越え，当日参加が25人前後くらいだったので，予想より多かったかなという感じ． やったこと 全体の概要 俺が軽めにやりました．Prestoの生まれた背景とか，依存している主要なライブラリ， @frsyukiのスライドを拝借しての主要なクラス群の紹介，現在サポートしている型， Slice使ってのデータの持ち方とか．後，最近の変更周りも少し紹介した HTTPレイヤー @tagomorisさんが担当で，