[レポート]BEACON Arriving At Data Readiness #BeADataBEACON

奈良県でリモートワーク中の玉井です。

Looker社のオンラインイベント「BEACON」の「Arriving At Data Readiness」というセッションをレポートします。

ウェビナー情報

公式情報

登壇者

プロフェッショナルサービスチームに所属しているとのことです。

補足

今の時代におけるデータ分析基盤のあるべき姿を示してくれた感じでした。特に強調していたのは、データのモデリングをDB構成とは切り離して考えるべき、という部分です。

レポート

本日は、最新のデータスタックとデータモデリングを活用する話をします。

本日は、主に3つの目的を取り上げます。

Availability、Quality、Aggregationなど、一般的なデータ準備の課題をレビューします。

最新のデータスタックを構成する4つの主要なコンポーネントを概観しつつ、最新のデータスタックへの道筋を描いていきます。

最後に、データのモデリングと変換についてお話します。特になぜモデリングが重要なのかについて詳しく見ていきます。ETLアプローチとELTアプローチを比較して、価値を出せるデータ分析体制への移行について見ていきます。

データの準備に関する一般的な課題を確認する

顧客が直面する最大の障害の1つは、データの準備ができていないことです。そこで問題となるのが、「（課題があるなかで）今、何をすべきか」ということです。まず「データの準備ができている」とはどういうことか、それを4つの主要なカテゴリーに分類してみました。それぞれについて説明し、いくつかの例を挙げていきます。

「Availability」とは、関連性があり、最新のものであり、そして迅速に問い合わせ可能な状態になっているということです。これは、人々が必要とするデータに、タイムリーにアクセスできることを意味し、データの更新時間やクエリにかかる時間が妥当であることを意味します。

「Quality」とは、データが、正しく、完全で、最適な構造になっていることです。データが確かに存在し完全で正しいか、また実際に分析をサポートする構造になっており、そこから質問に答えることができるかどうか…ということです。

「Aggregation」とは、分析ニーズに応じて、細かい粒度と粗い粒度、両方のデータを利用できるようにすることです。細かい粒度のデータとは、Webトラフィックデータのような非常に粒度の細かいデータになります。売上のコンテキストではトランザクションデータやそれに対応するデータのことです。

「Governance」とは、（データの）クエリおよび計算方法が標準化され、それらはレビューの対象となっており、バージョン管理が行われる状態になっているということです。ユーザーと下流のアプリケーションがすべて同じバージョンを使用しているという確信を持てるかどうかです。

これらのカテゴリがどう課題となるのか、例を挙げて、もう少し詳しく説明します。

「Availability」。データは複数の場所に分散しており、手動でアップロードする必要があるため、タイムラグが生じる可能性があります。これらのアプリケーションは、ほぼリアルタイムのデータ、または完全リアルタイムのデータを収集しており、そのデータをデータウェアハウスに取り込む必要があります。データはどのくらいの頻度でアップロードされているのでしょうか？データアナリストが実際にデータを見る必要がある場合、アップロードされるタイミングによって、実際のデータとのラグタイムが発生します。

「Quality」。データが不足していたり、正しいフォーマットになっていなかったりすることです。私が「Quality」の問題でよく目にするのは、タイムスタンプと日付の処理だと思います。アプリケーションによってはタイムスタンプをタイムゾーン付きで保存する場合もあれば、タイムゾーンなしで保存する場合もあります。ある期間に渡ってデータを見ているときに、そのデータがタイムゾーンなしで保存されているかどうかをどうやって判断しますか？異なるデータソースからのデータを見るとき、正確な期間を見ていることをどのようにして知ることができますか？

「Aggregation」。データが細かすぎる、または粗すぎる、ということがあります。つまり、本当に粒度の高いデータを持っている場合、特定のユースケースには必要のない生のイベントデータを見ているために、クエリのパフォーマンスが実際には非常に遅くなっている…ということです。逆に、事前に集計しすぎていて、データアナリストが必要とする詳細な情報を得ることができない…ということもあります。

「Governance」。データを作成する方法が組織内で散らばっていませんか？私は、重要な指標を変更する必要があるとしたら、どのような方法で変更するのかという質問をしたいと思っています。Aという定義とBという定義が保存されている様々な場所を変更するのに数週間から数ヶ月かかるかもしれない状況にあるのか、それとも非常に迅速に変更できるものなのか…。

データ準備における課題がわかったところで、今度は最新のデータスタックの紹介と、それらのスタックがデータ準備にどのように役立つか、また、価値を生み出すまでの時間をどのように促進するかについてお話します。

最新のデータスタックとは

まず最初に、最新のデータスタックには4つの重要なコンポーネントがあります。

まず、「Modern Analytical Warehouse」です。これは、データの行を取り込むだけに最適化されているのではなく、データの複雑な分析に最適化された、スケーリング可能なソリューションを持つことが全てです。

次に、「Extract-Load Platform」があります。柔軟かつタイムリーにデータをデータウェアハウスに持ち込むことができます。

そして、「In-Warehouse Transformation」により、データを読み込む前に必要な変換を事前に決定するのではなく、データウェアハウス内のデータの粒度を上げたり下げたりするようにデータを操作することができます。

最後に、「Modeling and Governance Platform」では、定義を標準化するために、データのモデルを変更することができます。

この図では、最新のデータスタックが赤でハイライトされています。一番左にあるのは、データを収集するすべてのアプリケーション…SaaSアプリケーションです。これらのデータは「Extract-Load Platform」を介して最新のデータスタックに持ち込まれます。「Modern Analytical Warehouse」に入ると、そこにはデータウェアハウスに入ったデータがあります。「In-Warehouse Transformation」は、「Data Modeling and Governance」レイヤーにロードされたデータを変換し、BIアプリケーション、機械学習、その他の顧客向けアプリケーションなどの他の下流のアプリケーションへのデータアクセスとデータの構造、およびデータの表示方法を提供します。

Modern Analytical Warehouse

「Modern Analytical Warehouse」は、データのための場所を持つことが全てであり、分析のために最適化されています。カラムナー型データベースを聞いたことがあるでしょう。特定の列に対するクエリと、データの行全体に対するクエリができるということです。異なるタイプのデータベースについての情報が必要な場合、下記を参照してみてください。

Looker社は、少し前に上記を作成しました。これは利用可能な様々なタイプのデータベースやデータウェアハウスを比較対照して、いくつかの考察を提供しています。これらのソリューションの多くはクラウドベースで、需要に応じて適切に拡張できるという点で非常に有益です。また、セキュリティやコンプライアンスの目的で必要な場合は、オンプレミスのソリューションを提供していますが、「Modern Analytical Warehouse」の鍵は、分析ワークフローのために迅速に拡張できることです。BIアプリケーション、機械学習プロセス、自動化をサポートすることができます。

Extract-Load

「Extract-Load」を見てみましょう。これは、データを自動的かつ迅速に必要な場所に取り込むことです。APIを介してアプリケーションに接続し、データをデータウェアハウスに移動させることができる安全でスケーラブルなプラットフォームがあります。もしあなたがカスタムETLプロセスを作成しようとしたことがあるならば、これらはオーケストレーションに長い時間がかかることを知っているでしょう。効果的にデータを取得する必要があり、非常に多くの考慮事項があるからです。しかし、これらの最新のプラットフォームは、数時間から数日で実装することができます。また、「Extract-Load Platform」には、エラー処理のリトライと失敗通知が直接組み込まれています。迅速なターンアラウンドタイムと、これらのエラー処理の複合効果は、データの手動アップロードというボトルネックを取り除くということです。

また、ETLではなくELTでデータを変換することをお勧めします。データ変換は、データ消費者のニーズに合わせてデータを仕立てることがすべてです。途中でデータを操作せず、データウェアハウスに配置し、その後でトランザクションデータを変換します。そうすることで柔軟性が高まり、ユーザーやアプリケーションに最高の素晴らしい体験を提供することができます。

いくつかの例としては、顧客レベルの分析を行う必要があるとき、データウェアハウス上で顧客レベルに集約することで、顧客ごとのLTVを計算することができます。パフォーマンス上の理由から、大規模で複雑なテーブルの結合を事前に計算し、週次・月次・四半期・四半期のサマリーテーブルを作成することで、クエリのパフォーマンスを大幅に向上させることができます。特定の時間間隔でレポートを送信する必要がある場合にも効果があります。さらに、事前に集約されたテーブルを作成することで、トラッキングデータからユーザーの行動を同期化してセッションを行うことができます。顧客分析を行うことができるようになることで、顧客のユーザージャーニーの分析ができるようになります。また、アプリケーションにとって本当に重要なファネルを作成することができます。

データのモデリングとガバナンス

これは、ユーザーおよび下流のアプリケーションとデータのやり取り方法を標準化するということです。データモデルとデータウェアハウス内のデータ構造を分離します。この方法では、テーブル構造は将来のデータアクセスやデータ分析の最終手段にはなりません。相互作用をモデル化し、構造化された方法でビジネスに提示するためのモデリングレイヤーを作成します。また、テストと主要なメトリクスの定義を標準化することができます。これにより、ビジネスが必要とするものを正しくモデリングしていることを確認することができます。KPIを微調整する必要がある場合、モデル内の論理的な定義をモデリングレイヤー内で変更することで、テストして、それが正しいことを検証することができます。その後は、変更を本番環境にプッシュすることができ、このKPIを追跡する組織内のすべての場所が新しい定義を継承することになります。これは、サイロ化されたビジネスロジックを使用している場合に、すべての異なるビジネス部門やツールに変更点を別々に伝える必要はなく、一括で変更点を伝えることができます。

ここでは、データのモデリングがなぜ必要か、についてお話します。最初に論理データモデルについてお話しします。前回のスライドでは、論理データモデルを使用することをお話しましたが、論理データモデルがどこにあるのか、ということが本当に重要なポイントだと思います。ここでは、論理データモデルの利点を、データベース側で統合されたモデル（以下データベース統合型モデル）に対比させて説明します。

データベース統合型モデルの問題は、モデルの構造がデータベースの構造に依存しているということです。もしデータを変更する必要がある場合、BIツールや機械学習などの下流アプリケーションすべてが影響を受けます。

モデルの修正をテストするには、それをデータベースに書き戻す必要があり、時間がかかることがあります。

多くの場合、他のチームがデータベースを制御しているので、必ずしもビジネスロジックを推進するデータアナリストのように、いつでもデータベースに変更を加えられるとは限りません。その結果、ほとんどの分析は抽出されたデータで行われます。データを取り出して、データウェアハウスからデータのコピーを取り出して、独自のモデルを構築する方が簡単です。アナウンス用のエクセルなどの他のツールを使っても、分析目的に合わせてデータの基本構造を変更するよりも簡単です。

データベース統合型モデルは妥協の原因となります。これは最終的には1つの構造になります。この1つの構造がすべての分析を駆動することはできないので、常に勝者と敗者が存在することになります。論理データモデルは、データソースや構造の変更は最小限の影響しかありません。上流のアプリケーションを切り替えたとして、テーブル構造が同じでない場合は、論理データモデルに変更を加える必要がありますが、下流のアプリケーションやユーザーには、変更を加えることはありません。下流のアプリケーションやユーザーは、データソースを変更したことを潜在的に知ることはありませんが、以前と同じ方法で同じメトリクスが表示されているため、実際には気づくことはありません。修正や変更は、最初に論理的に構築してテストすることができます。モデリングレイヤーを使用して検証を行い、すべてが正しいことを確認してから本番環境にデプロイすることができます。微調整やロジックのためにモデリングレイヤーに変更を加えるため、基礎となるデータ構造に触れる必要はありません。データから直接操作するクエリを標準化することができ、アラインメントを促進する共有論理データモデルを持っていることを確認して、「single version of the truth」を強制することができます。これにより、ユーザーは最新かつ最高のモデルを使用しており、誰もが共通の定義を共有して同じ「脚本」を読んでいることがわかります。

データをモデル化する際には、データモデルを活用して標準化されたクエリや関連コンテンツを作成し、ダッシュボードの構築を開始してKPIを表現し、組織のレポートニーズや分析を反映させるために、データをどのようにモデル化する必要があるかを把握することをお勧めします。

データの品質の修正を見つけてモデル化しましょう。実際にモデルを使用して既存のソリューションと比較して回答を検証したり、データが正しく見えるかどうかを確認したりすることができます。そして、これらを修正するための修正や微調整を実装し、実際にデータウェアハウスに変更を加える必要があるのか、それともこれらがモデリングレイヤー内で適用できる修正や微調整なのかを把握することができます。

パフォーマンスを向上させるために、より詳細な情報を必要とする場所と要約する場所を特定することができます。モデリングレイヤーを使用して証明することで、どの程度の詳細が必要なのかを正確に知ることができ、さらに創造性が必要な部分や、より高レベルの要件のための集計が必要な部分を知ることができます。これにより、ビジネスユーザーのニーズを満たすための迅速な反復処理を可能にします。

これらについて、覚えておくべき3つの重要なステップがあります。

既存のデータに基づいて初期モデルを作成し、ビジネスデータの専門家に相談することで、不足しているデータのギャップを迅速に特定します。もう一度言いますが、モデルの中で微調整を行うことで、データベースのエラーに対応することができます。そして、その微調整や修正がモデル内で行われるべきかどうか、あるいはその変更がデータウェアハウスの上流にプッシュバックされるべきかどうかを後から決めることができます。

このように、論理データモデルを使用することで、データウェアハウスの変換で柔軟に作業することができます。しかし、まず最初に、なぜデータウェアハウスでのデータ変換を推奨するのかを復習しておきましょう。

In-Warehouse Data Transformation

ETLの問題は、ユーザーやアプリケーションがデータを活用するために必要とする様々な方法をすべて知ることができないということです。変換ポイントにボトルネックを作ることは決してありません。意図した通りにデータを素早くロードすることはできません。ELTソリューションを使用すると、データウェアハウス内のデータを迅速かつ柔軟に照会して転送することができ、その結果、価値を生み出すまでの時間を短縮し、ビジネスユーザーのエクスペリエンスを向上させることができます。

これについて、4つの重要なステップがあります。

データモデリングレイヤーでデータ変換をモデル化し、Lookerの永続派生テーブルなどの一時的なテーブルを介して、テストのデータ変換をデータベースに書き戻します。次に、ユーザーやダッシュボード、下流のアプリケーションへの影響をテストします。そして、一度テストされたデータ変換が、データ変換プラットフォームに実装されると、データウェアハウス内で動作すると述べましたが、データ変換は論理データモデルと手を携えて動作します。なぜなら、論理データモデルを使ってデータ変換をモデル化し、データ変換プラットフォーム内でデータ変換を生産する前に、データ変換が正しいかどうか、必要なものであるかどうかを確認することができるからです。

まとめ

さて、ここまでの話を要約してまとめてみました。

これらがプレゼンテーションから得られた重要なポイントであることを願っていますが、まずは、最新のデータスタックに移行することをお勧めします。私は、アナリティクスに最適化された「Modern Analytical Warehouse」を使用し、「Extract-Load Platform」を使用します。「In-Warehouse Data Transformation」を使用することができます。データをロードして、論理データモデルを作成し、そのモデリングレイヤーをデータ構造から分離することができる「Data Modeling & Governance」を持ったら、rawデータをロードするために素早く移動します。オンラインのデータ変換プラットフォームを活用して、ELTからELTへと移行します。これにより、データを素早く取り込むことができます。すべてを完璧にこなすことを心配する必要はありません。取り込んだ後、ビジネスのニーズに合わせて変換することができます。データをモデル化して変換し、ユーザーやアプリがどのようにデータと対話するかを標準化する論理データモデルを構築し、分析的価値を引き出す目的で構築されたデータ変換を作成します。

おわりに

Looker社だから言っている…というのもあるとは思うのですが、やはりDB構成とデータのモデリングは切り離して管理する方がメリットが大きいと感じました。逆に言うと、テーブル等の変更作業って気を使うので、そういうのから解放されたいと考えているデータエンジニアの方も多いと思うので、この考え方によってDB側の負担軽減もできるんじゃないでしょうか。

あと、ETLよりELTっていうのは、100パー同意です。