FURUHASHI Sadayuki (frsyuki)
-
frsyuki FURUHASHI Sadayuki今日話したHadoop界隈ビッグネームな人たちは、全員 MessagePack を知っていたようで、驚かざるを得ないですね！？ 実は相当な知名度があると推測できたりしませんかね！？
-
frsyuki FURUHASHI SadayukiHBaseのschemaをDSLで設計するのがいい！なんて言い出したらだめス。OLAP処理をモデル化してDSLで宣言的に記述するようにしたところ、ランタイムの一部にHBaseが使えたという流れ。
-
frsyuki FURUHASHI SadayukiHBaseCon2012 終ったところ。名だたるビッグネームたちと話し込むなどした。disquss？というサービスがmsgpackを使っているらしいという非公式の噂が。
-
frsyuki FURUHASHI SadayukiAdobe's low latency OLAP engine is pretty interesting. They created a DSL that declare a data model. Key schema for HBase is defined by that
-
frsyuki FURUHASHI SadayukiI think. Twitter's Gizzard, DeNA's MySQL-master-ha and NHN' STS are the examples. https://github.com/twitter/gizzard http://t.co/YmPXezGL
-
frsyuki FURUHASHI SadayukiバッファプラグインのAPIを再考。あと emit のインタフェースを考える。Engine#emit と Output#emit と Buffer#emit の引数に src_id が必要か。省略されたら分岐なしと判断して、EventStream#chunk_id を引き継ぐか。
-
frsyuki FURUHASHI Sadayukiところで EXT3_LINK_MAX 32000 にハマったところ。1ディレクトリに作れるエントリ数の上限だから、例えば 1001, 1002, 1003 のようなディレクトリを作る代わりに、1/0001, 1/002, 1/003 のように１階層余分に掘れば回避できるのかな。
-
frsyuki FURUHASHI Sadayuki順序保証を入れなければ、データの分割は簡単なので、透過的なsharding機能を持つ分散データストアさえあれば、永続化だけがんばるのは非常にうまい案だと思う。再送はFluentd側持ちで、冪等性保証はプラグイン持ちなので、一貫性保証はルーズでも良い。
-
frsyuki FURUHASHI Sadayuki永続化にはRDBでも使えばいい。実装は buf_mysql のようなものを作れば済むので現実的。問題は、信頼性の高い永続化は性能がスケールしにくいという点。end-to-end の到達保証がある！と言う方が見栄えがする感。特にFlume界隈的に。
-
frsyuki FURUHASHI Sadayuki実は、案3：永続化のみ という手もあるなぁと思っているところ。到達検出と再送をプラグイン任せにする。永続化があれば end-to-end の到達保証は要らない。隣り合った2ノードの到達検出は単にackを返せば良いし、再送も永続化があれば実装は簡単。なので永続化だけやる。
-
-
frsyuki FURUHASHI Sadayuki案1：到達検出+再送+冪等性保証。データを受け取るときに少し工夫を入れて、冪等にする操作を入れる案。ただプラグインから先は面倒を見ようがないので、Fluentdのレイヤーで冪等性を保証するのはナンセンスだと思われる。なぜならどうせプラグインでも再実装しないといけないので。
-
frsyuki FURUHASHI Sadayuki先の通り分散システムにおける到達保証は確率の問題なので、1.到達検出 2.再送 3.永続化 4.冪等性 をそれぞれどこまでやるかは、スループットや実装の複雑さとのトレードオフで考える必要があって、そこで Fluentd ではどの辺りを落としどころにするかが問題なのだけども、
-
frsyuki FURUHASHI Sadayukiというのも、レプリケーションとデータの整合性を両立するのは、とても難しいので。で、色々な技術を見ていて最近思うには、MySQL の semi-sync replication のような手法が最も現実的なのではないかと。
-
frsyuki FURUHASHI Sadayukiこれらを組み合わせて、"これから到達する確率" を "事実上100%" するのが、分散システムにおける到達保証。で、何％より上なら事実上100%なのかは、場合によって違うという点を考慮するべきで、特に3つ目の永続化する仕組みの信頼性を議論する場合に。
-
-
frsyuki FURUHASHI Sadayuki一方で、既に到達したことを保証することはできる。これから到達する確率を上げるには、何回も試せば良いのだけども、つまり、分散システムにおいて到達保証というのは、次の要素からなる：到達したことを検出する仕組み、再送する仕組み、到達するまで再送できるようにデータを永続化する仕組み
-
frsyuki FURUHASHI Sadayuki一般的な話だけども、確実に到達することを保証することはできない。これから到達するかどうかは確率の問題で、それを上げることができるけど、保証はできない。
-
-
frsyuki FURUHASHI SadayukiMySQL、書き込もうとしたデータが長すぎて切れてしまう場合でも、エラーにならない？ 壊れたデータが書き込まれてしまって困る。エラーにするにはどうすればいいんだろう。
-
frsyuki FURUHASHI Sadayukiトゥギャりにはオチを付ける主義。 "Fluentd Casual Talks まとめ" http://togetter.com/li/305806 #fluentdcasual
-
frsyuki FURUHASHI Sadayukiトゥギャっときました。"Fluentd界隈の雰囲気をなんとなくつかめる Fluentd Casual Talks まとめ" #fluentdcasual http://togetter.com/li/305806
-
-
frsyuki FURUHASHI Sadayukiこれいいな。"FluentdとRedisではじめるカジュアルでリアルタイムなレコメンデーション" #fluentdcasual http://t.co/wuWVoKjN
-
