- キーワード
- 1. データ基盤とは，なぜデータ基盤が必要か
- 2. データ基盤には何が必要か：データ基盤の構成要素
- 3. データ基盤をどのように実現するか：データ基盤の実装
よく出てくる「データ基盤 / データ分析基盤」という言葉が分からなかったので，下記のスライドを読んで写経したり，調べたりしながらその全体像，用語の把握に努めた．本記事の内容は丸々写経である．
- Data Platform Guide - 事業を成長させるデータ基盤を作るには
キーワード
- データ基盤（データ分析基盤）
- データ基盤の構成要素
- 各データソースから取得したデータ（DB・各種ログなど．「元データ」，「生データ」ともいう）
- Data Lake データレイク
- Data Warehouse データウェアハウス
- Data Mart データマート
- データのソース
- クライアントサイド
- アクセス解析ツール（e.g. Google Analytics，Firebase Analytics）
- サーバーサイド
- Web サーバ：Web サーバログ
- AP サーバ：アプリケーションログ
- DB サーバ：データストア（RDBMS，KVS，etc...）
- クライアントサイド
- データ基盤の実現
調べられていないもの
- Kubenetes
- Airflow
- Kubeflow
- OLAP
1. データ基盤とは，なぜデータ基盤が必要か
- データ基盤の目的：データ活用で顧客に価値を提供する
DataOps
- DataOps：（主に企業が）データ活用を行うための仕組み
- Data（分析者）
- Ops（現場）
ユーザ（顧客） -- データ収集 --> DB・ログ -- 整形・集計・転送 --> 組織横断統合データ（e.g. DWH）-- 活用（分析者が分析して施策を考える） --> 施策・業務 -- 価値（DataOps において最大化すべき目的変数）-- ユーザ（顧客） -- データ収集 --> ...
上記サイクルでデータが充実するとより効果が高まる．
データ収集（DB・ログ） -> ETL（e.g. Embulk） -> DWH（e.g. BigQuery） -> BI（e.g. DataStudio，Tableau） -> 施策に生かし再度データ収集
データ基盤とは
- データ基盤
- データ活用を行うための基盤．多様なデータソース（e.g. 顧客のプロダクトから得られた利用ログ）と多様なユースケース（利用者がどのようにプロダクトを使用するか）を結びつけるもの．
データ基盤はなぜ必要か
- データが統合されていないと，横断での意思決定や調整が困難になる
- 単一情報源（組織横断統合データ）を持っている場合，データアナリストや他の意思決定者といったエンドユーザたちに優れた価値を提供することができる．彼らは組織内でデータを探す時間が少なくて済むようになり，データの利用（分析業務など）に多くの時間を割くことができるようになる．
企業が社内に点在する情報（データ）を有効活用し，経営に役立つ洞察を得るためには，必要な情報（データ）を 1 箇所に集約し蓄積する必要がある．
情報を蓄積するためのプログラムは，情報元となるデータソースの種類が多くなれば多くなるほど各データソースに応じてプログラミングするための専門的な知識が求められ，膨大な開発工数を必要とし，大きな障壁となる．
2. データ基盤には何が必要か：データ基盤の構成要素
- 手軽にデータを参照できるツール
- 安全にデータを受け渡せるシステム
- 安心してデータを扱えるプロセス
手軽にデータを参照できるツール
- データを集めるだけでは意味がない
- ユースケース（営業，マーケター，データアナリスト，ML エンジニアなど）に結びつかなければ意味がない．データを集めた上で，それを利用するポジションの人間が実際に参照するための仕組みを作る必要がある．
ツールは Excel，Tableau，Redash，Jupyter など，ポジションごとに使いやすいものは異なる．
安全にデータを受け渡せるシステム
- 共通箇所（？）を担保する仕組みが必要（良く分からなかった）
データの階層を分ける - データ基盤の 3 層構造
DB・ログなど ---> Data Lake -> Data Warehouse -> Data Mart ---> 利用者（マーケター，アナリストなど）
- Data Lake
- ログを加工せずにそのまま 1 つのシステムに集約したもの
- 何も加工していない，ただのコピーであることが重要
- もし加工済みのデータしか残っていないと，後で「この加工方法は間違っている」と判明したときに直せない
- データレイクに元データがあれば，調査や事後修正が可能
- ログを加工せずにそのまま 1 つのシステムに集約したもの
- Data Warehouse
- Data Mart
3 層構造におけるデータの流れ
- DB・ログの構築：顧客，社内で様々なデータを収集（事業やシステムの保有する全データ（元データ））
- データレイクの構築：元データのコピー（そっくりそのまま）
- データウェアハウスの構築：ドメイン知識を用い，集計・分析パターンを整理（頻出データなどを利用しやすい形にする）
- データマートの構築：ユースケースごとに最適化されたデータを用意する
安心してデータを扱えるプロセス
ここはあまり実感が湧かず分からなかった．
- サービスレベルの合意
- データ利用者がデータを扱える状態にあるかのチェック
- 部署や用途ごとに暗黙に期待されている品質を洗い出す
- 品質目標について関係者と合意する
- インシデント対応の仕組みか
- 期待品質が満たされないとき「どう対応するか」を定義
- 例：データ連携バッチジョブのエラー
- オペレーションを型化する
- 品質を計測する
- 定期的に見直す
- MTG のアジェンダに改善を仕込む
3. データ基盤をどのように実現するか：データ基盤の実装
データ基盤の実装に必要な 3 つの要素
3-1. データの取得元となる対象
この節は，データ基盤がどんなデータを集めてるのか気になってたのでなるほどとなった．データソースは自分が普段触れている部分に即していたので実感が湧くものが多かった．
Web サービスの代表的なデータソース
- Web サービスの構成
- ユーザ <-> クライアントサイド：Web サイトのやスマホアプリの画面 <-> サーバーサイド：Web サーバ，AP サーバ，DB サーバなど
上記スライドの載っている 4 つの代表的なデータソースをまとめた（太字）．
- データソース
- フロントエンド
- アクセス解析ツール（e.g. Google Analytics，Firebase Analytics）
- サーバーサイド
- Web サーバ：Web サーバログ
- AP サーバ：アプリケーションログ
- DB サーバ：データストア（RDBMS，KVS，etc...）
- フロントエンド
代表的なデータソース
- アクセス解析ツール（e.g. Google Analytics，Firebase Analytics）
- 画面遷移やボタンクリック
- Web サーバ：Web サーバログ
- AP サーバ：アプリケーションログ
- アプリケーションがロガーで出力したログ（e.g. Python の
logging，Rails.loggerなど）
- アプリケーションがロガーで出力したログ（e.g. Python の
- DB サーバ：データストア（RDBMS，KVS，etc...）
- RDBMS や KVS のデータ（e.g. 顧客情報や購買情報）．PostgreSQL や MySQL の各テーブルに含まれるレコード
データソースにおける注意点
- 元データの品質注意する
- 基盤でのカバーには限界がある（e.g. どうしても取得できないデータなど）．元データを見直す必要がある．
- 元データの仕様を管理する
- e.g. SQL のテーブル定義などに仕様を説明するコメントを書いておくと，データ利用が楽になる）
- 手入力のデータにも目を向ける
- ソフトウェアが自動で生成するデータだけでなく，スタッッフが手動入力するデータが必要な場面も多い
- ex1) 営業の訪問先リスト Salesforce，Kintone，HubSpot
- ex2) 販促キャンペーン一覧 Spreadsheet，kreisel
- ex3) 市区町村マスター プログラム定義（Java の Enum など）
- ソフトウェアが自動で生成するデータだけでなく，スタッッフが手動入力するデータが必要な場面も多い
（SW エンジニアが抵抗感を覚えるツールもあるかもしれない．でも必要なデータだよ！！）
3-2. データを集約するためのテクノロジー
データ基盤の 4 つの技術要素
- （元データ（DB・ログなど）Kintone，MySQL）
- ETL
- DWH
- BI ツール
- ワークフローエンジン（Airflow，Luigi，Prefect など）
元データ -- ETL --> DWH --> BI ツール
ワークフローエンジンは ETL，DWH を管理する．
BI（Business Intelligence） ツール
- BI ツール
DWH（Data Warehouse）
- DWH
ETL（Extract/Transform/Load）
- ETL
ETL ツールの選定
- 定期バッチ
- Embulk
- ストリーミング（メッセージキュー含む）
- 両方対応
ETL ツールの用途：DWH 環境の理想と現実
- 理想：理想的な DWH 環境
- データ統合のための処理が ETL レイヤーで完結
- 現実：DWH 環境を取り巻く現実
- ETL レイヤーで処理をまかないきれず，さまざまなレイヤーで処理が組まれ複雑化（ずぶずぶ）
ワークフローエンジン
- ワークフローエンジン
3-3. データを利用者（マーケター，アナリスト，ML エンジニアなど）に届けるまでの設計例
この説は面白かった．実際のアプリケーションとそのデータ基盤がどのように組み合わさっているか，アプリケーションのどの段階のデータ（ログなど）をデータ基盤に流すか，ワークフローエンジンの立ち位置（どこでワークフローエンジン使うの？みたいな話）がざっくり学べた．
データ基盤の例 1：創業直後のメディア企業
システム構成
- システムの解説
- アプリと連携する Web API は Google App Engine（GAE）で運用
- アクセスログは標準で StackDriver Logging（現在は Cloud Logging というサービス名に変更）に流れる
- 画面操作で以下を設定
- データ基盤の利用例
- 営業担当が商談の場でダッシュボードを見せて広告主に効果を報告
- アプリと連携する Web API は Google App Engine（GAE）で運用
設計のポイントは以下．
- 設計のポイント
データ基盤の例 2：大手企業の予約サイト
- システム構成
- データソースによって ETL の部分を扱うツールを分けている．
- システムの解説
- 以下の構成で BigQuery にデータを連携
- データ基盤の利用例
設計のポイントは以下．
- 設計のポイント
- 歴の長い会社で手堅く始めたい
- オンプレミス環境で使える技術要素を重視（BigQuery を除く）
- データソースが多様
- データソースに応じて複数の ETL ツールを使い分ける
- 手間を省くために可能な限り Embulk や fluentd を採用
- ツールごとに実行状況を管理するのは負担
- 1 つのジョブスケジューラで取りまとめる．社内に利用実績がある Jenkins を採用．
- 歴の長い会社で手堅く始めたい
データ基盤の例 3：大量データのメガベンチャー
システム構成
- システムの解説
- 【1 ~ 2】DB から定期的に Dump ファイル（
*.gz）とテーブル定義（schema.json）をストレージ（GCS）に出力して，Cloud Composer（ワークフローエンジン）に知らせる． - 【3】Cloud Composer が Cloud Dataflow（ETL ツール）に対してジョブ実行を指示する．DWH（BigQuery）に読み込めるように，ファイルの形式を書き換える．
- 【4 ~ 6】Cloud Dataflow が Dump ファイル（
*.gz）を取得 -> 加工 -> 保存する - 【7 ~ 9】データの変換が完了したら，Cloud Composer は GCS から返還後のファイルとテーブル定義を取得し，BigQuery に保存する
- 【10】BigQuery に保存されたデータを利用者が Looker で参照する
- 補足
- Cloud Composer：GCP で Airflow を動かせるプロダクト＝ワークフローエンジン
- Cloud Dataflow：柔軟なデータ処理プログラムを実行できるプロダクト＝ ETL ツール
- 【1 ~ 2】DB から定期的に Dump ファイル（
設計のポイントは以下．
- 設計のポイント
- 他システムから DB に無邪気にアクセスできる規模ではない（ETL 経由で MySQL を直接叩いて BigQuery にデータを転送することができない）
- mysqldump でファイルをエクスポート
- mysqldump の TSV/CSV フォーマットでは BigQuery にロードできない
- データの加工が必要
- 1 つのジョブで扱うデータ量が TB 単位になる
- 分散処理に対応した ETL ソリューションが必須
- サーバを自動で立ち上げ & 水平展開ができる Cloud Dataflow を採用
- 補足
- Dataflow は変換装置として責務を割り切るため，Dataflow から BigQuery に直接ロードせず，GCS に変換後のファイルを吐き出す
- 他システムから DB に無邪気にアクセスできる規模ではない（ETL 経由で MySQL を直接叩いて BigQuery にデータを転送することができない）
