包含:
•项目做了什么
我们的教育大数据分析平台项目就是将大数据技术应用于教育行业,为企业经营提供数据支撑
•用到了什么技术
Sqoop:sqoop
Mysql:5.7
基于CM上的 hadoop,hive、hue,Oozie
•解决了什么问题
一是数据量太大,现有Mysql数据库无法满足业务统计性能,效率需要。
二是系统多,数据分散。无法打通营销,咨询,报名,教学等业务环节的数据贯通
三是统计分析难度高,工作量大。缺乏规范存储,业务部门有需求时,需要程序员,DBA突击查数据,做报表,尤其是年底各部门排队等DBA协助出数据。
•用于哪个行业?行业有什么痛点是需要项目解决的
教育行业,信息的共享和利用不充分,导致了学校多年信息化应用积累了大量的数据,但信息孤岛的壁垒一直没有打破,如果无法对这些数据进行进一步挖掘,分析,加工,整理,就不能给学校教育,教学,研发,总务等各方面的管理决策提供科学,有效的数据支撑。
以第三个看板报名用户为例:
四张数据表。
customer_relationship(报名信息),itcast_clazz(报名后的校区和学科信息),employee(内部员工信息),scrm_department(部门信息)。
主要用到报名信息表
以报名信息表作为事实表,
以校区和学科信息表
内部员工信息表
部门信息表
作为维度表进行多维分析,
再复用之前的线索表和意向表。
十个需求
怎么分层,为什么这样分层
首先在ODS层原始数据包括有customer_relationship(报名信息),itcast_clazz(报名后的校区和学科信息),employee(内部员工信息),scrm_department(部门信息)。
其次是在DWD层对数据进行清洗,抽取,转换,所以我们在DWD层清洗保留客户表中不为空的,且是已支付的数据,并且转换获得线上线下及年月日等字段。
再次是DWM层,在DWD层基础上,关联校区,学科和咨询中心表,来获取想要的字段。
最后DWS层按产品的属性维度进行统计,得到统计宽表,产品属性维度包括:校区,学科组合分组,来源渠道,咨询中心。
校区报名柱状图:统计期内,全部报名客户中,各校区报名人数分布。
学科报名柱状图:统计期内,全部报名客户中,各学科报名人数分布。
总报名量:统计期内,已经缴费的报名客户总量。
数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、数据集成的(Integrated)、相对稳定(非易失)的(Non-Volatile)、反映历史变化(时变)(Time Variant)的数据集合,
用于支持管理决策(Decision Making Support)。
说白了就是企业想做数据分析,但存在数据孤岛和数据量太大的问题,所以做一个能够系统解决集中存储,海量数据计算和最好支撑SQL的东西叫做数据仓库
数据库:是一种逻辑概念,用来存放数据的仓库,通过数据库软件来实现。数据库由很多表组成,表是二维的,一张表里面有很多字段。字段一字排开,对数据就一行一行的写入表中。数据库的表,在于能够用二维表现多维的关系。如:oracle、DB2、MySQL等。
数据仓库:是数据库概念的升级。从逻辑上理解,数据库和数据仓库没有区别,都是通过数据库软件实现存放数据的地方,只不过从数据量来说,数据仓库要比数据库更庞大的多。数据仓库主要用于数据挖掘和数据分析,辅助领导做决策;
它们的主要区别体现在数仓是综合的或提炼的,数据库是细节的,数仓主要用星型模型或雪花模型;面向分析,支持决策需求;而数据库用的是实体-关系(E-R)模型;面向事务,一次操作使用的数据量小;此外数仓还存储历史数据,不包含最新数据;数据只读,只追加,一次操作一个集合,数据量大,而数据库与之相反。
OLTP: 在线事务处理
OLAP: 在线分析处理
OLTP通常事务操作频繁,数据量小,也就是主要做增删改,OLAP主要是查询操作,数据量大,也就是主要做查询,
OLTP系统主要为了业务能够顺畅、稳定的运行,OLAP系统主要为了数据能够高效的分析处理
同时OLTP响应速度快,主要面向业务操作人员,OLAP响应时间慢,主要面向管理决策人员。
一般分成三层
ODS——》DWD——》DWM——》DWS
由于我们做数据分析,大体上在数仓中都是迭代的计算,这种计算就会分层次来进行。
在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。
由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可。
项目分析的五个大方向(主题)
如:完全同意,请说出原因
如:完全不同意,请说出原因
如:部分同意,请说出原因
部分同意,优秀的数据分析能够指导企业的决策,发现弥补企业的漏洞,提高企业的收益,但“数据不是万能的”,数据只能为决策层提供意见,并不能替代企业做出决策,关键决策仍由领导者决定。
事实:就是事件的意思。表示的是系统中一个真实产生的事件信息。
维度表:记录的是一个事件或者实体的各个维度上的信息
区别:在数据量上,事实表是巨大的,维度表是相对事实表较少。
联系:基于事实表和维度表的关联,我们可以从多个维度上去分析事实表中的数据
宽表就是事实表和维度表的集合
指标
大白话:被看待的数据主题
维度:
大白话:以不同的视角去看待数据
指标一般是数值类型。Y轴展示的就是指标。指标分为绝对数值和相对数值。
维度一般是字符类型,指的是特性。X轴展示的就是维度信息。维度分为定性维度和定量维度。
维度能够转化为指标。
请大体概述一下,企业中遇到什么问题,又用数仓解决了什么问题
企业想做数据分析,但是有数据孤岛问题以及数据量太大,所以做出一个系统解决了集中存储的问题以及解决了海量数据计算的问题,同时还能支持SQL最好。那么这个我们叫做数据仓库。
最好一个,
因为企业面临的困境就是数据孤岛问题,如果数据存储太过分散就无法发挥数仓的优势。即使是两个数仓也会遇到数据同步问题,会浪费时间,降低效率。
维度属性随时间发生改变
例如:一个人的婚姻状态、工作经历、工作单位和培训经历等。
SCD渐变维也称之为拉链表
适用于完整记录版本更迭,又能极大节省存储空间的场景。
它是目前使用最广泛的模式。
维度并不是固定的,维度都可以对其进行细化得到其子维度。
在维度上,会有层级关系
表示上层和下层关系,我们叫做分层
同层之间的关系我们叫做分级
上卷:从当前维度向上找其上层维度进行统计分析
下钻:从当前维度向下找其下层温度进行统计分析
首先,数仓是数据的集中存储。
但是公司是有不同的部门(业务线),它们关心的东西不一样。
各个部门(业务线)是只关系数仓数据中的某一个数据子集
数仓可以划分出很多的数据子集,这种模式称之为:数据集市
数据集市不是必须的,看具体需要
把事务维度所有的描述性项目进行剔出后,形成维度为空。诸如这种事务编号、固有的操作型票据编号,应该自然的放入事实表中,而不用连接到维度表。
例如:订单号,发票号与提货单编号
为了提高数据明细层的易用性,DWD层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。
ods
源数据层(ODS)
此层数据无任何更改,直接沿用外围系统数据结构和数据,不对外开放;为临时存储层,是接口数据的临时存储区域,为后一步的数据处理做准备。
dwd
数据仓库层(DW)
DW 层的数据应该是一致的、准确的、干净的数据,即对源系统数据进行了清洗(去除了杂质)后的数据。
此层可以细分为三层:
明细层DWD(Data Warehouse Detail):存储明细数据,此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。
dwm
中间层DWM(Data WareHouse Middle):存储中间数据,为数据统计需要创建的中间表数据,此数据一般是对多个维度的聚合数据,此层数据通常来源于DWD层的数据。
dws
业务层DWS(Data WareHouse Service):存储宽表数据,此层数据是针对某个业务领域的聚合数据,应用层的数据通常来源与此层,为什么叫宽表,主要是为了应用层的需要在这一层将业务相关的所有数据统一汇集起来进行存储,方便业务层获取。此层数据通常来源与DWD和DWM层的数据。
ads(app)
前端应用直接读取的数据源;根据报表、专题分析的需求而计算生成的数据。
ETL
ETL(Extra, Transfer, Load)包括数据抽取、数据转换、数据装载三个过程。
版本控制工具一般有两种Git和SVN,git是分布式版本控制系统
,SVN是集中式版本控制工具。SVN容错性差,所以一般企业采用Git作为代码管理库
Git是分布式版本控制系统,它没有中央服务器,每个人的电脑就是一个完整的版本库
这样,工作的时候就不需要联网了,因为版本都是在自己的电脑上。
.git文件夹是git 初始化后在当前目录生成的一个管理git仓库的文件夹,
这里包含了所有git操作需要的东西,
如果删了git文件夹就没有了无法保存历史版本
本地库就是存储在本机的代码仓库,远程库就是托管在云端的代码仓库,比较著名的有码云,GitHub
压缩本质上:CPU的计算(执行算法)
它们就是一种特殊的加密算法,这个加密的要求是,加密后的体积要比原本更小
作用是将原来是硬盘负载或者网络负载转移到CPU负载,这是一种收益行为
行存储,数据行存储,一个文件可表达一个二维表。
优点是
概念容易理解,
针对行操作更快捷
事务支持比较好
缺点是针对列的操作性能比列存储低,
只能针对整行数据选定压缩算法,压缩率不高
排序只可基于某一列排序,再行与行之间排序
扩展列,删除列不方便
适用于一般的业务场景如CSV文件,文本文件
列存储,每个文件存储一个列,多个文件合成一张二维表
优点是相对行存储来说,行存储的缺点都是其优点,例如扩展列,删除列更简单,
能够指定列加载到内存中
缺点是整行相关操作性能低。同时对事务的支持性不行
适用的场景:
数仓的特性很大一部分是针对列的过滤,列的搜索,列的匹配,所以很多数仓结构比较适合使用列存储
列存储也比较适合做OLAP
分区就是通过文件夹的方式大范围切分表数据
分桶就是通过区分文件的方式在细粒度上切分表数据
分桶和分区不同,分区是粗粒度的划分数据,并且是大范围的
分桶是细粒度的数据划分
分区划分的是文件夹
分桶划分的是文件
分区的规则是:按照指定key的值来确定文件夹
分桶的规则是:按照hash散列来计算数据应该落入哪个分桶的文件中。
为什么要分区?通常来说庞大的数据量需要花费大量的时间去处理,而根据不同的维度去进行分区能够有效地节省时间,提升处理效率。
为什么要分桶?我个人的理解是减少试错成本,通过对数据进行采样分析,得出具有代表性的查询结果,而不是全部结果,能够极大提升开发的效率。
静态分区:导入数据时需要手动指定分区。动态分区:导入数据时,系统可以动态判断目标分区。 混合分区是两者的混合使用,一张表可同时被静态和动态分区键分区。
MapJoin顾名思义,就是在Map阶段进行表之间的连接。而不需要进入到Reduce阶段才进行连接。
这样就节省了在Shuffle阶段时要进行的大量数据传输。从而起到了优化作业的作用。
它适用于在二个要连接的表中,有一个很大,有一个很小,这个小表可以存放在内存中而不影响性能。
set hive.auto.convert.join=true;
–旧版本为hive.mapjoin.smalltable.filesize
set hive.auto.convert.join.noconditionaltask.size=512000000
两个表join的时候,小表不足以放到内存中,但是又想用map side join这个时候就要用到bucket Map join。
其方法是两个join表在join key上都做hash bucket,并且把你打算复制的那个(相对)小表的bucket数设置为大表的倍数。这样数据就会按照key join,做hash bucket。小表依然复制到所有节点,Map join的时候,小表的每一组bucket加载成hashtable,与对应的一个大表bucket做局部join,这样每次只需要加载部分hashtable就可以了。
全称Sort Merge Bucket Join。
大表对小表应该使用MapJoin来进行优化,但是如果是大表对大表,如果进行shuffle,那就非常可怕,第一个慢不用说,第二个容易出异常,此时就可以使用SMB Join来提高性能。
SMB Join基于bucket-mapjoin的有序bucket,可实现在map端完成join操作,可以有效地减少或避免shuffle的数据量。
简单说Hive是基于Hadoop的一个数据仓库工具,能够将结构化的数据文件映射为一张数据库表,并提供类SQL的查询功能。
Hive,实际上就是一个编译器,一个翻译机。把SQL翻译成MapReduce之类的作业。目前的Hive除了支持在MapReduce上执行,还支持在Spark和Tez 上执行。