在配置单元中生成星型模式

Zer*_*ity 10 hadoop hive data-warehouse dimensional-modeling fact

我来自SQL Datawarehouse世界,从平面Feed我生成维度和事实表.在一般数据仓库项目中,我们将Feed分为事实和维度.例如:

在此输入图像描述

我是Hadoop的新手,我开始知道我可以在hive中构建数据仓库.现在,我熟悉使用guid,我认为它适用于蜂巢中的主键.那么,下面的策略是在hive中加载事实和维度的正确方法?

  1. 将源数据加载到配置单元表中; 比方说Sales_Data_Warehouse
  2. 从sales_data_warehouse生成维度; 例如:

    从Sales_Data_Warehouse中选择New_Guid(),Customer_Name,Customer_Address

  3. 完成所有维度后,再加载事实表

    SELECT New_Guid()AS'Fact_Key',Customer.Customer_Key,Store.Store_Key ... FROM Sales_Data_Warehouse AS'source'JOIN Customer_Dimension Customer on source.Customer_Name = Customer.Customer_Name AND source.Customer_Address = Customer.Customer_Address JOIN Store_Dimension AS'Store' ON Store.Store_Name = Source.Store_Name JOIN Product_Dimension AS'Product'ON .....

这是我应该在hive中加载我的事实和维度表的方式吗?

此外,在一般仓库项目中,我们需要更新维度属性(例如:Customer_Address更改为其他内容)或者必须更新事实表外键(很少,但它确实发生).那么,如何在hive中加载INSERT-UPDATE.(就像我们在SSIS中查找或在TSQL中使用MERGE语句一样)?

Uli*_*hke 1

我们仍然可以从 Hadoop 和 Hive 上的维度模型中获益。然而,Hadoop 的某些功能要求我们稍微采用标准方法进行维度建模。

\n\n

Hadoop 文件系统是不可变的。我们只能添加数据而不能更新数据。因此,我们只能将记录附加到维度表(虽然 Hive 添加了更新功能和事务,但这似乎相当有问题)。Hadoop 上缓慢改变维度成为默认行为。为了获取维度表中最新的记录,我们有三个选项。首先,我们可以创建一个使用窗口函数检索最新记录的视图。其次,我们可以在后台运行压缩服务来重新创建最新状态。第三,我们可以将维度表存储在可变存储中,例如HBase,并跨两种类型的存储进行联合查询。

\n\n

数据在 HDFS 上的分布方式使得连接数据的成本变得昂贵。在分布式关系数据库(MPP)中,我们可以将具有相同主键和外键的记录共同定位在集群中的同一节点上。这使得连接非常大的表相对便宜。无需数据通过网络传输即可执行连接。这在 Hadoop 和 HDFS 上有很大不同。在 HDFS 上,表被分成大块并分布在集群上的节点上。我们无法控制单个记录及其密钥如何在集群中传播。因此,在 Hadoop 上连接两个非常大的表非常昂贵,因为数据必须通过网络传输。我们应该尽可能避免连接。对于大型事实和维度表,我们可以将维度表直接反规范化为事实表。对于两个非常大的事务表,我们可以将子表的记录嵌套在父表中,并在运行时展平数据。我们可以使用 SQL 扩展(例如 BigQuery/Postgres 中的 array_agg 等)来处理事实表中的多个粒度

\n\n

我还会质疑代理键的用处。为什么不使用自然键?也许复杂复合键的性能可能是一个问题,但除此之外,代理键并不是真正有用,我从不使用它们。

\n