Andrew Tanによる
モダンデータスタックの高くつく真実
データプラットフォームのチームに関わる機会が増えれば、誰もが同じ話を耳にする。企業は「モダンデータスタック」— データウェアハウス、処理レイヤー、オーケストレーター — を構築し、アーキテクチャ図上ではすべてがきれいに見える。しかし、しばらくするとデータウェアハウスの請求額が上昇し始める。取り込みジョブは思ったより頻繁に失敗する。何かが壊れるたび、問題がロードにあるのか、変換にあるのか、オーケストレーターにあるのか、それともデータウェアハウス自体にあるのかを判断するのに半日かかる。
ある時点で、チームの誰かが口に出して言う。「うち、高い統合ツールを偶然作ってしまったんじゃないか」
その通りであることがほとんどだ。
カテゴリーの錯誤
データウェアハウスは、問い合わせと保存を行うエンジンである。ある一つのこと、すなわち大規模なデータセットに対して分析上の問いに高速に答えることに最適化されている。
Data Pipelineは、データを移動・処理するランタイムである。異なる目的、すなわち必要な場所に、適切な形で、適切なタイミングで、確実にデータを届けることに最適化されている。
これらは別の仕事だ。しかしこの10年、私たちは静かにデータウェアハウスに両方を求めてきた。
最初は無害なことから始まった。データウェアハウスはデータの読み込みを得意にした。次にストアドプロシージャが登場した。そしてdbtがSQLを処理レイヤーに変えた。さらにオーケストレーターがデータウェアハウスの問い合わせをトリガーしてテーブル間のデータを移動させ始めた。誰が名付けたわけでもないのに、データウェアハウスは標準の統合レイヤーになっていた。
結果は予想どおりだ。データウェアハウスは分析には優れている。統合には平庸である。そしてそれをスケールで統合に使わせると、コスト、信頼性、そしてアーキテクチャのもろさという三つの通貨で支払うことになる。
データウェアハウスがData Pipelineになったときに起きること
コンピュート料金が予想外になる
データウェアハウスのコンピュートは分析用の問い合わせ向けに課金される。アナリストはいくつかの大きな問い合わせを実行し、結果を待ってから意思決定を行う。コンピュートは断続的で、人間のペースに合わせたものだ。
統合ワークロードはそうは見えない。継続的に、またはきついスケジュールで実行される。数百万行を移動し、同じ変換を何度も繰り返す。人間がダッシュボードを読むために一時停止することはない。
この種のワークロードをデータウェアハウス内で実行すると、メーターの回り方が違う。「単純な」毎時の同期が、分析ワークロード全体よりも多くのクレジットを消費することは珍しくない。データウェアハウスが悪いわけではなく、その仕事にはエンジンが向いていないだけだ。
障害が不透明になる
Data Pipelineには明確な仕事がある。Aからデータを取り、変換し、Bに届ける。失敗したとき、どのステップで、なぜ失敗したのかを知りたい。
データウェアハウスがData Pipelineである場合、障害はレイヤー全体に分散する。ロードが遅かったのはデータウェアハウスが過負荷だったからか。オーケストレーターが接続を失ったのか。変換用の問い合わせがタイムアウトしたのか。データが誤っているのはソースのせいか、変換のせいか、それともデータウェアハウスの実行計画の変更によるものか？
デバッグは考古学になる。問い合わせ履歴、オーケストレーターのログ、データウェアハウスのメトリクスを掘り起こし、実際に何が起きたのかを再構築しようとする。ツールはそろっている。明確さがないだけだ。
Latencyはデータウェアハウスの都合次第
Data Pipelineが一連のデータウェアハウスの問い合わせでできているなら、Latencyはデータウェアハウスのスケジューリングによって左右される。問い合わせはキューで待つ。コンパイルされ、実行される。プリエンプトされるかもしれない。スケールアップするかもしれない。しないかもしれない。
バッチ分析ではこれで問題ない。夜間レポートが午前3時に終わろうが3時15分に終わろうが、誰も気にしない。
しかし運用のユースケースでは問題だ。不正検知、在庫更新、顧客向けダッシュボード — これらには分や秒が必要で、データウェアハウスのキュー待ち時間ではない。データウェアハウスがあなたのData Pipelineであるとき、そのペースを引き継ぐ。そしてそのペースは運用ではなくアナリスト向けに設計されている。
ロックインが深まる
データウェアハウス内部に統合ロジックが増えるほど、脱却は難しくなる。書き換えはデータウェアハウス特有のSQL方言で行われる。オーケストレーションはデータウェアハウスのセッションに縛られる。データ品質ルールはデータウェアハウスの問い合わせとして実行される。コストの可視性さえデータウェアハウス色に染まる。
これは陰謀ではない。一つのツールが多くの仕事を引き受けたときに起きることだ。移行コストは増え続け、不満を抱えたまま留まる方が去るより楽に感じられるほどになる。
クリーンな分離がどのように見えるか
解決策はデータウェアハウスを捨てることではない。データウェアハウスは得意なことをこなせる。解決策は、それに得意なことをさせ、それ以外のすべてを求めるのをやめることだ。
実際には、これは通常一つではなく二つのプラットフォームを意味する：
統合・オーケストレーションランタイム
ここではデータが移動し、再整形され、検証され、適切な消費者へルーティングされる。Data Pipelineのスケジューリング、失敗の再試行、依存関係の強制、下流の処理のトリガーもここで行われる — プラットフォーム内部でも外部システムでもだ。ここでは、問い合わせのLatencyではなく継続的なデータフロー向けに設計されたエンジンが動く。
データウェアハウス
ここではデータが保存され、問い合わせられる。統合レイヤーから、きれいで問い合わせ可能な状態のデータを受け取る。データがどうやって到達したのか、次のロードはいつ来るのか、ジョブが失敗したらどうするのかを気にする必要はない。問い合わせに答えるだけだ。
論理的には、統合とオーケストレーションを別の関心事と考えられる。運用面では、両者はしばしば同じランタイムに属する。データは動かせても、自分でスケジュールできず、再試行できず、次のステップをトリガーできないData Pipelineは、半分しか役に立たない。最良のプラットフォームは両方を組み合わせる。
これらの関心事がデータウェアハウスから分離されると、各ツールはシンプルになる。統合レイヤーはThroughputと信頼性に最適化される。オーケストレーターは依存関係の管理と障害復旧に最適化される。データウェアハウスは問い合わせ性能に最適化される。
最も重要なのは、問題が自分の領域に留まることだ。取り込みに失敗したら、統合ランタイムを見る。レポートに誤りがあれば、データウェアハウスを見る。ジョブが実行されなければ、オーケストレーターを見る — クリーンな構成では、それはデータを動かす同じランタイムの一部だ。
データウェアハウス as Data Pipelineが実際に問題ない場合
これを過剰に主張したくはない。一部のチームにとって、データウェアハウスをData Pipelineとして使うパターンはうまく機能する。
規模が小さく、データ量が少なく、再整形が単純で、Latency要件が「明日でいい」なら、すべてを一か所に置くことは合理的なトレードオフだ。運用のシンプルさは、建築上の純粋性よりも価値がある。
問題は、そのパターンが自然な限界を超えてスケールし続けたときに始まる。成長しすぎたチームは通常、それを自覚している。請求が奇妙になり、障害が不可解になる。リアルタイムのユースケースを追加するアイデアが、設定変更ではなく数か月のプロジェクトになる。
問うべきは、そのパターンが悪いかどうかではない。今の自分たちにとってそれが適切なパターンかどうかだ。
誰も取らない移行パス
ほとんどのチームは、この分離をまるごと置き換えるプロジェクトだと考える。そうである必要はない。
より良いアプローチは、まず移動レイヤーを切り出すことだ。一つのデータソースを選ぶ。直接データウェアハウスに読み込み、そこで再整形するのではなく、まず専用の統合ランタイムを通して移動させる。クリーニングし、検証する。そしてクリーンなデータをデータウェアハウスに書き込む。
データウェアハウスはそれほど変わらない。アナリストは同じテーブルを問い合わせ続ける。ただし、これらのテーブルは、テーブルへの供給を目的に設計されたData Pipelineによって供給されるようになる。
一つのソースが移行されれば、パターンは繰り返される。ソースごとに。Data Pipelineごとに。時間をかけて、データウェアハウスは統合のハブではなく、本来あるべき分析のハブになる。
これを成功させるチームは、最も難しいData Pipelineから始めない。退屈なものから始める。退屈なData Pipelineが、リスクなしにパターンを教えてくれる。パターンが確立されれば、難しいData Pipelineも楽になる。
layline.ioが位置する場所
率直に言おう：これがlayline.ioの背後にあるアーキテクチャ上の賭けだ。
私たちは、統合とオーケストレーションのレイヤーを処理するデータ処理プラットフォームを構築した — バッチとStreamingの両方を — データウェアハウスに重労働をさせずに。Data Pipelineはデータを移動させ、再整形し、検証し、届ける。また、自分たちでスケジューリングし、失敗時に再試行し、依存関係を強制し、layline.io内部または外部システムのWorkflowsをトリガーする。
データウェアハウスはデータを保存し、問い合わせる。各ツールがそれぞれの仕事をする。
layline.ioが同じランタイム内でバッチとStreamingの両方を扱うため、時間ごとのロード用とリアルタイムイベント用に別々のツールを用意する必要がない。同じWorkflows、同じ可観測性、同じチームだ。そしてオーケストレーションが組み込まれているため、layline.ioとその他すべての間を調整する別のオーケストレーターを上に乗せる必要もない。
これはすべての人に向けた売り込みではない。データウェアハウス as Data Pipelineの構成が機能し、請求も健全なら、私たちは必要ない。しかしデータウェアハウスの請求が3倍になり、「単純な」同期がなぜこんなに高くついたのか疑問に思っているなら、私たちが説明している分離こそが、実際に求めているものだろう。
チームに問いかけるべき質問
最もコストのかかるデータウェアハウスのワークロードを3つ選べ。最大の分析問い合わせではなく — 一日中動き、データを移動・再整形しているものだ。
問いかけよう。これらのワークロードはビジネス上の問いに答えているのか、それともビジネス上の問いに答えられる形にデータを整えているだけなのか？
答えが後者なら、分析エンジンの中で統合処理が動いていることになる。それは道徳的な欠陥ではない。非常に一般的なアーキテクチャだ。しかし同時に、修正可能なアーキテクチャでもある。
データウェアハウスは強力なツールだ。ただし唯一のツールではない。
Andrew Tanは、layline.ioの創業者であり、バッチとリアルタイムの両方のワークロードをスケールで処理する企業データ処理インフラストラクチャを構築する連続起業家です。
