ストリーム処理とLamdaアーキテクチャへの挑戦

LinkedInでストリームインフラに関する業務を行うKarik Paramasivam氏は夏の間に2つの記事を執筆し、彼の会社がデータ処理のためにApache Samzaを使用してLambdaアーキテクチャを避けようと試みた理由と方法を明らかにした。

ストリーム処理技術はデータのストリームから素早く結果を得られるようになる場合はとても有用であるが、高い一貫性と強固な要件を持つユースケースが要求される場合はこれを満たせないかもしれない。

Lambdaアーキテクチャはバッチとストリーム処理を結合した有名なソリューションとなった。基礎となる概念は二つのデータレーンを持つことである。ストリーム処理技術を用いた低遅延で結果を提供するためのスピード層と、バルクデータに対して正確な結果を提供するジョブを実行するためのバッチ層である。Lambdaアーキテクチャは複数の技術に依存し、双方のデータレーンからの結果をマージする必要があることを示唆しており、実装が複雑である。

LinkedInでは、Apache Kafkaから流れるデータの処理を実行するためにSamzaが用いられている。記事に記されている問題の一つはイベントの遅延到着である。RocksDBベースのキーバリューストアがSamzaに追加され、より長い時間入力イベントを保持するようになった。遅延到着時にはローカルで再計算するための十分な情報があるという仮定で、フレームワークが影響を受ける全てのウィンドウベースの計算結果を再送出する。RocksDBベースのソリューションは、(例えばNoSQLのような)外部ストアに依存することで通信やシリアライズのためにネットワークとCPUのオーバーヘッドを発生させるのに対し、より好ましい特性を持つことがわかった。

Apache Flinkはまた別のストリーム処理フレームワークである。タイムスタンプに基づいた時間ウィンドウ (イベント固有、もしくはタイムスタンプに基づいたもの)越しに計算を行う能力があり、順序がばらばらなストリームでも一貫性した結果を提供する。データはメモリに記憶され、ウォーターマークイベントの受信に対応してウィンドウ計算を発動させる。ウォーターマークはクロック単位を表現し、Flinkに時間の通知を行う(これはイベント固有のものでもありうる)。

最低1回の配信保証に起因する 複製メッセージ処理のような他の問題は、大部分のフレームワークで内部チェックポイント機構により対処されている。

ストリーム処理の問題の最後のものはシステムを通過する間のデータに対してインタラクティブなやり方で実験を行う能力である。素早い実験は通常バッチシステムでSQLのような高レベルの言語を用いて行われ、Azure Stream Analyticsのような商用製品で行うことができる。

Samza SQLはSamzaのストリームプロセッサにApache Calciteを適用した成果であるとJulian Hyde氏によって説明されている。Samza SQLはまだ製品に使用できる段階ではない。代わりに、LinkedInはHadoopのバッチ形式を用いてオフラインのデータのセットに繰り返し実験を行っており、このデータセットはストリームを制御する際にSamzaベースのストリームプロセッサがクエリした本物のサービスデータベースと同じものからコピーされている。

Flinkは強固なストリームSQLのサポートに対して作業を行なっている。2016年8月にリリースされたFlinkのバージョン1.1はフィルタとストリームデータのユニオンをサポートしている。また、イベントのシーケンスへの対応方法に関する高レベルの記述方法として複雑なイベント処理もサポートしている。