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

Question

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

假设数据仓库开始显示性能下降。它的时间 从事实表得到的时间越长，从位图连接返回的结果越来越差。业务要求是事实表不断增长（我们无法将数据超过一年的数据移至存档存储）

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

1. 哈希对事实表进行分区，但这暂时阻止了不可避免的增长问题。
2. 数据库将物理星型模式数据库分区为多个模式/数据库。 1..N事实表及其维度副本，每个都通过散列（1..N）函数保存分配给它们的数据，该函数在单独的ETL临时数据库中执行，以确定哪个数据库/模式是事实行（由ETL产生）过程）将进入。如果任何维度发生更改，请将更改复制到其他数据库对应的维度。同样，这不会作为永久解决方案。
3. 折叠尺寸并将所有尺寸值直接存储在事实表中。 然后，将事实表导入Hadoop上的HBASE。你得到一个庞大的HBASE表，没有维度表的键值存储。我这样做是因为联接在HBASE中是成本禁止的（所以没有事实来维度连接，只是在维度列上强制维度值。）

有没有人曾经这样做过？

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

对于快速读取扩展，HBASE解决方案是否最佳？

就写作而言，我不关心快速写入，因为它们会在批处理过程中完成。

如果有人选择了解决方案1或2，那么是否有人使用consistent hashing algorithm（如果更多分区，动态创建散列键，则避免重新映射为普通旧散列）？没有完全重映射的分区数量的动态增长可能不是一个选项（就分区表而言，我还没有看到它在实践中完成）所以在我看来，任何分区解决方案都会导致扩展问题。

将具有多维度的巨型事实表（传统的DW星型模式）移动到HBASE巨型无量纲表的任何想法，建议和经验？

相关问题：

传统上驻留在物化视图中的聚合数据集合如何（或者作为单独的事实表链接到与最细粒度的事实表相同的维度 - 即基本事实表每小时的每小时/每日/每周/每月）在数据仓库中映射到HBASE？



我的想法是，由于HBASE中没有物化视图，因此聚合数据集合存储为HBASE表，在最细粒度，最低级别的事实表发生更改的任何时候都会更新/插入。

对HBASE中聚合表的任何想法？ 有没有人使用Hive脚本来更新实体化视图的行为，以更新存储在其中的聚合数据的二级HBASE表中的聚合列数据（即daily_aggregates_fact_table，weekly_aggregates_fact_table，monthly_aggregates_fact_table）对最细粒度的事实表的更改？

Answer 1

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

取决于互联网上的不良资源，我认为这个想法是：

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

适合您的问题吗？

Answer 2

HBase不是通用数据仓库的理想选择（具有实时查询时间） 任何单个表只允许您沿着一个维度向下钻取或沿着一个路径向下钻取尺寸（如果您设计正确的复合键右侧）。 它不可撤消（例如ebay built their new search engine on HBase），但它不是开箱即用的

在Hadoop上提供高性能SQL有很多努力（例如Hadapt或Rainstor），但它们不会为您提供良好的大规模并行数据库（如Vertica）的性能，Greenplum，Asterdata，Netezza等