Stream Processing Casual Talks 2 にいってきた & しゃべってきた
開催されたので参加してきた。
ついでにちょっと前に社内でのやりとりで思い付いてそのまま温めてたアイデアがあったので形にしてしゃべってみた。
しゃべってきた
社内でしゃべってたのは、ストリーム処理クエリって結局自分がもってるデータしか参照できなくて、じゃあ3年前のデータとJOINしたかったらクエリを3年走らせつづけないといけないの? 無理じゃね? みたいなあたり。過去データを参照したいケースは(特にビジネス要件のクエリで)普通に存在するいっぽう、現行のストリーム処理エンジンはクエリを開始した時点から受け取ったデータそのものしか参照できない*1
んで、いやよく考えたら過去データからストリーム処理クエリの計算中の状態を再現できれば、クエリ開始時に3年前からのデータをどこかからもってきて処理を起動できる、ストリーム処理系の脇にあるバッチ処理系を前提にしてこれができたらどんな過去データを扱うストリーム処理クエリも書き放題で、しかも好きなタイミングで再起動できるじゃん!!!! すげえ!!!! みたいなアイデアがある。SQLならできる。
これはいろいろ制約があって汎用の分散処理エンジンではなかなか難しかったりするのと、そもそもストリーム処理系とバッチ処理系で同じデータと同じ処理を前提に……これはラムダアーキテクチャというやつだ! ということでがーっとアイデアをまとめた。このアイデアの副産物として、同じ処理を内包する複数のストリーム処理クエリがオペレータ(とその内部状態)を共有できるというメリットもおまけについてきて、これが実現できればさらに基盤全体のスケーラビリティが上昇する。これはきた!!!!
まあ、分散処理版のNorikra(通称Perfect Norikra)はまだ1バイトも存在しないんだけど。スライド最後にちょっと書いたが、実は名前は既に決まっている。英語で普通の単語に聞こえ、かつユニークネスがある程度ありそうな単語を探すのは骨なので、プロダクト名が既にあるということはプロダクトを書き始めるまでの最大の問題が解決しているということだ。すばらしい。
いってきた
NiFiねー、とか、Hortonworks Streaming Analytics ManagerはUIよくできてんなー、とか。しかし全体としては面白技術という感じでもなくなって、みんな細かい改善がんばってんなあ、という気分。Apache Beamに乗るのはこれだから嫌なんだという感じがする。
ともあれ最近リサーチもサボってるので界隈の話題をひとさらいできてよかった。
*1:もちろんコードを何でも書ける処理エンジンであれば独自に外部データを参照してそれとJOINすることはできる、が、それはストリーム処理クエリがサポートしているとは言えないと思う。何でも書けるコードの中で勝手にやっているだけで、つまりそれはクエリ処理エンジンが分散をよろしくやれる範囲の外ということ。
