hadoop在hive中生成星型模式

8qgya5xd  于 2021-05-29  发布在  Hadoop
关注(0)|答案(1)|浏览(410)

我来自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中合并语句一样)?

5uzkadbs

5uzkadbs1#

我们仍然可以从hadoop和hive上获得维度模型的好处。但是,hadoop的一些特性要求我们稍微采用标准方法来进行维度建模。
hadoop文件系统是不可变的。我们只能添加但不能更新数据。因此,我们只能将记录追加到维度表(虽然hive添加了更新特性和事务,但这似乎有点缺陷)。在hadoop上缓慢改变维度成为默认行为。为了获得维度表中最新的和最新的记录,我们有三个选项。首先,我们可以创建一个使用窗口函数检索最新记录的视图。其次,我们可以在后台运行一个压缩服务,重新创建最新状态。第三,我们可以将维度表存储在可变存储中,例如跨两种存储类型的hbase和federate查询。
数据在hdfs中的分布方式使得连接数据的成本很高。在分布式关系数据库(mpp)中,我们可以将具有相同主键和外键的记录放在集群的同一节点上。这使得连接非常大的表相对便宜。执行连接不需要数据跨网络传输。这在hadoop和hdfs上是非常不同的。在hdfs上,表被分成大块并分布在集群上的节点上。我们无法控制单个记录及其密钥在集群中的分布方式。因此,在hadoop上连接两个非常大的表是非常昂贵的,因为数据必须通过网络传输。我们应该尽可能避免联合。对于大型事实和维度表,我们可以将维度表直接反规范化为事实表。对于两个非常大的事务表,我们可以将子表的记录嵌套在父表中,并在运行时展平数据。我们可以使用sql扩展,比如bigquery/postgres中的array\u agg等,来处理事实表中的多个粒度
我也会质疑代理密钥的有用性。为什么不用自然钥匙呢?也许复杂复合键的性能可能是一个问题,但否则代理键并不是真正有用的,我从来没有使用过它们。

相关问题