什么是缓慢变化维？
在实际生成情况中，很多维度属性并不是一成不变的，比如机构维度，职级维度
解决方案：
1.属性值不变-啥也不用改，变化的维度并不产生影响
2.重写维度属性--如：更新机构维度数据，问题是无法保留历史的维度值
3.拉链表--如：代理人职级晋升记录，表中的记录变化不大
4.增加维度行--如当维度属性发生变化时新增一条新的维度记录
5.增加属性列--属性变化时，增加一个新的字段来表示
6.全量快照，每天保存一份全量快照表
ETL过程中数据清洗（脏数据处理）小结
1.空值处理：一般使用默认值 入职时间-离职时间
2.数据格式处理： yyyy-MM-dd
3.枚举值处理：统一枚举值信息 ，如性别 男 1 女 2
4.字段类型处理：比如id字段，有的是String，有的是int
5.注释处理：表名，字段名
6.敏感数据处理：加密脱敏 姓名，身份照，手机号等
7.数据单位统一
8.逻辑错误 ：年龄>100
指标建设
分类：
原子指标：某一业务流程下的度量，不可再拆分的
派生指标：由原子指标+多个修饰词+时间周期 新增注册数，支付成功总数
衍生指标/复合指标： 比率型，比例型
目标：基于业务侧发起的需求进行开发工作，最后实现的业务需求真正达成想要的效果 如：为了实现代理人业绩增长考核 200分指标体系
过程：
1.拆解业务目标，梳理出整个指标的框架
2.指标分级分类
3.采用5W2H弥补迭代
数据仓库的规范做什么事？
重视流程和规范，提前打好基础，目的主要有两个：
1.前浪踩过的坑后浪不要踩，提高开发效率
2.需要小伙伴交接的时候，因为大家遵循的标准相同，可以迅速交接上手
主要从如下几个方面展开
数据模型分层设计（ods-dwd-dws-ads,dim）
层次调用：按照数据流向依次调用
命名规范：bas idld init ods sub
代码设计：脚本，复杂逻辑是否有备注，是否支持任务重跑，不允许引用临时表，是否存在笛卡尔积等
任务延迟原因及任务及时产出方案
1.模型层面
严格按照模型架构设计原则，避免链路过长
模型迭代：试运行再提交，避免select * 等操作
模型优化：检查链路那个任务产出时间晚，再进一步分析
2.调度层面
可能遇到的问题
1.上游任务跑完，下游任务过了很久才开始调用 检查调用时间，依赖
2.上游任务跑完，下游一直running 任务运行时间告警，占用资源告警
当天没跑完任务，第二天运维通知
数据质量监控-核心指标数据量，完成时间，任务状态
企业级数据质量是如何建设并落地的？
数仓建设真正的难点不在于数仓设计，而在于后续业务发展起来，业务线变的庞大的数据治理
数据治理的范围：数据安全，数据质量，数据架构，元数据，数据建模设计等
为什么要进行数据质量评估治理？
1.统计近7天用户的购买情况，发现很多数据发生了重复记录，甚至计量单位不统一
2.数据报表每天更新，突然发现某一天的数据量，暴涨暴跌，发现是当天数据缺失或重复
衡量标准
1.数据完整性，是否存在数据缺失的状况，或某个字段信息缺失
2.规范性，有没有遵循语法规则定义，时间格式定义为 yyyy-MM-dd
3.一致性，数据记录的规范和数据是否一致， 年龄 200
4.准确性，饱和度低
5.唯一性，数据大量重复
6.及时性，任务每天监测是否异常或延时
谈谈NameNode和SecondaryNameNode？
两个核心组件Fsimage（hdfs元数据的一个永久性检查点），Edits（hdfs所有更新操作）文件
1.namenode节点的磁盘需要经常进行随机访问，还有响应客户请求，必然效率过低，因此元数据必然放在内存，一旦断电，元数据必然丢失，必须要将元数据备份在磁盘中
2.当内存中的元数据更新时，如果同时更新Fsimage，必然效率过低，一旦断电必然丢失，因此引入了edits文件（只进行追加操作，效率很高），每当内存元数据更新时，修改的内存元数据就存入edits文件，这样可以通过Fsimage和edits合并元数据
3.但是，过长时间添加数据到edits中会导致edits文件过大，效率降低，且一旦断电，恢复时间较长，因此专门引入SecondaryName，用于合并操作
谈谈MapReduce工作流程
1.Read阶段 MapTask通过用户编写的RecordReader，从输入InputSpilt中解析出一个个key/value
2.Map阶段 将解析出来的key/value交给用户编写的Map函数处理，并产生新的key/value
3.Collect阶段 数据处理完后，一般调用OutPutCollect.collect()输出结果，并写入环形内存缓冲区中
4.Spill阶段 当环形内存缓冲区满后，会将数据写到本地磁盘上（对数据做一次本地排序，并在必要时对数据进行合并，压缩等操作），生成一个临时文件
5.Combine阶段 当所有数据处理完后，对所有临时文件进行一次合并
6.copy阶段 ReduceTask将各个MapTask上远程拷贝数据
7.Mergr阶段 启动两个线程对内存和磁盘的文件进行合并
8.Sort阶段 对多有数据进行一次归并排序
9.Reduce阶段 将计算结果写到hdfs上
hbase，hive，hadoop
hadoop本质上是一个分布式文件系统（hdfs）+分布式计算框架（Mapreduce）+调度系统（yarn）搭建起来的分布式大数据处理框架
hive是一个基于Hadoop的数据仓库，适用于一些高延迟性的应用，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql功能
hbase是一个hadoop的数据库，一个分布式，可扩展，大数据的存储。hbase是物理表，不是逻辑表，海量存储，列式存储，稀疏，不能支持条件查询，只能按照rowkey查询
谈谈Datanode工作机制
1.一个数据块block在datanode上以文件的形式存储在磁盘上，包括两个文件，一个数据本身，一个是元数据，包括数据块的长度，时间戳等
2.DataNode启动后，向NameNode注册，通过后，周期性的向Namenode上报所有的块信息
3.心跳机制监测datanode，有异常的则认为该节点不可用
当Datanode读取block的时候，计算checkSum，如果与创建时不一样，说明block损坏，client会读取其他Datanode上的block
谈谈hdfs文件上传：
1.client端通知namenode要上传文件，namonode检查文件名是否因存在，如果不存在通知可以上传，并且返回可以用于存储的datanode列表
2.client切割文件为block块（默认大小为128m），向namenode请求上传block1，namenode返回可用的Datanode信息
3.client和返回的第一个Datanode1建立通信管道，datanode1会和datanode2建立，datanode2会和datanode3建立，这样管道流就建立成功，之后开始上传文件内容，然后Datanode1会和datanode2同步数据，datanode2和datanode3同步数据
4.当统数据数据结束之后通知client上传完毕，client通知namenode块1上传完毕，Namenode会记录元数据信息（block1存在的Datanode位置）的时候进行block2上传
5.如果认为上传成功，namenode后续会指定其他DataNode与DataNode1同步副本数
谈谈hdfs下载文件：
1.client向Namenode提交get下载文件请求
2.Namenode返回相关数据的block list块列表，这个列表是排序过的，排序原则是根据距离client所在的机器的路由远及近和心跳检测
3.client获取离他最近的一个block的地址，与相关的Datanode建立通讯
4.通讯是socket stream 重复调用父类的dataInputStream的read方法直到读取完全部数据
5.读取完毕一个block会进行行数校验，check num，如果发现和Namenode记录的行数不一致会重新请求Namenode给一个新的block地址进行读取，会并行读取多个block块，最后合并成一个文件
谈谈Yarn的资源调度过程？
1.客户端向resourcemanager发送提交任务的请求
2.在resourcemanager端进行一系列的检查，检查输入和输出的目录、权限
3.所有的检查通过，resourcemanager会为当前的程序分配一个nodemanager节点，并在这个节点上启动container，并在这个container中启动MRAppMaster
4.MRAppMaster向resourcemanager申请资源，运行maptask任务和reducetask任务
5.resourcemanager向MRAppMaster返回资源，优先返回有数据的节点
6.MRAppMaster到相应的节点上启动container，然后再启动maptask和reducetask
7.maptask和reducetask启动后需要向MRAppMaster进行汇报自身的运行状态和进度
8.当maptask或reducetask运行完成，这个时候会向MRAppMaster进行注销自己，释放资源
9.当整个应用程序运行完后，MRAppMaster向resourcemanager注销自己，释放资源