クエリ駆動型データモデリングとは何ですか？

「クエリ駆動型データモデリングとは何か？」

もし見逃した場合、数週間前に私はData Engineeringの基礎の共著者の1人とライブショーを行い、クエリ駆動型データモデリングの概念を定義しました。

彼は参照していたのは以下の標準的なデータモデリングの概念です:

概念的
論理的
物理的
ただし、4番目の- クエリ駆動型モデリングを追加する

Reisによれば、多くの企業はもはや最初の2つを実行せず、単発のリクエストをサポートするためにクエリの開発に直接取り組む傾向があります。したがって、私たちはおそらくスタースキーマの形式さえ使用していないし、データマートやデータウェアハウスを構築しているかどうかを考えることさえありません。

代わりに、単一のリクエストをサポートするためだけにテーブルを構築している可能性があります。もしくは、再度Joeがそれを呼んだように、クエリ駆動型モデリングです。

しかし、クエリ駆動型モデリングとは何であり、データワールドでの役割はあるのでしょうか？

クエリ駆動型モデリング

出典: 著者

現在、「QDM」や「JITデータモデル」という公式の定義はありませんが、過去には「スキーマオンリーディ」という類似した用語がありました。

しかし、多くの人がそれが何であるかを知っていると思います。

それは単一のステークホルダーのリクエストに応じてテーブルやデータセットを作成することです。いくらかの要件収集があるかもしれませんが、単一のステークホルダーのためだけです。

クエリ駆動型モデリングの利点

今、エンジニアとしての選択と同様に、利点と欠点があります。

初期インサイトの高速化 — クエリ駆動アプローチで開発する最大の利点は、インサイトまでの時間が短くなることです（少なくとも短期的には）。
セルフサービス — dbtなどのツールは、多くのチームにとってデータへの入り口となっています。アナリストやSQLに精通した人々がクエリからテーブルに進む能力を迅速化するのにも役立っています。これにより、チームは「聖杯」とも言えるセルフサービスをはるかに迅速に実現することができました。私がデータの世界に初めて参入した時、自分でクエリをビルドし、実装して欲しいとEDWチームに連絡することがありました。それがデプロイされるまでには3〜4ヶ月待たなければなりませんでした…ビューとしてです。これは何でもなかったです。多くの分析チームはおそらくそのような環境では効果的に操作することができず、結果としてシャドウITチームやデータウェアハウスを作成することになります。
ステークホルダーは短期間で満足するでしょう — 多くのデータチームは、ステークホルダーがそうするよう圧力を感じるため、常にJITの開発に取り組んでしまいます。マネージャーやディレクターはVPに渡す数字が必要であり、VPはC-Suiteに渡す数字が必要であり、C-Suiteは理事会に渡す数字が必要です。そして、常に下方向への圧力は、新しく作られたアナリストや過労データエンジニアにダウンしてきます。彼らはマネージャーが求めるものを提供したいと思うか、強制されています。

したがって、クエリ駆動型モデリングを使用することが解決策です。生データセットからクエリを実行し、データのガットチェックを行い、完了です。

回答が得られます。

みんなが満足です。

クエリ駆動型モデリングのデメリット

チームがJITアプローチをデータモデルに使用することを決定する際には、常に費用がかかります。データモデルを使用するためのチームが意識的に決定するかどうかは問題ではありませんが、どちらにしても決まっています。明確な優先順位が存在します。

変更が必要な場合の柔軟性の低下ー開発時間は短縮されますが、システムの変更やピボットが求められる場合の能力は、モデル、依存関係、および技術的負債が蓄積されるにつれて悪化します。開発される複雑なシステムの新しい弱点は、誰も気づいていない可能性のある故障点につながる可能性があります。
一貫したメトリクスの欠如ー JITアプローチを採用するデータチームは、同じメトリクスが若干異なる方法で複数のチームによって開発される可能性が高いため、チームの数が合わないという古典的な問題が発生する可能性があります。多くの企業（その中にはFacebookも含まれます）は、重要なメトリクスを定義し、それらが使用されている箇所を紹介するためのメトリクスレイヤーやポータルを作成します。
スパゲッティパイプラインー JITに大きく依存すると、作成されるデータパイプラインシステムはすぐにスパゲッティパイプラインになる場合があります。18つのDAGを遡ってから、思っていたようにsource Aから来るはずだったcustomer_categoryフィールドが実際にはDestination Bによって生成され、最終的にSource Aに戻ったことに気付くことがあります（私はそれを見たことがあります）。
堅牢性の低いデータセットー自己依存のリスクに加えて、1つのパイプラインへのわずかな変更が大きな影響を与える可能性もあります。どのテーブルもコアとして定義されておらず、ガバナンスも最小限なため、変更の重要性を完全に理解するのは難しいでしょう。これに対する解決策として、データの起源などのソリューションを作成していますが、データセットの重要性を追跡するためにデータの起源に過度に依存している場合、既に問題がある可能性があります。
コストーデータの世界に入った最初の頃、ステークホルダーからはダッシュボード用のリアルタイムデータが欲しいと言われました。したがって、Tableauのダッシュボードで「ライブデータ」をクリックして公開しました。

ご想像の通り、データの世界に2年または3年しか身を置いていない方でも、サーバーにかなりの負荷を与えると指摘されるまであまり時間はかかりませんでした。実際、Tableauやdbtのようなツールは問題を解決する一方で、新たな問題を引き起こすこともあります。使いやすさからくる洞察の速さだけでなく、誤った意思決定やコンピュータの使用の速さも増すため、より大きなコストにつながることがあります。

それらのデメリットを考慮すると、クエリ駆動モデリングはデータの世界においてどのような位置を持つのでしょうか。

データの世界においてクエリ駆動モデルはどのような位置を持つのか

私は、データセットを作成する際によりJITアプローチが適する場所があると考えています。これは、アナリティクスエンジニアの役割が特定のチームにとって意味を持つ時です。

企業が大規模なデータチームを持ち、データをどのように使用するかに関する各部署ごとの明確な目標を持っている場合、JITアプローチを伝統的なコアデータモデルと組み合わせて使用することは合理的です。

これは、私たちがFacebookで実現したものです。

私が働いていたチームは、「データインフラ」と考えていたものを作成しました。つまり、私たちが作成したテーブルはFacebookの他の多くのチームに依存していました。他のデータエンジニアは、私たちが構築したものに基づいて彼らの洞察と分析を作成していました。

小さな変更の影響を手動で理解することはできなくなったため、私たちはデータを単なるテーブルではなく、インフラとして扱わなければなりませんでした。1人の利害関係者の要求によって変更することができるテーブルではないのです。

ただし、私たちから1つのチーム離れた場所に行くと、非常に技術的なアナリストやビジネス志向のデータエンジニアが、明確なビジネス要件をサポートするためによりワンオフなデータセットを作成しようとしていることが分かります（これがアプローチが包括的なため、私たちの影響を直接指摘するのが難しい場合があります）。ただし、依存関係が壊れないように、コアテーブルをインフラストラクチャとして扱い、ポリシーやガバナンスが整備されているモデルは合理的です。もちろん、これは完璧なモデルではありませんし、小規模な組織がJITモデリングを使用して適切に動作し、OBTを使用して適切に動作することができる場合もありますが、概念モデリングを扱っているような組織はあまり見かけません。

一般的に言えば、最終的にはテクニカルデットを支払う必要があります。それがコードを書き直すことであるか、続けて進み、このミームが現実になるという視点で立ち往生することにつながるかはわかりません。

出典：Chad Sanderson

もしデータインフラやデータ戦略の評価にヘルプが必要な場合、今すぐ相談を設定しましょう！

これは現代の多くのデータチームでよく起こることです。分析者やデータサイエンティストが独自のデータパイプラインを開発することを余儀なくされ、通常、特定の一連の要求に焦点を当てます。

堅牢なデータセットを開発しないことは、複数のユースケースをサポートすることができます。

デザインは二の次

要件収集なしで必要な時にデータセットとワークフローを構築することには利点があります。それは極端なプロトタイピングのような利点があります。ただし、利点がある一方で、トレードオフもあります。

データセットは複雑な依存関係のツリーの一部となり、ビジネスは常に変更を要求し、結果としてクエリは常に劣化していき、初めにテストされた量よりもはるかに多くの使用量を維持する可能性が高くなります。

例えば、建物の中に新しいストレスをかけた梁があるとします。

最終的には、それが崩壊し、他のいくつかの梁も同様に崩壊するでしょう。

クエリ駆動のモデリングはデータモデリングの一種ですか？もちろんです。

ただし、リスクを理解しておく必要があります。

この記事は元々こちらに投稿されました。許可を得て再掲載しています。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

Was this article helpful?

93 out of 132 found this helpful