ConfluentがApache Kafka用分散ストリーミングSQLエンジンのKSQLをリリース

ConfluentがリリースしたKSQLは、Apache Kafkaのインタラクティブな分散ストリーミングエンジンだ。Apache Kafka内のトピックに対する集約やジョイン、ウィンドウニング、セッション化といったストリーミング処理操作を簡単にする。このオープンソースのストリーミングSQLエンジンは、先日サンフランシスコで開催されたKafka Summitカンファレンスで発表された。

KSQLを使用することで開発者は、SQL風の構文でストリーミングデータの読み書きや処理を行なうことができるようになる。2つ以上のデータストリームを比較して異常を検出し、リアルタイムで対応する処理などがストリーム処理のサンプルとして提供されている。他の分散ストリーミングやSQLフレームワークとは異なり、KSQLは、イベント単位の逐次処理(event-at-a-time)をApache Kafkaで提供する。これまでKafkaのデータストリーム処理には、JavaやPythonによるプログラミングが必要だった。

Confuentの共同設立者でCTOのNaha Narkhede氏が、KSQLフレームワークの機能に加えて、異常検出や監視やストリーミングETLといった適用可能なユースケースについて記事を書いている。

内部的には、KSQLはKafkaのStreams APIを使ってトピックを操作する。KSQLにはStreamとTableという２つの中心的な抽象化があるが、これらはまた、APIの中心的な抽象化でもある。

ストリーム: ストリームはストリーミングアプリケーションで最も重要な、第１級の構成要素である。ストリームは変更不能な構造化データ(“ファクト”)の無制限なシーケンス(ストリームに新しいファクトを挿入することは可能だが、既存のファクトを更新あるいは削除することはできない)で、Kafkaのトピック、あるいは既存のストリームおよびテーブルから生成することができる。

テーブル: KafkaのテーブルはSTREAMあるいは他のTABLEのビューであり、変化するファクトのコレクションとしての意味を持つ。従来のデータベースにおけるテーブルと同じだが、新たなイベントが到着する度に継続的に更新されることと、ウィンドウニングなどのストリーミングセマンティクスがサポートされている点が異なる。テーブル内のファクタは変更不能である。すなわち、テーブルへの挿入は可能だが、既存ファクトの更新や削除はできない。テーブルはKafkaのトピック、あるいは既存のストリームやテーブルから生成することができる。

Apache Kafkaのトピックは、そのトピックの処理において意図するセマンティクス次第で、ストリームあるいはテーブルのいずれでも表現することができる。

以下の図は、システムに入力される２つのデータストリームに対して、KSQLがどのように動作するかを示したものだ。

InfoQはNarkhede氏に、KSQLの発表について話を聞いた。その中で氏は、ストリームデータに対してクエリを実行するSQLインターフェースを開発した動機について話してくれた。

KSQLは、Kafkaによるストリーミングファースト(streaming-first)のデータアーキテクチャという同社のビジョンにおいて、非常に重要な部分である。 ストリーミングファーストの世界において、KafkaとKSQLは、それまでリアルタイムでは不可能か、非常に複雑な処理を必要としていた機能を提供する。Kafkaログはストリーミングデータの中核的なストレージ抽象化である。これにより、オフラインのデータウェアハウスに入力されるものと同じデータを、ストリーム処理で使用することが可能になる。その他はすべて、KSQLを使用してログ上に生成したストリーミングマテリアライズドビューで、企業内のさまざまなデータベースや検索インデックス、その他のデータサービスシステムとなる。これら派生ビューを生成する上で必要なデータエンリッチメントとETLが、KSQLを使用してストリーミング形式で実行できるようになる。

InfoQ: クラスタリングやフェールオーバに関してKSQLがどのように動作するのか、技術的な詳細を説明して頂けますか？

Neha Narkhede: クエリを実行するKSQLサーバプロセスのセットがあって、クラスタとして動作します。KSQLサーバのインスタンスを起動することで、処理能力をダイナミックに追加できます。これらのインスタンスがフォールトトレラントなのです – ひとつがフェールすれば、他がその処理を引き継ぎます。インタラクティブなKSQLコマンドラインを使用してローンチされたクエリは、コマンドとして、REST API経由でそのクラスタに送られます。コマンドラインでは有効なストリームやテーブルを調べたり、新たなクエリを発行したり、実行中のクエリの状態チェックや停止が可能です。KSQLは、内部的にはKafkaのStreams APIを使って構築されます – これにより、エラスティックなスケーラビリティ、高度な状態管理、フォールトトレランスを引き継ぐとともに、Kafkaが先頃導入した正確に1回の処理セマンティクスをサポートしています。KSQLサーバではこれを組込むとともに、その上に分散SQLエンジン(クエリパフォーマンスのための自動バイトコード生成など、いくつかのトリックがある)と、クエリおよび管理用のREST APIを構築しています。

InfoQ: Kafka APIを使用してストリームデータにアクセスするような他のソリューションと比較した時、KSQLクエリを使用する場合、パフォーマンス面で考慮すべき事はありますか？

Narkhede: KSQLはKafkaのStream APIを使用して構築されていて、Kafkaと密接に結び付いています。Apache Kafkaのコアファンダメンタルと緊密に統合することで、非ネイティブなストリームデータ処理を行なった場合に必要となるような、データ移動やシリアライゼーションといった余分なレイヤを不要にしているのです。これによって、Kafkaトピックのデータストリーム処理にKSQLを使用する場合のオーバーヘッドは、比較的低くなっています。ただしKSQLはまだ開発者向けプレビュー版なので、パフォーマンスベンチマークといったものはありません。開発者プレビューでは、Kafkaコミュニティと連携して、KSQLのユーザエクスペリエンスが傑出したものであることの確認を目標にしています。今後数ヶ月は、パフォーマンス向上やテスト、運用上の安定化に注力する予定です。

InfoQ: データストリームのクエリの標準を提供するという点から、KSQLは、将来的にどのような役割を果たすと思いますか？

Narkhede: 私たちがKafkaを開発していた頃、メッセージングの標準はJMSでした。ログパラダイムに基づいたKafkaのシンプルなAPIは、業界でも初めてだったのです。今日Kafkaはメッセージングだけでなく、リアルタイムデータ管理でも標準になっています。 それが可能となった理由は、ユーザエクスペリエンスがシンプルなことと、大規模ストリーミングデータという新たな問題領域に広範に適用可能なことにあります。同じようにKSQLは、SQL標準に手を加えてストリーム処理に適応させた、SQLライクなインターフェースを提供します。その目的は、Streaming ETLやモニタリング、異常検出、分析といった現実世界でのユースケースに対して、ストリーム処理の持つ潜在能力のすべてを利用するために、ファーストクラスの抽象化としてストリームとテーブルをサポートすることにあります。KSQLがストリーム処理で実現するシンプルさと操作の容易さは、ストリームデータクエリの新たな標準にも影響を与える力になるでしょう。

InfoQ: Kafkaのロードマップと、読者が興味を持つであろう今後の機能について話して頂けますか？

Narkhede: KSQLを開発者プレビューとしてリリースしたのは、コミュニティの構築とフィードバックの収集を行なうためです。集約関数の拡張や、あるいはストリームデータに対する計算結果を継続的に取得する現行の機能に加えて、計算結果のクイック参照を可能にすることで継続的テーブルに対するポイント・イン・タイムなSELECTを実現するなどの方法によって、KSQLを品質、安定性、運用性の面で実用的なシステムとするために、オープンソースコミュニティと協力して機能を追加していきたいと思っています。

KSQLは現在、Apache 2.0ライセンスモデル下で開発者向けプレビューが公開中で、今後数ヶ月内には正式版がリリースされる予定である。

ツールについて詳しく知りたいのであれば、クイックスタートとKSQL Dockerイメージを確認するとよいだろう。コミュニティに参加したい向きには、KSQL Community Stack Channelが用意されている。その他のリソースとしては、リアルタイム監視や異常監視、警告などの目的でKSQLを使用する方法について解説したスクリーンビデオもある。