## フォルダ設計 実用的な運用パターン ```sh /data///y=/m=/d=
/ # 例 /data/marketing/silver/y=2025/m=06/d=01/*.csv /data/marketing/silver/y=2025/m=06/*.parquet # サブドメインパターン /data/>/ /data/sales/orders/bronze/y=2025/m=06 ``` ### パーティションディレクトリ構造 (Hive partitioning) * y=2025/m=06/d=01/ のように key=value で階層を切るのは、Hadoop/Hive 系からの習慣です。 * BigQuery、Athena、Spark、Trino、DuckDB などほとんどのエンジンが理解できます。 ### レイヤ * bronze/ = 生データ(取ってきたまま、CSVなど) * silver/ = 整形済み(型そろえ、Parquet化、パーティション付与) * gold/ = 集計/マート用(ダッシュボード直結) “品質レベル”が一目でわかる。AWSやGCPでもよく使う。 ### ファイル名などのイベント規則 フォルダで年月やドメインを切っているので、 ファイル名は中身や分割単位を表す情報を載せるのが一般的です。 * イベント種別 or データセット名 * `orders, clicks, refunds`など * 日付/時間(分割単位) * 2025-06-01, 2025-06-01-15h など * バージョン or チャンク番号 * 再生成や分割を考慮して _v1, _part-0001 ```sh # サンプル clicks_2025-06-01_v1.csv impressions_2025-06-01_v1.csv conversions_2025-06-01_v1.csv # チャンク clicks_2025-06-01_part-0001.csv ``` ## パイプライン型パターン * ELT型(データ)：Extract(取得) → Land(保存) → Transform(SQL/dbt/duckdb) * ML型：データ準備 → 特徴量 → 学習 → 評価 → 登録(MLflow/Weights&Biases) * イベント処理：ストリーム受信 → 変換 → 集計 → マート出力(Kafka→Druid/Pinot/ClickHouse * バッチETL：取り込み → 正規化 → 検証 → 出力(Airflow/Dagster/Luigi/Prefectでオーケストレーション) * dbt型：ソース → ステージング → マート(SQL中心・テストとドキュメント込み) ### ETL / ETL #### ELTとは (Extract → Load → Transform) `取得 → DBへロード → 変換`の流れで実行 変換は SQL や dbt など、DWH自体の計算能力を使う。 BigQuery / Snowflake / Redshift などのクラウドDWHの時代に主流になった。 **メリット** * 生データを残せる（Landに置くので後から再処理できる） #### ETLとは (Extract → Transform → Load) `取得 → 変換 → DBへロード`の流れで実行 90年代〜2010年代前半までの「オンプレDWH」時代によく使われた。 変換はアプリケーションサーバーや専用ETLツールでやるイメージです ## 汎用性を高めるための設計原則 * I/Oはアダプタ分離：FS/GCS/S3/DB接続は adapters/(同じ関数シグネチャで差し替え) * 実行ドライバは3種 * CLI(ローカル/CI): `python -m app run --date 2025-09-13` * HTTP(GCF/Cloud Run): main(request) → 同じ関数を呼ぶ * スケジューラ(Cloud Scheduler / cron / GitHub Actions) ## 用語集 **ETL / ELT** Extract, Transform, Load(または Load, Transform) データパイプラインの基本パターン **データレイク (Data Lake)** 生データをフォーマット問わず保存する場所。S3/GCS/HDFSなど **データウェアハウス (DWH)** 整形済みデータを分析用に最適化して保存するDB(BigQuery, Snowflake, Redshift など)