レポート

データエンジニア大集合!「実践的データ基盤への処方箋」輪読会レポート 〜データ整備編〜

この記事を読むのに必要な時間:およそ 6 分

データ整備の課題はテクノロジーだけで解決できるのか?

2人目の発表者のしんゆう氏は「⁠⁠データ分析とインテリジェンス』というブログを執筆しており,データアーキテクトまたはデータ整備人と名乗ることもある」と自己紹介したうえで発表をはじめました。担当したのは,第1章のデータレイク,データウェアハウス,データマートの作成方法について書かれている箇所です。

画像
しんゆう@data_analyst_

知ることに強い興味があり,うまくやるのが多分得意。フリーランスで活動する「データを使いやすくする人」たまに「データを分析してインテリジェンスを提供する人⁠⁠。その実態は謎のデータ分析業界ウォッチャー。最近のテーマは「もっとうまくやる」こと。ブログデータ分析とインテリジェンス

第1章 データ活用のためのデータ整備
1-5 データレイク層の一箇所にデータのソースのコピーを集約する
1-6 データウェアハウス層では分析用DBを使って共通指標を管理する
1-7 共通指標は本当に必要とされるものを用意する
1-8 特定用途に利用するデータマートはユースケースを想定してつくる

発表スライド

データレイク層とはデータを集約したもので,何も加工していない,ただのコピーであることが重要だと書かれていることを説明しました。なぜ一箇所に集めるべきかについては,集約による部門横断によるデータ活用と,分散されて置かれることの手間が減るということを説明し,データレイクの課題について紹介します。

しんゆう
「データレイクがデータレイクになっていないという問題が挙げられています。分析用に集計してから連携してしまう。複数の箇所にデータレイクをつくってしまうなどです。ほかにも,データレイクが存在してもそこにアクセスする権限がないことや,データレイクにデータがあるのかどうかわからないなどの課題があると思います。」

図5 データレイク層の課題

図5

データレイクを1箇所にデータを集める理由として,部門横断のデータ活用が容易になること,データが分散していると発生する作業がなくなることなどを説明しました。次に,本書では共通指標となるデータ,ならびにそのデータの置場のことを「データウェアハウス層」とみなしていると説明し,その共通指標については次のように書かれていると話します。

しんゆう
「部署ごとに独自の集計をしてしまうと,部署横断のデータ活用が進みません。SSOT(Single Source of Trust:信頼できる唯一の情報源)として,一箇所で定めておくことが必要です。少なくとも同じデータを使っていれば,売上を集計するときに定義がぶれなくなります。
部署が違えばルールも変わるので,売上が違うという話になれば,間違い探しが発生してしまいます。共通指標は集計があった方が良いこと,これはガバナンスにも関係すると言っています。」

図6 共通指標の集計について

図6

共通指標は複数のデータを統合・整理したデータで,分析用DBで集計・管理することが望ましいと説明し,データウェアハウス層に格納する共通指標をつくるには,データをクレンジングして,スタースキーマを作って,共通指標の集計を取るという流れを紹介しました。また,初期段階でデータウェアハウス層を作ってしまうと,実態にそぐわない共通データができあがって,現場で使われないことがあると説明し,最初はデータマートからデータレイク層を直接参照する方法を紹介します。実態にそぐわないデータができあがってしまう原因は,エンジニアが利用者の話を聞かずに,技術的にできるかどうかで判断してしまうことがあるとご自身のエピソードにもふれました。

次に,データマート層の説明に移ります。データマートは,特定の利用者,特定の用途向けに加工・整理したデータ,ならびにそのデータの置き場です。データマート層はユースケースと1対1となり,あるデータについてデータウェアハウス層に置くべきか,データマート層に置くべきかを判断できないときは,時期尚早なのでデータマートに置くことが書かれていると紹介しました。ユースケースごとに管理するメリットについても紹介します。

しんゆう
「1つは影響範囲を制限できること,もう一つは集計ロジックを再利用できることです。データ利用の視点に立つと,試行錯誤が容易になること,過去のロジックを再利用できること,システムの応答時間が速くなることがメリットだと言っています。」

さらにしんゆう氏はデータマートについての自論を展開します。

しんゆう
「大きなテーブルにクエリを投げても,システムの応答時間が気にならない程度にツールが発展すれば,ユースケースごとにクエリを持つだけで,データマートという入れ物はなくなるのかもしれないと思います。」

続いて,現場で生じるデータマート層の課題とその解決法について紹介しました。データマートのメンテナンスは難しく,ガバナンスが効きにくいので,利用が減ったデータを検知して,不要になったデータマートを削除することが書かれていると説明しました。

図7 データマート層の課題

図7

しんゆう氏はデータマート層の課題とその解決法について,自身のノウハウも紹介します。

しんゆう
「本書では,ツールが利用者との間で分断されるのを避けるには,最初の試行錯誤はBIや表計算ソフトで行って,利用方法が固まってきたらSQLに書き直すことを推奨しています。データマート自体が増えすぎる問題は確かにありますが,定期的に見続ける予定がなければ,アドホックなクエリだけを残しておく方法もあります。また,データマートやクエリを作っても,ある期間を設定して消えるようにしておく方法もあります。」

最後に以下のように発表をまとめました。

しんゆう
「主にテクノロジーで解決するための方法が書かれている印象を受けました。データ整備は対人スキルが必要になるケースが少なからずあって,そこを埋めてくれるコンテンツに需要がありそうだと思います。」

図8 担当章の感想

図8

しんゆう氏は,発表内で本書で示されているデータの三層構造について疑問を投げかけていました。それに対し著者のゆずたそ氏から次のような回答がありました。

ゆずたそ
「たとえば,ある会社では四層で作っているという話を聞きました。非構造データをテーブル形式に整えるとか,列名をわかりやすく変換するとか,元のデータのセマンティクスを変えない範囲内での変換を行っているようです。
本書の流れでは,ユースケースとデータソースという文脈があるので,そこに注目してください。ユースケースに紐づく層とデータソースに紐づく層,そしてその間を横断する層があります。この二層目は,粒度によって複数の層があり得ると思います。例えば,ソースコードを書くときに,エンジニアがクラスとパッケージとコンテキストをどう区別するかのような話と同じです。コンテキストという粒度なら三層かもしれないし,クラスまで分けるならもっと増えるかもしれません。そこは設計次第だと思います。
重要なのは最初のコンテキストの切り方は,データソースとユースケース,データの入口と出口に注目しましょう。それ以外にもう1つ必要になるはずというのがこの三つの分け方です。」

著者プロフィール

高屋卓也(たかやたくや)

編集者。2002年技術評論社に入社。販売促進部にて書店/取次などの担当を経て編集部に異動。主な担当書籍に『効果検証入門』(2020),『Kaggleで勝つデータ分析の技術』(2019),『前処理大全』(2018),『データサイエンティスト養成読本』などがある。

Twitter:@tkaytkuy

バックナンバー

2022年

バックナンバー一覧