我来自sqldatawarehouse世界，在那里我从一个平面feed生成维度和事实表。在一般的数据仓库项目中，我们将feed分为事实和维度。前任：
我对hadoop完全陌生，我知道我可以在hive中构建数据仓库。现在，我熟悉使用guid，我认为它可以作为配置单元中的主键。那么，下面的策略是在hive中加载事实和维度的正确方法吗？
将源数据加载到配置单元表中；比如说销售数据仓库
从销售数据仓库生成维度；前任：
从sales\u data\u warehouse中选择new\u guid（）、customer\u name、customer\u address
当所有维度都完成后，加载事实表，如
选择new\u guid（）作为'fact\u key'，customer.customer\u key，store.store\u key。。。从sales\u data\u warehouse作为'source'加入customer\u dimension customer on source.customer\u name=customer.customer\u name and source.customer\u address=customer.customer\u address加入store\u dimension作为'store'on store.store\u name=source.store\u name作为'product'加入product\u dimension on。。。。。
我应该这样在配置单元中加载事实和维度表吗？
此外，在一般的仓库项目中，我们需要更新维度属性（例如：customer\u address被更改为其他内容），或者必须更新事实表外键（很少，但确实会发生）。那么，如何在配置单元中进行插入更新加载(就像我们在ssis中查找或在tsql中合并语句一样）？
1条答案
按热度按时间5uzkadbs1#
我们仍然可以从hadoop和hive上获得维度模型的好处。但是，hadoop的一些特性要求我们稍微采用标准方法来进行维度建模。
hadoop文件系统是不可变的。我们只能添加但不能更新数据。因此，我们只能将记录追加到维度表（虽然hive添加了更新特性和事务，但这似乎有点缺陷）。在hadoop上缓慢改变维度成为默认行为。为了获得维度表中最新的和最新的记录，我们有三个选项。首先，我们可以创建一个使用窗口函数检索最新记录的视图。其次，我们可以在后台运行一个压缩服务，重新创建最新状态。第三，我们可以将维度表存储在可变存储中，例如跨两种存储类型的hbase和federate查询。
数据在hdfs中的分布方式使得连接数据的成本很高。在分布式关系数据库（mpp）中，我们可以将具有相同主键和外键的记录放在集群的同一节点上。这使得连接非常大的表相对便宜。执行连接不需要数据跨网络传输。这在hadoop和hdfs上是非常不同的。在hdfs上，表被分成大块并分布在集群上的节点上。我们无法控制单个记录及其密钥在集群中的分布方式。因此，在hadoop上连接两个非常大的表是非常昂贵的，因为数据必须通过网络传输。我们应该尽可能避免联合。对于大型事实和维度表，我们可以将维度表直接反规范化为事实表。对于两个非常大的事务表，我们可以将子表的记录嵌套在父表中，并在运行时展平数据。我们可以使用sql扩展，比如bigquery/postgres中的array\u agg等，来处理事实表中的多个粒度
我也会质疑代理密钥的有用性。为什么不用自然钥匙呢？也许复杂复合键的性能可能是一个问题，但否则代理键并不是真正有用的，我从来没有使用过它们。