問題タブ [dimensional-modeling]

仮説として、データ ウェアハウス環境にスター スキーマがあるとします。1 つの非常に長いファクト テーブル (数十億から数兆行と考えてください) と、カーディナリティの低いディメンション テーブル (100 ディメンション テーブルと考えてください) がいくつかあります。ディメンション テーブルの主キーを指す各ファクト テーブルの外部キーには、ビットマップ インデックスが付けられます。各ディメンション テーブルの主キーにも、ビットマップ インデックスが作成されます。これは高速結合のすべてです。すべてかなり標準的です。

データ ウェアハウスのパフォーマンスが低下し始めているとします。ビットマップ結合から結果を返すのにかかる時間は、ファクト テーブルが長くなるほど悪化します。ビジネス要件は、ファクト テーブルが成長し続けることです (1 年以上前のデータをアーカイブ ストレージに移動することはできません)。

以下の解決策を考えています。

1. ファクト テーブルをハッシュ パーティションしますが、これは避けられない増大の問題を一時的に回避するだけです。
2. データベースは、物理的なスター スキーマ データベースを複数のスキーマ/データベースとして分割します。1..N ファクト テーブルとそのディメンション コピー。それぞれがハッシュ (1..N) 関数を介して割り当てられたデータを保持します。この関数は別の ETL ステージング データベースで実行され、どのデータベース/スキーマがファクト行 (ETL の結果) であるかを判断します。プロセス）に入ります。ディメンションが変更された場合は、ディメンションに対応する他のデータベースに変更を複製します。繰り返しますが、これは永続的な解決策としては機能しません。
3. ディメンションを折りたたんで、すべてのディメンション値をファクト テーブルに直接保存します。次に、ファクト テーブルを Hadoop 上の HBASE にインポートします。ディメンション テーブルを持たない大規模な HBASE テーブル、キー値ストアを取得します。結合は HBASE では法外なコストがかかるため、これを行います (結合をディメンション化することは事実ではありません。ディメンション列にディメンション値を適用するだけです)。

誰もこれをやったことがありますか？

解決策＃3のヒントはありますか？

高速読み取りでスケールアップする限り、HBASE ソリューションは最適ですか?

書き込みに関しては、バッチ処理として時間外に行われるため、高速書き込みは気にしません。

解決策 1 または 2 を選択した人がいる場合、一貫したハッシュ アルゴリズムを使用した人はいますか? 完全な再マップを行わずにパーティション数を動的に増加させることは、おそらくオプションではありません (パーティション化されたテーブルに関する限り、実際に行われたことはありません)。

多くの次元を持つ巨大なファクト テーブル (従来の DW スター スキーマ) を HBASE の巨大な次元のないテーブルに移動することに関する考え、アドバイス、経験はありますか?

関連する質問:

従来、マテリアライズド ビュー (または、最も詳細なファクト テーブルと同じディメンションにリンクされた別のファクト テーブルとして (または、ベース ファクト テーブルが時間単位である時間単位、日単位、週単位、月単位など) に存在するデータ コレクションをデータに集約する方法HBASE への倉庫マップ?

私の考えでは、HBASE にはマテリアライズド ビューがないため、集計データ コレクションは HBASE テーブルとして格納され、最も詳細で最低レベルのファクト テーブルに変更があった場合はいつでも更新/挿入されます。

HBASE の集計テーブルについて何か考えはありますか? Hive スクリプトを使用して、最も詳細なファクト テーブルへの変更時に、集計データが格納されているセカンダリ HBASE テーブル (つまり、daily_aggregates_fact_table、weekly_aggregates_fact_table、monthly_aggregates_fact_table) の集計列データを更新する際にマテリアライズド ビューの動作を本質的に模倣した人はいますか?

レストランの販売取引のファクトテーブルを設定したいと思います。ファクトテーブル全体を合計すると、レストラン全体の売上全体が得られます。レストランには、食べ物と飲み物という2つの主な収入源があります。それぞれの寸法は大きく異なります。

たとえば、食品の場合は、乳製品が含まれていないか、グルテンが含まれていないかなどを追跡したい場合があります。または、料理がイタリア料理、フランス料理などであるかどうかを確認したい場合があります。ワインの場合、ヴィンテージに興味があるかもしれません。ワインは、ワインが何のブドウから来ているのか。

1つのファクトテーブルでこれを達成するにはどうすればよいですか？アイテムが食品の場合はワインのディメンションをNULLにし、アイテムがワインの場合は食品のディメンションをNULLにする必要がありますか？

遅れて到着するディメンションと NULL ビジネス キーのディメンション テーブルで -1 行と -2 行を使用する Kimball データ マートを実装しようとしています。以下に、ファクト データとディメンション データ用のステージング テーブルを 1 つ、ディメンション テーブルを 2 つ、データ マート用のファクト テーブルを 1 つ作成するサンプル コードを示します。SQL のデータを使用したサンプル コードを次に示します。

ソース システムでビジネス キーが欠落している行に -2 を割り当てるにはどうすればよいですか。この実装の背後にある理論については、Kimball から詳しく読むことができます。

• キンボールデザインのヒント128
• Kimball デザインのヒント 78

これは基本的に私が達成しようとしているものです:

ディメンションとメジャーでの NULL の処理

編集：

COALESCE左結合でorを使用できると思いますがISNULL、正しい結果が得られるようです。

次元モデルを解明するための少しの助けを探しています。Web イベント分析に要約されるものを見ています。Web ログが与えられた場合、URL に存在する変数を解析して保存したいと考えています。秘訣は、これらの変数が常に事前定義されているとは限らず、場合によっては変数に複数の値が含まれる場合があることです。

ある仮説を見てみましょう。次のようなクエリ文字列がある場合

session_id=SID&key1=value1&key2=value2&key3=value3a&key3=value3b&key3=value3c

私の目標は、これらのキーの任意の組み合わせによって集計を把握できるようにすることです。たとえば、「key3 の値が value3a であるページ ヒットの数」または「key1 の値が value1 で、key3 の値が value3b であるページ ヒットの数」と言うことができます。複雑さを増すために、最終的に key4 や key5 などが表示される可能性があり、値が表示される前に次元モデルを変更できるようにするための十分な事前警告がない可能性があります。

1 つの方法として、それぞれフィールドとフィールドを持つdim_key1、dim_key2、およびの3 つのディメンション テーブルを作成することが考えられます。dim_key3idvalue

次に、私のファクトテーブルは次のようになります

id, session_id, dim_key1, dim_key2, dim_key3, count

これの欠点はkey3、クエリ文字列から 3 つの値を適切に取得するために、ファクト テーブルに 3 つの行を作成する必要があることです。さらに、表示されるすべてのディメンションについて、事前に通知する必要があり、新しいディメンション テーブルを作成する必要があります。

dim_key3 により適した別の可能なアプローチは、次のようなディメンション テーブルを作成することです。

id, value3a, value3b, value3c, ...

そのテーブルの行は、これらの値の組み合わせを表す 1 と 0 で構成されています。たとえば、上記のクエリ文字列には のような行が1, 1, 1, 1, 0, 0, ...あり、ページ ヒット ファクト テーブルの dim_key3 ディメンション ID は 1 です。

プラス面としては、各ページ ヒットはファクト テーブルに 1 つのエントリしか持たず、ディメンション テーブルはスパース表現を保持できます。そこでは、実際に見た組み合わせに対してのみ新しい行を作成します (つまり、すべての key3 の組み合わせの累乗セット)。マイナス面としては、の新しい値ごとkey3に、そのディメンション テーブルに新しい列を追加する必要があります。

最後のアイデアは、見た値のコンマ区切りリストを格納する のようdim_key3なテーブルを持つことです。これは、「すべての値の列」アプローチと同様のアプローチですが、よりコンパクトな表現を維持するだけです。この場合、 のようなディメンション行があるとします。 id, value_listvalue_list1, "value3a,value3b,value3c"

同様に、これにはファクト テーブルの行が 1 つしか必要なく、追加の利点として、新しい値が表示されても新しい列が必要ありません。欠点は、全文一致/正規表現を実行する必要があるため、クエリが複雑になることです。（興味があればもっと詳しく話せますが、もう十分長く続けているような気がします）。

Kimball の「The Data Warehouse Toolkit」など、いくつかの参考文献を調べましたが、私の質問に直接答えるものは見つかりませんでした。クリック/ウェブ/イベントストリーム分析のディメンション モデルの例のほとんどには、不変で特異値を持つ変数の固定セットがあります。

私の 3 つの概説されたアプローチのいずれかが合理的ですか、および/または私が見逃した別のモデルについて誰か提案がありますか?

前もって感謝します！

環境：SSAS 2005、BIDS2008。

データスキーマ：

DepartmentMaster

• DepartmentNumber int（PARENT）
• SubDepartmentNumber int（CHILD）

カテゴリマスター：

• DepartmentNumberintはDepartmentMaster.DepartmentNumberを参照します
• CategoryNumber int

私が望む機能：

• 階層的なドリルダウン：
  
  • 部門->カテゴリ
  • 部門->サブ部門->カテゴリ

以下の方法で達成されます。

• カテゴリディメンション
• 部門ディメンション
  • サブ部門と部門の親子階層。

これが問題になる理由：

カテゴリは実際には同じディメンションにあり、「製品」または「アイテム」と呼ばれるべきだと思います。当初、サブ部門なしで、これは私がそれを設定した方法です：

• アイテムの寸法
  • 部門->カテゴリ

残念ながら、親エンティティが部門レベルで導入されると、正しく（またはまったく）構築された方法で属性関係を構成できなくなりました。

私の質問：

これらの関係を、すべてが1つの次元になり、上記の階層が得られるように構成することは可能ですか？可能であれば-私はそうすべきですか？そもそも間違ってやってるからうまくいかないの？

現在、私は以下のようなテーブルを持っています：

配偶者/子供がいないことを意味する1900年1月1日の日付。このテーブルを次のように変換したいと思います。

しかし、この表は、特定の時間（2006年1月1日）および（2011年1月1日）にこの質問に答える最良の方法を提供できませんでした。ユーザー1には何人の子供がいましたか？答えは1と2になります。また、テーブル1からテーブル2に変換するのも難しいので、同じuser_idに対して新しい行を作成する方法に固執しています。この状況を改善する方法、またはテーブルを変換する際の問題を解決する方法について何かアイデアはありますか？ヘルプは本当にありがたいです。前もって感謝します。

複数のテーブルから顧客設定を調達するためのディメンションを構築しようとしています。

ソーステーブルの例は次のとおりです。

私はすでにDimCustomerを構築しましたが、今度はCustomerPreferenceDimensionを設計する必要があります。新しいディメンションはSCD1になります。常に顧客に最新の好みを持っています。ただし、特定の顧客は複数の組み合わせを持つことができます。

今私の質問：各プリファレンステーブルのディメンションを設計するのは良いことですか？以下のように、顧客のすべてのプリファレンス属性を1つの単一のディメンションテーブルにまとめる必要があります：

強調表示された列は、顧客の独自の好みになります。*お客様は複数の設定を行うことができます。

将来、ビジネスでさらにいくつかの設定が導入され、ディメンションに含めたい場合はどうでしょうか。次に、これらの属性と、一意にするキーを上記の表に含める必要があります。

上記のように、設定ごとに個別のディメンションを実行するか、すべてを1つの大きなディメンションにマージする方がよいでしょうか。

提案をお願いします。

編集：

私の読書に加えて、私は自分の顧客の薄暗い次元と他の顧客の好みの次元との間のブリッジテーブルを設計する必要があることを理解しています。

私が計画しているのは、すべての組み合わせで各プリファレンスタイプのCustomerPreferenceディメンションを作成することです。そして、これらを多対多の顧客選好関係を持つことができるブリッジテーブルにマッピングします。

以下の例

これは正しい方法ですか、それともベストプラクティスがありますか。

[または]これは正しい方法ですか？

編集：2013年3月27日

Pondlifeの提案によると、以下のようにSnowflakeアプローチを採用しています。

6 次元のデータ ウェアハウスをモデル化しています。これらのディメンションの 1 つはクライアントで、約 60 万行あり、アカウントや製品などのその他のディメンションもあります。各ディメンション テーブルのカーディナリティを掛けて、ファクト テーブルの行数を見積もり、結果として 1*10^12 行が得られました。私の質問は、クライアントが特定の製品を持っていない場合、その製品の行 (ファクト テーブルに cero の値がある) があるのか​​、それとも行がまったくないのかということです。近似が行数の上限になるのか、それとも正確な行数になるのかを知るために、この情報が必要です。

「値」を持つファクトテーブルがあります。ファクト テーブルには、"Job Manager" と "Project Director" の 2 つの外部キーがあり、どちらも DimPerson テーブルの PersonKey にリンクしています。この DimPerson テーブルには人名などがあります。Job Manager で値を確認するにはどうすればよいですか? 個人名でしか確認できませんが、ジョブ マネージャーなのかプロジェクト ディレクターなのかはわかりませんが、両方が合計されています。powerpivot を使用して、ジョブ マネージャーで値を確認するにはどうすればよいですか? またはプロジェクトディレクターによる価値？