要件に基づいて列またはテーブルの粒度を選択する

粒度 は、データ モデルを構築するときに行う最も重要な設計上の決定事項の 1 つです。 テーブルにキャプチャされる 詳細レベル が定義され、 ストレージ コスト、 クエリ パフォーマンス、および回答できる分析の質問に直接影響 します 。 データ エンジニアは、粒度を理解することで、効率的な運用を維持しながらビジネス要件を満たすテーブルを設計できます。

このユニットでは、ディメンション モデリングのコンテキストにおける細分性の意味と、組織の要件に基づいてさまざまな粒度オプションを評価する方法について説明します。

細分性が表す内容を理解する

粒度 ( "グレイン" とも呼ばれます) は、テーブル内の各行が表す詳細レベルを表します。 ファクト テーブルでは、各行でキャプチャされるビジネス イベントまたは測定がグレインによって決まります。 ディメンション テーブルでは、エンティティの表現方法とバージョン管理方法がグレインによって決まります。

IoT センサー データのシナリオを考えてみましょう。 ファクト テーブルは、さまざまなレベルの細分性で設計できます。

• ミリ秒レベルの細分性: 各行は、ミリ秒レベルでキャプチャされた 1 つのセンサー読み取り値を表します。 これにより、各測定の正確なタイムスタンプ、センサー値、デバイス識別子など、最も詳細な情報がキャプチャされます。

• 2 番目の集計粒度: 各行は、デバイスの 1 秒あたりの平均、最小値、または最大値を表します。 個々の読み取り値は、1 秒あたりの統計情報にまとめられます。

• 分単位の集計粒度: 各行は、1 分間のデバイスの集計されたセンサー統計を表します。 これにより、最小限の詳細が提供されますが、必要なストレージは最小限です。

選択したグレインは、すべてのダウンストリームに影響します。 集計によって詳細が失われると、復旧できません。 分単位の集計テーブルで、センサー X が特定の分の間に平均温度 75°C であることを示している場合、温度スパイクが発生したミリ秒を特定したり、異常が発生した正確な瞬間を特定したりすることはできません。

粒度の決定に影響を与える要因を評価する

適切な粒度を選択するには、複数の競合する懸念事項のバランスを取る必要があります。 適切な選択は、特定のビジネス コンテキストと技術的な制約によって異なります。

ビジネス要件によって詳細度が決定される

組織が回答する必要がある分析の質問は、粒度を決定する 主な要因 である必要があります。 自問してみてください:最も詳細な分析レベルとはどれですか?

運用エンジニアがミリ秒レベルで機器の異常を検出する必要がある場合、分単位の集計では不十分です。 生産ライン別の時間単位の使用状況の概要のみが必要な場合、すべてのセンサー読み取り値を格納すると、リソースが無駄になります。

次のシナリオを考えてみます。

クエリ パターンがパフォーマンスに与える影響

ユーザーがデータに対してクエリを実行する方法は、最適な細分性に影響します。 通常、クエリでフィルター処理して上位レベルに集計する場合、過度に細かいデータを格納すると 、不要な処理オーバーヘッドが発生します。 各クエリでは、必要以上に多くの行をスキャンして集計する必要があります。

同時に、細分性が高すぎるデータを格納すると、ユーザーがドリルダウンして詳細な質問に答えるのを防ぐことができます。 バランスを見つけるには、現在のクエリ パターンと予想されるクエリ パターンの両方を理解する必要があります。

ストレージとコンピューティングのコストが蓄積される

細分性が高いほど 、行数が多くなり、 ストレージ コストが増加します。 また、クエリはより多くのデータを処理する必要があるため 、コンピューティング コスト も増加します。 Azure Databricks では、履歴データが蓄積されると、これらのコストが時間の経過と同時に複合化されます。

ミリ秒間隔で読み取り値をキャプチャする何千ものセンサーを備えた製造施設では、最も細かい粒度で毎日数十億行が生成される可能性があります。 1 秒あたりの統計または分単位の統計に集計すると、行数が 99% 以上削減され、ストレージとクエリのコストが削減されます。

コンプライアンスと監査の要件が重要

規制要件 では、特定の粒度レベルが必要になる場合があります。 多くの場合、金融サービス組織は、ストレージ コストに関係なく、監査のために トランザクション レベルの詳細 を保持する必要があります。 医療機関では、コンプライアンス上の理由から、個々の患者の相互作用を追跡することが必要になる場合があります。

コンプライアンスによって粒度の決定が促進されたら、要件を明確に文書化します。 利害関係者が、分析のニーズ以上に詳細を格納する理由を疑問に思うとき、この正当化は役立ちます。

ファクト テーブルに粒度を適用する

ファクト テーブルには通常 、最大の量のデータが含まれているため、細分性に関する慎重な決定が最も役立ちます。 ファクト テーブルのグレインは、 ディメンション キーの組み合わせによって決まります。

日付、製品、顧客、および店舗のディメンション キーを含む販売ファクト テーブルには、"1 日の店舗あたり顧客ごとに 1 つの製品ごとに 1 行" という粒度があります。これらのディメンション値の一意の組み合わせごとに、個別の行が作成されます。 時間ディメンションの時間レベルでキーを追加すると、粒度が「1 商品あたり、1 顧客あたり、1 店舗あたり、1 時間あたり 1 行」に変わり、行数が大幅に増加します。

ファクト テーブルを設計するときは、次のものが必要かどうかを検討してください。

• アトミック グレイン: ソース システムでキャプチャされた最も詳細なレベル。 アトミック グレインを選ぶことで、常に上位のレベルに集計できるため、分解して下位のレベルに戻すことはできないという制約がある中で、分析の柔軟性を最大限に発揮できます。

• 集計グレイン: ソースよりも高いレベルで事前に集計されたデータ。 集計ファクト テーブルを使用すると、一般的な分析パターンの クエリ パフォーマンスが向上 しますが、ユーザーが回答できる質問は制限されます。

多くの組織では、アトミックファクトテーブルと集計ファクトテーブルの両方を維持し、アドホック分析のためにアトミックな詳細を保持しながら、集計テーブルをパフォーマンス最適化として使用しています。 Azure Databricks では、 具体化されたビュー でこれらの集計テーブルを自動的に維持し、基になるアトミック データの変更に応じて更新できます。

ディメンション テーブルに粒度を適用する

ディメンション テーブルにもグレインがありますが、ファクト テーブル グレインとは動作が異なります。 ディメンション グレインによって、ビジネス エンティティの表現方法とバージョン管理方法が決まります。

顧客ディメンションの場合は、次を選択できます。

• 顧客ごとに 1 行: 属性が変更されたときに更新された各顧客の現在の状態 (SCD タイプ 1)。
• バージョンごとに顧客ごとに 1 行: 過去の状態 (SCD タイプ 2) を保持する重要な変更ごとに新しい行。
• 期間ごとに顧客ごとに 1 行: 顧客属性を定期的にキャプチャする定期的なスナップショット。

選択するディメンション グレインは 、ファクト テーブルのグレインと一致している必要があります。 ファクト テーブルが顧客ディメンションへの代理キーを持つ個々のトランザクションを追跡する場合、顧客ディメンション粒度はそのリレーションシップをサポートする必要があります。 顧客バージョン 5 を参照するトランザクションは、ディメンション テーブルでその特定のバージョンを検索できる必要があります。

細分性を選択するときのバランスのトレードオフ

単一の細分性の選択は、普遍的に正しくありません。 各決定には、特定の要件に対して評価する必要があるトレードオフが含まれます。

不明な場合は、 細かい粒度から始めると 、多くの場合、より安全です。 パフォーマンスの最適化のために後で集計テーブルをいつでも作成できますが、キャプチャされなかった 詳細を回復することはできません 。 ただし、このガイダンスでは、最初はきめ細かいストレージをサポートするための予算とインフラストラクチャがあることを前提としています。

適切な粒度を選択する方法を理解することで、コストを効果的に管理しながら、組織の分析ニーズをサポートするデータ モデルを設計できます。 Azure Databricks で選択した粒度でテーブルを構築および読み込むための実装の詳細については、後のユニットで説明します。