ドキュメントを追加

This commit is contained in:
ry.yamafuji 2025-09-15 13:11:45 +09:00
parent a6200d2809
commit c09b288ff6
2 changed files with 239 additions and 0 deletions

139
docs/collect.md Normal file
View File

@ -0,0 +1,139 @@
# データ収集
## コンポーネントについて
| コンポ―ネント | 内容 |
| ---------------- | ---------------------------------------------------------------------- |
| Parquet | 列指向のバイナリ形式のデータファイル |
| DuckDB | 手元で動く小さなDWH / Parquet/CSVに強い(ローカル向け) |
| BigQuery | マネージド型の DWHデータウェアハウス |
| ClickHouse | 列指向DBの代表格超高速集計、リアルタイム分析 |
| Apache Druid | 時系列分析やダッシュボード用途に強い / Supersetと相性がよい |
| Apache Pinot | Druidに似ていて、リアルタイム分析に特化広告配信やA/Bテスト分析など |
| Jupyter Notebook | |
| Metabase | |
| Superset | |
### DuckDB(クエリエンジン)
軽量・組み込み型の分析データベース
SQLiteが「小さなトランザクションDB」なら、DuckDBは「小さなOLAPエンジン」。
イメージとしては以下の通りです。
SQLite小さなアプリ用に最適化されたトランザクションDB
DuckDBデータ分析のために最適化された組み込みエンジン
* サーバ不要
* 1つのライブラリプロセスで動く。インストールもシンプルPython, CLI, R, C/C++など)
* 列指向ストレージ:大量データのスキャンや集計に強い。
* 外部ファイルを直接クエリできるのが大きな特徴。
**ユースケース**
* 毎月の CSVやParquetを置くだけで分析
* Jupyter NotebookやPythonスクリプトの中で 即席SQLエンジンとして活用
* BIツールMetabase / Superset / Tableauに接続して レポート化
### Parquet
Parquetパーケイ は列指向のバイナリ形式のデータファイル です。
Apache が開発したオープンフォーマットで、ビッグデータ処理や分析用に広く使われています。
* Parquet のファイル拡張子は .parquet(例: `logs_2025_09.parquet`)
* 列指向フォーマット
* 圧縮効率が高い
* 列ごとに同じ型・似た値が並ぶため、圧縮Snappy/Zstd/Gzipなどが効きやすい
* CSVは全部テキスト扱いだが、Parquetはカラムごとに「整数」「浮動小数」「日付」などの型を保持
* park / Hive / Presto / BigQuery / Snowflake / DuckDB / Pandas など、ほとんどの分析基盤がネイティブ対応
**CSV(行)**
```csv
id,name,age
1,Alice,24
2,Bob,30
3,Charlie,28
```
**Parquet (列指向・バイナリ)**
```
id: [1,2,3]
name:[Alice,Bob,Charlie]
age: [24,30,28]
```
### BigQuery
マネージド型の DWHデータウェアハウス
提供元はGoogle Cloudです
* サーバ運用不要(完全マネージド)
* データを GCS に置いて「外部テーブル」でクエリも可能
* 料金は ストレージ+スキャンしたデータ量に応じて課金。
* 同時接続や大規模並列処理が強く、Looker StudioなどBIツールと相性抜群。
* 無料プラン
* 毎月ストレージ部分で少量(例 10GB)まで無料の枠がある。
* クエリ処理も、毎月一定量(例 1TB の処理量)まで無料。
**ユースケース**
* 数百GB〜PB規模のデータをクラウドでガッツリ分析したいとき。
* 運用を省きたいとき
### ClickHouse
列指向DBの代表格超高速集計、リアルタイム分析
ログ分析、イベントデータ処理に強い。
## システム構成
### 1. CSV
PoCならCSVのみで運用することも多々あります
運用ルールとしてよくあるのは以下のようなものです
* ディレクトリは y=YYYY/m=MM[/d=DD] のHive風で粒度を切る
* ファイル名は 日付+ソース+バージョン を含める
`例: events_2025-09-13_sourceA_v1.csv`
* スキーマ/品質
* スキーマ表用意(列名・型・必須/NULL・説明
* 区切り・エンコーディング(UTF-8)・改行コード(LF) を固定
* ヘッダ1行固定、列順は変えない変えるなら列マップを同梱
* NULLは "" or 明示トークンNULLで統一
* タイムスタンプは ISO 8601 (UTC推奨)2025-09-13T00:00:00Z
### 2. CSV + DuckDB + Parquet
運用する際にディレクトリ構成に設計が必要になります。
ディレクトリ設計例
```
data/
raw_csv/
y=2025/m=09/*.csv # “年/月”で月次パーティション
parquet/
y=2025/m=09/*.parquet # 変換先(後述のバッチで作る)
duckdb/
lake.duckdb # メタ・ビュー定義だけを持つDBファイル
```
### 3. (列指向DWH) ClickHouse/Apache Druid/Apache Pinot
ClickHouse / Apache Druid / Apache Pinot は、CSV以外のフォーマットや
ストリームからそのまま取り込みできますし、直接INSERTや外部ファイルを直接クエリも可能です
基本は直接で速い・型が保てる・圧縮効率がよく・読み取りコスト低い
### 4. GCSのCSV/Parquet + BigQuery

100
docs/data.md Normal file
View File

@ -0,0 +1,100 @@
## フォルダ設計
実用的な運用パターン
```sh
/data/<domain>/<layer>/y=<YYYY>/m=<MM>/d=<DD>/
# 例
/data/marketing/silver/y=2025/m=06/d=01/*.csv
/data/marketing/silver/y=2025/m=06/*.parquet
# サブドメインパターン /data/<domain/<subdomain>>/<layer>
/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 など)