「ゼロETL」という言葉に惹かれて、最初に頭に浮かぶのは“面倒な変換作業が消える未来”でした。ところが現実はもう少しだけ泥臭くて、取り込みと変換の責務をどう切り分けるか、失敗したときにどこで食い止めるか、そこを決めた瞬間に運用のしんどさが半分になる、というタイプの話でした。自分が「openflow dbt」で調べ始めたのも、データ基盤の話が増えるほど、取り込みの都合で下流のモデルが壊れ、下流の都合で上流の再取り込みが増え、結局だれが何を直すのかが曖昧になる、そんな状態に疲れていたからです。
最初に触ったのはSnowflakeの世界観でした。すでにDWHの中心に据えていたので、ここを起点に“データの入口”を整えたい。そこで候補に上がったのがOpenflowです。触ってみると、いわゆるELの部分、つまり「外部から持ってきて、置ける形にして、運べるようにする」工程に強い手触りがありました。何が嬉しいかというと、取り込みの手順が画面のフローとして可視化され、どこで落ちたか、何が詰まっているかを見つけやすい。自分は最初の週、接続先の権限とネットワークの小さな制約で何度も止まりましたが、そのたびに“止まった場所”が把握できるのは精神的に助かりました。ログを追いかけて夜が更ける、あの感じが減るだけでも価値があります。
一方で、取り込みが形になった瞬間に次の悩みが来ます。届いたデータをどう整えるか。ここでdbtが効いてきました。自分が腹落ちしたのは、Openflowに「取り込む責務」を持たせ、dbtに「変換の責務」を持たせると、会話がスムーズになることでした。具体的には、Openflow側では“欠損しないで届ける”“再実行できる”“遅延や順序のブレが見える”を優先し、dbt側では“モデルの意味を固定する”“テストで壊れ方を定義する”“ドキュメントで共有する”を優先する。全部をどちらかに寄せるのではなく、境界線を引くことがポイントでした。
境界線を引くときに一番悩んだのは、スキーマの揺れです。ソースがRDBでもAPIでも、列が増える、型が変わる、NULLの意味が変わる、こういう出来事はだいたい月曜の朝に起きます。最初は「揺れを上流で吸収しよう」と思ってOpenflow側で整形を厚めにしました。ところがそれをやるほど、フローの変更が増えてレビューが重くなり、結果として“変更は早いけど、説明が追いつかない状態”になりました。そこで途中から方針を変え、Openflowでは原則として“取り込んで保全する”に寄せ、揺れはdbt側で段階的に吸収するやり方に寄せました。列の追加は受け止め、意味付けは下流のモデルで行う。モデルのテストで「この列が突然NULLだらけになったら異常」といった壊れ方を定義し、早めに気づく。これにしてから、変更対応の心理的負担が落ちました。上流をいじる回数が減ると、失敗時の切り分けも速くなります。
運用で本当に効いたのは、再実行とバックフィルの設計でした。最初は「失敗したらもう一回流せばいい」と軽く考えていましたが、下流にdbtの増分モデルがいると、上流の再実行は“同じデータがもう一度来る”を意味します。重複が出るのか、遅延が出るのか、順序が変わるのか。ここを曖昧にすると、数日後に数字がじわじわズレていくタイプの事故になります。自分がやったのは、取り込みの段階で「一意性を担保するキー」を必ず持たせ、dbt側で増分の取り込み条件と突き合わせることでした。言い換えると、上流は“データを運ぶ”、下流は“データを確定させる”。この役割分担を、障害対応の手順書にもそのまま落とし込みました。結果として、誰が見ても「いま壊れているのは運搬なのか、確定なのか」が分かるようになり、夜間対応が一気に静かになりました。
実際に“1本のパイプライン”を通したときの手応えも書いておきます。最初の成功体験として、毎日更新される小さめの業務テーブルを対象にしました。Openflowで取り込み、Snowflakeに置き、dbtでモデル化し、テストを数本だけ入れて可視化につなぐ。この小さな流れを作ったことで、「どこまでが取り込みの責任で、どこからが変換の責任か」がチームで共有できました。驚いたのは、技術的な難しさよりも、運用の言葉が揃うことの効果です。「今日はOpenflowの遅延だ」「いや、dbtのテストが落ちたから下流の意味が変わってる」みたいな会話ができるようになると、原因究明が“議論”ではなく“確認”になります。
最後に、ゼロETLの期待値の整え方です。自分の結論は、ゼロETLは「ETLを消す魔法」ではなく、「ETLの場所と責任を整理して、摩擦を減らす考え方」でした。Openflowとdbtを組み合わせると、入口の安定と下流の意味付けが分離できて、壊れたときの直し方が素直になります。逆に、上流で変換まで全部済ませたい、下流のモデルはなるべく触りたくない、というチームには刺さりにくいかもしれません。けれど、変化が多いデータを扱いながら、毎朝の数字を安心して眺めたいなら、この組み合わせはかなり現実的な落としどころでした。自分は今でも、月曜の朝に新しい列が増えたときの心拍数を思い出します。でも以前より確実に、「どこで受け止めれば被害が小さいか」を説明できるようになりました。それだけで、運用の景色は変わります。
コメント