亲爱的黑马坛友们: 今天看另一个问的较多的方向,数仓方向: 1. hive的开窗函数
一、over(partition by ......)主要和聚合函数sum()、count()、avg()等结合使用,实现分组聚合的功能
示列:根据day_id日期和mac_id机器码进行聚合分组求每一天的该机器的销量和即sum_num,hive sql语句:select day_id,mac_id,mac_color,day_num,sum(day_num)over(partition by day_id,mac_id order by day_id) sum_num from test_temp_mac_id;
2.hive的行转列
列转行
select id,tag,tag_new
from t_row_to_column_tmp
lateral view explode(split(tag, ',')) num as tag_new
where id=212022894;
行转列
select id,
concat_ws(',',collect_set(tag_new)) as tag_col
from t_column_to_row
group by id;
3.数据仓库的建模方法 以及区别
数据仓库的两种建模方法
范式建模
Inmon提出的集线器的自上而下(EDW-DM)的数据仓库架构。操作型或事务型系统的数据源,通过ETL抽取转换和加载到数据仓库的ODS层,然后通过ODS的数据建设原子数据的数据仓库EDW,EDW不是多维格式的,不方便上层应用做数据分析,所以需要通过汇总建设成多维格式的数据集市层。优势:易于维护,高度集成;劣势:结构死板,部署周期较长
范式建模应用在EDW层
一个符合第三范式的关系必须具有以下三个条件:
1. 每个属性的值唯一,不具有多义性;
2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
但是由于EDW的数据是原子粒度的,数据量比较大,完全规范的3范式在数据的交互的时候效率比较低下,所以通常会根据实际情况在事实表上做一些冗余,减少过多的数据交互。
维度建模
Kimball提出的总线式的自下而上(DM-DW)的数据仓库架构。同样的,操作型或事务型系统的数据源,通过ETL抽取转换和加载到数据仓库的ODS层,然后通过ODS的数据,利用维度建模方法建设一致维度的数据集市。通过一致性维度可以将数据集市联系在一起,由所有的数据集市组成数据仓库。优势:构建迅速,最快的看到投资回报率,敏捷灵活;劣势:作为企业资源不太好维护,结构复杂,数据集市集成困难。
星型模型(推荐)和雪花模型
在复合式的数据仓库架构中,操作型或事务型系统的数据源,通过ETL抽取转换和加载到数据仓库的ODS层,然后通过ODS的数据,利用范式建模方法,建设原子数据的数据仓库EDW,然后基于EDW,利用维度建模方法建设数据集市。
4.事实表和维度表的区别
以前一直对维度表, 事实表, 数据分析, BI等概念等有一些模糊. 这几天的学习终于让这些有了一些眉目了:
维度表示你要对数据进行分析时所用的一个量, 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按..分析就构成一个维度。前面的示例就可以有两个维度:类型和区域。另外每个维度还可以有子维度(称为属性),例如类别可以有子类型,产品名等属性。下面是两个常见的维度表结构:
产品维度表:Prod_id, Product_Name, Category, Color, Size, Price
时间维度表:TimeKey, Season, Year, Month, Date
而事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下:
销售事实表:Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量,以货币计), Unit(销售量)
上面的这些表就是存在于数据仓库中的。从这里可以看出它有几个特点:
1. 维度表的冗余很大,主要是因为维度一般不大(相对于事实表来说的),而维度表的冗余可以使事实表节省很多空间。
2. 事实表一般都很大,如果以普通方式查询的话,得到结果一般发的时间都不是我们可以接受的。所以它一般要进行一些特殊处理。如SQL Server 2005就会对事实表进行如预生成处理等。
3. 维度表的主键一般都取整型值的标志列类型,这样也是为了节省事实表的存储空间。
\
5.数据仓库中 ods与dw 的区别
ODS与DW的区别主要有以下几点:
1、数据的当前性
ODS包括的是当前或接近当前的数据,ODS反映的是当前业务条件的状态,ODS的设计与用户或业务的需要是有关联的,而DW则是更多的反映业务条件的历史数据。
2、数据的更新或加载
ODS中的数据是可以进行修改的,而DW中的数据一般是不进行更新的。ODS的更新是根据业务的需要进行操作的,而没有必要立即更新,因此它需要一种实时或近实时的更新机制。另外,DW中的数据是按照正常的或预先指定的时间进行数据的收集和加载的。
3、数据的汇总性
ODS主要是包括一些细节数据,但是由于性能的需要,可能还包括一些汇总数据,如果包括汇总数据,可能很难保证数据的当前性和准确性。ODS中的汇总数据生命周期比较短,所以可称作为动态汇总数据,如果细节数据经过了修改,则汇总数据同样需要修改。而DW中的数据可称为静态的汇总数据。
4、数据建模
ODS是站在记录层面访问的角度而设计的,DW或DM则是站在结果集层面访问的角度而设计的。ODS支持快速的数据更新,DW作为一个整体是面向查询的。
5、查询的事务
ODS中的事务操作比较多,可能一天中会不断的执行相同的事务,而DW中事务的到达是可以预测的。
6、用途
ODS用于每一天的操作型决策,是一种短期的;DW可以获取一种长期的合作广泛的决策。ODS是策略型的,DW是战略型的。
7、用户
ODS主要用于策略型的用户,比如保险公司每天与客户交流的客服;而DW主要用于战略型的用户,比如公司的高层管理人员。
8、数据量(主要区别之一)
ODS只是包括当前数据,而DW存储的是每一个主题的历史快照;
|