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阶段，输出，在value中标记数据是来自File1和File2，在reduce阶段，将key的value按照来源是File1还是File2分成两组，做集合乘积。

缺点：

i.  map阶段没有对数据瘦身，shuffle的网络传输和排序性能很低。

ii.  reduce端对2个集合做乘积计算，很耗内存，容易导致OOM。

示例：

在map阶段：map函数同时读入两个文件File1和File2，对每一条数据打一个标签，用来区分数据来源于File1还是File2。连接字段做为key，其他字段及标志做为value。

如

在shuffle阶段:  会按key分组，连接字段为key，各个map的的输出结果形成list做为value。

如

在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，如果不是，则生成对，假如记录来自B表，生成对，进入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的数据量，提高执行效率。