データ基盤の土台はクラウドDWH（データウェアハウス）です。代表3つはSnowflake（仮想ウェアハウスで干渉を避けられる）、BigQuery（サーバーレスで管理不要）、Databricks（レイクハウスで機械学習まで一気通貫）。出自と得意領域が違うので、自社の既存クラウド・ワークロード・チームスキルで選びます。

「どれが最強か」ではなく「自社に合うか」で決めます。GCPに資産があるならBigQuery、SQL中心の全社共有ならSnowflake、機械学習まで踏み込むならDatabricks、というのが現場の当たりです。

クラウドDWHの普及で、「変換してから入れる」ETLから「まず生データを入れて、後でDWH内で変換する」EL+T（Extract-Load + Transform）に主流が移りました。取り込みはマネージドSaaSのFivetran、OSSのAirbyte、独自API用の自前ELの3択です。

運用負担最小化ならFivetran、コスト・柔軟性ならAirbyte、独自要件のみ自前。新規プロジェクトはFivetranで動かしてからコストを見て移行、という段階的アプローチが現実的です。

取り込んだ生データを、いきなりダッシュボードで使うと壊れます。Bronze（生データ）→ Silver（クレンジング・統合）→ Gold（用途別マート）の3層に分けて整える、というのがメダリオンアーキテクチャの考え方です。Databricksが提唱し、いまや業界の事実上の標準です。

3層に分けることで、変更の影響範囲を限定でき、層ごとに責任とテストを分けられます。「全テーブルを直接Goldで作る」のは、最初は速いが半年で破綻するアンチパターンです。

変換層（Bronze→Silver→Gold）の実装で、いまの定番がdbt（data build tool）です。SQLでモデル（変換ロジック）を書き、依存関係はdbtが解決します。テスト・ドキュメント・リネージが一体化しているのが強み。

データ量が増えてくると、毎晩のfull-refreshが終わらなくなります。そこで使うのが「incremental models」。「初回は全件、以降は差分だけ追記」する設計で、変換時間とコストを大きく下げられます。unique_keyとon_schema_changeの設定、遅延データ対策の窓を入れることが運用の核心です。

「数字が間違っていた」は信用を一発で失います。dbtにはテスト機能があり、unique・not_null・accepted_values・relationshipsを宣言的に書けます。これだけで「主キーの一意性」「外部キーの整合性」「列挙値の妥当性」が毎回チェックされます。

dbtの外側で監視したいテーブルが増えてきたら、Sodaのような宣言的YAMLツール、Great Expectationsのような統計的検査、Monte Carloのような機械学習ベースのオブザーバビリティを段階的に組み合わせます。dbt testsから始めるのが鉄則です。

取り込み・変換・品質チェックが揃ったら、毎日確実に動かす仕組みが要ります。cronで足りるのはジョブ10〜20程度まで。依存関係が増え、失敗時のリトライ・再実行・通知が要件になったら、Airflow（業界標準）・Dagster（データアセット中心）・Prefect（Pythonで素直）のいずれかを検討します。

dbt中心の新規プロジェクトならDagsterが相性◎、既存実績・求人で安全を取るならAirflow、シンプル運用ならPrefect。マネージド版（Astronomer・Dagster+・Prefect Cloud）を使うと、運用負担を大きく下げられます。