目录
Hadoop
Hive
Hbase
Spark
协作组件
数仓
1、简答说一下hadoop的map-reduce编程模型
MapReduce计算模型主要由三个阶段构成:Map、shuffle、Reduce。
Map是映射,负责数据的过滤分法,将原始数据转化为键值对;Reduce是合并,将具有相同key值的value进行处理后再输出新的键值对作为最终结果。为了让Reduce可以并行处理Map的结果,必须对Map的输出进行一定的排序与分割,然后再交给对应的Reduce,而这个将Map输出进行进一步整理并交给Reduce的过程就是Shuffle。整个MR的大致过程如下:
Map和Reduce操作需要我们自己定义相应Map类和Reduce类,以完成我们所需要的化简、合并操作,而shuffle则是系统自动帮我们实现的,了解shuffle的具体流程能帮助我们编写出更加高效的Mapreduce程序。
Shuffle过程包含在Map和Reduce两端,即Map shuffle和Reduce shuffle
总结一句话:map->shuffle(分片、分区、合并、归并)->reduce
2、hadoop的TextInputFormat作用是什么,如何自定义实现
InputFormat会在map操作之前对数据进行两方面的预处理
1是getSplits,返回的是InputSplit数组,对数据进行split分片,每片交给map操作一次
2是getRecordReader,返回的是RecordReader对象,对每个split分片进行转换为key-value键值对格式传递给map常用的InputFormat是TextInputFormat,使用的是LineRecordReader对每个分片进行键值对的转换,以行偏移量作为键,行内容作为值
自定义类继承InputFormat接口,重写createRecordReader和isSplitable方法
在createRecordReader中可以自定义分隔符
3、hadoop和spark的都是并行计算,那么他们有什么相同和区别
两者都是用mr模型来进行并行计算,hadoop的一个作业称为job,job里面分为map task和reduce task,每个task都是在自己的进程中运行的,当task结束时,进程也会结束
spark用户提交的任务成为application,一个application对应一个sparkcontext,app中存在多个job,每触发一次action操作就会产生一个job
这些job可以并行或串行执行,每个job中有多个stage,stage是shuffle过程中DAGSchaduler通过RDD之间的依赖关系划分job而来的,每个stage里面有多个task,组成taskset,由TaskSchaduler分发到各个executor中执行,executor的生命周期是和app一样的,即使没有job运行也是存在的,所以task可以快速启动读取内存进行计算
hadoop的job只有map和reduce操作,表达能力比较欠缺而且在mr过程中会重复的读写hdfs,造成大量的io操作,多个job需要自己管理关系
spark的迭代计算都是在内存中进行的,API中提供了大量的RDD操作如join,groupby等,而且通过DAG图可以实现良好的容错
4、为什么要用flume导入hdfs,hdfs的构架是怎样的
flume可以实时的导入数据到hdfs中,当hdfs上的文件达到一个指定大小的时候会形成一个文件,或者超过指定时间的话也形成一个文件
文件都是存储在datanode上面的,namenode记录着datanode的元数据信息,而namenode的元数据信息是存在内存中的,所以当文件切片很小或者很多的时候会卡死
5.hdfs删除文件的机制
当删除文件时,将删除namenode里的元数据删除,但实际的数据仍将保留在datanode上。namenode和datanode之间的heatbeat会定期的去检测心跳,当发现元数据消失时就会真正去删除datanode上的数据
6、简单说一下hadoop和spark的shuffle过程
hadoop:map端保存分片数据,通过网络收集到reduce端
spark:spark的shuffle是在DAGSchedular划分Stage的时候产生的,TaskSchedule要分发Stage到各个worker的executor减少shuffle可以提高性能部分答案不是十分准确欢迎补充:-)
7、Hadoop平台集群配置、环境变量设置?
zookeeper:修改zoo.cfg文件,配置dataDir,和各个zk节点的server地址端口,tickTime心跳时间默认是2000ms,其他超时的时间都是以这个为基础的整数倍,之后再dataDir对应目录下写入myid文件和zoo.cfg中的server相对应。
hadoop:修改
hadoop-env.sh配置java环境变量
core-site.xml配置zk地址,临时目录等
hdfs-site.xml配置nn信息,rpc和http通信地址,nn自动切换、zk连接超时时间等
yarn-site.xml配置resourcemanager地址
mapred-site.xml配置使用yarn
slaves配置节点信息
格式化nn和zk。hbase:修改
hbase-env.sh配置java环境变量和是否使用自带的zk
hbase-site.xml配置hdfs上数据存放路径,zk地址和通讯超时时间、master节点
regionservers配置各个region节点
zoo.cfg拷贝到conf目录下spark:
安装Scala
修改spark-env.sh配置环境变量和master和worker节点配置信息环境变量的设置:直接在/etc/profile中配置安装的路径即可,或者在当前用户的宿主目录下,配置在.bashrc文件中,该文件不用source重新打开shell窗口即可,配置在.bash_profile的话只对当前用户有效。
8、Hadoop性能调优?
调优可以通过系统配置、程序编写和作业调度算法来进行。
hdfs的block.size可以调到128/256(网络很好的情况下,默认为64)
调优的大头:mapred.map.tasks、mapred.reduce.tasks设置mr任务数(默认都是1)
mapred.tasktracker.map.tasks.maximum每台机器上的最大map任务数
mapred.tasktracker.reduce.tasks.maximum每台机器上的最大reduce任务数
mapred.reduce.slowstart.completed.maps配置reduce任务在map任务完成到百分之几的时候开始进入
这个几个参数要看实际节点的情况进行配置,reduce任务是在33%的时候完成copy,要在这之前完成map任务,(map可以提前完成)
mapred.compress.map.output,mapred.output.compress配置压缩项,消耗cpu提升网络和磁盘io
合理利用combiner
注意重用writable对象
9、Hadoop高并发?
首先肯定要保证集群的高可靠性,在高并发的情况下不会挂掉,支撑不住可以通过横向扩展。
datanode挂掉了使用hadoop脚本重新启动。
10.fsimage和edit的区别
fsimage保存来最新的元数据检查点,包含来整个hdfs文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息,修改时间,访问时间等,对于目录老说包括修改时间,访问权限控制信息(目录所属用户,所在组)等。fimage就是在某一时刻,整个hdfs的快照,就是这个时刻的hdfs上所有的文件块和目录,分别的状态,位于哪些个datanode,各自的权限,各自的副本个数。
editlog主要是在Namenode已经启动情况下对hdfs进行的各种更新操作进行记录,hdfs客户端执行所有的写操作都会被记录到editlog中。客户端对hdfs所有的更新操作,比如说移动数据,或者删除数据,都会记录在editlog中。为了避免editlog不断增大,secondary namenode 会周期性合并fsimage和edits 合并成新的fsimage。新的操作记录会写入新的editlog中,这个周期可以自己设置(editlog到达一定大小或者定时)
1、Hive中存放是什么?
存的是和hdfs的映射关系,hive是逻辑上的数据仓库,实际操作的都是hdfs上的文件,HQL就是用sql语法来写的mr程序。
2、Hive与关系型数据库的关系?
没有关系,hive是数据仓库,不能和数据库一样进行实时的CURD操作。
是一次写入多次读取的操作,可以看成是ETL工具。
3、Hive中的InputFormat、OutputFormat与SerDe
当面临一个HDFS上的文件时,Hive将如下处理(以读为例):
(1) 调用InputFormat,将文件切成不同的文档。每篇文档即一行(Row)。
(2) 调用SerDe的Deserializer,将一行(Row),切分为各个字段。当HIVE执行INSERT操作,将Row写入文件时,主要调用OutputFormat、SerDe的Seriliazer,顺序与读取相反
4、hive加载数据的方法
1、加载本地文件到hive表中(相当于复制数据到表中)
load data local inpath '/opt/datas/dept.txt' into table dept;
load data local inpath '/opt/datas/emp.txt' into table emp;
2、加载hdfs中的数据到hive表中(相当于移动数据到表中)
create table dept2 like dept
load data inpath '/user/hive/warehouse/dept/dept.txt' into table dept2;
3、加载数据覆盖掉已有的数据(overwrite)
load data local inpath '/opt/datas/dept.txt' overwrite into table dept2;
load data inpath '/user/hive/warehouse/dept/dept.txt' overwrite into table dept2;
4、创建表的时候通过select加载(同as的用法)
create table dept_as as select * from dept limit 2;
5、通过insert加载数据(用到查询语句)
insert into table 表名 查询语句;
insert into table dept3 select * from dept limit 3;(不成功,因为dept3不存在)
create table dept3 like dept;
6、创建表的时候直接用location加载
5、hive跟hbase的区别是?
共同点:
hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储
区别:
1.Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统,HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。2.hive需要用到hdfs存储文件,需要用到MapReduce计算框架。
3.想象你在操作RMDB数据库,如果是全表扫描,就用Hive+Hadoop,如果是索引访问,就用HBase+Hadoop 。
4.Hive query就是MapReduce jobs可以从5分钟到数小时不止,HBase是非常高效的,肯定比Hive高效的多。
5.Hive本身不存储和计算数据,它完全依赖于HDFS和MapReduce,Hive中的表纯逻辑。
6.hive借用hadoop的MapReduce来完成一些hive中的命令的执行
7.hbase是物理表,不是逻辑表,提供一个超大的内存hash表,搜索引擎通过它来存储索引,方便查询操作。
8.hbase是列存储。
9.hdfs作为底层存储,hdfs是存放文件的系统,而Hbase负责组织文件。
7.Hive如何解决数据倾斜
表现:任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。
原因:某个reduce的数据输入量远远大于其他reduce数据的输入量
1、sql本身导致的倾斜
1)group by
如果是在group by中产生了数据倾斜,是否可以讲group by的维度变得更细,如果没法变得更细,就可以在原分组key上添加随机数后分组聚合一次,然后对结果去掉随机数后再分组聚合在join时,有大量为null的join key,则可以将null转成随机值,避免聚集
2)count(distinct)
情形:某特殊值过多
后果:处理此特殊值的 reduce 耗时;只有一个 reduce 任务
解决方式:count distinct 时,将值为空的情况单独处理,比如可以直接过滤空值的行,
在最后结果中加 1。如果还有其他计算,需要进行 group by,可以先将值为空的记录单独处理,再和其他计算结果进行 union。
3)不同数据类型关联产生数据倾斜
情形:比如用户表中 user_id 字段为 int,log 表中 user_id 字段既有 string 类型也有 int 类型。当按照 user_id 进行两个表的 Join 操作时。
后果:处理此特殊值的 reduce 耗时;只有一个 reduce 任务
默认的 Hash 操作会按 int 型的 id 来进行分配,这样会导致所有 string 类型 id 的记录都分配
到一个 Reducer 中。
解决方式:把数字类型转换成字符串类型
select * from users a
left outer join logs b
on a.usr_id = cast(b.user_id as string)
4)mapjoin
2、业务数据本身的特性(存在热点key)
join的每路输入都比较大,且长尾是热点值导致的,可以对热点值和非热点值分别进行处理,再合并数据
3、key本身分布不均
可以在key上加随机数,或者增加reduceTask数量
开启数据倾斜时负载均衡
set hive.groupby.skewindata=true;
思想:就是先随机分发并处理,再按照 key group by 来分发处理。
操作:当选项设定为 true,生成的查询计划会有两个 MRJob。
第一个 MRJob 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 GroupBy Key 有可能被分发到不同的Reduce 中,从而达到负载均衡的目的;
第二个 MRJob 再根据预处理的数据结果按照 GroupBy Key 分布到 Reduce 中(这个过程可以保证相同的原始 GroupBy Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。
4、控制空值分布
将为空的 key 转变为字符串加随机数或纯随机数,将因空值而造成倾斜的数据分不到多个 Reducer。
注:对于异常值如果不需要的话,最好是提前在 where 条件里过滤掉,这样可以使计算量大大减少
8.Hive的执行计划
HIVE提供了EXPLAIN命令来展示一个查询的执行计划,这个执行计划对于我们了解底层原理,hive 调优,排查数据倾斜等很有帮助
https://www.cnblogs.com/itlz/p/14423235.html
9.Hive动态分区
1、Hbase行健列族的概念,物理模型,表的设计原则?
行健:是hbase表自带的,每个行健对应一条数据。
列族:是创建表时指定的,为列的集合,每个列族作为一个文件单独存储,存储的数据都是字节数组,其中的数据可以有很多,通过时间戳来区分。
物理模型:整个hbase表会拆分为多个region,每个region记录着行健的起始点保存在不同的节点上,查询时就是对各个节点的并行查询,当region很大时使用.META表存储各个region的起始点,-ROOT又可以存储.META的起始点。
rowkey的设计原则:一定要有规则并且有序,常用的一些 rowkey 一定要连续,并且 rowkey的设计规则最好加入以后要查询的规则在里面方便日后校对查询。https://blog.csdn.net/lzhcoder/article/details/108928697
列族的设计原则: 尽可能少,经常和不经常使用的两类数据放入不同列簇中,列族名字尽可能短。
1.列族对于内存的影响,因为一个列族对应一个MemStore,如果列族过多,MemStore会占用RegionServer大量内存资源
2.列族对于flush的影响,MemStore里的数据进行flush,如果列族数据比较稀疏,分布不均衡,每次flush数据量小的列族会产生大量小文件,列族越多,小文件越多
3.列族数对 Compaction 的影响,与 Flush 操作一样,目前 HBase 的 Compaction 操作是 StoreFile级别的,过多的列族也会产生不必要的 IO。
4.列族对于region的split的影响,当某个region下的某个StoreFile需要切分时,因为切分时针对整个region的,数据量小的列族也会被切分,会产生更多的小文件
表的设计原则:各个列簇数据平衡,长度原则、相邻原则,创建表的时候设置表放入regionserver缓存中,避免自动增长和时间,使用字节数组代替string,最大长度64kb,最好16字节以内,按天分表,两个字节散列,四个字节存储时分毫秒。
2、Hbase的读写性能比较
首先,需要明确的是,Hbase写入速度比读取速度要快,根本原因LSM存储引擎
从存储引擎的角度分析
- Hbase底层的存储引擎为LSM-Tree(Log-Structured Merge-Tree)
- LSM核心思想的核心就是放弃部分读能力,换取写入的最大化能力。LSM Tree ,这个概念就是结构化合并树的意思,它的核心思路其实非常简单,就是假定内存足够大,因此不需要每次有数据更新就必须将数据写入到磁盘中,而可以先将最新的数据驻留在内存中,等到积累到最后多之后,再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的,可以通过合并排序的方式快速合并到一起)。
- LSM树的设计思想非常朴素:将对数据的修改增量保持在内存中,达到指定的大小限制后将这些修改操作批量写入磁盘,不过读取的时候稍微麻烦,需要合并磁盘中历史数据和内存中最近修改操作,所以写入性能大大提升,读取时可能需要先看是否命中内存,否则需要访问较多的磁盘文件。极端的说,基于LSM树实现的HBase的写性能比MySQL高了一个数量级,读性能低了一个数量级。
- LSM树原理把一棵大树拆分成N棵小树,它首先写入内存中,随着小树越来越大,内存中的小树会flush到磁盘中,磁盘中的树定期可以做merge操作,合并成一棵大树,以优化读性能。
Hbase为什么读取速度快
HBase的存储结构导致它需要磁盘寻道时间在可预测范围内,并且读取与所要查询的rowkey连续的任意数量的记录都不会引发额外的寻道开销
1、Spark Streaming和Storm和Flink有何区别?
对比项 | spark-streaming | storm | flink |
---|---|---|---|
流模式 | 微批处理 | 行处理 / 或者微批处理 | 行处理/或者微批处理 |
可靠性 | Exactly-Once | At-Least-Once | Exactly-Once |
延迟 | 秒级 | 毫秒级 | 毫秒级 |
吞吐量 | 比较高 | 非常高 | 非常高 |
容错机制 | Recourd ACKs机制 | 基于RDD的 CheckPoint | CheckPoint |
是否有状态 | 是 | 否 | 是 |
支持SQL | 支持 | 不支持 | 支持 |
与Hadoop兼容性 | 支持HDFS、HBase等数据源 | 不支持 | 支持HDFS、HBase等数据源 |
由于spark 和Flink都可以基于YARN的方式部署,共用了hadoop生态的HDFS,YARN组件,降低了基础平台的运维工作量。同时Flink的毫秒级延迟实时计算能力和spark秒级延迟实时计算能力是一种相互补充。Flink和spark形成互补且竞争关系。
Flink 在 Mlib,SQL 支持方面都有支持,功能方面和spark竞争关系,都是朝着生态方向发展。不过都可以基于相同的底层平台,大家切换和相互替换的成本都不高。
虽然storm的也可以基于yarn部署,但这不是其主流使用场景,所以在大数据基础平台方案中Flink可以最终替换的storm平台。
2、RDD机制?
rdd分布式弹性数据集,简单的理解成一种数据结构,是spark框架上的通用货币。
所有算子都是基于rdd来执行的,不同的场景会有不同的rdd实现类,但是都可以进行互相转换。
rdd执行过程中会形成dag图,然后形成lineage保证容错性等。
从物理的角度来看rdd存储的是block和node之间的映射。
3、spark有哪些组件?
(1)master:管理集群和节点,不参与计算。
(2)worker:计算节点,进程本身不参与计算,和master汇报。
(3)Driver:运行程序的main方法,创建spark context对象。
(4)spark context:控制整个application的生命周期,包括dagsheduler和task scheduler等组件。
(5)client:用户提交程序的入口。
4、spark工作机制?
用户在client端提交作业后,会由Driver运行main方法并创建spark context上下文。
执行rdd算子,形成dag图输入dagscheduler,按照rdd之间的依赖关系划分stage输入task scheduler。
task scheduler会将stage划分为task set分发到各个节点的executor中执行。
5、spark的优化怎么做?
通过spark-env文件、程序中sparkconf和set property设置。
(1)计算量大,形成的lineage过大应该给已经缓存了的rdd添加checkpoint,以减少容错带来的开销。
(2)小分区合并,过小的分区造成过多的切换任务开销,使用repartition。
1、Flume工作机制是什么?
核心概念是agent,里面包括source、chanel和sink三个组件。
source运行在日志收集节点进行日志采集,之后临时存储在chanel中,sink负责将chanel中的数据发送到目的地。
只有成功发送之后chanel中的数据才会被删除。
首先书写flume配置文件,定义agent、source、chanel和sink然后将其组装,执行flume-ng命令。
2、Sqoop工作原理是什么?
hadoop生态圈上的数据传输工具。
可以将关系型数据库的数据导入非结构化的hdfs、hive或者bbase中,也可以将hdfs中的数据导出到关系型数据库或者文本文件中。
使用的是mr程序来执行任务,使用jdbc和关系型数据库进行交互。
import原理:通过指定的分隔符进行数据切分,将分片传入各个map中,在map任务中在每行数据进行写入处理没有reduce
export原理:根据要操作的表名生成一个java类,并读取其元数据信息和分隔符对非结构化的数据进行匹配,多个map作业同时执行写入关系型数据库
3、kafka工作原理?
producer向broker发送事件,consumer从broker消费事件。
事件由topic区分开,每个consumer都会属于一个group。
相同group中的consumer不能重复消费事件,而同一事件将会发送给每个不同group的consumer。
1.数仓分层思想
- ODS层(数据接入层):主要存放原始数据信息。该层数据原则上和源系统数据保持一致
- DW层(数据明细层):对数据进行清洗和规范整合后的明细数据
- DM层(数据集市层):DM层存放的是轻度汇总的数据,以业务分析应用为出发点,但不面向具体的应用和需求
- DA层(数据应用层): DA层存放的是高度汇总的数据,面向具体的应用需求来进行加工汇总,可用于报表展示
- DIM层(数据维度层):维度层,包括业务领域内公共的维度表
- https://www.cnblogs.com/itboys/p/10592871.html
2.什么是拉链表
拉链表是针对数据仓库设计中表存储数据的方式而定义的,顾名思义,所谓拉链,就是记录历史。记录一个事物从开始,一直到当前状态的所有变化的信息。
https://blog.csdn.net/zhaodedong/article/details/54177686
3、元数据如何管理
第一步是采集元数据,第二步是利用采集到的元数据建设元数据管理平台
- · 实现对技术元数据抽取、汇集、梳理,注释相关库表、列信息。支持查看完整数据链路和关联图谱。
- · 梳理业务元数据,将相关的指标、流程在平台中建立起来,固化并传播企业专业知识。
- · 将业务元数据同技术元数据联系起来,联通业务与技术,给业务管理人员和技术维护人员提供更详尽的指导
在元数据管理平台中,可以搜索:
数据源搜索范围:数据源名称、数据源类型、创建人、负责人、标签
表搜索范围:表名称、负责人、Comment、标签
视图搜索范围:视图名称、负责人、Comment、标签
字段搜索范围:字段名称、标签、别名、描述
4、数仓建模方法
1)范式建模法
从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模,在某些时候反而限制了整个数据仓库模型的灵活性,性能等
2)维度建模法(最常用)
紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余
3)实体建模法
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0803zhousb/index.html
4、埋点的码表如何设计
1. 确认事件与变量
2. 明确事件的触发时机
3. 规范命名
4.明确优先级
https://www.douban.com/note/733876053/
5、数据漂移的概念和解决方案
概念:数据漂移是 ODS 数据的一个顽疾,通常是指 ODS 表的同一个业务日期数据中包含前一天或后凌晨附近的数据或者丢失当天的变更数据。
解决方案 :
(1)既然取一天的数据会有数据漂移现象且多半发生在凌晨(因为凌晨是一天的分隔,这不是废话么),那么自然而然就有一种方式:我们多向前一天要一部分数据,也向后一天多要一部分数据。根据一些经验,一般是15分钟。保证数据只多不少,切分时按照需要的业务时间再过滤。是这种方式会有一些数据误差,例如 个订单是当天支付的,但是第二天凌晨申请退款关闭了该订单,那么这条记录的订单状态会被更新,下游在统计支付订单状态时会出现错误。
( 2)通过多个时间戳字段限制时间来获取相对准确的数据
- 首先根据 log_time 分别冗余前一天最后 15 分钟的数据,并用 modified time 过滤非当天数据,并按modified_time升序排序,取第一条
- 然后根据 log_time 获取后一天 15 分钟的数据 针对此数据,按照主键根据 log_time 做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据(数据库日志将保留所有变化的数据,但是落地到 DS 表的是根据主键去重获取最后状态变化的数据)。
- 最后将前两步的结果数据做全外连接,通过限制业务时间proc_time 来获取我们所需要的数据。
时间戳字段分类:
- 数据库表中用来标识数据记录更新时间的时间戳字段(假设这类字段叫 modified time )。
- binlog日志时间戳字段·(假设这类宇段叫 log_time)。
- 数据库表中用来记录具体业务过程发生时间的时间戳字段 (假设这类字段叫 proc_time)。
正常proc_time
https://www.jianshu.com/p/3a0d7229e8c5
6、你们公司数据开发是需求驱动还是业务驱动,如何使用数据促进业务增长?
就怕数据存在数据仓库,需求方不动,数据开发就不动。如果你们数据部门只是简单的提数,没有其他应用,可以主动做一下用户画像,再做推荐系统,或者运营平台,促进业务增长
有业务才有需求,业务才是真真切切的资金流原动力,原动力有了才能流动起来,至于数据如何促进业务增长,那肯定需要看到需求,提取数据,净化细化数据,确定目标方向,计算极端值方案,细化业务方案,最后出执行方案,将历史数据优化找到业务增长点,数据跟业务也是相辅相成的