RedpandaとDatabricksによるリアルタイムのオープンレイクハウス

すべてのレイクハウスは「ストリーム供給型」であるべきです

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

Icebergという共通語を介したクラウド常駐データへのユビキタスなアクセスというこの物語において、主要な欠けていた要素の一つはストリーム、すなわちKafkaトピックでした。今日、静止している構造化データは、ネイティブに、あるいはIcebergとして「装飾」されて簡単に取り込むことができます。対照的に、リアルタイムアプリケーションを動かすストリーミングプラットフォームを流れる高価値の移動中のデータは、ポイントツーポイントのストリームごとのデータ統合ジョブを通じて、または独自のクラスターで高価なコネクタインフラストラクチャを実行することによって、ターゲットのレイクハウスに「ETL」される必要があります。どちらのアプローチも、重いKafka Consumerを利用し、リアルタイムデータ配信パイプラインに負荷をかけ、専門的なKafkaスキルを持つ仲介インフラストラクチャコンポーネントをスケーリング、管理、監視するために作成します。どちらのアプローチも、リアルタイムデータと分析データの間にとても高価な通行料を挿入することに等しく、それは本来必要のないものです。

ストリームをバックアップするためのクラウドオブジェクトストレージの使用が成熟し（Redpandaが数年前にその先駆けとなりました）、オープンテーブルフォーマットがレイクハウスで中心的な役割を果たすようになるにつれて、このストリームとテーブルの結合は、便利であると同時に「運命的」でもあります。DatabricksとRedpandaは、このアプローチを輝かせ、注目を集める2つの世界クラスのデータプラットフォームを提供します。両社は協力して、リアルタイムの意思決定、分析、AIにわたる、他に類を見ないデータ基盤を構築します。実際には、このアプローチは設定フラグ一つでストリームとテーブルを統合します。これは多室ダムのように機能し、選択可能なストリームをオンデマンドで統合データレイクにルーティングし、最新のインサイトを提供し、レイクハウスアーキテクチャがテーブルにもたらした新しい分析パイプライン内でのデータの任意の包含を可能にし、さらにIcebergエコシステムが提供する広範な開口部を通じてそれらを解放します。

リアルタイムと分析のデータインフラストラクチャをシームレスに融合させ、「ストリーム供給型レイクハウス」をボタン一つで実現することは、計り知れない価値を解き放つだけでなく、一般的なケースで適切に対処するために思慮深いアプローチを必要とする困難なエンジニアリング問題も解決します。以下で説明するように、この機能を市場に急いで投入するために手抜きはしませんでした。1年以上にわたり数十社のデザインパートナー（およびDatabricks）と協力し、Redpandaの単一コードベースを拡張しました。これにより、お客様が好むデプロイオプション（複数のクラウドでのBYOCを含む）を維持し、完全なKafka互換性（ワークロードを置き去りにしない）を保ち、可能な限りユーザーの成果物や手順の重複を回避しています。Redpanda Iceberg Topicsを構築するための指針を説明する中で、このビジョンの完全性が伝わることを願っています。Redpanda Iceberg Topicsは現在、AWSおよびGCPでDatabricks Unity Catalogと共に利用可能です！

ストリームからレイクハウスへのプラットフォームをどこでも実行

私たちの第一の原則は、選択肢を維持し、ユーザーがいる場所で対応することでした。Redpandaはすでに、成熟したマルチクラウドSaaS、BYOC、セルフマネージドの提供、BYOVPCのようなプライベートなソブリンネットワーキングオプションを備えており、一般的に顧客にクラウド、ネットワーク、オブジェクトストレージ、IdP、または採用を妨げたり、プラットフォームオーナーがストリーミングプラットフォームのデプロイ（データプレーンとコントロールプレーンの両方を含む）を最も理にかなった場所に配置するのを妨げるような、その他のいかなるものも移動させることを強制しません。その選択に関わらず、ユーザーはプラットフォームのすべての機能と、開発者と管理者双方にとって一貫したUXを利用できます。この単一プラットフォーム製品戦略により、Databricks向けのIceberg Topicsが本日AWS、GCP、Azureクラウドで一般提供されていること、そして組織がクラウドを切り替えたり、新しいフォームファクターに変更したりする場合でも、同じ基盤エンジン、Kafka互換性、セキュリティモデル、パフォーマンス特性、管理ツールを備えた同じ製品をデプロイしているという確信を持って展開できることを発表できます。この柔軟性と一貫性の幅広さは、市場の他の選択肢とは大きく異なります。

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

第二に、私たちはこれを単一のシステムとして構築すること、そして実際にそのように感じられるシステムとして構築することにこだわりました。完全に異なる2つのソフトウェアアーキテクチャを無理やり結合しても、2つのコンセプトをうまく融合させることはできません。SaaSの表面でごまかすことはできますが、肥大化したアーキテクチャは、少なくとも価格モデル、パフォーマンス、TCOに影響を及ぼし、最悪の場合にはユーザーエクスペリエンスにまで悪影響を与えます。私たちはそれを避けるために最善を尽くしました。

開発者にとって、単一システムの「感覚」とは、トピックをテーブルとして扱う単一のCRUDライフサイクルと一貫したUX、そしてそれらが機能するために必要なもの（つまりスキーマ）を意味します。Iceberg Topicsを使用すると、エントリや設定をコピーしたり、別のUIを使用して二重に作成したりする必要はありません。データとスキーマの両方について、単一のエンティティを信頼できる情報源として、常に同じツールを使用して管理します。私たちにとって、それは既存のツール（任意のKafkaエコシステムツール、当社のrpk CLI、Cloud REST APIs、またはK8s CRsやTerraform providerのようなRedpandaデプロイ自動化ツール）を介してCRUD操作を行うことを意味します。スキーマについては、広く受け入れられている標準APIを備えた組み込みのSchema Registryがあり、これによりIcebergテーブルスキーマが暗黙的または明示的に定義されます（お好みに応じて）。すべてが設定駆動型でDevOpsフレンドリーです。さらに、Unity Catalogの新しいマネージドIcebergテーブルにより、すべてのストリームはDatabricksツールを介して、デフォルトでIcebergテーブルとDelta Lakeテーブルの両方として検出可能です。

単一システムはプラットフォームオペレーターにも関係します。オペレーターは、複数のバケットやカタログの管理、Parquetファイルサイズのチューニング、クラスターのリソース制約時のストリームの遅延、ノード障害による厳密に1回の配信の損害について心配する必要がありません。Redpanda Iceberg Topicsを使用すると、これらすべてが自動運転されます。オペレーターは、データ到着SLAに合わせて調整される動的なバッチ処理されたParquet書き込みとトランザクションIcebergコミット、必要に応じてKafka Producerのバックプレッシャーを生成する自動遅延監視、およびIcebergスナップショットタグ付けによる厳密に1回の配信（インフラストラクチャ障害後のギャップや重複を回避）の恩恵を受けます。

Redpandaはすべてのデータを単一のバケット/コンテナで管理し、Unity Catalogで単一のIcebergカタログを使用し（Redpandaが正常なリカバリのために監視）、Redpanda CloudのUIでUnity CatalogのIceberg RESTエンドポイントを公開することで、テーブルを簡単に検出できるようにします。そして今、Unity CatalogマネージドIcebergテーブルにより、コンパクション、データ有効期限、Predictive Optimizationなどのテーブルメンテナンス操作が組み込まれ、Unity Catalogによってバックグラウンドで自動的に実行されます。一方、Redpandaはその役割に適した最小限のメンテナンス操作（現在はIcebergスナップショットのクリーンアップとテーブルの作成/削除）を担当します。Databricks管理者は、通常のUnity Catalogの権限をすべて使用して、これらのテーブルを保護および管理できます。

すべてを統治する1つのクラスター

最も重要なのは、スレッドごとのコアアーキテクチャを使用し、ライトキャッシュやマルチレベルのデータおよびワークロードバランシングなどの機能を備えた当社のR1マルチモーダルストリーミングエンジンのおかげで、管理者はこの高スループットのIceberg取り込みを、既存の10ミリ秒未満のSLAを持つ低遅延Kafkaワークロードを動かすのと同じクラスター、同じトピックで実行できることです。Produce/Consumeリクエストを処理するのと同じCPUコアにロックされた非同期のパイプライン処理を使用することで、単一プロセスで両方のワークロードを最大限の効率で処理します。最も重要なのは、Iceberg TopicsがKafkaトランザクションやコンパクションされたトピックを含むKafkaセマンティクスをフル活用できることです。この場合、Icebergレイヤーはコミットされたトランザクションからのレコードのみを受け取ります。洗練されたセマンティクスの難しい問題を解決する、根本的に効率的なアーキテクチャのこの組み合わせは、運用コストを大幅に削減するという大きな利益をもたらします。なぜなら、結局のところ、すべてを統治する1つのクラスターだからです。追加の製品は不要。個別のクラスターも不要。パイプラインの監視も不要。どこにでもデプロイ可能。ストリーミングプラットフォーム管理者よ、落ち着いて業務を続けましょう。

シンプルに

第三の原則は、デフォルトの動作について独自の意見に基づいた選択を行い、ほとんどのユースケースで機能する可能な限りスマートなハンズフリー構成で、ユーザーがシステムを徐々に学習できるようにすることでした。これは、組み込みの時間単位のテーブルパーティショニング（Kafkaトピックパーティションスキームから完全に分離）、無効なデータをキャプチャするためのテーブルとしての常時稼働のデッドレターキュー、そしてスキーマ推論のための「最新バージョン」や「TopicNameStrategy」のようなシンプルで標準的な規約が、容易な導入を可能にすることを意味します。また、メッセージパーティション、オフセット、キーなどのKafkaメタデータをIceberg Structとして一緒に持ち込むことで、開発者はIceberg SQLでストリーミングパイプラインの正確性を迅速に検証するためのすべての来歴情報を得ることができます。

\r\n

\r\n

もちろん、シンプルなものはシンプルであるべきですが、複雑なものも分かりやすいものであるべきです。そのため、Icebergのパーティション変換の全セットを使用した階層的なカスタムパーティショニングの定義や、特定のProtobufメッセージタイプをサブジェクト内から抽出してIcebergテーブルスキーマにするのも、やはり宣言的な単一行のトピックプロパティに過ぎません。Redpandaがインプレーステーブル進化を適用することで、スキーマはスムーズに進化できます。また、必要であれば、WebAssemblyを搭載したオンボードのデータ変換を使用して、生のトピックから複雑なメッセージをよりシンプルなIcebergファクトテーブルに展開する簡単なSMTをお好みの言語で実行できます。最終的な目標は、単一のパスで分析準備が整ったデータを着地させることです。さあ、Bronzeレイヤーの登場です。

\r\n

\r\n

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

\r\n\r\n

ここまでお読みいただいた皆様には、Redpandaがこの急成長する市場機会に対して、堅牢な製品を構築するという強力なエンジニアリング文化と情熱から生まれる、思慮深く厳密なアプローチを感じていただけたことと存じます。確かな実績を持つ根っからの技術者として、特にBYOCフォームファクターに注力しているRedpandaとDatabricksは、まるで一体であるかのように機能する2つの最高級プラットフォームを提供するために完全に連携しており、皆様にとってストリームからテーブルへの問題を完全に解決します。

\r\n\r\n

Redpanda独自のBring-Your-Own-Cloudオファリングを使用して、今すぐUnity CatalogでIceberg Topicsを試してみてください。または、セルフマネージド版のRedpanda Enterprise!の無料トライアルから始めてください: https://cloud.redpanda.com/try-enterprise。

\r\n

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事