Redpanda × Databricks で実現する リアルタイムなオープンレイクハウス

すべてのレイクハウスは “ストリームで育つ”べきだ。

Databricksが数年前に開始した「オープンレイクハウス」の概念は、最近のApache Iceberg™の台頭により、フレームワークの統合、ツールのサポート、カタログのサポート、データの相互運用性への主要ベンダーの投資により、より広く実現されています。これは、オープンレイクハウスの共通の基盤としてIcebergにコミットすることを意味します。 公開する能力などの進歩は、UniFormを通じてDelta Lakeテーブルを拡大するIcebergエコシステムに、Unity Catalogの予測最適化やIceberg RESTの高度な機能のサポート、Managed Icebergテーブル、そして最近のDelta/Icebergデータレイヤーの統一により、組織は今、「Icebergフォワード」のデータ戦略を自信を持って採用することができ、Databricksのような成熟したレイクハウス製品の豊富な機能セットの使用を妨げることなく、Iceberg V3すべてが可能になりました。

この物語で欠けていた主要なプレーヤーの一つは、Icebergの共通語を通じてクラウド上のデータに普遍的にアクセスするためのストリーム、つまりKafkaトピックです。今日では、任意の構造化データは、Icebergとして簡単に着陸させるか、「装飾」することができます。それに対して、リアルタイムアプリを動かすストリーミングプラットフォームを通じて流れる高価値データは、ポイントツーポイントのストリームごとのデータ統合ジョブを通じて、または高価なコネクタインフラストラクチャを独自のクラスタ上で実行することにより、ターゲットのレイクハウスに「ETL」される必要があります。どちらのアプローチも、リアルタイムデータ配信パイプラインにプレッシャーをかけ、特殊なKafkaスキルでスケール、管理、観察する中間インフラストラクチャコンポーネントを作成します。どちらのアプローチも、リアルタイムと分析データエステートの間に非常に高価な通行料を挿入することを意味し、それは本当に存在する必要はありません。

クラウドオブジェクトストアのストリームバックアップ用途が成熟し（数年前にRedpandaがその先駆けとなりました）、オープンテーブルフォーマットがレイクハウスの中心舞台を占めるようになると、このストリームからテーブルへの結婚は便利であり、「運命的」でした。DatabricksとRedpandaは、このアプローチを鮮やかに輝かせ、注目を集める2つの世界クラスのデータプラットフォームを提供します。一緒になると、リアルタイムの意思決定、分析、AIをカバーするデータ基盤が作成され、これを上回るものはありません。実際には、このアプローチは、設定フラグの簡単さでストリームとテーブルを統合します。それは多室ダムのように機能し、選択可能なストリームを要求に応じて統一されたデータレイクにルーティングし、最新の洞察を提供し、レイクハウスアーキテクチャがテーブルに与えた新しい分析パイプライン内のデータの任意の含有を解放し、そして今、Icebergエコシステムが提供する拡大された開口部を通じて。

リアルタイムと分析データインフラストラクチャをシームレスに融合させて「ストリーム給養レイクハウス」をワンボタンで実現することは、大きな価値を解放するだけでなく、一般的なケースで適切に対処するためには思慮深いアプローチが求められる難しいエンジニアリング問題を解決します。以下で説明するように、私たちはこの機能を市場に急いで投入するために手を抜くことはありませんでした。1年以上にわたり数十のデザインパートナー（およびDatabricks）と共同で、Redpandaの単一のコードベースを拡張し、お客様が好むデプロイメントオプション（複数のクラウド上のBYOCを含む）を維持し、完全なKafka互換性を維持し（ワークロードを残さない）、可能な限りユーザーのためのアーティファクトとステップの重複を避けました。私たちは、Redpanda Icebergトピックを構築するための指導原則を説明する際に、このビジョンの完全性が伝わることを願っています。これらは現在、Databricks Unity Catalogと共に利用可能です。AWSとGCPで！

ストリームからレイクハウスへ
あなたの基盤を、あらゆる場所で自由に展開！

私たちの最初の原則は、選択肢を維持し、ユーザーがどこにいても対応することでした。Redpandaはすでに成熟したマルチクラウドのSaaS、BYOCおよび自己管理のオファリング、BYOVPCのようなプライベートな主権ネットワークオプションを提供し、一般的には顧客にクラウド、ネットワーク、オブジェクトストア、IdP、または採用を阻害したり、プラットフォーム所有者がストリーミングプラットフォームのデプロイメント（データと制御面を含む）を最も理にかなった場所に配置することを防ぐ他のものを移動するように強制することはありません。その選択に関係なく、ユーザーはプラットフォームのすべての機能と、開発者と管理者の両方に一貫したUXを得ます。この一元化された製品戦略こそが、私たちが今日、AWS、GCP、Azureのクラウドで一般に利用可能なIceberg Topicsを発表できる理由であり、組織がクラウドを切り替えたり、新しい形状に変更したりするときに、同じ製品を同じ基礎エンジン、Kafkaの互換性、セキュリティモデル、パフォーマンス特性、管理ツールとともにデプロイしていることを確信しています。この柔軟性と一貫性の幅は、市場の他のオプションとは鮮やかに対照をなしています。

Unity Catalog と出会う、
史上最も統合されたストリーミングプラットフォーム。

また、私たちはこれを一つのシステムとして構築することに固執しました。そして、それが実際にそう感じられるものであること。まったく異なるソフトウェアアーキテクチャを二つ組み合わせてうまく融合させることはできません。SaaSの外観で一部を隠すことはできますが、肥大化したアーキテクチャは、最低でも価格モデル、パフォーマンス、TCOに漏れ出し、最悪の場合はユーザー体験にまで影響を及ぼします。私たちはそれを避けるために最善を尽くしました。

開発者にとって、単一のシステムの「感覚」は、トピックをテーブルとして一貫したUXと、それらが機能するために必要なもの（つまり、スキーマ）の単一のCRUDライフサイクルを意味します。Iceberg Topicsを使用すると、エントリーや設定をコピーしたり、別のUIを使用して2回作成したりすることはありません。データとスキーマの両方の真実の源として1つのエンティティを管理し、常に同じツールを使用します。私たちにとって、それはあなたが既に使用しているツールを通じてCRUDを行うことを意味します：任意のKafkaエコシステムツール、私たちのrpk CLI、Cloud REST APIsまたはRedpandaのデプロイメント自動化ツールのいずれか、たとえば私たちのK8s CRsまたはTerraform providerです。スキーマについては、広く受け入れられている標準のAPIを持つ私たちの組み込みのSchema Registryがあり、それはIcebergテーブルスキーマを暗黙的に、または明示的に定義します。すべてが設定駆動で、DevOpsに優れています。そして、Unity Catalogの新しいManaged Icebergテーブルを使用すると、すべてのストリームがデフォルトでIcebergとDelta Lakeの両方のテーブルとしてDatabricksツールを通じて発見可能になります。

単一のシステムはまた、プラットフォームオペレータにとっても関心事であり、彼らは複数のバケットやカタログを管理したり、Parquetファイルサイズを調整したり、クラスタがリソースに制約があるときにテーブルがストリームを遅れることを心配したり、ノードの障害が正確に一度の配信を妨げることを心配する必要はありません。Redpanda Icebergトピックでは、これらすべてが自己運転です。オペレータは、データ到着SLAに合わせて調整される動的にバッチ化されたparquet書き込みとトランザクション型のIcebergコミット、必要に応じてKafka Producerのバックプレッシャーを生成する自動ラグ監視、およびIcebergスナップショットタグ付けによる正確に一度の配信（インフラストラクチャの障害後のギャップや重複を避ける）から利益を得ます。

Redpandaはあなたのデータを単一のバケット/コンテナで管理し、Unity Catalog内の単一のIcebergカタログを使用し（Redpandaが監視してスムーズなリカバリーを行う）、テーブルを簡単に見つけられるようにするためにUnity CatalogのIceberg RESTエンドポイントをRedpanda CloudのUIに表示します。そして今、Unity Catalog Managed Iceberg Tablesを使用すると、テーブルのメンテナンス操作（コンパクション、データの有効期限、予測最適化）が組み込まれ、Unity Catalogがバックグラウンドで自動的に実行します。一方、Redpandaはその役割に適した最小限のメンテナンス操作（現在はIcebergスナップショットのクリーンアップとテーブルの作成/削除）を引き受けます。その後、Databricksの管理者は、通常のUnity Catalogの権限を使用してこれらのテーブルを安全に管理できます。

すべてを制する、ただひとつのクラスタ。

最も重要なことは、私たちのR1マルチモデルストリーミングエンジンは、スレッドごとのコアアーキテクチャを使用し、書き込みキャッシングやマルチレベルのデータとワークロードバランシングなどの機能を搭載しているため、管理者はこの高スループットのIcebergインジェストを同じクラスタで実行し、既存の低レイテンシーのKafkaワークロードをサブ10msのSLAで動力を供給するのと同じトピックで実行することができます。非同期のパイプライン化された操作をProduce/Consumeリクエストを処理するのと同じCPUコアにロックすることで、私たちは最大の効率で両方のワークロードを一つのプロセスで処理します。最も重要なことは、Iceberg TopicsはKafkaのセマンティクスの全セットを活用でき、Kafkaのトランザクションやコンパクトなトピックを含み、Icebergレイヤーはコミットされたトランザクションからのレコードのみを受け取ります。このような基本的に効率的なアーキテクチャと洗練されたセマンティクスの難問を解決する組み合わせは、運用コストを大幅に削減する大きな利益をもたらします。なぜなら、一つのクラスタがすべてを支配するからです。追加の製品は不要です。別々のクラスタは不要です。パイプラインのベビーシッティングは不要です。どこでもデプロイできます。ストリーミングプラットフォームの管理者は、落ち着いて進めてください。

シンプルにする

私たちの第三の原則は、デフォルトの動作についていくつかの意見を持った選択をすることで、ユーザーが最もスマートなハンズフリーの設定でシステムを徐々に学ぶことができるようにしました。これは、組み込みの時間単位のテーブルパーティショニング（Kafkaトピックパーティションスキームから完全に分離）、常にオンのデッドレターキューを無効なデータをキャプチャするテーブルとして、そして「最新バージョン」や「TopicNameStrategy」のようなシンプルで標準的な規約をスキーマ推論に使うことで、簡単に採用できます。また、メッセージパーティション、オフセット、キーなどのKafkaメタデータをIceberg Structとして持ってきて、開発者がIceberg SQLでストリーミングパイプラインの正確さを迅速に検証できるようにしています。

シンプルなものはもちろんシンプルであるべきですが、洗練されたものも直感的であるべきです。したがって、Icebergのカスタムパーティショニングの全セットを使用した階層的な定義や、特定のProtobufメッセージタイプを主題から引き出してIcebergテーブルスキーマにすることは、再び、宣言的な単一行のトピックプロパティです。スキーマは、Redpandaがテーブル進化を適用することでスムーズに進化します。そして必要であれば、お気に入りの言語で単純なSMTを実行し、複雑なメッセージを生のトピックからWebAssemblyによって動力を得たオンボードのData Transformsを使用して、よりシンプルなIcebergファクトテーブルに展開します。最終目標は、一回のパスで分析準備が整った状態に着陸することです。

このすべての革新の背景には、もちろん、急速に進化するApache Icebergプロジェクトと仕様、そして一般的にRedpandaのオープンスタンダードへのコミットメントがあります。そのコミットメントは、Kafkaプロトコル、スキーマレジストリ、HTTPプロキシAPI、さらには組織がKafkaアプリケーションの全体を変更せずにシームレスに移行できるようにする標準的なトピック設定などの詳細を早期にサポートすることから始まりました。Icebergの領域では、Redpandaはコミュニティでの先駆者として積極的に取り組み、オープンソースで利用可能なものではない完全なC++ Icebergクライアントを一から実装しました。このクライアントは、完全なIceberg V2テーブル仕様、すべてのスキーマ進化ルール、およびパーティション変換をサポートしています。Icebergカタログの側では、repandaはファイルベースのカタログを出荷し、Unity Catalogなどのリモートカタログでの作成、コミット、更新、削除などの操作のためのIceberg RESTを話し、OIDC認証をサポートし、Unity Catalogの資格情報をあなたの秘密として慎重に扱い、それをあなたのクラウドプロバイダのシークレットマネージャで透明に暗号化します。Redpandaはまた、Databricksや他のIcebergのリーダーと密接に協力して、仕様が半構造化ストリームデータをサポートするように拡張できる方法を探し、Variantタイプを通じて、また、2つのプラットフォーム間でポリシーを同期させることでテーブルRBACの管理をよりシームレスにする方法を探しました。この標準化と常に仕様に基づいて実装することは、ベンダーロックインを最小限に抑えることを意味します。組織は常に、より良いオプションを見つけた場合には、システムの任意の部分を交換する自由があります：ストリーミングプラットフォーム、Icebergカタログ、またはテーブルをクエリ/処理するlakehouse。

ここまで読んでいただけたなら、Redpandaがこの熱い市場機会に対する考え抜かれた厳格さを感じていただけたことを心から願っています。これは強固なエンジニアリング文化と堅牢な製品を作るための情熱から生まれています。テクノロジストとしての心を持ち、確固たる実績を持ち、特にBYOC形態に焦点を当てている私たちは、RedpandaとDatabricksは、二つの最高のプラットフォームを一つのように動作させ、感じさせることができ、あなたにとっては、蒸気からテーブルへの問題がよく解決されているということです。

Icebergトピックを試してみてくださいUnity Catalogと共に、RedpandaのユニークなBring-Your-Own-Cloudオファリングを今日試してみてください。または、自己管理型のフレーバー、Redpanda Enterpriseの無料トライアルから始めてみてください：https://cloud.redpanda.com/try-enterprise.