概要
エンジニアのためのデータ分析基盤入門を読んで、重要そうなところをメモする。
データ分析基盤とは何か
- データ分析のために作られたシステム
- つまり、データ基盤とは異なるシステムである。
以下の書籍によると、データ基盤はデータ分析だけを目的にしてない。
ビジネスアプリケーションからの利用も想定している。
Google Cloudで始めるデータエンジニアリング入門
- つまり、データ基盤とは異なるシステムである。
- データレイク、データウェアハウス、データマートの３つを合わせたもの
- データレイク
- 構造化＆非構造化データ
- ローデータをそのまま保管
- データウェアハウス
- 構造化データ
- 整理されて管理された状態のデータ
- データマート
- 構造化データ
- データウェアハウスと、データマートには明確な線引きはない
- ダッシュボードなど、特定の目的のために作られている
- 構造化データ
- データレイク
データ分析基盤の変遷
データ分析基盤を取り巻く人
- データエンジニア
- データを集めて統合
- データ分析基盤やデータパイプラインの整備
- 分散システムの構築管理
- データの取り込みやETLを通したデータパイプラインの最適化
- データが格納されているストレージの管理
- ユーザへのアクセス提供
- データサイエンティスト
- データアナリスト
- ビジネスプロセスに詳しい
- SQL、BIツール
- データから価値を見出す
セルフサービスモデル
- 従来のモデル
- データマートやダッシュボードの作成もデータエンジニアが担う
- セルフサービスモデル
- データエンジニアはパイプラインの新規作成、システム不具合対応、コスト最適化に集中
- データマート作成はデータアナリストが、ダッシュボード作成はユーザが行うという風に分担する
# 正直あまりイメージが湧かない、、、
データエンジニアリングで心に留めておくべき事項
- さまざまなインターフェースを提供
- メタデータの取得（データの在り処をわかりやすく示す）
- データ品質の可視化
- パフォーマンスの向上（パーティション、ファイルフォーマット、圧縮を駆使する）
- コストの最小化
- 障害が起こりにくい
- すぐに復旧できる
データ世界のレイヤー
- コレクティングレイヤー：データを集める（バッチ、ストリーミング）
- プロセシングレイヤー：データを処理する
- ストレージレイヤー：データを保持する
- アクレスレイヤー：データを利用する
プロセシングレイヤー
ETLとデータラングリング
- データラングリング（データプリパレーションとも呼ばれる）
- ETLとデータラングリングの違い
- どちらもデータを変換するという点では一緒
- 「データラングリングでデータから価値を見つける。データラングリングで見つけたルールを、ETLにてワークフローとして定義する」という感じ
暗号化
- トランスペアレントエンクリプション：書き込み時に暗号化、読み出し時に復号
- エクスプリシットエンクリプション：読み込み、書き込みも元のデータがわからなくしてしまう
- ディアイデンティフィケーション：個人を特定しにくくする。データを入れ替えたり、別の値に置き換える
データ品質/メタデータ計算
ストレージレイヤー
5つのゾーンに分けて管理することで、ライフサイクル設定やアクセス権限の整理が容易になる - ローゾーン - 集めたデータをそのまま保存しておく（データレイク） - ゴールドゾーン - データウェアハウス、データマート - ステージングゾーン - データを不変な状態で保管。オリジナルのデータを修正してしまうと戻せなくなる。ステージングゾーンのデータをもとにゴールドゾーンを修復する。 - クォレンティンゾーン - 機密情報を保持する隔離されたゾーン。アクセス権限を絞る。 - テンポラリゾーン - 気が向いたときに好きなデータを取り込む。自動的に削除される設定を入れておくと良い。
タグによるゾーン管理
- 物理的なゾーン分け
- 例えば、ゾーンごとにストレージを分ける
- ゾーン間のデータ移動に時間や費用といったコストがかかる
- タグによるゾーン分け
- タグを変更するだけで、ゾーンを変更できる
- 物理的なデータの移動が発生しない。瞬時にゾーンが切り替えられる
- 例えば、タグ毎にアクセス制御を設定することで、アクセス管理が容易になる
アクセスレイヤー
SSOT (Single Source of Truth)
- フィジカルSSOT：物理的にデータを1か所に集める
- ロジカルSSoT：データを1か所に集めたように見せる
バックアップ
- フルバックアップ：すべてのデータをバックアップする
- 一部のデータをバックアップする
- バージョニング：コストは高くなるが効率的にバックアップと復元が可能
アクセス制御
以下の粒度で制御を行う - ゾーン - データベース - テーブル - カラム
技術スタック
コレクティングレイヤー
プロセシングレイヤー
ワークフローエンジン
- Digdag
- Apache Airflow
- Rundeck
ストレージレイヤー
フォーマット
- Paruquet
圧縮形式
- Snappy
- gz
- bz2
スプリッタブルとは - 1つのファイルを複数のノードに分けて処理可能
◆ スプリッタブルなフォーマットと圧縮形式の組み合わせ | | Paruquet | Avro | CSV/JSON | | ---- | ---- | ---- | ---- | | Snappy | Y | Y | - | | gz | Y | Y | N | | bz2 | - | - | Y | | 無圧縮 | Y | Y | N |
データ保管時の注意点
- スモールファイル：小さすぎるファイルが沢山ある
- データスキューネス：ファイル間でファイルサイズに偏りがある。1つのファイルが巨大で、もう一方のファイルが相対的に小さい
アクセスレイヤー
アクセス制御
- chmod/chown
- IAM
メタデータ管理
ビジネスメタデータ
テクニカルメタデータ
- テーブルの抽出条件：テーブル取り込み時の抽出方法
- リネージュ、プロバナンス
- テーブルのフォーマット（Paruquet、Avro）
- テーブルのロケーション
- ETL完了時間
- テーブル生成予定時間
リネージュとプロバナンス
- リネージュ：データの紐付き
- プロバナンス：データの生まれ、起源
オペレーショナルメタデータ
- テーブルステータス
- In-Service：当日のワークフローが完了
- Error：当日のワークフローでエラーが発生
- Investigating
- メタデータの更新日時
- ファイルサイズの中央値
- 誰がアクセスしているか
データプロファイリング
- カーディナリティ
- どれくらいデータがばらけているか
- 性別はカーディナリティ低。IPアドレスはカーディナリティ高
- データ分析基盤では特に意識する必要なし
- セレクティビティ
- カラムの値がどれくらいユニークか。値が高いほどユニーク。最大値は１
- 全５レコード中、５レコードとも異なる値 → セレクティビティは、1 = 5/5
- 全５レコード中、２レコードが同じ値。つまり、カラムには４種類の値が存在 → 0.8 = 4/5
- デンシティ NULL
- NULLの密度
- NULLの密度が高ければ、そもそもカラムをクエリ―の対象から除外するという判断につながる
- コンシステンシー
- 参照整合性
- IDのフォーマットや、カラムの論理名に一貫性があるか
- コンプリートネス
- 全レコード中、すべてのカラムに値が入っているレコードがどれくらいあるか
- データ型
- レンジ：特定の範囲内の値に収まっているか
- フォーマット：郵便番号の桁など
- 形式出現頻度
- データ冗長性
- 最小値は１。小さいほど良くて、１だとベスト。
- 数値が高いと、色んなところにコピーが存在してしまっている
- 数値が低ければ、データが１か所に集まっている。つまり、SSoTが実現できている
- バリディティレベル
- アクセス頻度
- テーブルがどれだけアクセスされているか
- 不要なデータを検知する
- その他
- 合計、最大値、最小値、平均値、標準偏差
データカタログ
どのようなデータが存在しているか。以下のような情報をカタログに記載する - データタイトル - 形式（CSV、JSON） - データのオーナー
