Andrew Tanによる
典型的なデータチームのオーケストレーションスタックは、合理的なステップで進化します。最初はAirflowから始めます。それで十分です。チームはそれを知っています。DAGはスケジュール通りに実行されます。5年後、Airflowは300のDAGを実行しており、誰もベースイメージに触れるのを恐れています。
その後、何かモダンなものが必要になります。新しいメンバーがPrefectを推奨します。Pythonネイティブで、開発者の体験が向上し、UIがクリーンです。そこで、新しいプロジェクトはPrefectで始め、古いものはAirflowに残します。
次に、MLチームが登場します。彼らはDagsterを望んでいます。asset中心の考え方と系譜追跡が、彼らのフィーチャーストアの作業に適しているからです。合理的です。Dagsterを追加します。
誰も悪い決定をしたわけではありません。各ツールはコンテキストにおいて正しい選択でした。しかし、チームは今、3つのスケジューラ、3つのワーカーセット、3つのモニタリングダッシュボード、3つのメンタルモデルに対して費用を払っています。データがAirflowからDagsterに流れ、PrefectでオーケストレーションされたAPIコールに行くとき、系譜が途切れます。各ステップを個別に見ることはできますが、全体のチェーンを見ることはできません。
これがオーケストレーションの税金です。そして、2年以上データインフラを構築している企業ではほぼ普遍的です。
税金が現れる方法
隠れた請求書は、ほとんどのチームが測定しない3つの場所に現れます。
調整のシーム。 パイプラインA（Airflow）がパイプラインB（Dagster）をトリガーする必要があるとき、それはどうやって行いますか？通常は、ファイルドロップ、データベースフラグ、APIコール、または最も一般的には、各システムを所有する人間間のSlackメッセージです。その「統合」は今や荷重を支えています。それが壊れると、静かに失敗します。Dagsterのパイプラインが昨日のデータで実行されたときに、3時間後に気づきます。
一部のチームは、内部で「グルーレイヤー」と呼ばれるものを維持するために専任のエンジニアを抱えることになります。それは3つのオーケストレーションツールを1つであるかのように見せかけるためにPythonスクリプトを書くフルタイムの役割です。
デバッグ迷路。 BIツールでデータ品質の問題が表面化します。数値が間違っています。どこで間違ったのか？Airflowのログから始めます。DAGは成功しました。Prefectをチェックします。イベントフローは成功しました。Dagsterをチェックします。assetsはマテリアライズされました。システム間の引き渡しのどこかで、何かが横道にそれましたが、何が起こったのかを統一的に見ることはできません。
クロスシステムの障害に対する平均解決時間（MTTR）は、これを追跡するチーム全体で一貫して単一システムの障害の3〜5倍高くなっています。デバッグコストが最大の隠れた部分です。
コンテキストスイッチの負担。 Airflowのスケジューラはcron式とタスク依存関係で考えます。Dagsterはassetsと新鮮さポリシーで考えます。Prefectはフローとデプロイメントで考えます。それぞれが独自の認証モデル、独自の秘密管理、独自のリトライ処理方法を持っています。エンジニアは3つすべてに精通するようになりますが、それはどれにも専門的でないことを意味し、各ツールの移行はスプリントトラッカーに現れない認知的負担を伴います。
Kestraの状況
これがKestraのマーケティングが共鳴する理由です。彼らの売り文句は、「Airflow、Spark、dbt、カスタムスクリプトを1つのオーケストレータから実行できる」というもので、マルチツールのフラストレーションに直接対応しています。
しかし、単一のガラスのパネルと単一の真実の源には違いがあります。Kestraは既存のツールをラップできます。それは役に立ちます。しかし、分散調整の問題を実際に減らすわけではありません。3つのツールの上にもう1つのツールを追加しただけです。
オーケストレーションのスプロールはUIの問題ではありません。それはデータフローの所有権の問題です。チェーンをトリガーするイベントを誰が所有しているのか？システム間で渡されるデータのスキーマを誰が所有しているのか？ステップ2とステップ3の間の引き渡しが失敗したとき、誰が責任を負うのか？
新しいオーケストレーションレイヤーを上に追加しても、これらの質問に答えることはありません。それは、午前2時にデバッグするときに見るべきシステムをもう1つ追加するだけです。
実際に役立つこと
問題を移動させるだけでなく、実際に機能するものについて直接述べましょう。
機能する：1つのモデルに積極的に統合する。 現在のワークロードの80％をうまく処理するツールを選び、できる限りすべてを移行し、レガシージョブを移行する摩擦を受け入れます。それは6か月間痛みを伴います。その後、1つのスケジューリングモデル、1つのワーカーセット、失敗したときに見るべき1つの場所を持ちます。これを行うチームは、一貫して1年以内にインシデント対応時間が40〜60％減少したと報告しています。
機能する：システム間の引き渡しをファーストクラスのデータとして扱う。 正当な理由で複数のツールを実行する必要がある場合（例：MLパイプラインがDagsterのassetモデルから本当に利益を得る場合）、すべての引き渡しを明示的で監視されたデータ転送にします。ファイルドロップではありません。4年前に誰かがテーブルに追加したデータベースフラグでもありません。観測可能性、リトライ、アラートを備えた定義されたスキーマです。グルーはシステム設計の一部となり、偶然の産物ではありません。
機能しない：断片化の上に観測可能性を追加する。 3つのシステムのステータスを表示する別のダッシュボードは、調整の問題を解決しません。それは分散した失敗をより多くの場所で可視化するだけです。観測するものを減らす必要があります。より多くのものを観測するためのより良いツールではありません。
機能しない：移行劇場。 「今後18か月でDagsterに移行する」は計画ではありません。それは、実際の作業を行うにはまだ痛みが十分ではないという声明です。古いツールを実際に廃止するまでは、計画中に統合の表面積を追加しているだけです。
バッチ/ストリーミングの部分
複数のオーケストレーションツールを実行する本当の理由の1つは、バッチとストリーミングが本当に異なる要件を持っていることです。Airflowはジョブをスケジュールします。Kafkaはストリームを処理します。異なるパラダイム、異なるツール — そして、同じデータプラットフォームで両方を提供しようとすると、2つの別々のワークフローマネジメントシステムを持つことになります。
これは直接名前を付ける価値があります：同じデプロイメントモデル、同じワークフロー定義、同じ運用ツールを持つプラットフォームは、夜間のETLを実行する同じチームがリアルタイムイベント処理を所有できることを意味します。誰もAirflowやKafkaを再発明しているわけではありませんが、「スケジュールされた」と「イベント駆動」の間の分割が、2つの別々のエンジニアリング専門分野と2つの別々のモニタリングシステムを必要としないようにするためです。
目標は、持っているものをすべて置き換えることではありません。税金を払うのをやめることです。
実際の質問
会話は通常、同じ質問に戻ります：「これは実際に解決する価値のある問題なのか、それともデータシステムを構築する本質なのか？」
公平です。どの会社にも技術的負債があります。すべての負債が返済する価値があるわけではありません。
これを考える簡単な方法があります：オンコールローテーションに「3つのスケジューラをすべてチェックする」が毎回のランブックのステップとして含まれている場合、毎週オーケストレーションの税金を払っています。新しいデータエンジニアが生産的になるのに1か月かかる場合、それは複数のツールのメンタルモデルを学ぶ必要があるからであり、毎回の採用でそれを払っています。デバッグプロセスが3つの異なるログシステムをクロスリファレンスする必要がある場合、それは毎回のインシデントでそれを払っています。
それを合計してください。そして、決めてください。
オーケストレーションのスプロールに対処しており、特にバッチとリアルタイムのワークロードの両方を処理している場合に、統合への道がどのように見えるかを理解したい場合は、お問い合わせください。あなたの特定のセットアップを通じて歩き、何を変更する価値があるか、何がないかを正直にお伝えします。
Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムのワークロードをスケールで処理するエンタープライズデータ処理インフラを構築するシリアルアントレプレナーです。
