1. Hbase表设计原则
http://gao-xianglong.iteye.com/blog/2031543
1)宽表指的是行少列多,如果一行数据量过大,可能造成一个HFile放不下。但宽表有行级原子性的优势。高表指的是行多列少,Hbase只能按行分片,因此高表更有优势。具体还是要根据业务场景综合考虑。
2) 最好不要定义过多的ColumnFamily,一般来说, 一张表一个ColumnFamily就好。因为Flushing和压缩是基于Region的。当一个ColumnFamily所存储的数据达到Flushing阀值时,该表中的其他ColumnFamily可能没存储多少数据,也要跟着进行Flushing操作,这将会带来很多不必要的IO消耗。ColumFamily越多,对性能的影响也就越大。此外,同一个表中不同的ColumnFamily存储的数据量差别也不要太大,不然有些数据会分散在太多的Region上,会影响检索效率。
2. Hbase rowkey设计原则
总的原则:综合考虑业务场景,及hbase的存储访问特点。
几个简单的原则:rowkey唯一,长度一致,能短则短。
然后考虑几个问题:
1)读取方便?
i. 尽可能的把检索条件存储于rowkey中。
ii. 同时访问的数据,rowkey尽量连接,即可以利用scan指定start和end rowkey直接访问。
2) 提高写效率?
i. 评估业务场景,根据数据分布情况进行预分区,提高并发度。
ii. 有些情况下,可以加入散列值,使写分散到各regionserver,避免单点过载。
3. mapreduce 的 join 方法有哪些?
http://database.51cto.com/art/201410/454277.htm (里面的例子很好理解)
https://my.oschina.net/leejun2005/blog/95186
如有两个文件File1和File2,文件内容如下:
File1: (学生编码,学生名字,性别)
zs 张三 男
...
File2: (学生编码,选修课程,得分)
zs c1 80
zs c2 90
...
1) reduce join
适用于两张表都是大表
在map阶段,输出<key,value>,在value中标记数据是来自File1和File2,在reduce阶段,将key的value按照来源是File1还是File2分成两组,做集合乘积。
缺点:
i. map阶段没有对数据瘦身,shuffle的网络传输和排序性能很低。
ii. reduce端对2个集合做乘积计算,很耗内存,容易导致OOM。
示例:
在map阶段:map函数同时读入两个文件File1和File2,对每一条数据打一个标签,用来区分数据来源于File1还是File2。连接字段做为key,其他字段及标志做为value。
如<zs, {"张三 男", 0}>
<zs, {"c1 80", 1}>
<zs, {"c2 90", 1}>
在shuffle阶段: 会按key分组,连接字段为key,各个map的的输出结果形成list做为value。
如<zs, { {"张三 男", 0}, {"c1 80", 1}, {"c2 90", 1} }>
在reduce阶段: 对同一个key, 按标志位,将value分成左表和右表,然后进行笛卡尔连接输出。
如 左表 = { "张三 男" }
右表 = { "c1 80", "c2 90" }
然后两个for循环实现笛卡尔连接输出:
张三 男 c1 80
张三 男 c2 90
2) map join
适合一张小表,一张大表。
小数据文件全部加载到内存,大数据文件作为map的输入文件,在内存中和小数据文件进行连接,按key分组输出。减小shuffle阶段的排序和网络传输消耗。
示例:
假设File1为小表,File2为大表。
i. 将小表文件File1放到该作业的DistributedCache中。
ii. 在setup函数中,将File1从DistributedCache中读入内存中,如hash map中。如:
{zs, "张三 男"}
iii. 在map函数中,扫描File2,判断File2的key在不在hasp map中,如果在,直接输出(
key + hash map中该key的value + File2中其他字段) 如:
zm 张三 男 c1 80
3)semi join
reduce join的一个变种。将File1中参与join的key单独抽取出来,存入File3。通过Distributed Cache分发到相关节点,然后将其取出放到内存中,如hash set中。在map阶段扫描连接表,将key不在set中的记录过滤掉,将那些参与join的记录打上标签通过shuffle传输到reduce端进行操作,后面的过程和reduce join是一样的。
4)reduce join + boomfilter
如果semi join 抽取出来的key在内存中还放不下,则考虑将key放入boomfilter。通过boomfilter过滤掉不需要参与join的记录,将那些参与join的记录打上标签通过shuffle传输到reduce端进行操作,后面的过程和reduce join是一样的。boomfilter是通过二进制位(0101这些)记录数据,所以占用空间比较小。
4. MR 数据倾斜原因和解决方案
数据倾斜就是数据key分布不均匀,导致分发到不同的reduce上,个别reduce任务特别重,导致其他reduce都完成,而这些个别的reduce迟迟不完成的情况。
http://blog.sina.com.cn/s/blog_9402246001013kxf.html
http://www.cnblogs.com/datacloud/p/3601624.html
原因如下:
1) key分布不均匀
2) 业务数据本身的特征
解决方案:
假设A、B两张表关联,A中存在数据倾斜的key
1)先对A表进行采样,将造成数据倾斜的key的记录存入一个临时表tmp1。
2)一般情况下,造成数据倾斜的key不会太多,所以tmp1会是一个小表。所以可以将tmp1和B表进行map join,生成tmp2,再把tmp2分发到distribute file cache。
3)map读入A表和B表,假如记录来自A表,则判断key是否在tmp2中,如果是,输出到本地文件a,如果不是,则生成<key,value>对,假如记录来自B表,生成<key, value>对,进入reduce阶段。
4)将文件a和步骤3中reduce输出文件合并起来写到hdfs。
通俗的说法:
1)map端数据倾斜,一般是输入文件太多且大小不一造成的,可以考虑合并文件。
2)reduce端数据倾斜,一般是默认的分区器问题,可以考虑自定义分区, 根据数据中key特性及分布情况自定义分区,使之尽可能均匀地分配到reduce。
3)设置Combine, 聚合精简数据。
4 ) 两张表join, 如果造成数据倾斜的key记录占全量数据比例较少的话,可以考虑将数据分为倾斜和非倾斜部分,这样倾斜部分会是小文件,可以使用map join处理,非倾斜部分则可以按正常reduce处理,最后合并起来即可。
如果使用hive统计,可以通过以下办法解决:
1) 调节hive配置参数:
i. hive.map.aggr = true --map端部分聚合 相当于Combiner
ii. hive.groupby.skewindata = true --有数据倾斜时,查询计划生成两个mr job,第一个job先进行key随机分配处理,先缩小数据量。第二个job再进行真正的group by key数理。
2) SQL调节
i. 大小表join
使用map join让小表先进内存,在map端完成reduce。
ii. 大表join大表
如果是空值造成数据倾斜,那么把空值变成一个字符串加上随机数,把这部分倾斜的数据分发到不同的reduce上。
iii. count distinct 大量相同特殊值 (如空值)
空值可以不用处理,直接最后count结果加1即可。或者空值单独拿出来处理,最后再union回去。
iv. 不同数据类型关联
默认的hash操作会按其中一种类型的值进行分配,导致别一种类型全部分发到同一个reduce中。把两个关联的类型转换成相同类型。
5. RDMS数据库三范式
1NF:字段不可分割。 org_id只能存机构编码,不能存机构编码+用户编码
2NF:主键不可冗余。 org_id+kpi_code 做为主键可以。 org_id+org_name+kpi_code做为主键不妥。
3NF:非主键不可依赖。org_id,kpi_code,kpi_value做为一张表可以,org_id, org_name, kpi_code, kpi_value做为一张表不妥,因为依赖到非主键org_name。
其实OLTP可以完全遵守3NF,但OLAP只要做到2NF就可以了。
6、hadoop 运转的原理?
通过namenode管理文件系统的命名空间,维护文件系统树中的所有文件和文件夹的元数据,由datanode存储实际数据,并向namenode汇报数据存储情况。即通过hdfs实现数据存储,通过mr实现数据计算处理。
7、mapreduce 的原理?
一个根本思想就是“分而治之”,将一个大任务分解成多个小任务,map并行执行后,reduce合并结果。
8、说说mapreduce 是怎么来运转的?
先将文件进行分割后,进行map操作,后面进行shuffle操作,分为map端shuffle和reduce端shuffle,map输出结果放在缓冲区,当缓存区到达一定阈值时,将其中数据spill(也就是溢写)到磁盘,然后进行partition, sort, combine操作,这样多次spill后,磁盘上就会有多个文件,merge操作将这些文件合并成一个文件,reduce端shuffle从map节点拉取数据文件,如果在内存中放得下,就直接放在内存中,每个map对应一块数据,当内存占用量达到一定程度时,启动内存时merge,把内存中的数据输出到磁盘的一个文件上。如果在内存中放不下的话,就直接写到磁盘上。一个map数据对应一个文件,当文件数量达到一定阀值时,开始启动磁盘文件merge,把这些文件合并到一个文件中。最后,把内存中的文件和磁盘上的文件进行全局merge,形成一个最终端文件,做为reduce的输入文件。当然merge过程中会进行sort,combine操作。
9、HDFS 存储的机制?
namenode负责维护所有数据目录及文件的元数据,datanode负责实际数据存储。
客户端向hfds写数据,首先会将数据分块,与namenode通信,namenode告知客户端将数据写入datanode的地址,第一个datanode写完后,将数据同步给第2个datanode,依次类推,直到所有备份节点写完为止,然后进入下一个数据块的写操作。
在有启用机架感知的情况下,存储策略为本地一份,同机架内其它某一节点上一份,不同机架的某一节点上一份。
10、mapreduce 中 Combiner 和 Partition 的作用
Combiner就是在map端先进行一次reduce操作,减少map端到reduce端的数据传输量,节省网络带宽,提高执行效率。
Partition就是将map输出按key分区,送到不同的reduce上去并行执行,提高效率。
11、Hive 元数据保存的方法有哪些,各有什么特点?
1)、内嵌模式:将元数据保存在本地内嵌的derby数据库中,内嵌的derby数据库每次只能访问一个数据文件,也就意味着它不支持多会话连接。
2). 本地模式:将元数据保存在本地独立的数据库中(一般是mysql),这可以支持多会话连接。
3). 远程模式:把元数据保存在远程独立的mysql数据库中,避免每个客户端都去安装mysql数据库。
12、 hadoop机架感知
http://blog.csdn.net/l1028386804/article/details/51935169
topology.script.file.name
value指定一个可执行程序,通常是一个shell脚本,该脚本接受一个参数(ip),输出一个值(机架位置)。
可以将ip,主机名,机架位置配置在一个配置文件中。然后脚本读取该配置文件,去解析传入ip对应的机架位置,并输出即可。当然也可以用java类实现。
hdfs存储策略是本地存储一份,同机架内其他节点存储一份,不同机架某一节点存储一份,当执行计算时,发现本地数据损坏,可以从同一机架相邻节点拿到数据,速度肯定比跨机架来得快。同时,如果整个机架的网络出现异常,也能保证能从其他机架拿到数据。 要实现这个存储策略,就需要机架感知。
13、hdfs 的数据压缩算法
http://www.tuicool.com/articles/eIfAJbM
压缩格式:gzip, bzip2, lzo
压缩算法:deflate[dɪ'fleɪt], bzip2,lzo
从压缩效果来讲:bzip2 > gzip > lzo
从压缩速度来讲:lzo > gzip > bizp2
另外bizp2,lzo都支持文件分割,gzip不支持。
所有压缩算法都是时间和空间的权衡,在选择哪种压缩格式时,我们应该根据自身的业务需要来选择。
14、hadoop 的调度器有哪些,工作原理?
http://www.mamicode.com/info-detail-1097801.html
http://www.cnblogs.com/xing901022/p/6174178.html
https://my.oschina.net/ssrs2202/blog/494729?p={{currentPage+1}}
http://www.tuicool.com/articles/M3ayEj
http://lxw1234.com/archives/2015/10/536.htm
FIFO调度器,只有一个队列,按先进先出的原则为job分配资源。
Capacity调度器,可以设置多个队列,并为每个队列设置资源占比,比如有三个队列,资源占比可以设置为30%,30%,40%。队列之间支持共享资源,当某个队列的资源不用时,可以共享给其他有需要的队列。当集群繁忙时,一旦有些任务完成释放资源形成空闲资源,优先分配给资源利用率低的队列,最终达到按“队列容量”分配资源的效果。队列里面的Job按FIFO规则选择优先顺序。
当然,可以设置队列的最大资源使用量,这样可以保证每个队列都不会占用整体集群的资源。
Fair调度器,可以设置多个队列,并为每个队列设置最小份额,权重等指标,比如整个集群有100G内存,有三个队列,最小份额分别设置为40G,30G,20G,权重分别设置为2,3,4(按照谁愿意分享更多,谁获得更多的原则,即最小份额跟权重成反比关系)。队列之间支持资源共享,当某个队列的资源不用时,可以共享给其他有需要的队列。当集群繁忙时,一旦有些任务完成释放资源形成空闲资源,优先分配给“饥饿程度”(已使用资源量跟最小份额之间的差距程度)较高的队列,慢慢地,大家就会进入都不“饥饿”的状态,这时按已使用资源量/权重 谁小分配给谁,最终达到按最小份额和权重“公平”分配资源的效果。队列里面的Job可按FIFO或Fair(Fair判断指标有:job已使用资源量与实际需要资源量的差距,提交时间)选择优先顺序。
还有Capacity和Fair调度器都支持资源抢占。
15、hive 中的压缩格式 RCFile、TextFile、SequenceFile 各有什么区别?
http://blog.csdn.net/yfkiss/article/details/7787742
TextFile:Hive默认格式,不作压缩,磁盘及网络开销较大。可以结合Gzip, Bzip2使用,但使用这种方式,hive不会对数据进行切分,从而无法对数据进行并行操作。
SequenceFile: SequenceFile 是Hadoop API提供支持的一种二进制文件,具有使用方便,可分割,可压缩的特点,支持三种压缩选择:NONE, RECORD, BLOCK。RECORD压缩率低,一般建议使用BLOCK压缩。
RCFILE: RCFILE是一种行列存储相结合的的存储方式。首先,将数据按行分块,保证同一个record在一个块上,避免读一个记录需要读取多个block。其次,块数据列式存储,有利于数据压缩。
总结:相比TEXTFILE和SEQUENCEFILE,RCFILE由于列式存储方式,数据加载时性能消耗较大,但是具有较好的压缩比和查询响应。数据仓库的特点是一次写入,多次读取,因此,整体来看,RCFILE相比两它两种格式,具有较明显的优势。
16、Hive中的内部表,外部表,分区表、桶表有什么区别和作用?
内部表:数据存储在Hive的数据仓库目录下,删除表时,除了删除元数据,还会删除实际表文件。
外部表:数据并不存储在Hive的数据仓库目录下,删除表时,只是删除元数据,并不删除实际表文件。
分区表:跟RDMS的分区概念类似,将一张表的数据按照分区规则分成多个目录存储。这样可以通过指定分区来提高查询速度。
桶表:在表或分区的基础上,按某一列的值将记录进行分桶存放,即分文件存放,也就是将大表变成小表的意思,这样,涉及到Join操作时,可以在桶与桶间关联即可,大大减小Join的数据量,提高执行效率。