by Chris Joynt
この記事は、2023/10/17 に公開された「5 Key Takeaways from #Current2023」の翻訳です。
9月26日と27日にサンノゼで、Current 2023 (旧Kafkaサミット) が開催されました。ストリーミング開発に特化したコンテンツをまとめたカンファレンスがほとんどない中、Current は昔から、ストリーミング分野で何が起きているのかを把握しようとする人にとって重要なイベントとなっています。2,000人を超える参加者が集まり、多くの新しいソリューションが紹介されたこのイベントは、ストリーミングの現状とその方向性を明確に示すものでした。本ブログでは、カンファレンスに参加できなかった方向けに概要をまとめ、Current 2023 の主なポイントおよび Cloudera の見解をご紹介したいと思います。
Current 2023で学んだ5つのポイント
1：Apache Flink はストリーム処理の事実上の標準となるという声が上がっている。
すでに Flink に精通している多くの人にとっては当たり前のことかもしれませんが、指摘する価値のあることとして次のことがあります。アーキテクチャを選ぶことは長期的な影響を及ぼします。そのために、ストリーム処理エンジンを選択する際は、その技術がこれから先停滞してしまうのか、それともオープンソースコミュニティの貢献によって進化し続けるのかを、考慮することは重要です。今から、3年後に Flink の開発者を見つけられるでしょうか？コミュニティの答えは「イエス」です。つまりFlink が今後も続いていくことを意味します。
Apache Flink が標準として台頭してきたのは当然のことでしょう。Flink は、世界初のオープンソースによるストリーミングファーストの分散ストリーム処理エンジンとして2015年に発表され、以来 Spark に匹敵するほどの人気を博しています。低レベルの操作から高レベルの抽象化まで、API が階層化されているため、Flink は幅広いユーザーが活用できます。Flink の採用は、ストリーミングデータ量の増加とストリーミング市場の成熟を反映しています。企業が Kafka によるデータドリブン型アプリケーションの最新化から、リアルタイムの洞察の提供やスマートな自動化システムの強化へとシフトする中、Flink は強みとなります。
Current で注目を集めた Flink を、Cloudera を含む多くのベンダーはストリーム処理製品のエンジンとして使用しています。不正行為の監視、リアルタイムのサプライチェーン洞察、IoT を活用した車両運行、リアルタイムのお客様の意向の調査、分析パイプラインの最新化などのユースケースが、開発活動の原動力となっています。技術的な経費を最小限に抑え、技術革新のスピードを維持するために、異なる処理フレームワークを単一の包括的なフレームワークに統合することの価値は、すでに理解されているかと思います。
イベントで行われた大きな発表は、Confluent Cloud における Apache Flink のお披露目でした。実際には、SQL コンソールに多くの不満が残り、サーバーレスの自動スケーリング機能以外には、びっくりする要素がなかったため、少し物足りないものでした。この記事を書いている時点では、この製品はまだ一般提供はされず、オンプレミスで提供される予定もありませんが、Confluent のユーザーベースが非常に大きいため、このお披露目はやはり重要だったと言えます。Flink はストリーミングの未来なのです。
Cloudera の視点：Cloudera は、お客様がストリーム経由で移動するデータ量が増加していることに早くから気づいていました。コスト上昇や、要求の厳しい関係者にリアルタイムの洞察を提供するのに苦労されている点です。そこで私たちは 2020 年に Flink に大きく賭け、それを企業向けに導入するためのツールの開発を開始しました。そして、銀行、通信、製造、IT のお客様に、成熟した Flink 製品を使用していただきました。kSQLdb、Spark Structured Streaming、そして Flink がもたらす真にオープンで分散されたステートフルなストリーム処理能力に及ばない、他のプロプライエタリなアプローチは、おそらく減速するでしょう。
2：「ストリーミングデータベース」という新カテゴリーの競合が出現している。
Flink に代わるストリーム処理用データベースとして、ストリーミングデータベースを位置づけているベンダーがあります。ストリーミングデータベースは、インメモリ処理とステート管理により、Flink よりも本質的に高速であるというのが、その価値提案のコア部分にあります。たしかにそれは、理論的には理に適っていますが、どれだけ速くなるかについては、かなり乱暴な主張があり、業界に独立したベンチマークもないため、懐疑的な見方が必要です。しかし、その技術は興味深く「何でもできる」DB ツールの魅力は大きいと言えます。
Cloudera の視点：ストリーミングアーキテクチャにリアルタイム処理機能を導入することで、取り込める価値は大きなものがあります。Kafka 中心のアプローチには多くの改善点が残されており、最も顕著なのは操作の複雑さとバッチデータの統合の難しさがあります。リアルタイムデータベースは、ストリーミングエコシステムのなかでその役割を果たしていますが、Flink のようなスケーラビリティの高いエンジンがデータを処理した後に、結果セットを公開し、広く利用可能にすることがその役割です。Cloudera は、API 経由でアクセス可能なマテリアライズドビューを介してこれを行います。ストリーミングデータベースについては、次のような疑問が出てくることでしょう。接続性とデータ分配はすでに解決されているのに、なぜまた解決する必要があるのか？ストリーミングデータはデータベース内でどのくらいの期間保存され、期限切れになるとどうなるのか？これはまた別のデータベースなのか？データのロックインについてはどうか？相互依存性の高い機能では、ビジネスやデータの要件が変化したときに修正を加えるのは難しいのではないか？
非常に興味深い技術ですが、まだ新しいため「様子をみるべき」というのがアドバイスとしては賢明かもしれません。
3: チェンジデータキャプチャは注目の的であり、Debezium はこの分野における事実上の基準である。
CDC 全般と Debezium に関して参加者からの質問が多かったことから判断すると、Debezium は CDC にとって、ストリーム処理における Flink のような存在になっていると言えます。Flink と同様に、Debezium はオープンソースの分散サービスで、ストリーミングの価値を拡張し、新しいユースケースを獲得するために Kafka と共に頻繁に使用されています。Debezium は、一般的なデータベースの変更ログを継続的に読み取り、Kafka トピックにパブリッシュすることで、レガシーなバッチシステムをデータストリームに効果的に変換します。
もちろん、Debezium にはリソース管理やスキーマの進化といった複雑な問題もありますが、一方で多くの価値があります。
Cloudera の視点：データの鮮度は重要です。鮮度の高いデータが良い結果をもたらすことは当然で、逆のパターンの事例は思いつきません。変更データキャプチャは、ストリーミングエコシステムの重要な部分です。Cloudera では、Kconnect と Flink 用の Debezium コネクタをサポートし、NiFi プロセッサも近々リリースする予定です。それによってユーザーの皆様は、データ配信をきめ細かく制御できるようになります。
4：Kafka エコシステムのツールは改善されている。
Kafka のデプロイが非常に複雑であることは既に知られているとおりです。クラスタのセットアップ、ブローカー/パーティション/トピックの監視と管理、メッセージの順序の処理、一度だけの保証、スキーマの進化、セキュリティなど、これらはすべて運用の経費になります。データの系譜とデバッグはかなり大変です。ストリーミングスペースが成熟度を増すにつれて、目立つようになったのが、このスペースにおけるツールの改善です。Confluent のデータポータルの将来ビジョンは、発見可能性とガバナンスに関する、より良いツールとよりスムーズなユーザー体験を提供するための努力の好例です。多くのベンダーが、観測可能性を実現し、パフォーマンスを向上させるための拡張ツールを提供しており、また MQTT や Pulsar といった他のフレームワークを統合することでエコシステムを拡張しています。
Cloudera の視点：Cloudera は2015年に Kafka エコシステムのサポートとツールの構築を開始し、安定したエンタープライズソリューションを開発してきました。Streams Messaging Manager ツールは、Cloudera Streams Processing の無料コミュニティ版に含まれています。さらに、Cloudera SDXは、ストリーミングを含むデータライフサイクル全体にわたって、統合されたセキュリティおよびガバナンスツールをご提供します。Kafka プラットフォームが Zookeeper から Kraft に移行したことは、Kafka の運用を管理する者にとって大きな安心材料となりました。Kraft はすでに次のリリースのための技術プレビューの段階にあります。
このような理由もあり、IBM は Cloudera を戦略的 Kafka パートナーとして選択し、コスト効率に優れたスケーラブルなソリューションをお客様に提供しています。
5：ストリーミング分野にはまだ成長と成熟の余地がある。
ストリーミング技術の採用は着実に増加していますが、平均的なストリーミング成熟度はまだ初期段階にあります。ストリーミングの成熟とは、単に多くのデータをストリーミングすることではなく、ストリーミングデータをより深く業務に織り込み、企業全体でリアルタイムの活用を促進することです。一つの Kafka トピックがサポートするユースケースの数は、1秒あたりのイベントのような生のボリューム指標よりも良い指標です。ただ、Kafka トピックのほとんどに複数のユースケースを持っているユーザーはほとんどいませんでした。ストリーミングの成熟度を測るもう一つの特徴は、リソースの利用や、新しいユースケースの開発や変更のしやすさという点で、システム全体が効率的であるかということです。リアルタイム処理はストリームのデータ量を大幅に減らすことができ、それは良いことです。データストリーマーの大半は、この実験を始めたばかりです。
ストリーミングデータの影響力の拡大について焦点を当てた講演もありました。イベントストリームに対するリアルタイムの異常検知やその他の時系列処理、リアルタイムMLパイプラインのための Python の運用が話題として取り上げられました。また、例えば Apache Pinot と統合することで Kafka の負荷を軽減する方法など、全体的な効率性に焦点を当てた講演もありました。(このトピックに関するニューヨークのミートアップへのリンクは下記)。そんな中で、生成 AI に特化したコンテンツはかなり少なく、2023年に業界全体が注目している分野であることを考えると、これは少し意外なことでした。ストリーミングデータは、基礎モデルの微調整、プロンプトの最適化、出力のコンテキスト化と補強など、生成 AI で果たすべき役割は非常に大きいです。この話題については、また改めてお話しできればと思います。
Cloudera の視点：データストリームは、より広範なデータライフサイクルの一部です。Kafka ですべてを実施することはできません。Kafka は、アプリケーション統合のためのリアルタイムバスとして、また分析ワークフローのためのメッセージバッファとして利用されるときに力を発揮します。しかし、そのようなコア的な能力以上に引き伸ばすと、過度に複雑になり、技術的な経費が嵩みます。だからこそ、ストリーミングに対する完全なアプローチが必要になってきます。効率的でスケーラブルなストリーミングアーキテクチャは、シンプルでありながら、継続的な反復開発サイクルに対応するツールを完備していなければなりません。これには、データ配信 (別名ユニバーサルデータ配信）、エッジ・データ・キャプチャ、ストリームフィルタリング、アナリストがアクセス可能な独自に変更可能なストリーム処理、低コストでアクセス可能なストレージのための保存データとの統合に対する、ファーストクラスのサポートが含まれます。最後に、プロンプトや埋め込みを含む多構造化データのリアルタイム処理と移動は、AI の変革力を活用するために不可欠です。
Cloudera Stream Processing Community Editionをダウンロード (無料) すれば、1時間以内に Flink を使いこなすことができます。当社の SQL Stream Builder コンソールは、他にはない最も完全なコンソールです。
Cloudera の NiFi ベースの DataFlow の無料トライアルに登録し、ストリームフィルタリングやクラウドデータウェアハウスの取り込みなどのユースケースを、ご覧ください。
Cloudera と Apache Pinot をベースとする Startree の共催のミートアップ (私とディベロッパーのTim Spannが参加) をニューヨークで開催し、生成 AI についてなど最新情報をお届けしています。
