大数据面试题资料.doc

《大数据面试题资料.doc》由会员分享，可在线阅读，更多相关《大数据面试题资料.doc（383页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-date大数据面试题资料大数据面试题资料1、 Hive内部表与外部表的区别？ 先来说下Hive中内部表与外部表的区别：Hive 创建内部表时，会将数据移动到数据仓库指向的路径；若创建外部表，仅记录数据所在的路径，不对数据的位置做任何改变。在删除表的时候，内部表的元数据和数据会被一起删除，而外部表只删除元数据，不删除数据。这样外部表相对来说更加安全些，数据组织也更加灵活，方便共

2、享源数据。需要注意的是传统数据库对表数据验证是 schema on write（写时模式），而 Hive 在load时是不检查数据是否符合schema的，hive 遵循的是 schema on read（读时模式），只有在读的时候hive才检查、解析具体的数据字段、schema。读时模式的优势是load data 非常迅速，因为它不需要读取数据进行解析，仅仅进行文件的复制或者移动。写时模式的优势是提升了查询性能，因为预先解析之后可以对列建立索引，并压缩，但这样也会花费要多的加载时间。下面来看下 Hive 如何创建内部表：1createtabletest(userid string);2LOAD

3、DATA INPATH/tmp/result/20121213INTOTABLEtest partition(ptDate=20121213);这个很简单，不多说了，下面看下外部表：01hadoop fs -ls /tmp/result/2012121402Found 2 items03-rw-r-r- 3 june supergroup 1240 2012-12-26 17:15 /tmp/result/20121214/part-0000004-rw-r-r- 1 june supergroup 1240 2012-12-26 17:58 /tmp/result/20121214/part

4、-0000105- 建表06createEXTERNALtableIFNOTEXISTS test (userid string) partitionedby(ptDate string) ROW FORMAT DELIMITED FIELDS TERMINATEDBYt;07- 建立分区表，利用分区表的特性加载多个目录下的文件，并且分区字段可以作为where条件，更为重要的是08- 这种加载数据的方式是不会移动数据文件的，这点和 load data 不同，后者会移动数据文件至数据仓库目录。09altertabletestaddpartition (ptDate=20121214) locat

5、ion/tmp/result/20121214;- 注意目录20121214最后不要画蛇添足加 /*，我就是linux shell用多了，加了这玩意，调试了一下午。注意：location后面跟的是目录，不是文件，hive会把整个目录下的文件都加载到表中：1createEXTERNALtableIFNOTEXISTS userInfo (idint,sex string, ageint,namestring, email string,sd string, ed string) ROW FORMAT DELIMITED FIELDS TERMINATEDBYtlocation/hive/dw;否

6、则，会报错误：FAILED: Error in metadata: MetaException(message:Got exception: org.apache.hadoop.ipc.RemoteException java.io.FileNotFoundException: Parent path is not a directory: /hive/dw/record_2013-04-04.txt最后提下还有一种方式是建表的时候就指定外部表的数据源路径，但这样的坏处是只能加载一个数据源了：CREATE EXTERNAL TABLE sunwg_test09(id INT, name str

7、ing)ROW FORMAT DELIMITEDFIELDS TERMINATED BY tLOCATION /sunwg/test08;上面的语句创建了一张名字为sunwg_test09的外表，该表有id和name两个字段，字段的分割符为tab，文件的数据文件夹为/sunwg/test08select * from sunwg_test09;可以查询到sunwg_test09中的数据。在当前用户hive的根目录下找不到sunwg_test09文件夹。此时hive将该表的数据文件信息保存到metadata数据库中。mysql select * from TBLS where TBL_NAME=

8、sunwg_test09;可以看到该表的类型为EXTERNAL_TABLE。mysql select * from SDS where SD_ID=TBL_ID;在表SDS中记录了表sunwg_test09的数据文件路径为hdfs:/hadoop00:9000/hjl/test08。# hjl为hive的数据库名实际上外表不光可以指定hdfs的目录，本地的目录也是可以的。比如：CREATE EXTERNAL TABLE test10(id INT, name string)ROW FORMAT DELIMITEDFIELDS TERMINATED BY t2、Hbase的rowkey怎么创建比

9、较好？列簇怎么创建比较好？ HBase是一个分布式的、面向列的数据库，它和一般关系型数据库的最大区别是：HBase很适合于存储非结构化的数据，还有就是它基于列的而不是基于行的模式。既然HBase是采用KeyValue的列存储，那Rowkey就是KeyValue的Key了，表示唯一一行。Rowkey也是一段二进制码流，最大长度为64KB，内容可以由使用的用户自定义。数据加载时，一般也是根据Rowkey的二进制序由小到大进行的。HBase是根据Rowkey来进行检索的，系统通过找到某个Rowkey (或者某个 Rowkey 范围)所在的Region，然后将查询数据的请求路由到该Region获取数据

10、。HBase的检索支持3种方式：（1） 通过单个Rowkey访问，即按照某个Rowkey键值进行get操作，这样获取唯一一条记录；（2） 通过Rowkey的range进行scan，即通过设置startRowKey和endRowKey，在这个范围内进行扫描。这样可以按指定的条件获取一批记录；（3） 全表扫描，即直接扫描整张表中所有行记录。HBASE按单个Rowkey检索的效率是很高的，耗时在1毫秒以下，每秒钟可获取10002000条记录，不过非key列的查询很慢。2 HBase的RowKey设计2.1 设计原则2.1.1 Rowkey长度原则Rowkey是一个二进制码流，Rowkey的长度被很多

11、开发者建议说设计在10100个字节，不过建议是越短越好，不要超过16个字节。原因如下：（1）数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率；（2）MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。（3）目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。2.1.2

12、Rowkey散列原则如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。2.1.3 Rowkey唯一原则必须在设计上保证其唯一性。2.2 应用场景基于Rowkey的上述3个原则，应对不同应用场景有不同的Rowkey设计建议。2.2.1 针对事务数据Rowk

13、ey设计事务数据是带时间属性的，建议将时间信息存入到Rowkey中，这有助于提示查询检索速度。对于事务数据建议缺省就按天为数据建表，这样设计的好处是多方面的。按天分表后，时间信息就可以去掉日期部分只保留小时分钟毫秒，这样4个字节即可搞定。加上散列字段2个字节一共6个字节即可组成唯一 Rowkey。如下图所示：事务数据Rowkey设计第0字节第1字节第2字节第3字节第4字节第5字节散列字段时间字段(毫秒)扩展字段065535(0x00000xFFFF)086399999(0x000000000x05265BFF)这样的设计从操作系统内存管理层面无法节省开销，因为64位操作系统是必须8字节对齐。但

14、是对于持久化存储中Rowkey部分可以节省25%的开销。也许有人要问为什么不将时间字段以主机字节序保存，这样它也可以作为散列字段了。这是因为时间范围内的数据还是尽量保证连续，相同时间范围内的数据查找的概率很大，对查询检索有好的效果，因此使用独立的散列字段效果更好，对于某些应用，我们可以考虑利用散列字段全部或者部分来存储某些数据的字段信息，只要保证相同散列值在同一时间（毫秒）唯一。2.2.2 针对统计数据的Rowkey设计统计数据也是带时间属性的，统计数据最小单位只会到分钟（到秒预统计就没意义了）。同时对于统计数据我们也缺省采用按天数据分表，这样设计的好处无需多说。按天分表后，时间信息只需要保留

15、小时分钟，那么01400只需占用两个字节即可保存时间信息。由于统计数据某些维度数量非常庞大，因此需要4个字节作为序列字段，因此将散列字段同时作为序列字段使用也是6个字节组成唯一Rowkey。如下图所示：统计数据Rowkey设计第0字节第1字节第2字节第3字节第4字节第5字节散列字段(序列字段）时间字段(分钟)扩展字段0x000000000xFFFFFFFF)01439(0x00000x059F)同样这样的设计从操作系统内存管理层面无法节省开销，因为64位操作系统是必须8字节对齐。但是对于持久化存储中Rowkey部分可以节省25%的开销。预统计数据可能涉及到多次反复的重计算要求，需确保作废的数据

16、能有效删除，同时不能影响散列的均衡效果，因此要特殊处理。2.2.3 针对通用数据的Rowkey设计通用数据采用自增序列作为唯一主键，用户可以选择按天建分表也可以选择单表模式。这种模式需要确保同时多个入库加载模块运行时散列字段（序列字段）的唯一性。可以考虑给不同的加载模块赋予唯一因子区别。设计结构如下图所示。通用数据Rowkey设计第0字节第1字节第2字节第3字节散列字段(序列字段）扩展字段（控制在12字节内）0x000000000xFFFFFFFF)可由多个用户字段组成2.2.4 支持多条件查询的RowKey设计HBase按指定的条件获取一批记录时，使用的就是scan方法。 scan方法有以下

17、特点：（1）scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；（2）scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下），可以在遍历结果时获得很好的性能。（3）scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。在满足长度、三列、唯一原则后，我们需要考虑如何通过巧妙设计RowKey以利用scan方法的范围功能，使得获取一批记录的查询速度能提高。下例就描述如何将多个列组合成一个RowKey，使用scan的

18、range来达到较快查询速度。例子：我们在表中存储的是文件信息，每个文件有5个属性：文件id（long，全局唯一）、创建时间（long）、文件名（String）、分类名（String）、所有者（User）。我们可以输入的查询条件：文件创建时间区间（比如从20120901到20120914期间创建的文件），文件名（“中国好声音”），分类（“综艺”），所有者（“浙江卫视”）。假设当前我们一共有如下文件：IDCreateTimeNameCategoryUserID120120902中国好声音第1期综艺1220120904中国好声音第2期综艺1320120906中国好声音外卡赛综艺1420120908

19、中国好声音第3期综艺1520120910中国好声音第4期综艺1620120912中国好声音选手采访综艺花絮2720120914中国好声音第5期综艺1820120916中国好声音录制花絮综艺花絮2920120918张玮独家专访花絮31020120920加多宝凉茶广告综艺广告4这里UserID应该对应另一张User表，暂不列出。我们只需知道UserID的含义：1代表 浙江卫视； 2代表 好声音剧组； 3代表 XX微博； 4代表赞助商。调用查询接口的时候将上述5个条件同时输入find(20120901,20121001,”中国好声音”,”综艺”,”浙江卫视”)。此时我们应该得到记录应该有第1、2、3

20、、4、5、7条。第6条由于不属于“浙江卫视”应该不被选中。我们在设计RowKey时可以这样做：采用 UserID + CreateTime + FileID组成RowKey，这样既能满足多条件查询，又能有很快的查询速度。需要注意以下几点：（1）每条记录的RowKey，每个字段都需要填充到相同长度。假如预期我们最多有10万量级的用户，则userID应该统一填充至6位，如000001，000002（2）结尾添加全局唯一的FileID的用意也是使每个文件对应的记录全局唯一。避免当UserID与CreateTime相同时的两个不同文件记录相互覆盖。按照这种RowKey存储上述文件记录，在HBase表中

21、是下面的结构：rowKey（userID 6 + time 8 + fileID 6） name category .00000120120902000001000001201209040000020000012012090600000300000120120908000004000001201209100000050000012012091400000700000220120912000006000002201209160000080000032012091800000900000420120920000010怎样用这张表？在建立一个scan对象后，我们setStartRow(0000012

22、0120901)，setEndRow(00000120120914)。这样，scan时只扫描userID=1的数据，且时间范围限定在这个指定的时间段内，满足了按用户以及按时间范围对结果的筛选。并且由于记录集中存储，性能很好。然后使用 SingleColumnValueFilter（org.apache.hadoop.hbase.filter.SingleColumnValueFilter），共4个，分别约束name的上下限，与category的上下限。满足按同时按文件名以及分类名的前缀匹配。（注意：使用SingleColumnValueFilter会影响查询性能，在真正处理海量数据时会消耗很大

23、的资源，且需要较长的时间）如果需要分页还可以再加一个PageFilter限制返回记录的个数。以上，我们完成了高性能的支持多条件查询的HBase表结构设计。3、 用mapreduce怎么处理数据倾斜问题？1. map /reduce程序卡住的原因是什么？2.根据原因，你是否能够想到更好的方法来解决？（企业很看重个人创作力）map /reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多（有时是百倍或者千倍之多），这条key所在的reduce节点所处理的数据量比其他节点就大很多，从

24、而导致某几个节点迟迟运行不完，此称之为数据倾斜。用hadoop程序进行数据关联时，常碰到数据倾斜的情况，这里提供一种解决方法。(1)设置一个hash份数N，用来对条数众多的key进行打散。(2)对有多条重复key的那份数据进行处理：从1到N将数字加在key后面作为新key，如果需要和另一份数据关联的话，则要重写比较类和分发类（方法如上篇hadoop job解决大数据量关联的一种方法）。如此实现多条key的平均分发。int iNum = iNum % iHashNum;String strKey = key + CTRLC + String.valueOf(iNum) + CTRLB + “B”

25、;（3）上一步之后，key被平均分散到很多不同的reduce节点。如果需要和其他数据关联，为了保证每个reduce节点上都有关联的key，对另一份单一key的数据进行处理：循环的从1到N将数字加在key后面作为新keyfor(int i = 0; i sort-reduce，也称shufflemapred.reduce.parellel.copies（5）：任一个map任务可能包含一个或者多个reduce所需要数据，故一个map任务完成后，相应的reduce就会立即启动线程下载自己所需要的数据。调大这个参数比较适合map任务比较多且完成时间比较短的Job。mapred.reduce.copy.

26、backoff：reduce端从map端下载数据也有可能由于网络故障，map端机器故障而失败。那么reduce下载线程肯定不会无限等待，当等待时间超过mapred.reduce.copy.backoff时，便放弃，尝试从其他地方下载。需注意：在网络情况比较差的环境，我们需要调大这个参数，避免reduce下载线程被误判为失败。io.sort.factor：recude将map结果下载到本地时，亦需要merge，如果reduce的瓶颈在于I/O，可尝试调高增加merge的并发吞吐，提高reduce性能、mapred.job.shuffle.input.buffer.percent（0.7）：red

27、uce从map下载的数据不会立刻就写到Disk中，而是先缓存在内存中，mapred.job.shuffle.input.buffer.percent指定内存的多少比例用于缓存数据，内存大小可通过mapred.child.java.opts来设置。和map类似，buffer不是等到写满才往磁盘中写，也是到达阈值就写，阈值由mapred.job,shuffle.merge.percent来指定。若Reduce下载速度很快，容易内存溢出，适当增大这个参数对增加reduce性能有些帮助。mapred.job.reduce.input.buffer.percent (0)：当Reduce下载map数据完

28、成之后，就会开始真正的reduce的计算，reduce的计算必然也是要消耗内存的，那么在读物reduce所需要的数据时，同样需要内存作为buffer，这个参数是决定多少的内存百分比作为buffer。默认为0，也就是说reduce全部从磁盘读数据。若redcue计算任务消耗内存很小，那么可以设置这个参数大于0，使一部分内存用来缓存数据。5、 Hbase内部是什么机制？深入分析HBase RPC(Protobuf)实现机制Binospace2013-08-022730阅读背景在HMaster、RegionServer内部，创建了RpcServer实例，并与Client三者之间实现了Rpc调用，HB

29、ase0.95内部引入了Google-Protobuf作为中间数据组织方式，并在Protobuf提供的Rpc接口之上，实现了基于服务的Rpc实现，本文详细阐述了HBase-Rpc实现细节。HBase的RPC Protocol在HMaster、RegionServer内部，实现了rpc 多个protocol来完成管理和应用逻辑，具体如下protocol如下：HMaster支持的Rpc协议：MasterMonitorProtocol，Client与Master之间的通信，Master是RpcServer端，主要实现HBase集群监控的目的。MasterAdminProtocol，Client与Ma

30、ster之间的通信，Master是RpcServer端，主要实现HBase表格的管理。例如TableSchema的更改，Table-Region的迁移、合并、下线(Offline)、上线(Online)以及负载平衡，以及Table的删除、快照等相关功能。RegionServerStatusProtoco，RegionServer与Master之间的通信，Master是RpcServer端，负责提供RegionServer向HMaster状态汇报的服务。RegionServer支持的Rpc协议：ClientProtocol，Client与RegionServer之间的通信，RegionServe

31、r是RpcServer端，主要实现用户的读写请求。例如get、multiGet、mutate、scan、bulkLoadHFile、执行Coprocessor等。AdminProtocols，Client与RegionServer之间的通信，RegionServer是RpcServer端，主要实现Region、服务、文件的管理。例如storefile信息、Region的操作、WAL操作、Server的开关等。(备注：以上提到的Client可以是用户Api、也可以是RegionServer或者HMaster)HBase-RPC实现机制分析RpcServer配置三个队列：1）普通队列callQue

32、ue，绝大部分Call请求存在该队列中：callQueue上maxQueueLength为$ipc.server.max.callqueue.length,默认是$hbase.master.handler.count*DEFAULT_MAX_CALLQUEUE_LENGTH_PER_HANDLER，目前0.95.1中，每个Handler上CallQueue的最大个数默认值(DEFAULT_MAX_CALLQUEUE_LENGTH_PER_HANDLER)为10。2）优先级队列: PriorityQueue。如果设置priorityHandlerCount的个数，会创建与callQueue相当容

33、量的queue存储Call，该优先级队列对应的Handler的个数由rpcServer实例化时传入。3）拷贝队列：replicationQueue。由于RpcServer由HMaster和RegionServer共用，该功能仅为RegionServer提供，queue的大小为$ipc.server.max.callqueue.size指定，默认为1024*1024*1024，handler的个数为hbase.regionserver.replication.handler.count。RpcServer由三个模块组成：Listener =Queue= Responder这里以HBaseAdmi

34、n.listTables为例， 分析一个Rpc请求的函数调用过程：1) RpcClient创建一个BlockingRpcChannel。2）以channel为参数创建执行RPC请求需要的stub，此时的stub已经被封装在具体Service下，stub下定义了可执行的rpc接口。3）stub调用对应的接口，实际内部channel调用callBlockingMethod方法。RpcClient内实现了protobuf提供的BlockingRpcChannel接口方法callBlockingMethod， Overridepublic Message callBlockingMethod(Meth

35、odDescriptor md, RpcController controller,Message param, Message returnType)throws ServiceException return this.rpcClient.callBlockingMethod(md, controller, param, returnType, this.ticket,this.isa, this.rpcTimeout);通过以上的实现细节，最终转换成rpcClient的调用，使用MethodDescriptor封装了不同rpc函数，使用Message基类可以接收基于Message的不同的

36、Request和Response对象。4）RpcClient创建Call对象，查找或者创建合适的Connection，并唤醒Connection。5）Connection等待Call的Response，同时rpcClient调用函数中，会使用connection.writeRequest(Call call)将请求写入到RpcServer网络流中。6）等待Call的Response，然后层层返回给更上层接口，从而完成此次RPC调用。RPCServer收到的Rpc报文的内部组织如下：Magic(4Byte)Version(1Byte)AuthMethod(1Byte)ConnectionHead

37、erLength(4Byte)ConnectionHeaderRequest“HBas”验证RpcServer的CURRENT_VERSION与RPC报文一致目前支持三类：AuthMethod.SIMPLEAuthMethod.KERBEROSAuthMethod.DIGESTRPC.proto定义RPCProtos.ConnectionHeadermessage ConnectionHeader optional UserInformation userInfo = 1;optional string serviceName = 2;/ Cell block codec we will use sending over optional cell blocks. Server throws exception/ if cannot deal.optional string cellBlockCodecClass = 3 default