Tableflow の一般提供を開始 : 数回のクリックで Apache Kafka® Topic を Apache Iceberg™️ および Delta Lake テーブルと統合

本日は Confluent にとって大きな節目となります。Tableflow の一般提供を開始しました！これにより、データエンジニアの日常業務がはるかに楽になります。本日より Tableflow は AWS で一般公開されており、近日中に Azure と GCP もサポートされる予定です。

Apache Kafka® のデータをデータレイクにストリーミングしようとしたことがある方なら、その苦痛をご存知でしょう。パイプラインは壊れやすく、不良データが発生すると、クリーンアップ作業が増え、データが重複し、形式間の型変換は頭痛の種になります。しかも、うまくいったとしても、時間もコストもかかります。

Tableflow はそのすべてを解決します。Tableflow により、スキーマを持つ任意の Kafka Topic を取得し、それを Apache Iceberg™️ または Delta Lake テーブルとして公開できます。ステッチングパイプラインがなく、データの重複が少なく、スキーマの問題もありません。Tableflow を有効にするだけで、Kafka データが分析ツールや AI ツールからすぐにアクセス可能になります。

これは、当社がこれまでに発表した中で最もインパクトのある製品の1つです。ユーザーがストリームを管理するのを支援することから始め、追加の作業を必要とせずにストリームとテーブルを同時に管理できるように支援するまでになりました。

データレイクとデータウェアハウスに運用データが必要な理由

リアルタイムイベントをキャプチャするために Kafka を使用している方は、ストリーミングデータがもたらす価値をすでにご承知でしょう。しかし、ストリーミングだけでは十分ではありません。そのデータを分析し、履歴データと結合して、人工知能（AI）モデルに入力し、実際の意思決定を行う必要があります。そのためには、データレイクまたはデータウェアハウス内の構造化された形式が必要です。

ただ、データウェアハウスは常にストリームではなくテーブルで動作してきました。そして、これらのテーブルは処理エンジンに緊密に結合されているため、例えば Redshift のテーブルは基本的に Snowflake や Trino では使用できませんでした。

Kafka のデータは、データレイクで使用されるさまざまなテーブル形式では到達せず、通常、未加工で乱雑な状態でダンプされるため、使用可能にするには追加処理が必要です。これは、Kafka が分析処理ではなく、リアルタイムのイベントストリーミング用に設計されているためです。高スループット・低レイテンシのメッセージングで機能するものが、データウェアハウスやデータレイク内の分析・クエリテーブルの構造化された要件と衝突することはよくあります。

過去数年間、ほとんどのレイクハウスが標準化している Delta Lake や Apache Iceberg™️などのオープンテーブル形式が登場してきました。そのため、Kafka データを Iceberg テーブルや Delta テーブルに移動することが重要です。未加工の Kafka イベントを、ダウンストリームのツールがすぐにアクセスできる構造化されたクエリ可能なテーブルに変換し、顧客インサイトから機械学習モデルまであらゆるものを強化します。

ただ、Kafka データをそれらのテーブルに取り込むのは思ったよりも難しく、データを使用可能にするには、データを適切にマッピング、変換、クリーニングする必要があります。

Kafka データをテーブルに取り込むのが難しい理由

当社では、Kafka データをデータレイクに取り込む際の課題について100社を超えるお客様と話し合ってきましたが、常に同じメッセージが返ってきました。それは、壊れやすく、コストがかかり、管理が難しいという点です。

一般的なプロセスには以下が含まれます。

1. Kafka からのデータの読み取り – Spark ジョブを構築するか、Kafka コンシューマーを構成するか、シンクコネクタを設定します。各オプションにはチューニングとメンテナンスが必要であり、機能しなくなった場合は、インフラストラクチャのトラブルシューティングを行い、重複を作成せずに処理を再開する必要があります。

2. データの変換 – Kafka メッセージは Avro、JSON、Protobuf でシリアル化されますが、データレイクでは通常 Parquet が必要です。データ型を変換し、フィールドをマップするには、カスタムロジックを記述する必要があります。型の不一致やシリアル化エラーが原因で取り込みが失敗することがよくあります。

3. スキーマの進化 – スキーマは頻繁に進化する可能性があり、通常、ユーザーはメッセージのスキーマが期待どおりであることを確認したり、違いを処理したりするために、スキーマ処理ロジックを構築する必要があります。

4. 圧縮とファイル管理 – データをオブジェクトストレージにストリーミングすると、小さなファイルが大量に生成されるため、クエリのパフォーマンスが低下します。通常、ユーザーは独自の圧縮プロセスを考え出す必要があり、これには非常に多くの計算リソースとコストがかかる可能性があります。

今説明した内容はすべて、通常 1 つのストリームに対して実行されます。これを N 個のストリームに拡張することを想像してみてください。相当な苦痛です。そのため、多くの企業は、Kafka データをレイクまたはウェアハウスの下流で AI や分析に使用できるようにするのに苦労しています。しかし、その状況は変わりました。

Tableflow で Kafka Topic を Iceberg テーブルや Delta Lake テーブルとして簡単に表現

Tableflow は、数回のクリックで Kafka Topic とそれに関連付けられたスキーマを Iceberg テーブルまたは Delta Lake テーブルとして表現することで、上述の複雑さを排除します。スケーリングや管理のためのカスタムコードやパイプラインは不要で、すぐにクエリできるテーブルを AI や分析に即座に利用できます。

一般提供リリースの新機能

• Iceberg テーブル: 一般提供が開始され、Confluent Cloud ユーザーは Kafka Topic 内のストリーミングデータを Iceberg テーブルとして公開できるようになりました。

• Delta Lake テーブル: 現在オープンプレビュー中で、ユーザーは Kafka Topic を独自のストレージ内の Delta Lake テーブルとしてマテリアライズできます。これらのテーブルは、当社が機能を改良し強化し続ける間、ストレージバックの外部テーブルとして利用できます。

Tableflow が舞台裏で課題を解決する方法

Tableflow は、Kora ストレージレイヤーのイノベーションを使用して、Kafka セグメントを取得して他のストレージ形式 (この場合は Parquet ファイル) に書き出す柔軟性を実現します。Tableflow は、Confluent の Schema Registry を利用して、スキーママッピング、スキーマの進化、型変換を処理しつつ、Iceberg メタデータと Delta トランザクションログを生成する新しいメタデータ公開サービスをバックグラウンドで使用します。

バックグラウンドでは次のように動作します。

• データ変換 – Confluent Cloud の Schema Registry を信頼できる情報源として使用し、Avro、JSON、Protobuf の Kafka セグメントとスキーマを Iceberg および Delta 互換のスキーマと Parquet ファイルに変換します。

• スキーマの進化 – Tableflow は、フィールドの追加や型の拡張などのスキーマの変更を自動的に検出し、それぞれのテーブルに適用します。

• カタログの同期 – Tableflow で作成されたテーブルを AWS Glue、Snowflake Open Catalog、Apache Polaris、Unity Catalog (近日公開) の外部テーブルとして同期します。

• テーブルメンテナンスとメタデータ管理 – Tableflow は、十分な数の小さなファイルを検出すると自動的に圧縮し、スナップショットとバージョンの有効期限も処理します。

• ストレージの選択 - データを独自の Amazon S3 バケットに保存するか、Confluent にストレージのホストと管理を任せるかを選択できます。

Tableflow の有効化 : プロセスは簡単

データパイプラインをパッチワークから精密なものに変えるのが、これまで以上に簡単になりました。Tableflow を有効にするには、次の手順に従ってください。

1. Confluent Cloudを開きます。

2. Kafka Topic を選択します。

3. [Tableflow を有効化] をクリックします。

4. データの保存場所を選択します。

これでストリームがテーブルとしてクエリ可能になりました。

Apache Flink® とストリーム処理 : 分析対応テーブルへの次のステップ

Tableflow は、Kafka データを構造化されたテーブルに変換するという面倒な作業を処理しますが、実際のデータは、テーブルに取り込まれた後でも依然として乱雑なことがよくあります。事前定義されたクエリに対応し、本当に分析可能な状態にするには、データレイクに取り込む前に処理と整備を行う必要があります。

最終的に、テーブルが常に単一の Topic とまったく同じように見えるようにすることを望む場合やダウンストリーム分析で既存のデータエンジニアリングパイプラインで複数のストリームを1つのテーブルに統合する必要がよくある場合には、クリーンなテーブルと Kafka の速度を維持するために、そうしたテーブルの処理をシフトレフトする方が効率的です。

ここで登場するのが Apache Flink® のストリーム処理です。

Flink があれば、Kafka ストリームがテーブルに到達する前にリアルタイムで変換を実行できます。Flink を使用すると、データストリームをフィルタリング、変換、集計、結合、充実化でき、未加工の Kafka イベントをクリーンアップして AI や分析にすぐに使用できる形に整えることができます。

Tableflow と Flink を組み合わせることで、レイクに最新のデータが確実に保存され、事前に変換されてクエリの準備が整った状態になります。同じ未加工データを同じ方法で処理することで各チームが不注意にコストを引き上げてしまうことを防ぎ、上流でのスキーマやデータの変更をレイクで問題になる前にガバナンスツールが確実にキャッチします。

パートナーカタログや分析エンジンとのシームレスな相互運用性

Confluent は Amazon Web Services (AWS)、Databricks、Snowflake と提携し、それぞれの Iceberg および Delta Lake カタログとのネイティブ統合を作成しました。Tableflow は AWS Glue、Databricks Unity Catalog (近日公開)、Snowflake Open Catalog との統合をサポートしています。また、関連する分析ツール (AWS 分析サービス、Databricks Intelligence Platform、Snowflake Cortex AIなど) もサポートしています。下記の通り、当社のパートナーは非常に意欲的です。

Tableflow とパートナーのネイティブ統合を組み合わせることで、ストリーミングデータを簡単に発見し、Amazon Athena、Amazon EMR、Amazon Redshift、Amazon SageMaker Lakehouse、Databricks、Snowflake などの主要なデータレイクやデータウェアハウスで即座にアクセスできるようになります。Tableflow には、プラットフォームによって生成されるすべての Iceberg テーブルの信頼できるリポジトリとして機能する組み込みの Iceberg REST カタログも含まれています。

これらすべてを統合

Tableflow は、単に運用データを Kafka からデータレイクに取り出すための優れた方法を提供するだけでなく、ガバナンス、ストリーム処理、データ形式の統合によって、より根本的なこと、つまり、運用システムと分析システムの両方にわたるデータの単一かつ一貫したビューの作成を実現します。断片化されたパイプラインや不一致のスキーマを処理する代わりに、リアルタイムイベントと履歴データが完全に整合する1つの統合システムを活用できるようになります。Tableflow は、Kafka データをクリーンで構造化された形式で Iceberg テーブルと Delta テーブルとしてマテリアライズし、ストリーム処理により、データがテーブルに到達する前に、強化され、重複が排除され、一貫してマッピングされることを保証します。つまり、データはビジネスインテリジェンスや AI ツールで利用できるだけでなく、完全かつ正確で、すぐに実行可能となります。

この単一のビューは、企業がデータを扱う方法を変えます。運用システムと分析システムが同期すると、複雑なパイプラインを構築または維持することなく、顧客の行動をリアルタイムで分析し、リアルタイムの需要に基づいて価格を調整し、常に更新されるデータを AI モデルに提供できるようになります。すべてが一箇所に整然と配置されているため、古いデータや不完全なデータに基づく意思決定のリスクがなくなります。

Tableflow とストリーム処理を組み合わせることで、単に複雑さを軽減するだけではありません。ビジネスのスピードを加速し、より賢く対応し、成果を最大化するための統合されたデータ基盤を構築できます。

Tableflow の今後の展開

Tableflow の最初のローンチに興奮していますが、これは製品チームとエンジニアリングチームにとってほんの始まりにすぎません。当社は、年間を通じて次のような新しい機能を展開していく野心的なロードマップを用意しています。

• Tableflow を Microsoft Azure と Google Cloud に導入

• Delta Lake および Unity Catalog 向けの Tableflow の一般提供

• Upsert テーブルのサポートで Tableflow が重複排除と主キー操作によるマージを処理可能に

• 互換性のないレコードをデッドレターキューに送信する機能やカスタムパーティショニングなどの追加構成

Confluent Cloud と Tableflow の利用を開始

Tableflow が Iceberg で一般提供開始され、Delta Lake テーブルではオープンプレビューとなった今は、リアルタイムデータワークフローを効率化する方法を検討するのに最適なタイミングです。今すぐ利用を開始して、フィードバックを共有し、シームレスなデータ統合の限界を押し広げ続ける Confluent の試みにご参加ください。Tableflow をさらに強力にするための次の機能強化にすでに取り組んでいます。今後の発表にご期待ください。

Apache®、Apache Kafka®、Kafka®、Apache Flink®、Flink®、Apache Iceberg™️、Iceberg™️ は、Apache Software Foundation の米国およびその他の国における登録商標または商標です。これらの商標の使用は、Apache Software Foundation による推奨を意味するものではありません。その他の商標は各所有者に帰属します。