文档介绍：该【大数据面试题 】是由【小吴】上传分享，文档一共【84】页，该文档可以免费在线阅读，需要了解更多关于【大数据面试题 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。Hive内部表与外部表的区别？
先来说下Hive中内部表与外部表的区别： 
Hive 创立内部表时，会将数据移动到数据仓库指向的路径；假设创立外部表，仅记录数据所在的路径， 
不对数据的位置做任何改变。在删除表的时候，内部表的元数据和数据会被一起删除， 
而外部表只删除元数据，不删除数据。这样外部表相对来说更加平安些，数据组织也更加灵巧，方便共享源数据。 
需要注意的是传统数据库对表数据验证是 schema on write〔写时模式〕，而 Hive 在load时是不检查数据是否 
符合schema的，hive 遵循的是 schema on read〔读时模式〕，只有在读的时候hive才检查、解析具体的 
数据字段、schema。 
读时模式的优势是load data 非常迅速，因为它不需要读取数据进行解析，仅仅进行文件的复制或者移动。 
写时模式的优势是提升了查询性能，因为预先解析之后可以对列建立索引，并压缩，但这样也会花费要多的加载时间。 
下面来看下 Hive 如何创立内部表： 
create table test(userid string);
LOAD DATA INPATH '/tmp/result/' INTO TABLE test partition(ptDate='');
这个很简单，不多说了，下面看下外部表： 
hadoop fs -ls /tmp/result/
Found items
-rw-r--r--   june supergroup       -- : /tmp/result//part-
-rw-r--r--   june supergroup       -- : /tmp/result//part-
-- 建表
create EXTERNAL table IF NOT EXISTS test (userid string) partitioned by (ptDate string) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t';
-- 建立分区表，利用分区表的特性加载多个目录下的文件，并且分区字段可以作为where条件，更为重要的是
-- 这种加载数据的方式是不会移动数据文件的，这点和 load data 不同，后者会移动数据文件至数据仓库目录。
alter table test add partition (ptDate='') location '/tmp/result/';
-- 注意目录最后不要画蛇添足加 /*，我就是linux shell用多了，加了这玩意，调试了一下午。。。
注意：location后面跟的是目录，不是文件，hive会把整个目录下的文件都加载到表中：
create EXTERNAL table IF NOT EXISTS userInfo (id int,sex string, age int, name string, email string,sd string, ed string)  ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' location '/hive/dw';
否那么，会报错误：
FAILED: Error in metadata: MetaException(message:Got exception: : Parent path is not a directory: /hive/dw/record_--.txt
最后提下还有一种方式是建表的时候就指定外部表的数据源路径，
但这样的害处是只能加载一个数据源了：
CREATE EXTERNAL TABLE sunwg_test(id INT, name string) 
ROW FORMAT DELIMITED 
FIELDS TERMINATED BY ‘\t’ 
LOCATION ‘/sunwg/test′; 
上面的语句创立了一张名字为sunwg_test的外表，该表有id和name两个字段， 
字段的分割符为tab，文件的数据文件夹为/sunwg/test 
select * from sunwg_test; 
可以查询到sunwg_test中的数据。 
在当前用户hive的根目录下找不到sunwg_test文件夹。 
此时hive将该表的数据文件信息保存到metadata数据库中。 
mysql> select * from TBLS where TBL_NAME=’sunwg_test′; 
可以看到该表的类型为EXTERNAL_TABLE。 
mysql> select * from SDS where SD_ID=TBL_ID; 
在表SDS中记录了表sunwg_test的数据文件路径为hdfs://hadoop:/hjl/test。 
# hjl为hive的数据库名 
实际上外表不光可以指定hdfs的目录，本地的目录也是可以的。 
比方： 
CREATE EXTERNAL TABLE test(id INT, name string) 
ROW FORMAT DELIMITED 
FIELDS TERMINATED BY ‘\t’ 
、Hbase的rowkey怎么创立比拟好？列簇怎么创立比拟好？？
HBase是一个分布式的、面向列的数据库，它和一般关系型数据库的最大区别是：HBase很适合于存储非结构化的数据，还有就是它基于列的而不是基于行的模式。
既然HBase是采用KeyValue的列存储，那Rowkey就是KeyValue的Key了，表示唯一一行。Rowkey也是一段二进制码流，最大长度为KB，内容可以由使用的用户自定义。数据加载时，一般也是根据Rowkey的二进制序由小到大进行的。
HBase是根据Rowkey来进行检索的，系统通过找到某个Rowkey (或者某个 Rowkey 范围)所在的Region，然后将查询数据的请求路由到该Region获取数据。HBase的检索支持种方式：
〔〕 通过单个Rowkey访问，即按照某个Rowkey键值进行get操作，这样获取唯一一条记录；
〔〕 通过Rowkey的range进行scan，即通过设置startRowKey和endRowKey，在这个范围内进行扫描。这样可以按指定的条件获取一批记录；
〔〕 全表扫描，即直接扫描整张表中所有行记录。
HBASE按单个Rowkey检索的效率是很高的，耗时在毫秒以下，每秒钟可获取~条记录，不过非key列的查询很慢。
HBase的RowKey设计
. 设计原那么
.. Rowkey长度原那么
Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在~个字节，不过建议是越短越好，不要超过个字节。
原因如下：
〔〕数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比方个字节，万列数据光Rowkey就要占用*万=亿个字节，将近G数据，这会极大影响HFile的存储效率；
〔〕MemStore将缓存局部数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。
〔〕目前操作系统是都是位系统，内存字节对齐。控制在个字节，字节的整数倍利用操作系统的最正确特性。
.. Rowkey散列原那么
如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。
.. Rowkey唯一原那么
必须在设计上保证其唯一性。
. 应用场景
基于Rowkey的上述个原那么，应对不同应用场景有不同的Rowkey设计建议。
.. 针对事务数据Rowkey设计
事务数据是带时间属性的，建议将时间信息存入到Rowkey中，这有助于提示查询检索速度。对于事务数据建议缺省就按天为数据建表，这样设计的好处是多方面的。按天分表后，时间信息就可以去掉日期局部只保存小时分钟毫秒，这样个字节即可搞定。加上散列字段个字节一共个字节即可组成唯一 Rowkey。如以下图所示：
事务数据Rowkey设计
第字节
第字节
第字节
第字节
第字节
第字节
…
散列字段
时间字段(毫秒)
扩展字段
~(x~xFFFF)
~(x~xBFF)
这样的设计从操作系统内存管理层面无法节省开销，因为位操作系统是必须字节对齐。但是对于持久化存储中Rowkey局部可以节省%的开销。也许有人要问为什么不将时间字段以主机字节序保存，这样它也可以作为散列字段了。这是因为时间范围内的数据还是尽量保证连续，相同时间范围内的数据查找的概率很大，对查询检索有好的效果，因此使用独立的散列字段效果更好，对于某些应用，我们可以考虑利用散列字段全部或者局部来存储某些数据的字段信息，只要保证相同散列值在同一时间〔毫秒〕唯一。
.. 针对统计数据的Rowkey设计
统计数据也是带时间属性的，统计数据最小单位只会到分钟〔到秒预统计就没意义了〕。同时对于统计数据我们也缺省采用按天数据分表，这样设计的好处无需多说。按天分表后，时间信息只需要保存小时分钟，那么~只需占用两个字节即可保存时间信息。由于统计数据某些维度数量非常庞大，因此需要个字节作为序列字段，因此将散列字段同时作为序列字段使用也是个字节组成唯一Rowkey。如以下图所示：
统计数据Rowkey设计
第字节
第字节
第字节
第字节
第字节
第字节
…
散列字段(序列字段〕
时间字段(分钟)
扩展字段
x~xFFFFFFFF)
~(x~xF)
同样这样的设计从操作系统内存管理层面无法节省开销，因为位操作系统是必须字节对齐。但是对于持久化存储中Rowkey局部可以节省%的开销。预统计数据可能涉及到屡次反复的重计算要求，需确保作废的数据能有效删除，同时不能影响散列的均衡效果，因此要特殊处理。
.. 针对通用数据的Rowkey设计
通用数据采用自增序列作为唯一主键，用户可以选择按天建分表也可以选择单表模式。这种模式需要确保同时多个入库加载模块运行时散列字段〔序列字段〕的唯一性。可以考虑给不同的加载模块赋予唯一因子区别。设计结构如以下图所示。
通用数据Rowkey设计
第字节
第字节
第字节
第字节
…
散列字段(序列字段〕
扩展字段〔控制在字节内〕
x~xFFFFFFFF)
可由多个用户字段组成
.. 支持多条件查询的RowKey设计
HBase按指定的条件获取一批记录时，使用的就是scan方法。 scan方法有以下特点：
〔〕scan可以通过setCaching与setBatch方法提高速度〔以空间换时间〕；
〔〕scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。
通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起〔应该在同一个Region下〕，可以在遍历结果时获得很好的性能。
〔〕scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的根底。
在满足长度、三列、唯一原那么后，我们需要考虑如何通过巧妙设计RowKey以利用scan方法的范围功能，使得获取一批记录的查询速度能提高。下例就描述如何将多个列组合成一个RowKey，使用scan的range来到达较快查询速度。
例子：
我们在表中存储的是文件信息，每个文件有个属性：文件id〔long，全局唯一〕、创立时间〔long〕、文件名〔String〕、分类名〔String〕、所有者〔User〕。
我们可以输入的查询条件：文件创立时间区间〔比方从到期间创立的文件〕，文件名〔“中国好声音〞〕，分类〔“综艺〞〕，所有者〔“浙江卫视〞〕。
假设当前我们一共有如下文件：
ID
CreateTime
Name
Category
UserID
中国好声音第期
综艺
中国好声音第期
综艺
中国好声音外卡赛
综艺
中国好声音第期
综艺
中国好声音第期
综艺
中国好声音选手采访
综艺花絮
中国好声音第期
综艺
中国好声音录制花絮
综艺花絮
张玮独家专访
花絮
加多宝凉茶广告
综艺广告
这里UserID应该对应另一张User表，暂不列出。我们只需知道UserID的含义：
代表 浙江卫视； 代表 好声音剧组； 代表 XX微博； 代表赞助商。调用查询接口的时候将上述个条件同时输入find(,,〞中国好声音〞,〞综艺〞,〞浙江卫视〞)。此时我们应该得到记录应该有第、、、、、条。第条由于不属于“浙江卫视〞应该不被选中。我们在设计RowKey时可以这样做：采用 UserID + CreateTime + FileID组成RowKey，这样既能满足多条件查询，又能有很快的查询速度。
需要注意以下几点：
〔〕每条记录的RowKey，每个字段都需要填充到相同长度。假设预期我们最多有万量级的用户，那么userID应该统一填充至位，如，…
〔〕结尾添加全局唯一的FileID的用意也是使每个文件对应的记录全局唯一。防止当UserID与CreateTime相同时的两个不同文件记录相互覆盖。
按照这种RowKey存储上述文件记录，在HBase表中是下面的结构：
rowKey〔userID + time + fileID 〕 name category ….
怎样用这张表？
在建立一个scan对象后，我们setStartRow()，setEndRow()。
这样，scan时只扫描userID=的数据，且时间范围限定在这个指定的时间段内，满足了按用户以及按时间范围对结果的筛选。并且由于记录集中存储，性能很好。
然后使用 SingleColumnValueFilter〔〕，共个，分别约束name的上下限，与category的上下限。满足按同时按文件名以及分类名的前缀匹配。
〔注意：使用SingleColumnValueFilter会影响查询性能，在真正处理海量数据时会消耗很大的资源，且需要较长的时间〕
如果需要分页还可以再加一个PageFilter限制返回记录的个数。
以上，我们完成了高性能的支持多条件查询的HBase表结构设计。
用mapreduce怎么处理数据倾斜问题？
map /reduce程序卡住的原因是什么？
.根据原因，你是否能够想到更好的方法来解决？〔企业很看重个人创作力〕
map /reduce程序执行时，reduce节点大局部执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多〔有时是百倍或者千倍之多〕，这条key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完，此称之为数据倾斜。
用hadoop程序进行数据关联时，常碰到数据倾斜的情况，这里提供一种解决方法。
()设置一个hash份数N，用来对条数众多的key进行打散。
()对有多条重复key的那份数据进行处理：从到N将数字加在key后面作为新key，如果需要和另一份数据关联的话，那么要重写比拟类和分发类〔方法如上篇?hadoop job解决大数据量关联的一种方法?〕。如此实现多条key的平均分发。
int iNum = iNum % iHashNum;
String strKey = key + CTRLC + (iNum) + CTRLB + “B〞;
〔〕上一步之后，key被平均分散到很多不同的reduce节点。如果需要和其他数据关联，为了保证每个reduce节点上都有关联的key，对另一份单一key的数据进行处理：循环的从到N将数字加在key后面作为新key
for(int i = ; i < iHashNum; ++i){
String strKey =key + CTRLC + (i) ;
(new Text(strKey), new Text(strValues));}
以此解决数据倾斜的问题，经试验大大减少了程序的运行时间。但此方法会成倍的增加其中一份数据的数据量，以增加shuffle数据量为代价，所以使用此方法时，要屡次试验，取一个最正确的hash份数值。
======================================
用上述的方法虽然可以解决数据倾斜，但是当关联的数据量巨大时，如果成倍的增长某份数据，会导致reduce shuffle的数据量变的巨大，得不偿失，从而无法解决运行时间慢的问题。
有一个新的方法可以解决 成倍增长数据 的缺陷：
在两份数据中找共同点，比方两份数据里除了关联的字段以外，还有另外相同含义的字段，如果这个字段在所有log中的重复率比拟小，那么可以用这个字段作为计算hash的值，如果是数字，可以用来模hash的份数，如果是字符可以用hashcode来模hash的份数〔当然数字为了防止落到同一个reduce上的数据过多，也可以用hashcode〕，这样如果这个字段的值分布足够平均的话，就可以解决上述的问题。
Hadoop框架如何优化？
. 使用自定义Writable
自带的Text很好用，但是字符串转换开销较大，故根据实际需要自定义Writable，注意作为Key时要实现WritableCompareable接口
(new Text( ),new Text())
( ) ( ) (key,value)
前者会产生大量的Text对象，使用完后Java垃圾回收器会花费大量的时间去收集这些对象
 
. 使用StringBuilder
不要使用Formatter StringBuffer〔 线程平安〕
StringBuffer尽量少使用多个append方法，适当使用+
 
. 使用DistributedCache加载文件
比方配置文件，词典，共享文件，防止使用static变量
 
. 充分使用Combiner Parttitioner Comparator。
Combiner : 对map任务进行本地聚合
Parttitioner ： 适宜的Parttitioner防止reduce端负载不均
Comparator ： 二次排序
比方求每天的最大气温，map结果为日期：气温，假设气温是降序的，直接取列表首元素即可
 
. 使用自定义InputFormat和OutputFormat
 
. MR应防止
静态变量：不能用于计数，应使用Counter
大对象：Map List
递归：防止递归深度过大
超长正那么表达式：消耗性能，要在map或reduce函数外编译正那么表达式
不要创立本地文件：变向的把HDFS里面的数据转移到TaskTracker，占用网络带宽
不要大量创立目录和文件
，而使用Logger
不要自定义过多的Counter，最好不要超过个
不要配置过大内存， -Xmxm是用来设置mapreduce任务使用的最大heap量
.关于map的数目
map数目过大[创立和初始化map的开销]，一般是由大量小文件造成的，，对于小文件可以archive文件或者Hadoop fs -merge合并成一个大文件.
map数目过少，造成单个map任务执行时间过长，频繁推测执行，且容易内存溢出，并行性优势不能表达出来。-M
压缩的Text 文件是不能被分割的，所以尽量使用SequenceFile，可以切分
 
.关于reduce的数目