赞
踩
第一范式:列不可在进行拆分,也就是原子性
第二范式:记录有唯一标识,不存在部分依赖
第三范式:要求字段不能由其他字段派生出来,不存在传递依赖;
事实表:记录了事件的数字化信息,一般由数值型数字和维度表的外键组成 此类数据较大 更新比较频繁
事务事实表:描述业务过程,保存的是最原子的数据
周期快照事实表:以周期为时间间隔,来记录事实
累计快照事实表:用来描述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期;
1 星型模型是一个事实表 多个维度表 维度与维度之间没有任何关系 缺点是存在一定程度的数据冗余
2 雪花模型 即一个事实表 多个维度表 维度表之间通过某种关系可以关联在一起 优点是减少了数据的冗余 缺点是查询效率低于星型模型
3 星座模型多个事实表和多个维度表 共享维表信息这些表在某些特定的情况下会关联在一起 查询性能低
1 尽可能包含所有业务过程相关的事实,即使存在冗余
2 只选择与业务过程相关的事实,如下单的这个业务过程,事实表不应存在支付金额这个表示支付过程的事实
3 事实的单位保持一致 比如 订单金额 优惠金额
4 对null值要处理 因为在过滤中这些条件都不生效
首次创建拉链表 在mysql里面将业务数据导入到 ods层的表中 ods的表创建为分区表 以dt为分区字段 之后由ods层导入到 dwd层的拉链表里面 增加两列 事件的开始时间 和结束时间 9999为结束时间 开始时间自定义(可以采用创建时间 或者 修改时间 或者 导入的时间) 后续有增量及更新的数据 从mysql导入到 ods 将ods的数据新增的数据与旧的拉链表进行左关联 右表里面 id是空 或者 结束时间 不等于 9999 就继续采用左表的结束时间 否则的话 就采用分区时间的前一天 作为失效时间 将得出的数据插入到临时拉链表中 再将新增及变化的数据 插入到临时拉链表里 最终覆盖掉拉链表
1 面向主题
2 集成性
3 非易失性
4 时变性
1 联机事务处理:面向应用
传统关系型数据库的主要应用/日常事务的处理
强调的时候数据库内存效率
2 联机分析处理:面向主题
数据仓库的主要应用,支持复杂的分析,并且提供直观易懂的查询结果
强调的数据分析,磁盘io,分区等
1 数据仓库包含数据集市,在一个数据仓库中可以有多个数据集市
2 数据仓库 数据集团数据中心,基于业务形成各种业务宽表或者统计宽表
3 数据集市基于部门或者主题,形成相应的表数据
1 清晰数据结构,更好的进行定位和理解
2 规范数据分层,开发一些中间层的数据,减少重复计算
3 复杂问题简单化
数据中台是通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。数据中台把数据统一之后,会形成标准数据,再进行存储,数据中台更加侧重于“复用”和“业务”。
数据平台:提供计算和存储能力,为业务提供数据集
数仓:建设数仓里面一整套表
数据中台:包含了数据平台和数据仓库的所有内容,将其打包,整合成产品化的方式
数据湖:存储企业各种原始数据的大型仓库,包括结构化和非结构化的数据,数据库的数据来源
写入流程:
1.客户端连接namenode发起文件上传的请求
2.namenode检查文件是否存在,父目录是否存在,最终返回是否可以上传
3.客户端请求第一个block上传到哪一台datanode服务器上
4.namenode根据配置文件指定的副本数量以及副本放置策略,返回可用的datanode地址.
5.客户端请求三台中的一台datanode上传数据,第一台收到请求之后会调用第二台,第二台调用第三台,从而建立整个通信管道
6.客户端开始向第一台datanode上传第一个block块,以packet为单位默认64k大小,每传一个packet会放入应答队列等待应答.
7.数据在通信管道里面依次传输,传输完成后,在通信管道反方向上逐个发送ack(命令应答),最终由第一台datanode将ack 发送给客户端
8.当一个block传输完成后,客户端会再次请求namenode上传第二个block块.
读取流程:
1.客户端向NameNode请求下载文件,namenode收到请求后会进行一系列检查(如文件是否存在,客户端是否有操作权限等等),检查完成后,找到文件块所在的DataNode地址,并返回地址给客户端
2.挑选一台DataNode(就近原则,然后随机)服务器,请求读取数据
3.DataNode开始传输数据给客户端(从磁盘里面读取数据输入流,以packet为单位校验)
4.客户端以packet为单位接收,先在本地缓存,然后写入目标文件
5.写入完成,关闭资源
心跳机制:datanode默认向namenode每隔3秒钟汇报一次,主要汇报两点,datanode的状态信息和datanode存储的所有的数据块的信息,如果某一时刻开始,某个DataNode不汇报了,可能就是宕机了,NameNode连续10次没有收到汇报,便认为可能存在宕机的可能,NameNode会发送命令向DataNode确认,一般会确认2次,每5分钟确认一次;如果2次都没有返回结果,那么认为DataNode已经挂了
负载均衡机制:主要是保证DataNode中的block块信息大致是相等的,同时namenode还会让数据优先保存在存储余量比较大的DataNode上
副本机制: Block保存多个副本,防止数据丢失,提高数据保存的安全性。默认存3份副本,第一副本放置在上传文件的DataNode上,第二副本放置在与第一个副本不同的机架的节点上,第三副本,放置在与第二个副本相同机架的不同节点上
采用多个节点处理任务,将一个任务拆分成多个子任务,分别运行在不同节点上进行并行计算操作,各个节点计算完成后,将各个节点结果进行汇总处理即可
map阶段:
1 对文件进行切片,每一个切片由一个map处理(解析出来的key/value交给编写的map()函数处理 产生新的key/value)
2对切片的数据解析成key/value键值对,默认是把每一行的内容解析成键值对
3 将解析处理来的键值对交给map函数处理 产生新的键值对
4 maptask产生的结果输出到环形缓冲区里面
5当环形缓冲区的数据达到阈值 80% 开始溢写操作,在数据写入到磁盘前进行一次排序
6 所有溢写的文件进行合并,确保一个maptask只产生一个中间数据文件
reduce阶段:
1 reduce主动从map任务复制输出的键值对
2 把复制到reduce本地数据 全部进行合并,分散的数据合并成一个大的数据文件,并对合并后的数据进行排序
3 对排序后的键值对 调用reduce方法,最终把这些输出的键值对写入到hdfs文件中
1,数据倾斜
2,map和reduce的个数设置不合理
3,reduce等待过久
4,小文件过多
5,大量不可分块的超大文件
6,spill阶段次数过多 (溢写,环形缓冲区)
7,merge阶段次数过多等 (在reduce端进行合并)
8.动态分区过多
一> 数据输入时
1,合并小文件:小文件过多会导致map的个数很多,可以在执行mr之前对小文件进行合并
2,采用ConbinFileInputFormat来作为输入,解决输入端大量小文件的场景
二> map阶段
1,减少spill次数,通过调整io.sort.mb及sort.spill.percent参数值,增大触发spill的内存上限,减少输出的次数,从而减少磁盘的IO
2,减少merge次数,通过调整io.sort.factor参数,增大merge的文件数目,从而缩短mr处理时间
3,在map后进行combine处理,减少I/O
三>reduce阶段
1,合理设置map数和reduce数
2,设置map和reduce共存,调整slowstart.completedmaps参数,使map运行到一定程度后,reduce也开始运行,减少reduce的等到事件
3,规避使用reduce,因为reduce在用于连接数据集的时候将产生大量的网络消耗
4,合理设置reduce端的buffer,正常来说,当数据达到某个阙值时,buffer中的数据会写入到磁盘中,然后reduce会从磁盘中获取所有的数据,过程是 写入磁盘->读磁盘的过程,可以通过参数设置,使buffer的数据直接输送到reduce,从而减少IO
参数:mapred.job.reduce.input.buffer.percent 默认是0.0,当值大于0时,会保留指定比例的内存读buffer中的数据直接拿给reduce用
四>IO传输
1,采用数据压缩的方式,减少网络IO的事件,安装Snappy和LZOP压缩
2,使用SqquenceFile二进制文件
五>数据倾斜问题
减少数据倾斜的方法:
1,抽样和范围分区
2,自定义分区
3,combine
Map:
1.通过参数设置
2.根据数据分成的block块的数量决定
Reduce:
通过参数设置,不设置默认为1
MapTask:
由用户提交的切片(block个数)个数决定
ReduceTask:
小于等于MapTask个数
1-先进先出调度器:将应用放置在一个队列中,然后按照提交的顺序运行应用,按照先进先出的队列顺序。
优点是:简单易懂,配置简单
缺点:不适合共享集群。大应用会占用集群中的所有资源,所以每个应用必须等待着,直到轮到自己运行。
2-容量调度器:一个独立的专门队列保证小作业一提交就可以启动,由于队列容量是为那个队列中的作业保留的,因此这种策略是以整个集群的利用率为代价的。这与FIFO调度器相比,大作业执行的时间会更长。
3-公平调度器:用公平调度器时,不需要预留一定量的资源,因为调度器会在所有运行的作业之间动态平衡。第一个大作业启动时,它是唯一运行的作业,因此获得集群中所有资源。当第二个小作业启动时,它被分配到集群的一般资源,这样每个作业都能公平共享资源。
1 client 向rm提交应用程序
2 rm挑选一台nm启动 applicationmaster
3启动的am向rm注册自己,启动完成后 与rm保持心跳
4 am向rm发送资源申请,申请相应的container
5 rm返回am申请的container信息,之后由am与nm保持通信,在nm上启动container,am与nm保持心跳,进而对nm上运行的任务进行监控和管理
6 运行期间,am对container进行监控,container向am进行汇报自己的进度和状态信息等
7 运行期间 客户端直接和 am通信获取应用的状态,进度更新等信息
8 应用程序结束之后,am向rm注销自己
HIve的文件存储格式有四种:TEXTFILE、SEQUENCEFILE、ORC、PARQUET,前面两种是行式存储,后面两种是列式存储;所谓的存储格式就是在Hive建表的时候指定的将表中的数据按照什么样子的存储方式,如果指定了A方式,那么在向表中插入数据的时候,将会使用该方式向HDFS中添加相应的数据类型。
比对三种主流的文件存储格式TEXTFILE 、ORC、PARQUET
压缩比:ORC > Parquet > textFile(textfile没有进行压缩)
查询速度:三者几乎一致
如果为textfile的文件格式,直接load就OK,不需要走MapReduce;如果是其他的类型就需要走MapReduce了,因为其他的类型都涉及到了文件的压缩,这需要借助MapReduce的压缩方式来实现
行转列
concat(string,string……):字符串连接
concat_ws(参数1,string,string……):参数1是分隔符,按分隔符分隔连接字符串
collect_set(字段名):将字段的值去重,产生array类型字段
列转行
Explode(字段名):将某列中的array或map拆分成多行
Split(字段名,分隔符):根据分隔符来切分某字段元素
Lateral view:写在split,explode等UDTF前,将一列数据拆成多行,再聚合
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。