「実践的データ基盤への処方箋」読書メモ
Posted at
1章 データ活用のためのデータ整備
- データの一連の流れを把握し、入り口から出口までを書き出す
- ソース → コレクション → レイク → ウェアハウス → マート → ユースケース
- CRUD表
- 用語の整理
- データの品質は生成元のデータソースで担保する
- データが生じる現場を把握して業務改善につなげる
- CRUD表
- ERD
- 業務レイヤ
- 組織の枠を超えて改善の仕組みを作る
- 課題に気づく: FB
- 解決したいと思える: インセンティブ
- 簡単に解決できる: UX
- データソースの整備ではマスタ・共通ID・履歴の3つを担保する
- データレイク層の一か所にデータソースのコピーを集約する
- オブジェクトストレージかウェアハウス
- コピーするだけにする
- 複数個所に作らない
- データウェアハウス層では分析用DBを使って共通指標を管理する
- Single Source of Truthを形成する
- BIツールは転用しにくい
- 共通指標は本当に必要とされるものを用意する
- クレンジング、スタースキーマ作成、共通指標の集計をしてウェアハウスを作る
- 初期段階ではウェアハウス層をつくらない: 共通指標が固まってから
- 特定用途に利用するデータマートはユースケースを想定して作る
- 影響範囲を制限できる
- ロジックを再利用できる
- 応答時間が短くなる
- ワークフローエンジンを利用する
- メンテナンス難
- 組織横断のクリーニングの仕組み
- BIツールにロジックが移動する
- ユースケースを優先的に検討しツールの整備を逆算する
- ユースケースの便益以上に手間をかけない
- 組織課題からブレイクダウンする
- データの調査コストを減らすためにメタデータを活用する
- レイクではカラムなどデータの説明文を作成する
- ウェアハウスやマートではワークフローエンジンやETLツールを活用する
- サービスレベルを設定・計測して改善サイクルにつなげる
- ユースケースごとに設定する
- 関係者、対象データ、品質水準、違反時の影響、を記述する
- 過剰品質にしない
- データ基盤の品質を支えるデータスチュワードの役割を設ける
- データ利用者とデータ生成者の橋渡し
- 問い合わせ対応と整備の推進
2章 データ基盤システムのつくり方
- 一般的なデータ基盤の全体像と分散処理の必要性を理解する
- データソースごとに収集方法が違うこと、その難しさを理解する
- 最も難しいコンポーネント
- robots.txt
- フェデレーション: データ仮想化、データがあるかのように振る舞う
- ファイルを収集する場合は最適なデータフォーマットを選択する
- ファイルシステム
- 配置完了キュー
- 収集処理
- データ構造も同時に収集する
- avro: schema on read
- データの量を減らしたい場合はparquetを検討する
- APIのデータ収集では有効期限や回数制限に気を付ける
- SQLを利用したデータベース収集ではデータベースへの負荷を意識する
- テーブルが大きい場合はフェッチを利用する:
fetchmany
- 収集が間に合わない場合はテーブルの一部だけを収集する
- 追記されるだけのテーブル: 追記分の一部
- 更新もされるテーブル: 更新日のデータを取得、更新前後のテーブルを交換することも
- インデックスを活用する
- それでも間に合わない場合は並列実行する
- レプリカを用意する
- キャッシュ汚染を回避する
- 長時間クエリを避ける
- 一時ファイルによるディスク圧迫を避ける
- データベースの負荷を考慮したデータ収集では、エクスポートやダンプファイル活用を視野に入れる
- ワークフローエンジンを活用する
- デメリット
- バックアップ用のダンプファイルを流用する
- 更新ログ経由のデータベース収集はデータベースの負荷を最小限にしてリアルタイムに収集できる
- データではなく操作を収集する
- 更新ログを出力するようにする: ログから復元する、そんなにメリットはない
- 帯域を減らせる
- 専用ツールが必要になる
- 仕組みが複雑になる
- CDCツールを利用する
- RDBとWHのパフォーマンスの差異
- Striim
- 障害時の再実行が難しい
- ログ収集はエージェントのキャパシティに注意
- アクセスログ
- アプリケーションログ
- fluentd, logstash, cloud watch, cloud logging
- 端末データの収集は難易度が高いためできるだけ製品を利用し無理なら自作する
- ブラウザイベント、スマホアプリイベント、IoT
- ブラウザイベントやスマホアプリイベントでは製品を検討する
- 自作する場合は分散メッセージキューを使う
- 順序性保証の有無
- メッセージの重複有無
- 可視性タイムアウト
- デッドレター: どのコンシューマも処理できないメッセージ
- バックプレッシャー: プロデューサに対して生成量を抑止する仕組み
- ETL製品を選ぶポイントは利用するコネクタの機能性とデバッグのしやすさ
- embluk, fluentd, Sqoop, Nifi, talend, glue, dms, data fusion, trocco
- ソースコードレベルでデバッグしやすいものを選ぶ
- データレイクでは収集したデータをなくさないようにする
- そのまま格納する
- データがオンプレミスにあってもレイクはクラウドにする
- データウェアハウスには抽出や集計に特化した分析用DBを採用する
- 分析用DBはクラウド上で使い勝手が良い製品を選ぶ
- Hadoop or DWH
- on-premise or cloud
- gui
- 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気を付ける
- データの一部の更新・削除は苦手
- データの読み飛ばし
- 全件削除する場合はdropする
- テーブルを更新する場合は新たなテーブルを用意して置き換える
- データを入れるときは複数件まとめて入れる
- 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する
- ワークフローエンジンは専用か相乗りかをまず考える
3章 データ基盤を支える組織
- アセスメントによって組織の現状を客観的に把握する
- レベル
- 1: データ活用の初期段階で、属人的にデータが活用されている
- 2: データ活用プロセスに最低限の統制がとられ、再現可能である
- 3: データ活用における基準を設け、それが守られている
- 4: プロセスを数値化し、モニタリング・管理できている
- 5: プロセス改善のゴールを数値化し、それに向けた最適化に取り組んでいる
- 文化
- データ活用を妨げる文化要素はないか
- データを誰がどのように管理しているか
- 業務と組織構造
- データ活用の狙いと業務遂行に乖離がないか
- 組織戦略においてデータが果たす役割はどれくらい認識されているか
- スキルと人
- 組織の状況に合わせて組織構造を採用する
- データ組織を構成する職種と採用戦略の基本を押さえる
- データ活用とセキュリティはトレードオフの関係にあることを理解する
- ステークホルダー
- 法規制
- 現場のニーズ
- ビジネス上の検討事項
- 組織の利益となるデータのセキュリティポリシーとそのセキュリティ基準を定める
- 情報資産への従業員のアクセス可否
- 職責や役割に応じたセキュリティ、アクセス可否
- セキュリティ違反報告ポリシー
- アプリケーション、データベースの保護
- 情報のセンシティビティにおけるカテゴリ分類
- e.g. セプテーニ
- confidentiality, integrity, availability
- 適切な権限設定とリスク管理方法を定める
- データ利用や権限管理などの運用ルールをドキュメント化する
- 社内でデータを活用したいメンバー必要な情報
- 情報の場所と種類
- アクセス権限
- 承認フロー
- 問い合わせ窓口
- 権限管理者に必要な情報
- 各種権限の設定情報
- ユーザーの権限の情報
- 権限を付与したり、変更したりするオペレーションについて
- ユーザーの削除方法
- IaC
- 担当、見直しサイクル、判断基準を決めてデータやツールの棚卸を定期的に行う
- 不正アクセスに備えてデータ保護や匿名加工技術を適用する
- 個人情報
- 生年月日
- 名前
- 住所
- 電話番号
- メールアドレス
- など
- 監査では評価方法を理解して客観性を担保する
- Information Security Management System
- PDCA
- リスクアセスメント
- 対策基準
- 自社にとって最適な管理策は何か
- どのように分かりやすく記載するか
- 脅威
- 脆弱性
- リスク
- 技術的対策
- 管理的対策
Register as a new user and use Qiita more conveniently
- You get articles that match your needs
- You can efficiently read back useful information
- You can use dark theme
What you can do with signing up