4

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

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

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

  1. 哈希分区事实表，但这只是暂时阻止了不可避免的增长问题。
  2. 数据库将物理星型模式数据库划分为多个模式/数据库。1..N 个事实表及其维度副本，每个都保存通过 hash(1..N) 函数分配给它们的数据，该函数在单独的 ETL 暂存数据库中执行以确定事实行的数据库/模式（由 ETL 产生过程）将进入。如果任何维度发生更改，请将更改复制到其他数据库对应的维度。同样，这不会作为永久解决方案。
  3. 折叠维度并将所有维度值直接存储在事实表中。然后，将事实表导入到 HBASE on Hadoop。你得到一个巨大的 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

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

依赖于来自互联网的资源贫乏，我认为这个想法是：

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

它适合您的问题吗？

于 2012-12-04T06:40:35.577 回答
0

HBase is not a good choice for a general purpose data warehouse (with real-timish query times) Any single table will only allow you to drill down along one dimension or along one path through dimensions (if you design the right composite key right). It isn't undoable (e.g. ebay built their new search engine on HBase) but it isn't out of the box

There are several efforts to provide high-performance SQL over Hadoop (e.g. Hadapt or Rainstor ) but they won't give you the performance of a good massively parallel databases like Vertica, Greenplum, Asterdata, Netezza and the like

于 2012-09-27T18:44:48.307 回答