この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Looker社によるロードマップ、顧客事例、パートナー企業によるセッションが堪能出来るデジタルイベント『BEACON Japan 2020』が2020年09月03日から2020年09月24日までの毎週木曜日、計4日間に渡り開催されています。
当エントリでは、その中から2020年09月10日に発表された「Lookerセッション：データの準備を整える」のレポートをお届けします。
目次
セッション概要
公式ページで紹介されているセッションの概要情報は以下の通りです。
Lookerセッション：データの準備を整える
登壇者：
・川窪 善人 - Looker 事業本部 カスタマーエンジニア, グーグル・クラウド・ジャパン合同会社
発表内容：
変化するテクノロジーや働き方に対して日々の業務やワークフローも柔軟に適応することが求められます。本セッションではこれからのデータ活用に対する考え方についてご紹介します。
セッションレポート
ここからは、当日に公開されたセッションの内容についてレポートします。
イベントのセッション動画については下記リンクにてアクセス可能です。
はじめに
このセッションでは、組織でデータを使ってより早く、大きな価値を得るために最新型のデータスタックやデータモデルを使ってどの様に改善すれば良いかを説明していきます。
改善点を理解するにあたって3つの観点があります。『データ準備における一般的な課題の確認』『最新型データスタックへのデータ登録手順の策定』『データのモデリングと変換』です。
「データの準備が整っていない」とは
お客様が分析能力を強化しようとする時には総じて『データの準備が整っていない』という事の方が多いのではないでしょうか。そして、何を以て『整った』と言えるのでしょうか。DWHが稼働し、データが安全に格納されていれば良いのでしょうか。これは我々(Looker)が考えている条件とは異なります。我々の考える『条件』とは以下の内容となります。
上記4点がなぜ必要なのか、データ分析時の一般的な問題を例にとって説明します。
『可用性』については、この条件を満たす"アップロード"が出来るまで待つ必要があり、大きなタイムロスが発生します。『品質』については、トランザクションが切り捨てられることでデータが欠落したり、正しい形式では無い情報が入ってくる事が想定されます。『集計』では、例えばIoTデータでは集計単位によっては何十億件にのぼるというケースもありえます。生データそのままでは集計に時間が掛かりますし、かといって集計単位が大きすぎると深堀りな分析を行いたくても成す術がありません。『ガバナンス』では、組織横断的にデータを集計しなければならない状況になったときに、集計に用いた計算式が組織全体で統制されたものである、という保証はあるといえるでしょうか。
以上のことから、この4つの観点を踏まえてデータを整備する事が重要となってきます。
最新型のデータスタック -主要なコンポーネント-
最新型のデータスタックには、以下4つの主要なコンポーネントがあります。
- 最新の分析ウェアハウス：大規模にスケール出来、数億件以上のデータを使った分析に最適化
- 抽出/読み込みプラットフォーム：最新型DWHに取り込み、スケーラビリティと柔軟性を兼ね備える
- ウェアハウス内での変換：事前に定義した変換方法でデータをDWH内で如何様にも加工出来る
- モデリングとガバナンスのプラットフォーム：データの扱われ方を理解し、定義変更時に商用環境反映前にテストを実施可能
最新型データスタックは図中の赤線枠内の要素となります。左側には異なるデータソースが並び、抽出・読み込みプラットフォームを通して中央の最新の分析DWHに取り込まれます。取り込まれた後にデータ変換プラットフォームによって利用しやすい内容に加工され、保存されます。データモデリングとガバナンス層がアクセス権を制御した上で左側にあるBI、機械学習、自動化や顧客応対向けのアプリケーションにデータを提供します。
最新型の分析DWHについては「列指向」「クラウドベースのソリューションをオンデマンドでスケールアップ／ダウン出来る」「分析ワークロードの素早いスケーリングが可能」等の特色を備えています。対応するものに関しては下記リンクをご参照ください。
抽出/読み込みの重要な4つのコンポーネント
重要なのは以下4つのコンポーネントです。
- APIを使ってアプリケーションに接続し、データをウェアハウスに移動出来る安全でスケーラブルなプラットフォーム
- 数週間や数ヶ月ではなく、数時間・数日といった期間で実装が可能
- データの手動アップロード／カスタム作成したスクリプト／失敗したジョブというボトルネックを取り除く仕組み
- 「抽出-変換-読み込み(ETL)」では無く「抽出-読み込み」を経て変換出来る(ELT)仕組み
データ変換
このフェーズでは、データ利用者のニーズを満たすためにデータを調整出来ることが必要となります。
データを「入ってくる時に途中で加工」するのではなく、トランザクションデータをDWH内で変換することで、ユーザーとアプリケーションに最適な"クエリエクスペリエンス"を作成する際の柔軟性を高めることが出来ます。想定される変換のユースケースは以下のようなものが挙げられます。
- 顧客別のライフタイム支出を計算
- 大規模/複雑なテーブルの事前計算結合
- 週/月/四半期ごとのサマリーテーブルを作成
- 追跡データからユーザーの行動をシーケンス化してセッション化
データのモデリングとガバナンス
このフェーズでは、下流工程のユーザーとアプリケーションがデータをやり取りする方法を標準化することが重要です。
- データモデルの概念をウェアハウスのデータ構造と切り離してとらえる
- 主要なメトリクスの定義を標準化し、テストし、再検討する
- エンドユーザーは、自分が「信頼できる単一の情報源」に基づいて作業していることを確信
- API主導の統一されたデータアクセス手法がアプリケーションに備わる
データのモデリングと変換
もう少し詳しく、論理データモデルが必要な理由について説明します。
そもそもデータベースに統合されたモデルには、データモデルがデータベースの構造に押し込められているという問題があります。データベース統合モデルにてデータを変更しようとすると、下流へのデータフローを崩してしまう恐れがあります。論理データモデルがあれば、あるシステムが別のシステムに置き換えられたとしても論理モデルでその変更点を吸収出来ることが多く、データソースや構造の変更による影響を最小限に抑えられます。
モデリングが出来ることによって、どのようにしてデータの準備と価値実現までに掛かる時間が短縮されるかを見ていきます。
例えば、販売データの可視化を構築する際に一連の標準的なクエリや関連するコンテンツをデータモデルを使って作成したとします。もし数値が正しく無く、データ品質の問題調査が必要となった場合にも、データモデルを見れば追求・調査が可能です。問題の根本的な原因を探り、期待値に応えるための対策を検証するとします。データモデルがあれば、モデルの修正やテストといった検証作業を手軽に行なえます。それを見れば、上流工程を直すべきなのか、単純にデータモデルを修正するだけで良いのかを短時間で判断出来ます。
ETLの問題は、新しいデータ変換が必要となる度に実装する必要があり、その作業に時間が掛かってしまうことです。前もって必要なデータ変換を全て揃えられれば良いのですが、組織全体のデータの利用ケースを網羅的に把握することは不可能であり、変換が必要となる度に実装するしかありません。一方DWH内での変換処理であれば、そういった心配は無くなります。迅速かつ柔軟に新しい利用ケースに対応出来ます。従来のETLで利用ケースに合わせたデータ変換を対応するよりも、他の分析や部署に影響を与えることなく、短時間で変換処理を実装出来ます。その結果生産性が向上し、価値実現までの時間を短縮出来ます。
まとめ
という訳で、Looker BEACON Japanセッション「データの準備を整える」でした。
分析前の『データ準備』段階が重要である事は当然認識はしていますが、Lookerを用いることでデータ準備のみならず、分析業務における様々なメンテナンスや各種作業にスムーズに対応出来る仕組みや機能を利用出来る事が再確認出来ました。
24
