目次
第0章 ［速習］データ分析基盤と周辺知識 データ分析基盤入門プロローグ
0.1 データ分析基盤とサービスの提供先 サービスの提供先は4つに分類される
- SoR/SoE/SoI システムは3つに分類される
- データ分析基盤とSoR/SoE/SoI/人 SoIはサービスの提供先とのハブ
0.2 データ分析基盤と周辺技術 データ開発以外でも利用するツールも活躍
- データ分析基盤から見たデータベースとストレージ 役割が異なるストレージとデータベースを使いこなそう
- オブジェクトストレージ データ分析基盤でデータを保存するといったらここ
- RDB オーソドックスなデータベース
- KVS 高速なアクセスを提供するデータベース
- Web API システムを疎結合するためのインターフェース
0.3 データ分析基盤と外部との接点を理解しよう データ分析基盤もユーザー接点が大事
- データの可視化 データの可視化により行動の変革を促す
- 外部への付加価値の提供 データをアプリケーションと連携していこう
0.4 データ分析基盤開発とサポートツール データ開発以外でも利用するツールも活躍
- 単体テスト テストの基本はデータ分析基盤も同じ
- CI/CD 自動化してデータとシステムの品質を上げよう
- コマンドライン オペレーションの効率を高める
- 監視/運用 監視対象を決め継続的に状況を可視化し対策する
0.5 本章のまとめ
第1章 ［入門］データ分析基盤 データ分析基盤を取り巻く「人」「技術」「環境」
1.1 データ分析基盤の変遷 多様化を受け入れるために進化する
- データとは何か パターンと関係を捉えるための情報源
- 構造データと非構造データ
- データ分析基盤とは何か パターンと関係を知るためのツールの一つ
- データ分析基盤の変遷 単一のノードから複数ノードへ
- シングルノード時代 個人のPCで分析する時代
- マルチノード/クラスター時代 限られたグループで基盤を利用して分析する時代
- クラウド時代 全社員が分析する時代
- 主要なクラウド関連のプロダクトとデータ利用の流れ
- データ分析基盤が持つ役割 データレイク，データウェアハウス，データマートという名称
- データレイク 非構造データを保持する役割
- データウェアハウス 構造化されたデータを保持する役割
- データマート テーブルを掛け合わせたデータを保持する役割
- データレイク，データウェアハウス，データマートの違い データ量の規模は関係ない
1.2 処理基盤/クラスターの変遷 よりマネージレスにしてコストを減らし，より本来の業務へ集中する時代
- 分散処理の登場 Hadoop MPP，そしてオンプレミスからクラウドへ
- スレッド処理と，マルチノードにおける分散処理 従来のスレッド処理との違いに注目
- Hadoopの登場 Hadoopエコシステムとその進化
- MPPDBの登場 RDBの技術要素をビッグデータにも
- クラウドでのマネージレスなクラスターの登場（Hadoop，Kubernetes，MPPDB） Hadoopがクラウドへ
1.3 データの変遷 ExcelからWeb，IoT，そして何でもあり（!?）へ
- 増え続けているデータ 有り余るほどあるデータ
- 重要性や認知を増すデータ 意思決定の大半はデータにより行われる
- 機密性を増すデータ 個人識別情報が含まれるのが普通
- 種類の増すデータ 決済情報，ログデータ，ストリーミングなど
- 活用方法の拡大 不正検知，パーソナライズ，機械学習，AI，検索
1.4 データ分析基盤に関わる人の変遷 データにまつわる多様な人材
- データエンジニアのスキルセット 全米で急上昇な仕事8位（IT業界以外含む）
- データエンジニアリング領域
- データエンジニアに求められる知識 データエンジニアとスモールシステムの知識
- データサイエンティストのスキルセット データから価値を掘り出す
- データアナリストのスキルセット データから価値を見い出す
1.5 データへの価値観の変化 データ品質の重要度が高まってきた
- 量より質＝Quality beats quantity
- データ品質とデータ管理への注目度が高まっている
1.6 データに関わる開発の変遷 複雑化するプロダクトと人の関係
- データエンジニア中心のシステム 何をするにもデータエンジニアを介さなければならなかった
- とりあえずエンジニアに頼む 一部の玄人しか利用できない基盤
- DataOpsチームの登場 価値のあるものを選択し素早くデータを届けることに価値を置く
- セルフサービスモデルの登場 各個人に権限を委譲，大人数で長期間運用することを前提とした構成
1.7 本章のまとめ
第2章 データエンジニアリングの基礎知識 4つのレイヤー
2.1 データエンジニアリングの基本 ポイントと本書内の関連章について
- みんなにデータを届けよう ニーズを押さえた品質の高いインターフェース
- パフォーマンスとコストの最適化 パーティション，圧縮，ディストリビューション
- データドリブンの土台 数値で語る
- シンプルイズベスト
2.2 データの世界のレイヤー データ分析基盤の世界を俯瞰する
- データ分析基盤の基本構造 データ分析基盤を俯瞰する
- コレクティングレイヤー データを収集するレイヤー
- プロセシングレイヤー 収集したデータを処理するレイヤー
- ストレージレイヤー 収集したデータを保存するレイヤー
- アクセスレイヤー ユーザーとの接点となるレイヤー
2.3 コレクティングレイヤー データを集める
- ストリーミング 絶え間なくデータを処理する
- バッチ 一定以上の塊のデータを処理する
- プロビジョニング ひとまず仮にデータを配置する
- イベントドリブン イベントが発生したら都度処理を行う
2.4 プロセシングレイヤー データを変換する
- ETL 次の入力のためにデータを変換する
- データラングリング データに対する付加価値をつける
- データラングリングの3つの作業
- データストラクチャリング データを構造化する
- データクレンジング データの精度を高める
- データエンリッチング データ分析のための準備作業
- ETLとデータラングリングの違い データに対する付加価値をつける
- 暗号化/難読化/匿名化 データを推測しづらくしてセキュリティやプライバシーに配慮する
- トランスペアレントエンクリプション シンプルな暗号化方式
- エクスプリシットエンクリプション 機密データの暗号方式
- ハッシュ化 元のデータをわかりにくく変換する
- ディアイデンティフィケーション 特定しにくくする難読化手法の一つ
- 匿名化と匿名加工 個人情報を復元できないようにする加工
- データ品質/メタデータ計算 データの状態を可視化する
- モデルの作成 世の中の事象をルールに当てはめる
- モデルを利用した推論 データをルールに通したらどうなったのか
- リバースETL データを外部システムに連携する
2.5 データ分析基盤におけるデータの種別とストレージ戦略 プロセスデータ，プレゼンテーションデータ，メタデータにおける保存先の選択
- プロセスデータ/プレゼンテーションデータ/メタデータ データの種別と利用用途の組み合わせにより格納場所が変わる
- 各種データとデータ置き場オーバービュー データの種類とアクティビティによって保存先を使い分けよう
2.6 ストレージレイヤー データやメタデータを貯蔵する
- データレイク/DWH プロセスデータをメインとして管理する場所
- マスターデータ管理 マスターデータによってデータはもっと活きる
- データ活用型のマスターデータ管理 既存のシステムが大量にある場合はこの方式がお勧め
- データのライフサイクル管理 データの誕生から役目の終わりまで
- データのゾーン管理 データを管理するときの基本
- プレゼンテーションデータストア 外部アプリケーションとの連携を前提とした保存場所
- メタデータストア メタデータを管理/保存する場所
2.7 アクセスレイヤー データ分析基盤と外の世界との連携
- GUI Web画面の提供
- GUIを通したメタデータの参照/更新 みんなの強い味方
- GUIを通したデータ分析基盤へのオペレーションの提供
- BIツール（SQL）アクセス データアクセスの王道
- ストレージへの直接アクセス データの貯蔵庫へ直接アクセスをする
- ［参考］Sparkにて，プロセシングレイヤーからストレージレイヤーのParquetファイルを読み込む
- ファイル連携 ファイルを介したデータの連携
- データエンリッチング データに付加価値をつける
- クロスアカウントによるアクセス アカウントを分けてアクセス
- API連携 データ分析基盤へのアクセスをラップする
- データ分析基盤をAPIを通して操作可能にする ジョブの実行から指標提供まで
- プレゼンテーションデータ向けのAPI活用 活用データを利用して改善サイクルを回そう
- メタデータアクセス 指標提供を行う
- 分散メッセージングシステム ストリーミングデータを一時保存するところ
2.8 セマンティックレイヤーとヘッドレスBI アクセスレイヤーを拡張して外部へのデータ提供をより効率的に行う
- セマンティックレイヤー アクセスレイヤーを拡張して指標を統一しよう
- データ利用における不確実性 同一目的に対するアプローチのばらつき
- セマンティックレイヤーの効果と配置パターン データの一貫性を確保するための最適なアプローチ
- ヘッドレスBI データ提供をより確実に簡単にするソリューション
2.9 本章のまとめ
第3章 データ分析基盤の管理＆構築 セルフサービス，SSoT，タグ，ゾーン，メタデータ管理
3.1 セルフサービスの登場 全員参加時代への移行期
- データ利用の多様化 データに対する価値観が異なる人たち
- 従来のエンジニア中心のモデル Analytics as IT Service
- セルフサービスモデル Analytics as Self-Service
- セルフサービスモデルの特徴 ユーザーごとに適切なインターフェースを提供する
3.2 SSoT データは1ヵ所に集めよう
- データのサイロ化 とくに避けるべき事態
- フィジカルSSoT 実際にデータを1ヵ所に集める
- ロジカルSSoT 1ヵ所に集めたようにユーザーに見せる
3.3 データ管理デザインパターン ゾーンとタグ
- タグとゾーンを組み合わせる 管理の汎用性を向上させる
- タグを使った論理ゾーン化によるゾーンの管理 物理的ロケーションに囚われずに管理する
- タグによるデータ管理 物理ゾーン化の弱点を解消する
- GAパターン 一般公開は少し待ってから
- GAパターンにおけるデータの動き データは手続きを得て公開される
- プロビジョニングパターン お好きなときにお好きにどうぞ
- プロビジョニングパターンにおけるデータの動き ユーザー主体で分析可能
- プロビジョニングパターンとGAパターンの弱点 人のボトルネック
- システムによる自動チェック データのチェックは機械（システム）にまかせる
3.4 データの管理とバックアップ データ整理と，もしものときの準備
- テーブルによる管理 ビッグデータの世界でもテーブル
- ロケーション テーブル定義と物理データの分離に対応する
- パーティション ビッグデータでは必須。データの配置を分割する
- データのバックアップと復元 一番怖いのは「人」
- フルバックアップ すべてのデータをバックアップしておく
- 一部のデータをバックアップするパターン しくみやルールで解決
- 復元方法も考えておく いざ戻せないと意味がない
- バージョニング 効率的なバックアップ＆復元手段
3.5 データのアクセス制御 ほど良いアクセス権限の適用
- データのアクセス権限 できる限りオープンな環境作り
- アクセス制御の種類 アクセス制御が必要になる背景にも注目
3.6 One Size Fits All問題 デカップリングで数々の問題を解決しよう
- デカップリングを前提に考える One Size Fits All問題への対応
- 障害時の影響の最小化 できる限り持続可能なシステムに
- 計算リソースの最適化 システムによって，元々の要件が異なる
- ストレージレイヤーとプロセシングレイヤーの分離 デカップリングの基本戦略
- コレクティングレイヤーやアクセスレイヤーの分離 ソフトウェアやミドルウェアのアップデートを簡単に
3.7 データのライフサイクル管理 不要なデータを残さないために
- データの発生 絶え間なく生まれるデータ
- データの成長 データのバトン
- データの最後 そして，生まれ変わる
- サマリー化 サマリーによるデータ圧縮
- コールドストレージへデータをアーカイブ 使用頻度の低いものは，アクセス速度の遅い場所に配置
- 不要なデータは削除する データマートやデータウェアハウスのデータ
3.8 メタデータとデータ品質による管理 データを知る基本ツール
- メタデータストアはどのように管理される データベースやマネージドツールなど
3.9 ハイブリット構成 柔軟に技術を選択しよう
- ハイブリット構成の大きなメリット 柔軟な機能実現と，データ統合コスト削減
- データバーチャライゼーション そもそも取り込まない（!?）
- ハイブリッドのデメリット 迷わせないことがデメリット解消の一歩
- ❶データの所在，オーナーが不明になりやすい
- ❷管理対象の増加によるコスト増大や障害復旧の複雑化
3.10 データ分析基盤とSLO/SLA データ分析基盤の説明書を作る
- SLO/SLAとは？ システムのお約束
- データ分析基盤とSLO より目線を上げて規定する
- 可用性 どれだけ継続可能か
- データの取り扱い データはどのように管理されている？
- パフォーマンス/拡張性 どこまでの規模を想定する？
- セキュリティ 基本的な対策で思わぬ落とし穴を防ごう
- 技術/環境要件 データ分析基盤を構成する要素と動いている場所は？
3.11 本章のまとめ
第4章 データ分析基盤の技術スタック データソースからアクセスレイヤー，クラスター，ワークフローエンジンまで
4.1 データ分析基盤の技術スタック 全体像を俯瞰する
- データ分析基盤のクラスター選択 データ分析基盤における計算能力の要
- クラスターの計算能力 インプットを処理してアウトプットするための能力
- コレクティングレイヤーの技術スタック 多種多様なデータを取り込む入り口
- プロセシングレイヤーの技術スタック 多種多様なデータを処理する場所
- ストレージレイヤーの技術スタック 多種多様なデータを格納する場所
- アクセスレイヤーの技術スタック 多種多様なアクセスを提供する場所
- 全体を通して利用する技術スタック 堅牢なデータ分析基盤運用を支えるツール
4.2 データ分析基盤のためのクラスター選択 無理な利用にも耐えられる必要がある
- Hadoop ビッグデータの黎明期，オンプレミスのHadoopの問題
- デカップリングの登場 クラウド環境のクラスター
- Hadoop on クラウド Hadoopのマネージドは今でも便利
- EMRとDataproc クラウド上で簡単に分散処理を実現する
- Kubernetes コンテナライズされた環境
- MPPDB ビッグデータシステムでも使えるスモールデータシステムの技術
- HA環境下のLinuxサーバー 切っても切り離せないLinuxサーバー
- SaaS型データプラットフォーム インフラの構築/管理の手間を省き別作業へシフトする
4.3 コレクティングレイヤーの技術スタック セルフサービス時代のデータの取り込み
- コレクティングレイヤーオーバービュー データソースによって技術を使い分けよう
- バッチ処理のデータ取り込み データの塊を一度に処理する
- Embulkを活用したデータ収集 プラグインが豊富な取り込みの王道
- CLIを活用したデータ収集 さまざまなコマンドを使いこなしてデータ収集しよう
- API経由でのデータ収集 制限や速度に注意しながら取り込み方法を工夫しよう
- ストリーミングのデータ取り込み 組み合わせの基本
- 分散メッセージングシステム Kafka pub/sub kinesissなど
- プロビジョニング データを簡単に素早く取り込む
- イベントドリブンにおけるデータ取り込み 応答性を確保して逐次処理する
4.4 プロセシングレイヤーの技術スタック データ変換を行うレイヤー
- バッチ処理のデータ変換 王道のデータ変換
- Apache Spark 最強のコンピューティングエンジンの登場
- Apache Hive
- ストリーミング処理のデータ変換 データを1行ずつ処理する
- ストリーミングETL データに付加価値をつける
- Spark Structured Streamingと分散メッセージングシステム ストリーミングにおける組み合わせの基本
- データ転送 データ分析基盤間，プロダクト間，クラウドベンダー間の連携
- データをバッチで転送する際に気をつけるポイント 正しく送られているか確認しよう
- プロダクトの連携時によく使われるファイルのバッチ転送方法 クラウドベンダーのコマンド
- クラウド間でよく使われる転送方法 オンプレミス，クラウド間で使われるツール
- ストリーミング処理における転送方法
- ストリーミングデータの送受信で気をつける点 データの重複，遅延，偏りに注意
- リバースETL データ分析基盤から外部システムへデータを連携する
4.5 ワークフローエンジン データ取り込みと変換を統括する
- データパイプラインとワークフローエンジン 次へつながるインプットに着目する
- 汎用型と特化型 大まかな分類
- データ分析基盤向けのワークフローエンジン選択 5つのポイント
- Digdag 汎用型ワークフローエンジン
- Apache Airflow Pythonで定義可能
- Rundeck GUIが直感的で使いやすい
4.6 ストレージレイヤーの技術スタック データの保存方法
- データレイクやDWHで扱う技術スタック データ保存の効率化と最適化
- ❶ストレージレイヤーが扱うフォーマット データウェアハウス，データマートで何を使うか
- ❷列指向フォーマットと行指向フォーマット パフォーマンスと用途の違い
- Parquet 多くのデータ分析基盤はこのフォーマットで事足りる
- Avro ストリーミングや，部門間にまたがり開発する際に有効
- ❸データ分析基盤が扱う圧縮形式 特性と選択基準に注目
- ❹その形式は「スプリッタブル」か 分散処理可能な組み合わせを選ぼう
- スプリッタブル 適度に分割したほうが処理しやすい
- 圧縮形式とフォーマットの組み合わせ スプリッタブルな組み合わせかどうかが重要
- ❺データストレージの種類 基本的なストレージから，データ分析基盤に特化したストレージまで
- オブジェクトストレージ データレイク/DWHにおけるデータ保存候補としての筆頭
- プロダクトストレージ オブジェクトストレージより早い処理が可能
- オンプレミスにおけるストレージ 安価になったSSD
- ❻データストレージへのデータ配置で気をつけたいポイント 偏りをできる限りなくそう
- 1ファイルの大きさ スモールファイルに注意
- データスキューネス データやファイルサイズの偏りに注意
- ❼オープンテーブルフォーマット 既存フォーマットを拡張するソフトウェア
4.7 プレゼンテーションデータを扱う技術スタック 効果的なデータ参照のための設計戦略
- データモデル設計 データ分析基盤では参照要件を気にしよう
- プレゼンテーションデータストアにおけるデータ保存 データ分析基盤から外部システムへデータを書き込む
4.8 アクセスレイヤー構築の技術スタック セルフサービス時代のユーザーへのデータ提供
- BIツールを提供する 万人とつながる可視化ツール
- 参照者が多い場合に利用するBIツール シンプルなダッシュボード向け
- 編集者が多い場合に利用するBIツール 大半のBIツールはこの部類
- SQLの提供 最強のデータ分析/活用技術
- Presto（Trino） BIツールを通して，よく実行されるSQLのタイプ❶
- PostgreSQL BIツールを通して，よく実行されるSQLのタイプ❷
- ノートブック 多様なデータアクセスを提供するインターフェース
- Jupyter Notebook オープンソースの対話型ツール
- APIを提供する データ分析基盤へのインターフェースとして活躍
4.9 セマンティックレイヤー 統一的なデータを提供しよう
- セマンティックレイヤーとは何か アクセスレイヤーを拡張する
- BIツールと連携したセマンティックレイヤー セマンティックレイヤーの意義を実例を使って理解しよう
- ヘッドレスBIの活用 データ提供をより確実に簡単に実現する
4.10 アクセス制御 アクセスレイヤーに対するアクセス制御
- ユーザーの認証と制御の歴史 大きなデータ（大量のファイル）を持つデータ分析基盤特有の悩み
- chmod/chown ジェネラルアクセスパーミッション
- IAM ロールベースパーミッション
- タグ（属性）による管理
4.11 コーディネーションサービス 分散システムを支える影の立役者
- コーディネーションサービスとは何か ノード間の同期を円滑にする要
- コーディネーションサービスの役割 システムの安定性を支えるしくみ
- アンサンブル構成 コーディネーションサービスも冗長化する
4.12 本章のまとめ
第5章 メタデータ管理 データを管理する「データ」の重要性
5.1 データより深いメタデータの世界 データは氷山の一角
- メタデータとは何者なのか データを表すデータ
- なぜメタデータを提供する必要があるのか データを見つけるためにデータを検索するのは非効率
- ❶疑問点の解消につながる 解答の糸口を持っている
- ❷データに対するドメイン知識のギャップを緩和できる 暗黙のルールは言語化しにくく，またできる人が限られている
- ❸データを利用するシステムや人の動きを統一する 指標を用いて統一感を出す
- ❹非同期にデータを利用する状況を作る 生産性向上に寄与
- ❺アクセス権限に縛られずデータを見つけるヒントになる データを見つけられないジレンマ
5.2 メタデータとデータ 3つのメタデータを整理/整備しよう
- データより深いメタデータ データ理解へのインターフェースとなる
- ビジネスメタデータ テーブルやデータベースの意味を表すメタデータ
- データプロファイリング データの形はどのような形か
- テクニカルメタデータ 技術的な内容を表すメタデータ
- テーブルの抽出条件 実はオリジナルデータと違うかもしれない
- リネージュとプロバナンス テーブルのデータはどこから取得しているか
- テーブルのフォーマットタイプ フォーマットの違いがもたらす課題に注目
- テーブルのロケーション テーブルが参照しているデータはどこにあるか
- ETLの完了時間 処理は終わっているか
- テーブルの生成予定時間 次はいつ実行されるか
- データの最終更新日時 データの鮮度を確認する
- オペレーショナルメタデータ データの5w1hを表すメタデータ
- テーブルステータス そのテーブルは使えるか，使えないか
- メタデータの更新日時 ドキュメントはいつ更新したか
- 1ファイルのデータのサイズ スモールファイルは常に気をつける
- 更新頻度 データ更新の誤解を防ぐ
- 誰がアクセスしているか オペレーショナルメタデータにおける5W1H
5.3 データプロファイリング データの状態を知る
- データプロファイリングの基礎 データの特性からデータそのものを推論
- データプロファイリング結果の表現方法 大別すると2パターン
- データプロファイリングをどのレベル（単位）で表現するか カラムレベルからデータベースレベルまで
- カーディナリティ どれくらい値はばらけている？
- セレクティビティ ユニークさを表現する。1なら，そのカラムはユニークである
- デンシティNull NullもしくはNullに匹敵するものの密度
- コンシステンシー 一貫性があるか？
- リファレンシャルインテグレティ（参照整合性） データにはお互いに結合（SQLなどでJOIN）できるのか
- コンプリートネス 値はNullではないか
- データ型 年齢は数字か
- レンジ 特定の範囲内か？
- フォーマット 郵便番号は7桁かなど
- フォーマットフリークエンシー（形式出現頻度） フォーマットのパターンはどれくらいある？
- その他の基本的なプロファイリング項目 年齢は数字か
- データリダンダンシー データが何ヵ所に存在しているか
- バリディティレベル 有効か否か
- フリークエンシーアクセス どれだけアクセスされているか？
5.4 データカタログ 手元にないメタデータはカタログ化しよう
- データカタログとは カタログを見て注文する
- データカタログの必要性 データには3種類の認知が存在する
- データカタログはECサイト データを取り寄せる
5.5 データアーキテクチャ メタデータの総合力としてのリネージュとプロバナンス
- データアーキテクチャ データフローの設計書
- リネージュ テーブルの紐付きを表す
- ❶データ生成の方法が記載されているので，利用している技術スタックの見通しが良くなる 改善のヒントになる場合も
- ❷障害時のトラッキングが行いやすくなる もしもの事態に備えよう
- ❸オーナーの明確化が可能 いざという時の問い合わせ先
- ❹データの設計書を残せる データ分析基盤ユーザーのための設計書
- ❺プロバナンスやメタデータと統合する データのルーツをめぐる
- プロバナンス データのDNAを表す
- データモデル 表現の粒度
5.6 本章のまとめ
第6章 データマート＆データウェアハウスとデータ整備 DIKWモデル，データ設計，スキーマ設計，最小限のルール
6.1 データを整備するためのモデル DIKWモデル
- DIKWモデル データの整備されていくステージを示す
- Data 断片的なデータ
- Information（情報） 分類されたデータ
- Knowledge（知識） データからパターンと関係を見つける
- Wisdom（知恵） ルールから新たなひらめきを産む
6.2 データマートの役割 「Data」を整備して知恵の創出をサポートする
- データマートとは何か 「Data」を「Information」にすること
- KnowledgeやWisdomのない世界 知識と知恵を生み出すための土台がない
- データマートとデータウェアハウスの違い データを掛け合わせて新価値を作る
- 中間テーブルとデータマートの違い 中間テーブルで十分な場合が多い
- データマートを生み出す苦しみ 使ってもらうのは大変です
6.3 スキーマ設計 データに関するルールを設計する
- スキーマ設計の考え方 スキーマ設計によりデータの利活用効率を上げよう
- スタースキーマ オーソドックスなスキーマ設計の一つ
- 非正規化 データ分析基盤特有のテーブル設計
- データ分析基盤でJOINはコストの高い操作
6.4 データマートの生成サポート コミュニケーションの省略＆活用
- データ分析基盤ができるサポート データマートを代わりに作ることではない
- コミュニケーションの不要な中間テーブルの生成方法 粛々と中間テーブルを作成する
- アクセスログとExplainを使って機械的に生成する アクセスの分析結果を活用する
- アクセスログを利用した方法のさらなるメリット
- コミュニケーションの必要な中間テーブルの生成方法 ビジネスに直結したクエリーしやすいテーブルを作成する
- Viewによる中間テーブルの作成 手軽にクエリーしやすくする
- 履歴テーブルを作ろう 過去に遡る分析に備えよう
- オープンテーブルフォーマットを利用しない場合（データレイクそのままの場合）
- オープンテーブルフォーマットを用いた場合
6.5 データマートのプロパゲーション メタデータやルールの作成
- データマートを自由に作成してもらうために 作りっぱなしを防ぐ
- アクセス頻度を確認 要不要はアクセスログが知っている
- データマート生成停止の条件を定める 作った後もしっかりとメンテナンスをする
- アクセス数が減ってきたときの対応策 データマートは時間の経過とともに劣化する
- 環境整備におけるメタデータの役割 情報伝搬のツールとして使う
- オペレーショナルメタデータ 活用例❶
- ビジネスメタデータとしてデータマートのテーブル定義を管理 活用例❷
6.6 ストリーミングとデータマート 瞬時にKnowledge化する
- ストリーミング処理におけるデータマート作成 バッチとは処理単位が違うだけ
- ストリーミングにおけるデータマート作成の流れ Avroフォーマットの活用
- Avroフォーマットとデータマート作成
- 分散メッセージングシステムの連鎖 Aの出力はBへの入力
6.7 本章のまとめ
第7章 データ品質管理 質の高いデータを提供する
7.1 データ品質管理の基礎 データ蓄積から次の段階へ進む
- 本書で扱うデータ品質管理について
- データ品質管理の三原則 事前に防ぐ。見つける。修正する
- 三原則の適切な割合 どれかに偏り過ぎるのはNG
- データ品質について データの状態を継続的に可視化し改善を示唆する
- データ分析基盤におけるデータ品質担保の難しさ ステークホルダーがあちらこちらにも
- データ品質を測定する 6つの要素
- データ品質の指標とデータの見方
- データ品質 システム観点での重要性＋コスト削減効果も
- 分析観点での「データ品質」の重要性 分析のための煩雑な作業を緩和する
- 不確実性観点での「データ品質」の重要性 揺らぎを排除できるか？
- 生産性観点での「データ品質」の重要性 「ちょっと違う」に要注意！
7.2 データの劣化 データは放置するだけで劣化する
- データの劣化の原因 データの移動時と時間の経過に注意
- データの往来 データ分析基盤に到着する前にも劣化する
- データの変換 システムの守備範囲，データマートの作成
- 時間の経過 10年前のデータは正しいデータか
- 人的要因 人にはミスがある
- さまざまな劣化に早く気づき修正する
7.3 データ品質テスト 劣化に気づくための品質チェック
- データ品質テスト実施の流れ
- レベル 品質テストを行う粒度の設定
- カラムレベルで行うことができるテスト データの単体テスト
- 正確性のテスト 基本的なデータ品質の項目
- ユニーク性と有効性のテスト 社内の常識の範囲
- 一貫性のテスト 一貫性は取れているか
- 適時性のテスト 必要なときに正しいデータが存在しているか
- 完全性のテスト データはしっかりと情報を持っているか
- テーブル間で行うことができる一貫性のテスト データを整えるために必要なテスト
- ナチュラルキーの特定を行う トランザクションIDなど
- エクスターナルコンシステンシー 外部と一貫性をテストする
- テーブル単位で行うことができるテスト シンプルなテストでも効果絶大
- その他のテスト データの基本的な特徴を表す
- 単体テストとデータ品質のテストは違う（?!） 2つのテストで相乗効果を狙おう
7.4 メタデータ品質 生産性を向上させるために
- メタデータの名寄せ テーブルの名称やカラムは統一されているか
- 言語の認識合わせ あなたの第一クォーターは，あの人の第一クォーターか
7.5 データ品質を向上させる 品質テストの結果を活かす
- データのリペア データ不備を修正する/未然に防ぐ
- データ品質管理におけるプリベンションにつなげる リペア方法❶
- すでにストレージレイヤーに存在するデータの不備を見つけて修正する リペア方法❷
- ユーザーからのデータ修正依頼 リペア方法❸
- インサイドアウトとアウトサイドイン 内から，外からデータを修正する
- チェックし過ぎに注意 80％を善しとする
- メタデータと連携したデータ品質の表現方法
- データの品質を事実で表現する
- データの品質を数値で表現する
7.6 本章のまとめ
第8章 データ分析基盤から始まるデータドリブン データ分析基盤の可視化＆測定
8.1 データ分析基盤とデータドリブン エンジニアもデータドリブンに行こう
- データドリブンと狭義のデータドリブン データのみを元に行動を起こす
- 広義のデータドリブン メタデータとデータ，両方用いて行動する
8.2 データドリブンを実現するための準備 データ分析基盤のPDCAと数値
- データドリブンのためのPDCA
- KGI/（CSF）/KPIを定義して課題設定する まずは目標設定から
- データ分析基盤におけるKGI/（CSF）/KPIの設定
- 測定用のツールで改善前後の数値を測定 事前の数値取得は忘れずに
- BIツールでの可視化 ベーシックな可視化手法
- 監視ツールでの可視化 便利なツールはいっぱいあります
- 他ツールでの可視化 見やすくすることを意識しよう
- アクションを決める 簡単にできて効果の高いものを選ぶ
- アクションの実施 複数チームや組織における実行
- SLO システムが交わすユーザーに対して守るべきKPI
- コレクティングレイヤーにおけるSLO
- プロセシングレイヤーにおけるSLO
- ストレージレイヤーにおけるSLO
- アクセスレイヤーにおけるSLO
8.3 KPIをどのように開発に活かすのか データ分析基盤の「コスト削減KGI」の例
- PDCAを高速に回す Planに時間をかけ過ぎない
- コスト削減KGI 間接部門のわかりやすい成果指標
- データ分析基盤のためのPDCAの例
- コスト削減KGIの設定 コストは安いほうが良い
- コスト削減CSFの設定 どのような課題があるか
- コスト削減KPIの設定 重要な指標を選択する
- KPI改善のためのアクション設定 意外とある簡単でも効果の高いもの
- アクションから得る学び 成功や失敗を次に活かそう
8.4 データ分析基盤観点のKGI/（CSF）/KPI 改善の着眼点
- クエリーのしやすさKGI SQLの実行しやすさ
- JOINの数 一体いくつのテーブルが結合されているのか
- クエリーの実行時間 クエリーが遅過ぎる
- データスキャン量 どれくらいのデータがスキャンされているか
- フリクションKGI データを利用するまでにかかる時間
- データパイプラインの処理時間 データを早く届ける
- 調整コスト より合理的に無駄を省く
- データマネジメントKGI データをしっかりと守っています
- データリダンダンシー データの冗長性はどれくらいある？
- データ品質 データの「良さ」を定量的に表現する
- データエンゲージメントKGI データ利用はどれくらい広がっている？
- 配置率 センサーやJavaScriptファイルなど
- 参画人数 メタデータのエンゲージメントはどのくらいか
- SQLの発行数 全体で発行されているSQLの数
- 発行ジョブ数 データ分析基盤の成長指標
- 参画人数 アクセスログを使う
- さまざまな数値がKPIになり得る 数値管理との違い
8.5 本章のまとめ
第9章 ［事例で考える］データ分析基盤のアーキテクチャ設計 豊富な知識と柔軟な思考で最適解を目指そう
9.1 テーマとゴールを考えてみよう 基本的な要件で思考の順番を掴もう
- テーマとゴール 基本的な要件でアーキテクチャのイメージを掴もう
- 技術的な前提条件の整理 基本的な要件でアーキテクチャのイメージを掴もう
9.2 データ分析基盤の骨格を考えよう まずは大きなデータの流れについて考慮しよう
- データのアウトプットを起点に考えよう 目的のないデータ分析基盤の構築はやめよう
- インプットとアウトプットを見比べて全体のロジックをつなげる データソースとインプットは整合性が取れているだろうか
- アウトプットとインプットデータの整合性確認
- どのようなBIツールを利用するか
- 為替の考慮
- どのようにデータを収集するか 技術的に達成可能か
- データ取得および処理は時間内に終わるか
- APIトークンはどのように扱うか
- スケジューラーやワークフローの有無
- どのようなストレージが最適か，どのように保存するか
- データの保存先をどこにするか
- メタデータストア
- データのゾーン管理
- ゴールドゾーンへ作成するテーブルのパーティションはどうするか
- 保存フォーマットをどうする？
- データ処理をどのように行うか 目的に向けてどのようなデータ変換を実施するか
- メタデータ テーブルの定義はどのようにするか
- ［補足］設定のポイント整理＆リファレンス
- データパイプラインはどのようになったか
9.3 データ分析基盤構築における不確実性に備えよう ソフトスキルも大事にしよう
- パズル台紙にはめられない場合はどうする？ ソフトスキルやソフトウェアエンジニアリングが必要な場面も
- 制約もアーキテクチャの考慮に入れよう 一つ違うだけで大局が変わることもある
9.4 データ分析基盤に必要な機能を揃えよう 非機能についても目を向けよう
- データ品質実行アプリを付け足す データを常に監視しよう
- アーキテクチャにメタデータの管理の考慮を入れてみよう データを多くの人に知ってもらおう
9.5 本章のまとめ
Appendix ［ビッグデータでも役立つ］RDB基礎講座
A.1 データベースとは何か？ 検索，更新，制約機能を持った入れ物
- データベースの機能と形態
- Excelデータベースの限界 データベースの基本機能を満たせるか
- RDBの誕生 データベースと言えばコレ
A.2 RDBの基本 データベースの基本を振り返る
- RDB 現実世界を表す表形式のデータ集合体
- テーブル テーブルを定義するのは3つの要素
- 行（レコード） 横方向のデータ塊
- 列（カラム） 縦方向のデータの塊
- スキーマ 行と列に制約を課す
- 型情報 データの特性を決める
- 主キーと外部キー RDBにおける大事な制約
- SQL データを操作する最も汎用的な技術
- SELECT（検索） 目的のデータを見つける
- INSERT/UPDATE/DELETE（登録，更新，削除） 対象のデータを更新する
- CREATE TABLE テーブルを作成する
- CREATE View 別名を付ける
- トランザクション 同時実行性を解決する
- インデックス 検索性能を向上させる
- 代表的なRDB 概念理解が大事
- クエリーエンジン SQLを動かすソフトウェアやミドルウェア
A.3 RDBにおけるアーキテクチャ RDBの設計
- アーキテクチャとは何か 構成を考える
- データアーキテクトとデータアーキテクチャ データの保持方法と表現方法
- 正規化と正規型 データの保存方法の整理
- 非正規型 横方向にカラムが増えていく
- 第1正規化 横方向のカラム整理
- 第2正規化 主キー属性における従属関係の分離
- 第3正規化 非キー属性における従属関係の分離
- 正規化のメリットとデメリット 手順に囚われすぎないようにしよう
- ER図 データやテーブルの表現方法