『実践的データ基盤への処方箋』第一章 要約
本記事は『実践的データ基盤への処方箋』第一章の要約です。
著者：ゆずたそ、渡部徹太郎、伊藤徹郎
わかること：データ基盤って何？
つまり、どういう要素があるか？
それらがどういう関係でつながってるのか？
それぞれの要素はなぜ必要なのか？
そして、イメージを持ちやすくなるように、
具体例を多めに引用させていただきました。
データ基盤の概要
全体の流れは以下の通りです。
個別の要素はこれからご説明します。
データソース
→データ収集
→データレイク層
→データウェアハウス層
→データマート層
→ユースケース
そして、図にはないですが全ての段階にまたがって
メタデータが存在します。
データ収集
データソースからデータを集める仕組み。
例：ECサイトのDBから記録を取り出す。紙の台帳をデジタルに変換する。
データレイク層
各所からデータを集約する場所。
ここに置かれるデータは、
データソースを単に丸コピしたデータ。加工や結合はしていないもの。
データウェアハウス層
先ほどと異なり、加工・結合したデータを置く場所。
ここに置かれるデータは、後続の分析の段階で共通指標となるものです。
例：商品Xを販売する場合の「売り上げ」という指標を考えます。ここでは販売チャネルは、自社ECサイトor店頭があるとする。自社ECサイトと店頭では「売り上げ」データが別々の場所でカウントされています。そこで、データウェアハウス層で二つを合流させ、それらを足し合わせて新しく「売り上げ」という横断の指標を作ります。
データマート層
先ほどと同じく、加工・結合したデータを置く場所。
それなら何が違うんだ？？となりますね。
ここに置かれるデータにはちゃんとウェアハウスと違いがあります。
違いとは、ここのデータには用途が結び付けられている点です。
つまり、ここのデータは、データをどう使いたいかが見越してあります。
例：「毎週のジャンル別の売り上げ」
ユースケース
先ほどチラッと出ましたが、これはデータ基盤の用途を指します。
例：経営者が「毎週のジャンル別の売り上げ」を見て、経営判断に使用します。
メタデータ
こいつだけ↑の奴らとやや毛色が違うように見えます。
これはデータを説明するためのデータです。
例：「購買記録データに含まれているのは、購入者や購入金額のデータである」「山田さんが購買記録データを12/15に更新した」
ここから各論です。
データの処理の順序は上述のとおりデータソースから始まるのですが、
実際にデータ基盤を作る際に、一番最初に注目すべき点を最初に説明します。
それはユースケースです。
ユースケース
データ基盤の存在意義は、活用されることです。
開発と運用のコスト < ユースケースで得られる利益
を目指すことになるでしょう。
実際にデータ基盤に投資するかを判断する際には、
まず検討した方がよいのはユースケースです。
そこから、データの収集・整備をするか判断しましょう。
データ活用のためには、まず自社のデータの流れを書き出す
どうやってデータの流れを把握すればよいのでしょうか。
第一に重要なのは、
どういう用途でデータを活用したいのか？＝ユースケースの選択
そのために必要なデータはどこから集めるのか？＝データソースの選択
この二点の選択です。
次に「活用する」と「集める」を精緻に把握します。
具体的にやることは、データの入口と出口のマッピング。
これは、どのようなデータ整備が必要かを明確にするためです。
具体例：「購買履歴はすでに集めている→出口の活用方法を整備せねば！」
「入口である在庫情報の更新頻度は少なすぎないか？→入口を整備しよう」
そのために役立つフレームワークはCRUD表。
データへの処理であるCreate, Read, Update, Deleteの頭文字をとっています。
CRUD表に基づき、「誰が」「どのデータを」「どう処理する(集める/活用する)か」が特定されます。これが分かると、どんなデータのシステムが必要かが明瞭になります。
(例：気象庁が生成するデータをメルマガ配信システムが参照して、雨天であればメルマガを配信する。ではそれを実現するためには、メルマガ配信システムは気象庁のデータを参照できるように整備する必要がある…)
データ基盤の意義を把握しました。
次はデータ基盤の外部のコンポーネント、
そして内部のコンポーネントを見ていきます。
データソース
本書ではデータソースは、データ基盤の外部にあるととらえます。
定義：もともとのデータあるいはデータの発生源
具体例：
ECサイトで客が注文→データベースに購買履歴が記録される
商品の材料の仕入れが紙の台帳に記録される
ECサイトを構築しているサーバがログを出す
ここでのデータの発生源＝データソースは客・材料・サーバ。
データを分析するためには、
「なんでもデータを集めればそれでいい」ではありません。
良いデータと悪いデータはあります。
分析したい内容のために、必要な種類のデータを集めていますか？
例：ECサイトでキャンペーンバナーの効果を知りたい。
そこで、バナーが表示か非表示かによって、
ユーザーの画面遷移がどう変化したかを分析したい。
しかし、画面遷移のログに顧客IDが含まれていなかった
→分析できない
それでは、数あるデータソースの内、
どのデータが必要なのかを判断するには？
考え始める際の着眼点は2つです。
・データの生成過程
・ユースケースの目的
具体例：
・ユースケースは、ECサイトの「売上」の集計
・適切そうなデータソースは、「Webサイトの売り上げデータベース」
「銀行の入出金データ」の2つ。
・この2つのどちらがより適切でしょうか？
・「Webサイトの売上データベース」のデメリット
ある時、数日間の障害が発生しWebサイト上の決済が不能に！
その間、例外的に電話を用いた銀行振り込みで代金の支払いをする手続きを採用しました。
その結果、「データベース」上の売上データは「銀行の入出金」に比べて欠損を含むことになります。
・「銀行の入出金データ」のデメリット
会計では、売上を計上するタイミングが独特です(発生主義という)。
タイミングは、
お金が振り込まれた日ではなく
取引が成立したタイミングです。
そのため、「銀行の入出金データ」の売上の日付データは
振込日ではありません。
購買日と振込日がずれた場合には、「購買日」のつもりで
日付データを用いると誤っていることになります。
・このように、「Webサイトの売り上げデータベース」
「銀行の入出金データ」のどちらもデメリットがあります。
「売上」を正確に集計するには、それぞれのデータソースの生成過程とユースケースの目的に基づき、複数のデータソースをうまく組み合わせる必要があります。
必要な種類のデータソースは決まった！
これでもう大丈夫…？
もう一つあります。
データに誤りはないですか？
例：Aさんという顧客データを見ると購買回数が3。
一方、購買履歴をいると2件しかない。
それでは、データの品質は、どう担保するか？
もちろん、データソースから来た悪いデータに対し
データクレンジング等で対処する方法もあります
(データレイクーデータウェアハウス間の処理)。
しかし、データソースの時点で良いデータを得る方が
効率良い&低リスク です。
根本的な原因を発生段階で解消できるからです。
そのためには、データの利用者がデータの生成者(データソース側)に対して
「ここを直してくれ」と伝えることが重要です。
その他の集めるべきデータ
・マスタデータ
・共通ID
・履歴データ
特に、履歴データはなぜ必要？
現象の要因を解明するためには、どういう変数が変動したからその現象が起こったのか？を考えます。変数の変動を見るには履歴が必要です。
だから履歴は重要となります。
具体例：ECサイト上の商品の説明文の履歴データがないと…
ある日突然売上が伸びた。その近くのタイミングで商品の説明文を変更した。履歴データがないと、説明文を変えたことと売上の伸びが関連していそうかを調べられない。。。
1つのデータソースを精緻に把握しましょう
・まず、どれほど精緻に把握すると良いのでしょうか？
それは、分析したい目的がある時に
そのデータで事足りるのか、不足しているのかを気づける程度です。
すなわち、メタデータとデータ間の関連を把握しているのが望ましいです。
・そのためのツール：ERD(E-R図, 実体関連図)
データ基盤の内側のコンポーネント
データレイク層
・修正も加工もないデータが集約された場所
・なぜ必要？ないとどうなる？
多様な分析を行う対象、たとえると原材料となるからです。
たとえ話：稲からとった玄米を格納しておく。
「どうせおにぎりにしか製造しないから」と全て精米した米を格納しておくと、後で「やっぱり玄米を加工したレトルト製品も製造したい」
となった時に困ります。
精米しかありません。
他にもメリットはあります。
部署ごとに散在している複数のデータソースを一元化できます。
それにより、データ活用の機会が増えると期待できます。
具体例：
集客部門とカスタマーサポート部門が、Excelでそれぞれデータを管理
集客部門のデータは、キャンペーンやクーポンの発行情報など。
ある日、カスタマーサポート部門に顧客からキャンペーンに関する問い合わせが来たとします。その時、カスタマーサポート部門がすぐに
集客部門のデータソースにアクセスできない場合があります。
さらに、部門を超えてデータを統合できるようになると、
ビジネスをよくする打ち手の仮説を発見しやすくなりそうです。
具体例：カスタマーサポート部門Ａさんは集客部門のデータを見て
「クーポンをきっかけに流入した顧客はすぐ解約するようだが、
クーポンで流入した顧客のサポートに労力を費やしていた」
データウェアハウス層
・データウェアハウス層はなぜ必要か？
まず、部門間の共通指標を集計することが必要です。
具体例：
経理部門 売上は消費税抜き の合計金額
Webサイト運営部門 売上は消費税込み の合計金額
これだと、二つの売上を単純に足し算できません。
データを意思決定に用いるには、
数字ごとに共通の指標を用いる方が良いでしょう。
データウェアハウス層の作成手順
①データクレンジング
具体例：欠損値の補完、
重複したレコードの除去、
名寄せ
ただし、理想的にはデータ基盤上ではなく
発生源のデータソースを修理して、
不備のあるデータが生じないようにするのがおすすめです。
不備のあるデータは、データ分析以外の通常業務にも影響を及ぼしている
場合があるからです。
②ディメンショナルモデリング
＝データ構造を表現する際のモデル
ここでは例として「スタースキーマ」というモデルを紹介します。
画像元：https://ascii.jp/elem/000/000/494/494736/2/
データ構造を、
ファクトテーブル
ディメンションテーブル
の2要素で表現します。
ファクトテーブルとは、着目する事象のデータです。
具体例：ECサイトの「販売履歴」
ディメンションテーブルとは、その事象にある側面のテーブルです。
具体例：「販売履歴」データには、
商品という側面
顧客という側面
があります。
つまり
何を販売したかー商品 →商品テーブルの「商品ID」「商品名」「価格」
誰に販売したかー顧客 →顧客テーブルの「顧客ID」「顧客名」「年齢」
というイメージです。
③共通指標の集計
スタースキーマを用いて、
共通指標を集計します。
具体例：ECサイトの人気商品を月次でモニタリングするために、
「購入履歴」を「商品」「年月」という側面(ディメンション)から
切り出して、「売上」を集計します。
データマート層
データマートとは
データウェアハウス層のデータを
ピンポイントの分析目的のために加工して、
それを保存する場所です。
具体例：
部門ごとに異なるジャンルの商品を販売しているとします。
このもとでやりたいことは、ジャンルごとの商品の売れ行きを週次で確認することとします。商品のジャンルは「飲食系」や「アクセサリー系」などです。
手順は次の通りです。
週次、ジャンル、売上 の3指標を組み合わせて集計
→データマート層に保存
→BIツールで可視化
データウェアハウス層のデータは
利用者間の共通資産みたいな感じです。
それを変更すると、他の人が使うものに影響が及びます。
利用者はデータ本体ではなく、
複製したものに加工し分析します。
その加工済みデータを
データマートに置いておきます。
アドホックではなく、ちゃんと保存しておく利点はあります。
同じ計算ロジックを使ってデータを何度も表示する場合、
表示の度に計算する必要が省けるので、
表示はより速いです。
データマートの作成手順
①データレイク層とデータウェアハウス層のデータを抽出
②集計
メタデータを活用しよう
メタデータとは
データに関するデータ。
すなわち、「このデータはどのようなデータなのか」を示す情報です。
メタデータのメリット
・メタデータがあれば、データ活用現場での手間が減ります。
例：テーブルに個人情報が含まれているか否かで、そのテーブルを参照できるかが変わる場合があります。 メタデータで個人情報の有無が分かれば、調べるよりも手間が少ないです。
・データ基盤の開発と運用の際、データの中身を把握する必要があります。メタデータを見ることで、データそのものを見るよりも手間が減ります。
データ基盤はどう作るか？
サービスレベルを設定しましょう
サービスレベルとは
サービスの品質水準
具体例：ECサイトのサービスレベル
…1日の売上データの集計は翌朝7時に完了している
どのように設定？
ユースケースをヒアリング
→ユースケースにおけるサービスレベルを定義
https://yuzutas0.hatenablog.com/entry/2018/04/23/083000
データ基盤を支える組織
データエンジニア
コンピュータシステムの構築や運用を担う
データ収集も担う (ゆえに、データ加工や蓄積技術も必要)
データスチュワード
データの整備や利用者のデータ活用をサポートする役割を担う
データ利用者からのフィードバックを受け止め、データ基盤を改善する
組織長
企業におけるデータ分析文化を醸成
データ活用人材の採用
データガバナンスやセキュリティの管理
データスチュワードという役割
データスチュワードとは
データ活用に関する顧客の相談窓口
&課題解決をリードするという役割
具体例：
データ利用者から、データの使いにくさについて伺う
「ECサイトとオフラインのデータを横断して分析できない」という課題
→ECサイトのWebエンジニアに「顧客IDを統合したい」と提案
データ基盤を整備するチームのためのtips
コミュニケーションの齟齬を防ぐためにも、
用語の意味は関係者の内で共通しているようにアクションが必要。
具体的には、関係者に向けた用語集を作るのがおすすめです。
例えば、データレイク、データウェアハウス...の語が指す中身は
文脈によりブレがちです。
例：データウェアハウスの語義のブレ
・データウェアハウス層(設計面に注目)＝役割はデータウェアハウス層のデータ管理のみ
・データウェアハウス製品(ツール)＝データウェアハウス層のデータ管理のみならず、データレイク層やデータマート層のデータを扱えることもある。
定義がずれると前提がずれて議論が混乱しますね。
第一章のみですが、以上です。
お読みいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？