あなたのデータが適切にモデル化されていない5つの兆候
5 signs that your data is not properly modeled.
クラウド時代の共通の課題
クラウド技術の拡大と安価なストレージコストにより、過去10年間で多くの組織が想像を絶するほどの大量のデータを蓄積しました。多くのクラウドデータウェアハウスプロバイダー（AWS、GCP、Azure）が提供するペイアズユーゴーモデルは、前払い資本リソースの必要性を減らし、デジタルインフラストラクチャの考慮が不要になったことを意味します。
良いニュースは、これによりほとんどの組織にとってデータサイエンスの取り組みがよりアクセス可能になったことです。
悪いニュースは、データレイクがデータスワンプのようになりつつあることです。
データモデリングとは何か？そして、どのような課題があるのか？
上級管理職にウェルモデル化されたエコシステムの価値を伝えることは、データエンジニアにとってしばしば困難です。これは、ステークホルダーに可視なものがBIツールや予測モデルのみであるためです。しかし、不適切にモデル化されたデータは、データガバナンスの観点から分析チームに大きな障害を引き起こします。これにより、ワークフローが遅くなり、繰り返しのタスクが導入され、報告の精度が低下するなど、多くの負の副作用が生じます。
「ウェルモデル化された」データを定義することは、それ自体が別のトピックです。しかし、データウェアハウスにおける以下の概念によって考えることができます。
- ビジネスエンティティに関連するデータテーブルを見つける方法に明確なパターンが存在する。
- 次元モデル、エンティティリレーションシップモデル、データボルトなど、意図的または既知のモデリング技術が使用される。
- テーブルとフィールドの命名規則が一貫しており、適切に文書化され、ビジネス価値を持つ。
データモデリングには、ホリスティックでマルチシステムなアプローチがあることも指摘しておきます。それは、データが最初に記録される場所であるOLTP（オンライントランザクション処理）システムから始まります。以下はその例です。
- SalesforceのようなCRMシステム
- StripeのようなPOSシステム
- AmazonのようなECサイト
理想的には、データはソースシステムを通じて3次正規化され、分析環境（オンライン分析処理）に取り込まれます。ここでは分析モデリング技術が適用されます。本記事の文脈では、OLAPシステムはクラウドデータウェアハウスと同義です。ただし、OLAPシステムには、SQL Server、MySQL、PostgreSQLなどの独立したホストツールも含まれます。
データアナリストやデータサイエンティストはOLAPシステムだけとやり取りしますが、組織のデータモデリング戦略はOLTPとOLAPの両方を考慮する必要があります。
分析環境が不適切にモデル化されていることを示す5つの主要な兆候
1.) データを見つけるためにトライバルな知識が必要
新しいアナリストが雇われた場合、データウェアハウスにどのようなデータがあり、それがどこから取得され、どのようなビジネスコンテキストがあるのか、明確なロードマップが必要です。しかし、データが不適切にモデル化されたチームは、新しいメンバーが基本的なビジネスの質問に答えるのにかかる時間が長いことを理解せず、新しい候補者をオンボードするのに苦労します。適切なメンターシップがないと、アナリティクスチームは新しいメンバーが成功するために必要なツールを与えられないため、高い離職率を経験する可能性があります。
データアナリストとデータサイエンティストは、ビジネスの問題に答えることに集中する必要があり、ビジネスエンティティの場所を見つけるために時間を浪費すべきではありません。チームが利用可能なデータに早く慣れることができれば、ダッシュボードや予測モデルがより早く完成することになります。これは、最終的にチームの生産性を向上させます。
基本的なビジネスの質問に答えることができるアナリストがわずか数名しかいない場合、それは問題です。そのような孤立したアプローチで働くことはスケーラブルではなく、チームが解決できる問題の数を制限するだけです。
2.) 異なるアナリストが同じメトリックに対して異なる結果を生み出している
真実の単一のソースがない場合、異なるチームメンバーが同じメトリックを異なる方法で計算することが簡単になります。たとえば、収益はどのように定義されますか？そして、これを計算するためにどのテーブルが使用されますか？ビジネスロジックを定義するためには明確なパスが必要であり、すべては意図的なデータモデルから始まります。
私は、同じビジネスエンティティを表す3つの異なるテーブルがあり、すべて異なるSQLロジックを利用して類似したが同じではないレコード出力に到達している環境で働いたことがあります。このシナリオに加えて、管理が不十分なレポート要求キューがあると、2人の異なるアナリストが異なる結果で同じ質問に答えることになります。これはステークホルダーがデータに対する信頼を失うだけでなく、チーム全体で面倒で不要な調整作業が必要になります。
3.) チームはビジネスロジックの冗長なコードブロックを再利用する必要があります
私は、特定のビジネスメトリックを説明するSQL CASEステートメントのGoogleシートを持っているチームを見ました。これらは長くて読みにくいものでした。それはチーム全体で一貫性を提供しようとするものですが、これは組織内のDRY（Don’t Repeat Yourself）原則に違反する問題があります。
このような問題を抱える多くのチームにとって、DBTなどの変換ツールを使用することで、アナリティクスエンジニアがビジネスロジックを一箇所に定義し、アナリストがそのロジックを多数の場所で参照できるようにすることができます。
以下の例を考えてみてください。あなたが電子商取引会社である場合、ページビューを複雑な方法で計算する方法がある場合（これは問題ありません）、なぜあなたがそのビジネスロジックをBIツールで配布し、複製する必要があるのでしょうか？ロジックが毎回正確にコピー＆ペーストされていない場合、これは危険です。また、これは、ほとんどのクラウドプロバイダの最大の費用であるコンピューティングの無駄です。
これを解決するために、共通の集計およびビジネスロジックをマッピングし、変換ジョブを毎日（または必要に応じて頻繁に）実行し、それをテーブルに書き込みます。その後、BIレイヤーをその上に配置します。
4.) データウェアハウスのパフォーマンスが悪い
上記で指摘されたように、不適切にモデル化されたデータは冗長性を導入します。しかし、これは不必要な複雑さを作り出すことにもつながります。余分なコンピューティングリソースは、このバイプロダクトであり、すべてのクラウドデータウェアハウスには一定の価格設定のしきい値があります。その限界に達すると、新しいクエリを実行することが非常に遅く、場合によっては実行できなくなる可能性があります。
どのデータエンジニアに尋ねても、この問題に対する持続可能な解決策として、単に追加のリソースを購入することはありません。
長くて複雑なクエリが単独で実行されるだけでなく、環境で利用可能なリソースも減少します。20つの結合が必要なクエリを実行する必要がある場合を考えてみてください。データベースに必要なデータが簡単にアクセスできる形式ではないことを示しているため、理想的な解決策である可能性は非常に少ないです。これだけの結合は、関連するテーブルが大量のデータを含んでいる場合や、ON句に複数の列が含まれる場合など、演算コストが高くなる場合があります。ディメンショナルモデルを実装している場合は、チームがこれらのシナリオでデータベースに新しいファクトテーブルを作成することを検討することができます。
リソースは、使用しているクラウドプロバイダによって異なる方法で測定されますが、すべてのクラウドプロバイダは仮想CPUの専用数を使用するという同じ概念に従います。たとえば、BigQueryはスロットの概念を使用しています。これは、クエリを実行するために使用される利用可能なコンピューティングリソースの数です。オンデマンドの価格設定を受け取る組織は、いつでも使用できる2,000スロットを受け取ります。したがって、1つのクエリが非常に複雑で、利用可能なスロット数を超えるような場合、他のクエリは実行される前にキューに残されます。
5.) SQLで値をハードコードする必要があることがよくあります
ハードコードされた値は、データウェアハウスに必要なデータが欠落していることを示す兆候であることがよくあります。ディメンショナルモデルの文脈で、これは通常、追加の列をソースとする新しいディメンションテーブルを作成する必要があることを意味します。
Zach Quinn氏の記事では、ルックアップテーブルで長いCASEステートメントを排除する方法を非常によく説明しています。この例をディメンショナルモデルの文脈に置くと、あなたの組織が多くのジオスペーシャル分析を行う必要があると仮定します。州の略語を提供するcustomer_dimensionテーブルがありますが、それを完全な州名として表示したい場合があります。以下のようなものを書くことができます。
SELECTcustomer_id, customer_name, address, city, state AS state_abrevaition, CASE WHEN state = 'NJ' THEN 'New Jersey' WHEN state = 'NY' THEN 'New York' WHEN state = 'PA' THEN 'Pennsylvania' .............. END AS state_full_name, zip_codeFROM customer_dimensionしかし、この種のCASE文は持続可能ではありません。より詳細にこの解決策を改善したい場合は、zip_code_dimensionテーブルをcustomer_dimensionテーブルに結合する必要があります。以下に示すように、zip_code_dimensionを使用すると、さらに詳細な分析が可能になります。テーブルは以下のようになります。
したがって、新しいテーブルを使用して、次のクエリを実行できると想像してください。
SELECTc.customer_id、c.customer_name、c.address、c.state AS state_abreviation、z.state_name、c.zip_code、z.county_name、z.country_name、z.timezone、z.lat、z.lngFROM customer_dimension cLEFT JOIN zip_code_dimension z ON c.zip_code = z.zip_codeこれは、フルステート名を生成するためによりエレガントかつ読みやすいクエリであり、より多くの質問に答えることができます。zip_code_dimensionを使用すると、その郵便番号の緯度と経度を追加して、よりクリーンな形式でマップの可視化を作成できます。さらに、出力に含めるために数百行のハードコードが必要だった可能性のある他の次元フィールドがいくつかあります（国、タイムゾーンなど）。
結論
上記のポイントのいずれかが環境に関連している場合は、データパイプライン全体をホリスティックに見直し、分析チームがギャップを埋める必要がある場所を理解する必要があります。チームのデータを適切にモデル化するためには、関連するビジネスエンティティを概念化し、組織化する必要があります。これは万人に合うアプローチではありませんが、すべてのチームメンバーに明確になり、一貫した方法で作成される必要があります。
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
Related articles
