hbase - 将数据仓库星型模式映射到 HBASE

Question

假设，假设我在数据仓库设置中有一个星型模式。
有一个非常非常长的事实表(想想几十亿到几万亿行)和几个低基数维度表(想想 100 个维度表)。每个事实表外键
指向一个维度表的主键是位图索引的。每个维度表主键也是位图索引。这一切都是为了快速连接。都很标准。

假设数据仓库开始表现出性能下降。它的时间
从位图连接返回结果的时间越长，事实表越长。业务需求是事实表不断增长(我们不能将超过一年的数据移到存档存储中)

我正在考虑以下解决方案:

对事实表进行哈希分区，但这只是暂时阻止了不可避免的增长问题。

数据库将物理星型模式数据库划分为多个模式/数据库。 1..N 个事实表及其维度副本，每个数据表都通过 hash(1..N) 函数保存分配给它们的数据，该函数在单独的 ETL 登台数据库中执行以确定事实行(由 ETL 产生的数据库/模式)过程)将进入。如果任何维度发生更改，请将更改复制到其他数据库对应的维度。同样，这不会作为永久解决方案起作用。

折叠维度并将所有维度值直接存储在事实表中。
然后，将事实表导入到 HBASE on Hadoop。您将获得一个庞大的 HBASE 表，即没有维度表的键值存储。我会这样做是因为连接在 HBASE 中成本过高(所以没有维度连接的事实，只是在维度列上强制执行维度值)。

以前有人这样做过吗？

有没有人对解决方案＃3有任何提示？

就快速读取的扩展而言，HBASE 解决方案是否最佳？

至于写入，我不关心快速写入，因为它们会作为批处理在下类时间完成。

如果有人选择了解决方案 1 或 2，是否有人使用过 consistent hashing algorithm (为了避免在有更多分区的情况下像在普通旧哈希中那样重新映射，哈希键是动态创建的)？没有完整重映射的分区数量的动态增长可能不是一种选择(就分区表而言，我还没有在实践中看到它)所以在我看来，任何分区解决方案都会导致扩展问题。

将具有多维的巨型事实表(传统的 DW 星型模式)移动到 HBASE 巨型无维表的任何想法、建议和经验？

相关问题:

如何在数据中聚合传统上驻留在物化 View 中的数据集合(或者作为单独的事实表链接到与最细粒度的事实表相同的维度——即每小时/每天/每周/每月，其中基本事实表是每小时)仓库映射到 HBASE？



我的想法是，由于 HBASE 中没有物化 View ，因此聚合数据集合存储为 HBASE 表，该表会在最细化、最低级别的事实表发生更改时随时更新/插入。

对 HBASE 中的聚合表有什么想法吗？
有没有人使用 Hive 脚本在更改最细粒度的事实表时，在更新存储有聚合数据的辅助 HBASE 表(即daily_aggregates_fact_table、weekly_aggregates_fact_table、monthly_aggregates_fact_table)中更新聚合列数据时，本质化 View 的行为？

Answer 1

Dimension 将被定义为 HBase 中的 keyrow。该值是您的度量值。如果您的事实表是无事实的，则 HBase 行中的值可以为空。

取决于互联网上的可怜资源，我认为这个想法是:

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

它适合您的问题吗？