Amazon Athena — Serverless Interactive Query Service - AWS Prestoのフォースを感じたので，知り合いが試した情報も含めて，今思っている所を書いてみる． 実装 Athenaのページにあるように，実行エンジンは独自実装ではなくて，Facebookが公開しているPrestoを使っている．FacebookのみならずTreasure Data，Airbnb，Netflixなどクエリがガンガン飛ぶ環境で元気に動いている実績もあるので，拡張性，パフォーマンス，安定性で選ばれたのだろうと思われる．あとAWS的にJavaの方が相性は良さそう． パフォーマンス いくつかの記事で言及されている． Analyzing Data in S3 using Amazon Athena Amazon AthenaをBigQueryと比較してみた Amazon

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

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