Andrew Tan 著
「streamhouse」という誰も定義しなかった言葉
先月、私はパネルディスカッションに参加していました。そこで誰かが2分間に5回も「streamhouse」という言葉を使いました。その人は本気でした。彼はこれを「lakehouse以降のデータアーキテクチャにおける最大のシフトだ」と言いました。「ストリーミングとアナリティクスの間の境界を崩壊させる」とも言いました。また、これを採用しないチームは18ヶ月以内に「レガシーなバッチインフラを維持し続けることになる」とも述べました。
パネル終了後、私は彼に「streamhouseとは実際に何なのか」と尋ねました。
彼は少し間を置いてからこう答えました。「ストリーミングプラットフォームとウェアハウスが同じものになることです」。例を求めると「Kafka with Iceberg」と答えました。それがFlinkがすでにやっていることとどう違うのかと聞くと、「streamhouseはnativeだ」と答えました。「native」とはこの文脈で何を意味するのかと聞くと、ストリームからウェアハウスへデータを移動させるための別ジョブが不要になることだと説明しました。ではストリームをリプレイしたり、バックフィルしたり、slowly changing dimensionテーブルと結合したりする必要が生じた場合はどうなるのかと聞くと、「それは実装の詳細です」と答えました。
彼はベンダーでした。何かを売ろうとしていました。しかしその言葉自体はすでに世の中に広がっており、データアーキテクト、プラットフォームリード、そして2027年の戦略は「analytics stackをstreamhouse化することだ」と言うCTOからも耳にしました。
だからこそ、マーケティングがやらないことをやってみましょう。このものを定義し、本物の変化と単なるリパッケージングを分離し、これがあなたが気にすべきカテゴリなのか、それともすでに抱えている複雑さに新しいラベルを貼っただけなのかを明らかにします。
「streamhouse」が本来意味しているもの
この用語は、今年初めにConfluent、Aiven、Redpanda、StreamNative、Ververicaによって発表されたワーキンググループに由来します。その主張はシンプルです。ストリーミングデータと分析データは長すぎる間、別々のシステムに存在してきました。Kafkaがストリームを、Snowflakeがアナリティクスを担当し、その間にパイプラインを構築します。そしてパイプラインが壊れ、互いに相手のチームを責め合うのです。
streamhouseの提案は、これらを統合することです。ストリーミングデータは到着と同時にオープンなテーブル形式（Iceberg、Delta Lake、Paimon）に書き込まれます。クエリエンジンはそのテーブルを直接読みます。ETLジョブも、バッチ同期も、実行の間に古くなる「landing zone」も必要ありません。ストリームがテーブルであり、テーブルがストリームなのです。
ConfluentはこれをTableflowと呼び、AivenはAiven Streamsと呼んでいます。ベンダーによって正確なブランド名は異なりますが、アーキテクチャは一貫しています。
- イベントはストリーミングレイヤー（Kafka、Redpanda、Pulsar）に到着する
- ストリーミングエンジン（Flink、Spark Structured Streaming、またはベンダー独自のランタイム）が、データをインクリメンタルにオープンなテーブル形式へ書き込む
- クエリエンジン（Trino、DuckDB、Snowflake、BigQuery）が、通常のウェアハウステーブルであるかのようにそのテーブルを読み取る
- テーブルは「定期的に更新される」のではなく「継続的に更新される」
これは詐欺ではありません。ここには本物の技術的達成があります。ストリーミングパイプラインが、スキーマ進化、コンパクション、スナップショット分離を備えたほぼリアルタイムでクエリ可能なテーブルファイルを生成することは、本当に困難です。これを構築しているチームは称賛されるべきです。
しかしこのアーキテクチャ自体は新しいものではありません。これはFlink、Kinesis Analytics、そして一部のカスタムKafka-to-S3パイプラインが何年も前から行ってきたことの洗練版に過ぎません。新しくなったのはマーケティングの傘です。「streamhouse」という言葉、ワーキンググループ、そしてこのパターンが別々のバッチシステムとストリーミングシステムの必要性をなくすという約束です。
その最後の部分が、かなり強引な主張です。
何が変わり、何が変わらないか
現実的な部分と願望的な部分を分けましょう。
実際に良くなること：
- クエリ可能なデータまでのレイテンシが低下する。1時間ごとにバッチ同期を実行している場合、継続的なマイクロバッチ処理や真のストリーミングに移行することで、それを数秒〜数分に短縮できます。新鮮さが重要なユースケース（不正検知、運用ダッシュボード、リアルタイム価格設定）では、これは本物の改善です。
- スキーマ進化がよりクリーンになる。オープンなテーブル形式は、ほとんどの手作りストリーミング-to-ウェアハウスパイプラインよりもスキーマ変更を上手く扱います。カラムの追加にマイグレーションスクリプトは不要です。フィールド名の変更はメタデータで追跡されます。これにより「誰がダッシュボードを壊したのか」というインシデントが減少します。
- 1つのストレージレイヤーでコピーが減少。アナリティクスのチームが、ストリーミングパイプラインが生成したのと同じIcebergファイルをクエリできるなら、別途ウェアハウスから抽出する必要がなくなります。コピーが減れば、同期ジョブも減り、一貫性ウィンドウも減り、データが乖離する箇所も減ります。
全く変わらないこと：
- オーケストレーション。streamhouseは、ジョブの調整、依存関係、リトライの必要性をなくしません。ストリーミングパイプラインがdbtモデルを介してダッシュボードにデータを供給する場合、そのDAGは依然として管理する必要があります。streamhouseはバッチ抽出ステップを置き換えますが、オーケストレーション層を置き換えるものではありません。
- バックフィルとリプレイ。バグによって3日分のストリーミングデータが破損した場合、ログを巻き戻して再処理する必要があります。streamhouseのテーブル形式はこれを可能にしますが、簡単にはしません。コンシューマオフセットの管理、ストリーム途中で発生したスキーマ変更への対応、下流システムが既に見たデータとリプレイデータが一致しているかの検証が依然として必要です。
- 複数システムに跨るワークフロー。現実のパイプラインのほとんどは複数のシステムに触れます。ストリームがAPI呼び出しをトリガーし、キャッシュを更新し、データベースに書き込み、通知を生成することもあります。streamhouseはアナリティクスのパスを扱いますが、運用パスは扱いません。異なる一貫性モデルと障害モードを持つシステム間で調整できるランタイムが依然として必要です。
- コスト構造。ストリーミングインフラは常に稼働しているインフラです。1時間に10分だけ実行されるバッチジョブは、1時間あたり10分のコンピュートコストです。継続的に実行されるストリーミングジョブは60分分のコストになります。streamhouseは同期ジョブのコストをストリーミングコンピュートに移します。それが安価になるかどうかは、データ量、クエリパターン、コンパクションのチューニング次第です。
streamhouseはストリーミングデータのストレージとクエリ可能性を改善します。しかし、そのデータを巡る煩雑な運用作業を扱うランタイムの必要性をなくすものではありません。
継続的テーブルの幻想
streamhouseの提案で最も魅力的なアイデアは「continuous table」です。決して古くならないテーブルです。クエリすれば常に最新のデータが得られ、バッチジョブも待機も必要ありません。テーブルは生きています。
これは強力なメンタルモデルです。しかし、少しだけ誤解を招きます。
継続的テーブルとは、1つの場所で更新され続ける単一のオブジェクトではありません。それはテーブルのある時点を表すスナップショットのシーケンスです。クエリするとき、あなたはそのスナップショットのどれか1つを読んでいます。クエリエンジンは自分が知っている最新のものを選択します。ストリーミングエンジンは常に新しいファイルを追加し、新しいスナップショットをコミットし続けています。
これが重要な理由は、「最新のイベントが到着した瞬間」と「最新のスナップショットがクエリ可能になる瞬間」の間にゼロのギャップはないからです。これは以下の要素に依存します。
- コミット頻度。ストリーミングエンジンはどのくらいの頻度で新しいスナップショットを書き込むか？ 毎秒か？ 毎分か？ 速ければ速いほどメタデータのオーバーヘッドが増えます。
- コンパクションの遅延。テーブルは小さなファイルを蓄積します。クエリが遅くなります。誰か（またはスケジュールされたジョブ）がそれらのファイルをより大きなファイルにコンパクションしなければなりません。コンパクション中はクエリの挙動が変わることがあります。
- カタログの一貫性。クエリエンジンはカタログを通じて新しいスナップショットを知ります。カタログが結果整合性の場合（ほとんどの場合そう）、クエリは実際のストリームより30秒遅れたスナップショットを読む可能性があります。30秒はリアルタイムではありません。リアルタイムの衣装を着たニアリアルタイムです。
継続的テーブルは便利な抽象化です。しかし、それはあくまでマイクロバッチの塊に対する抽象化に過ぎません。ファイルは離散的です。スナップショットも離散的です。新鮮さはコミット間隔、コンパクションスケジュール、カタログのレイテンシによって制限されます。「continuous」と呼ぶことは、エンジニアリングの現実——より小さなバッチ、より高速なコミット、同じ調整問題——を覆い隠してしまいます。
チームが結局複数のランタイムを繋ぎ合わせることになる場面
streamhouseのマーケティングが見せないシナリオは次の通りです。
Icebergテーブルにイベントを書き込むストリーミングパイプラインがあります。アナリティクスのチームはTrinoでそれをクエリし、MLチームはSparkで読み、運用チームは特定のイベントパターンが発生したときにアラートをトリガーする必要があります——それはテーブルに書き込まれた後ではなく、ストリームに到着した瞬間にです。
streamhouseはアナリティクスとMLのパスを扱います。しかし運用アラートは、イベントがテーブルスナップショットにコミットされる前の生のストリームに対して実行される必要があります。そこで生のストリームを処理するための別個のFlinkジョブを立てます。これで2つのランタイムができました。1つはテーブルパス用、もう1つは運用パス用です。
次にビジネスが、ストリーミングデータとERPシステムからのバッチデータを突き合わせて週次レポートを作成したいと言ってきました。ERPデータはストリームでは来ません。毎日届くCSVダンプです。そこでCSVを読み、Icebergテーブルと結合してレポートを作成するバッチジョブを構築します。これで3つのランタイムになりました。
さらに、火曜日に6時間にわたってスキーマドリフトによりストリーミングパイプラインが不正データを生成していたことが発覚しました。ストリームを巻き戻し、ロジックを修正してリプレイする必要があります。しかしそのリプレイは、下流のクエリが既に見たのと完全に同じテーブルスナップショットを生成しなければ、MLチームの学習実行が不整合になります。そこでMLチームのパイプラインとリプレイを調整します。これで4つのシステムに跨るランタイムオーケストレーションを行うことになります。
streamhouseは「どうやってストリームをクエリするか」という問題を解決しました。しかし「異なるセマンティクスを持つ複数のランタイムをどう調整するか」という問題は解決しませんでした。その問題は依然としてあなたのものです。
正直な意思決定フレームワーク
チームにとってstreamhouseパターンが意味があるかどうかを評価するなら、アーキテクチャ図から始めてはいけません。自分が実際に何をしようとしているのかから始めましょう。
streamhouseを使うべき場合：
- 主なユースケースが継続的に到着するデータに対するアナリティクスまたはMLであり、現在のバッチ同期がボトルネックになっている
- 既にKafka（またはRedpanda、Pulsar）を利用しており、そのデータをウェアハウスに移動させる別のパイプラインを維持するのが面倒になっている
- クエリパターンがオープンなテーブル形式（カラムナ読み込み、述語プッシュダウン、スナップショット分離）と互換性があり、サブ秒レベルの運用トリガーは必要としていない
- ストリーミング速度でのコンパクション、カタログの一貫性、スキーマ進化を管理できるチームがある
streamhouseを使うべきではない場合：
- 「ストリーミング」と呼んでいるユースケースが実際には15分ごとに実行されるバッチジョブである場合。streamhouseは無料ではありません。誰も15分より速いデータ更新を必要としていないなら、断続的な価値のために継続的なコンピュートコストを支払うことになります。
- イベント到着時に即座に発火しなければならない運用トリガー（API呼び出し、キャッシュ更新、通知）が必要な場合。streamhouseはアナリティクスのパターンであり、運用パターンではありません。
- チームが既にオープンなテーブル形式の運用に苦労している場合。streamhouseはその運用にストリーミング速度を追加します。コンパクションとカタログ管理が既に苦痛なら、それを高速化しても簡単にはなりません。
- これでオーケストレーション層を置き換えられると期待している場合。置き換わりません。依存関係、リトライ、バックフィル、複数システムに跨るワークフローを管理する何らかの仕組みは依然として必要です。
streamhouseはストレージとクエリのパターンです。ランタイムのパターンではありません。あなたの課題がストレージとクエリの課題（古いデータ、同期遅延、コピーの多さ）であるなら、評価する価値があります。課題がランタイムの問題（調整、障害復旧、複数システムのセマンティクス）であるなら、streamhouseは役に立たず、むしろ複雑さを増す可能性があります。
ベンダーが本当に売っているもの
streamhouseワーキンググループが不誠実だとは思いません。ただ、選択的に語っていると思います。彼らはこのパターンが輝くユースケース——リアルタイムアナリティクス、継続的なML特徴量ストア、運用ダッシュボード——だけを示し、うまくいかないユースケースは静かに省略しています。
彼らが本当に売っているのは、重心のシフトです。この10年間、ウェアハウスがデータ宇宙の中心でした。すべてのものがそこに流れ込んでいました。streamhouseの提案は、ストリームが中心であり、ウェアハウスはその多くのコンシューマのうちの1つに過ぎないと言っています。
これは一部の組織にとっては意味のあるシフトです。ビジネスがイベント駆動型（不正検知、IoT、リアルタイムトレーディング）である場合、ストリームファーストのモデルは理にかなっています。しかしほとんどの組織はイベント駆動型ではありません。スケジュール駆動型です。レポートを実行し、ダッシュボードを更新し、モデルを夜間に再学習させています。そうしたチームにとって、重心をストリームに移すことは、問題を探し求める解決策です。
ベンダーたちはこれを知っています。だからこそマーケティングでは、具体的な運用改善ではなく「将来を見据えた」「モダンなデータアーキテクチャ」を強調するのです。streamhouseは、クラウドやその前のlakehouseのように、避けられない進化として位置づけられています。裏のメッセージは「これをやっていないと取り残される」というものです。
確かにそうかもしれません。しかし、何に対して「取り残される」のでしょうか。バッチパイプラインが信頼性が高く、ステークホルダーが満足し、コストが予測可能であるなら、ベンダーが「避けられない」と言うからstreamhouseを採用するのは近代化ではありません。FOMO（取り残される不安）によるアーキテクチャです。
layline.ioの立ち位置
layline.ioでは、streamhouseを売りません。私たちが売っているのは、バッチとストリーミングの両方を同じパイプラインで、既に持っているインフラ上で扱うランタイムです。
これが重要な理由：多くのチームがstreamhouseを評価しているのは、バッチとストリーミングを2つの別々のスタックを維持せずに共存させたいからです。これは本物の問題です。しかしstreamhouseはストリームを中心としたストレージの統合によってこれを解決します。私たちはWorkflowを中心としたランタイムの統合によって解決します。
アナリティクスのチームがウェアハウステーブルを必要とし、運用チームがストリームトリガーを必要とする場合、両方の経路を同じパイプラインロジック、同じ可観測性、同じ障害復旧を通じて実行できます。ストレージ形式はアーキテクチャ上のコミットメントではなく、設定上の選択になります——役立つときはIceberg、必要ないときはParquet、運用レイテンシが必要なときはメッセージバス、というように。
streamhouseは特定の課題に対する有用なパターンです。それは万能のアーキテクチャではなく、深夜2時にパイプラインを稼働させ続ける運用ランタイムの代替にはなりません。これを成功させるチームは、正しい理由——クエリレイテンシ、同期オーバーヘッドの削減、よりクリーンなスキーマ進化——で採用し、それが決して解決するよう設計されていない問題を解決しようと期待しないチームです。
このバズワードはいずれ消えます。しかし基盤となる技術——オープンなテーブル形式への継続的インジェスト——は残り、改善され続けます。問題は、マーケティングが「あなたはこれを必要としている」と言う前に、あなたのチームが本当にそれを必要としていたかどうかです。
チームがstreamhouseのシグナルとノイズを分離しようとしている場合、またはバッチとストリーミングを扱うランタイムを探していて、特定のストレージ形式を宗教のように強制されたくない場合は、お問い合わせください。私たちはこのトレードオフの評価を多くのチームで支援してきました。そして答えは、たいていアーキテクチャ図が示唆するよりもシンプルです。
Andrew Tan is a serial entrepreneur and founder of layline.io, building enterprise data processing infrastructure that handles both batch and real-time workloads at scale.
