本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

2024年12月11日
GitHubでJark Wuにアクセス
Flussプロジェクトのクリエイター
大規模データ処理がオフラインからリアルタイム処理への移行により、業界は明確かつ著しい転換期を迎えています。この転換は、Eコマース、自動車ネットワーク、金融、およびその他の様々な分野で、リアルタイムデータアプリケーションが業務に不可欠なものとなることを可能にし、企業はリアルタイムな洞察を活用してビジネス影響を高め、意思決定を改善するためにより大きな価値を引き出せるようになりました。
大規模データ技術の進化は、ますます影響力を増し、コンピューティングアーキテクチャの風景を再構成しています。従来型のHiveベースのデータウェアハウスは、Lakehouseモデルから始まり、最近では中国市場で大いに普及し、欧州/米国市場にも拡大し始めたPaimonストリーミングLakehouseなどの現代的アーキテクチャに置き換えられています。これらのアーキテクチャ革新の中心的な駆動力は、データ処理の即時性を向上させる必要性です。データの新鮮性は、従来のT+1（翌日の準備）からT+1時間、そして現在はT+1分まで改善されています。しかし、ファイルシステムベースであるLakehouseアーキテクチャは、実際の上限として数分の遅延が内在しています。一方、検索や推薦システム、広告アトリビューション、異常検知など、多くの重要なユースケースは秒単位の遅延を要求しています。大規模データ技術は大幅に進化していますが、現代のリアルタイムユースケースに対応するための使いやすい、秒間スケールのストレージソリューションという明確なギャップが残っています。ほとんどのリアルタイムデータシナリオでは、Apache Kafkaがデファクトスタンダードの秒間スケールストレージソリューションとして登場しています。そのApache Flinkとの統合は、リアルタイムデータウェアハウス構築の主流アーキテクチャとなっています。しかし、広く採用されながらも、この組み合わせは真のリアルタイム分析を大規模に行う上で重要な課題を提起しています。 Kafkaによる大規模データ分析の限界は、現代のリアルタイムユースケースのニーズに応えるためのより強固な解決策の必要性を浮き彫りにしています。 [Kafkaがリアルタイム分析で不十分である理由](https://alibaba.github.io/fluss-docs/blog/why-fluss/#kafka-falls-short-in-real-time-analytics target=_blank)
[更新サポートのない](https://alibaba.github.io/fluss-docs/blog/why-fluss/#no-support-for-updates target=_blank)
Apache Kafkaに関する最初の大問題は、データウェアハウスにとって重要である更新機能のサポートがないことです。データウェアハウスにおいて、更新はデータを修正または訂正するために頻繁に必要となります。しかしながら、Kafkaが更新を処理できないため、同じ主キーを持つ重複したレコードが発生します。コンピューティングエンジンによって消費されると、この重複を解消するための高コストな重複除去プロセスが必要になり、計算とストレージコストが大幅に増加することがあります。この制限はパフォーマンスにのみ影響を与えるだけでなく、Kafkaに格納されたデータをダウンストリームのビジネスプロセスで再利用することも妨げられます。 [問い合わせ機能の不足](https://alibaba.github.io/fluss-docs/blog/why-fluss/#lack-of-querying-capabilities target=_blank)
Apache Kafkaの二つ目の主要な制限は、問い合わせ機能の不足に起因しており、特にデバッグが困難になることがあります。データウェアハウスにおいて、問い合わせはトラブルシューティングやアドホック分析を行うために不可欠であり、データのトレンドを理解するために不可欠です。残念ながら、Kafkaは黒箱のように振る舞い、追加のツールやレイヤーなしにはこれらの重要なタスクを遂行するのが難しいです。
この制限に対処するために、業界はそれぞれのトレードオフがある二つの主なアプローチを採用しています：
KafkaデータをOLAPシステムに同期する：これにより、OLAPシステムの機能を使ってデータを問い合わせることができます。しかし、このアプローチはアーキテクチャに追加の要素を導入し、複雑さとコストを増加させます。また、同期遅延によるデータの一貫性の問題のリスクもあります。Trinoを使用してKafkaを直接照会する：TrinoはKafkaを照会することができますが、それは完全スキャンに完全に依存しており、大規模な操作に対して非効率的です。たとえば、わずか1GBのKafkaデータに対する簡単な問い合わせでも最大1分かかるため、大規模なデータセットやリアルタイム要件に対しては実用的ではありません。これらの制限により、Kafkaは現代のデータウェアハウスワークフローでの効率的かつスケーラブルなデータ探索に不適切であることがわかります。 [データバックフィリングの困難さ](https://alibaba.github.io/fluss-docs/blog/why-fluss/#difficulty-with-data-backfilling target=_blank)

Apache Kafkaに関する三つ目の主要な問題は、データバックフィリングと呼ばれる歴史的なデータの処理です。これは、データウェアハウスでは一般的な要求です。例えば、物流では、数ヶ月前の歴史的データを処理と分析することがよくあります。しかし、Kafkaはストレージコストが高いため、データを僅か数日間保存するだけです。Kafkaコミュニティは、長期データの問題に対処するために、[階層化ストレージ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage target=_blank)を導入しましたが、まだ限界があります。歴史的データを読むためには、すべてのデータがKafkaブローカーを通過することが必要であり、ブローカーの不安定化や[ライブトラフィックへの中断](https://www.warpstream.com/blog/tiered-storage-wont-fix-kafka#increased-complexity-and-operational-burden target=_blank)のリスクを伴う可能性があります。これらの制限により、Kafkaは大規模かつ長期的な分析ユースケースにおけるデータバックフィリングのための効果的な解決策ではなく、リアルタイムデータウェアハウスに関してはさらに頑健な代替手段の必要性が浮き彫りになります。 [過剰なネットワークコスト](https://alibaba.github.io/fluss-docs/blog/why-fluss/#excessive-network-costs target=_blank)
Apache Kafkaに関する最後の主要な課題は、全体的な運用費の約88％を占める高いネットワークコストです。データウェアハウスでは、一度書き込み、複数回読み取りのパターンが一般的であり、各コンシューマーは通常必要なデータのサブセットのみを必要とします。しかし、Kafkaの設計により、コンシューマーは実際に必要な量に関係なく、全データを読み取ることが求められます。
例えば、アリババでは数千個のFlink SQLジョブがあり、各ジョブあたり平均してアップストリームのカラムのうち約49％しか使用されていません。にもかかわらず、コンシューマーはすべてのカラムを読み取り、100％のネットワークコストを支払う必要があります。これは非常に非効率的で無駄です。要約すると、Kafkaを使用したリアルタイム分析には、
操作システムでは、データベースとストリームストレージがどちらも主に行指向形式を使用しています。これは、トランザクションワークロードに対して行ストレージが効率的だからです。一方、Apache IcebergやSnowflakeなどの分析システムでは、列指向ストレージが優れたパフォーマンスを発揮するため、好まれます。興味深いことに、マトリックスの右上隅は空いているため、市場における大きなギャップを示しています：分析シナリオ向けのストリーミングストレージです。予想通り、このようなストレージはリアルタイム分析のニーズを効果的に満たすために列指向形式を採用する可能性が高いでしょう。

このギャップを埋め、Flinkとストリーミング分析における問題を解決するために、2年前からストリーミングストレージの開発に取りかかったところです。プロジェクト名はFLink Unified Streaming Storageであり、その頭文字から「Fluss」という名前が生まれました。

興味深いことに、「Flink」はドイツ語で「機敏な」という意味であり、「Fluss」はドイツ語で「川」を意味し、プロジェクトビジョンと深く共鳴します。それはストリーミングデータが絶え間なく流れ、データレイクに配信され、集まるのを象徴しています。川のように。FlussのローンチはFlinkの10周年にあわせ、ストリーミングデータの風景に対するプロジェクトの遺産と持続的な貢献への適切な賛辞となっています。

Flussに関する詳細情報は、次のブログ記事で学ぶことができます。そこで、Flussのアーキテクチャ、設計原則、主要機能についてより深く掘り下げ、リアルタイム分析でKafkaを使用する際の課題に対する取り組みについて探求します。