Fivetran のコストとスキーマの課題：データ取り込みの摩擦を自動モデリングで解消

Fivetran を導入した最初の 1 ヶ月は極めて快適です。午後の数時間でコネクタが開通し、ウェアハウスにデータが蓄積され、チームは迅速にレポート構築へ着手できます。しかし、基幹 ERP の大規模マイグレーションや一括更新の後に届く請求書を見た瞬間、社内の空気は一変します。そして同じ頃に、固定されたスキーマ構造に関する深刻な課題が噴出し始めます。

プラグ＆プレイ ELT が要求する見えない代償

マネージドな取り込みサービスは「手軽さ」と引き換えに 2 つの重要な要素を差し出すことを要求しますが、その代償は導入初日には表面化しません。

• コストの予測不可能性： Monthly Active Rows（MAR：月間アクティブ行数）は変更されたデータ行を課金対象としますが、何行が変更されるかを決定するのは、データ移行や一括更新を実行するソースシステム側の開発チームです。請求額は自社の予算計画ではなく、他チームの作業カレンダーに振り回されます。詳しくは MAR 課金に関する記事をご覧ください。
• スキーマ制御の喪失： 各コネクタは標準化された独自のスキーマでデータをランディングさせます。複数ソースを統合するビジネスキー、カスタム属性、システム横断ルールはすべてその上に手作業で構築しなければならず、ソース側の仕様変更によって容易に破損します。詳しくは 固定スキーマに関する記事をご覧ください。

これら 2 つの問題は本質的に同一です。「データを運ぶだけのツール」に、コストの決定権とデータ形状の設計責任まで負わせてしまったことが原因であり、そのツールは本来そこまでを担うようには設計されていないのです。

2 つの解決策（両方を同時に採用可能）

コストを圧迫しているテーブルの内製化： Datavault Builder は、データベース、ファイル、REST API、NoSQL、Python ソース、さらには Kafka ストリーム（マイクロバッチ）からのバッチ、差分、CDC ロードを標準装備しています。MAR の大半を占めている少数の巨大テーブルはプラットフォームを介して直接取り込み、既存の自社コンピュート上で処理します。ロングテールの SaaS ソースは、安価なコネクタにそのまま任せます。

すべての背後に自社所有のデータモデルを配置： コネクタ経由であれ直接ロードであれ、ステージングにランディングされたデータは、Data Vault 2.0 モデル（ビジネスキーのための Hub、リレーションシップのための Link、コンテキストと履歴のための Satellite）へと視覚的にマッピングされます。ロード用コードはそのモデルから自動生成されます。ソースの変更はマッピングの修正だけで吸収され、その上位にある Business Vault やデータマート層には一切悪影響を及ぼしません。

現場で得られる具体的なメリット

• 全件リロードはステージングに留まる： Vault には差分（デルタ）のみがロードされるため、上流で全件リロードが発生しても、上位レイヤー全体を全件再処理する必要はありません。
• 顧客データは 3 つのテーブルではなく 1 つの Hub に統合： 複数ソースにまたがるキーはモデル内で一度だけ統合され、完全なリネージが保持されます。
• ビジネスルールの一元管理： ビジネスロジックは Business Vault またはデータマート層に集約され、モデル内で明確に可視化されます。無数の SQL スクリプトやノートブックに分散することはありません。
• BI ツールには使い慣れたスタースキーマを提供： Vault の上にディメンショナルマートが自動生成されるため、レポート作成者が複雑な Vault 構造を意識する必要はありません。
• コストを自社のリソース計画として管理： ウェアハウスのコンピュート費用は自社で測定・予約・予測可能です。他社システムの予測不能な行数変動に振り回されることはありません。

何から始めるべきか

まずは半日かけて 2 つのリストを作成してください。MAR レポートをテーブル順に並べ替えたリストは「どのソースを直接取り込みへ移行すべきか」を教えてくれます。コネクタの出力スキーマを再加工するためだけに作られた SQL スクリプトの一覧は「モデルに何を定義すべきか」を教えてくれます。どちらのリストも想像以上に短く、それこそがプロジェクトの全体像そのものです。