4

仮説として、データ ウェアハウス環境にスター スキーマがあるとします。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) の集計列データを更新する際にマテリアライズド ビューの動作を本質的に模倣した人はいますか?

4

2 に答える 2

1

ディメンションは、HBaseでキー行として定義されます。値は測定値です。ファクトテーブルにファクトがない場合、HBase行の値はnullになる可能性があります。

インターネットからの貧弱なリソースに依存しますが、私はその考えは次のとおりだと思います。

**RowKey**                                **Value**
DimensionA                             XX
DimensionA:DimensionB                  XX
DimensionB:DimensionC                  XX
DimenesionA:DimensionB:DimenesionC:   XXX

それはあなたの問題に適していますか？

于 2012-12-04T06:40:35.577 に答える
0

HBase は、汎用のデータ ウェアハウスには適していません (リアルタイムのクエリ時間が必要です)。単一のテーブルでは、1 つのディメンションまたはディメンションを通る 1 つのパスに沿ってしかドリルダウンできません (適切な複合キーを正しく設計している場合)。元に戻すことはできませんが (たとえば、ebay は HBase で新しい検索エンジンを構築しました)、すぐに使用できるわけではありません。

Hadoop ( HadaptやRainstorなど)で高パフォーマンスの SQL を提供するためのいくつかの取り組みがありますが、 Vertica、Greenplum、Asterdata、Netezzaなどの優れた超並列データベースのパフォーマンスは得られません。

于 2012-09-27T18:44:48.307 に答える