2023年大数据面试题

《2023年大数据面试题》由会员分享，可在线阅读，更多相关《2023年大数据面试题（119页珍藏版）》请在装配图网上搜索。

1、1、 Hive内部表与外部表的区别？ 先来说下Hive中内部表与外部表的区别：Hive 创建内部表时，会将数据移动到数据仓库指向的途径；若创建外部表，仅记录数据所在的途径，不对数据的位置做任何改变。在删除表的时候，内部表的元数据和数据会被一起删除，而外部表只删除元数据，不删除数据。这样外部表相对来说更加安全些，数据组织也更加灵活，方便共享源数据。需要注意的是传统数据库对表数据验证是 schema on write（写时模式），而 Hive 在load时是不检查数据是否符合schema的，hive 遵循的是 schema on read（读时模式），只有在读的时候hive才检查、解析具体的数据字

2、段、schema。读时模式的优势是load data 非常迅速，由于它不需要读取数据进行解析，仅仅进行文献的复制或者移动。写时模式的优势是提高了查询性能，由于预先解析之后可以对列建立索引，并压缩，但这样也会花费要多的加载时间。下面来看下 Hive 如何创建内部表：1createtabletest(userid string);2LOADDATA INPATH/tmp/result/20231213INTOTABLEtest partition(ptDate=20231213);这个很简朴，不多说了，下面看下外部表：01hadoop fs -ls /tmp/result/2023121402Fo

3、und 2 items03-rw-r-r- 3 june supergroup 1240 2023-12-26 17:15 /tmp/result/20231214/part-0000004-rw-r-r- 1 june supergroup 1240 2023-12-26 17:58 /tmp/result/20231214/part-0000105- 建表06createEXTERNALtableIFNOTEXISTS test (userid string) partitionedby(ptDate string) ROW FORMAT DELIMITED FIELDS TERMINAT

4、EDBYt;07- 建立分区表，运用分区表的特性加载多个目录下的文献，并且分区字段可以作为where条件，更为重要的是08- 这种加载数据的方式是不会移动数据文献的，这点和 load data 不同，后者会移动数据文献至数据仓库目录。09altertabletestaddpartition (ptDate=20231214) location/tmp/result/20231214;- 注意目录20231214最后不要画蛇添足加 /*，我就是linux shell用多了，加了这玩意，调试了一下午。注意：location后面跟的是目录，不是文献，hive会把整个目录下的文献都加载到表中：1cre

5、ateEXTERNALtableIFNOTEXISTS userInfo (idint,sex string, ageint,namestring, email string,sd string, ed string) ROW FORMAT DELIMITED FIELDS TERMINATEDBYtlocation/hive/dw;否则，会报错误：FAILED: Error in metadata: MetaException(message:Got exception: org.apache.hadoop.ipc.RemoteException java.io.FileNotFoundEx

6、ception: Parent path is not a directory: /hive/dw/record_2023-04-04.txt最后提下尚有一种方式是建表的时候就指定外部表的数据源途径，但这样的坏处是只能加载一个数据源了：CREATE EXTERNAL TABLE sunwg_test09(id INT, name string)ROW FORMAT DELIMITEDFIELDS TERMINATED BY tLOCATION /sunwg/test08;上面的语句创建了一张名字为sunwg_test09的外表，该表有id和name两个字段，字段的分割符为tab，文献的数据文献

7、夹为/sunwg/test08select * from sunwg_test09;可以查询到sunwg_test09中的数据。在当前用户hive的根目录下找不到sunwg_test09文献夹。此时hive将该表的数据文献信息保存到metadata数据库中。mysql select * from TBLS where TBL_NAME=sunwg_test09;可以看到该表的类型为EXTERNAL_TABLE。mysql select * from SDS where SD_ID=TBL_ID;在表SDS中记录了表sunwg_test09的数据文献途径为hdfs:/hadoop00:9000/

8、hjl/test08。# hjl为hive的数据库名事实上外表不光可以指定hdfs的目录，本地的目录也是可以的。比如：CREATE EXTERNAL TABLE test10(id INT, name string)ROW FORMAT DELIMITEDFIELDS TERMINATED BY t2、Hbase的rowkey怎么创建比较好？列簇怎么创建比较好？ HBase是一个分布式的、面向列的数据库，它和一般关系型数据库的最大区别是：HBase很适合于存储非结构化的数据，尚有就是它基于列的而不是基于行的模式。既然HBase是采用KeyValue的列存储，那Rowkey就是KeyValue的

9、Key了，表达唯一一行。Rowkey也是一段二进制码流，最大长度为64KB，内容可以由使用的用户自定义。数据加载时，一般也是根据Rowkey的二进制序由小到大进行的。HBase是根据Rowkey来进行检索的，系统通过找到某个Rowkey (或者某个 Rowkey 范围)所在的Region，然后将查询数据的请求路由到该Region获取数据。HBase的检索支持3种方式：（1） 通过单个Rowkey访问，即按照某个Rowkey键值进行get操作，这样获取唯一一条记录；（2） 通过Rowkey的range进行scan，即通过设立startRowKey和endRowKey，在这个范围内进行扫描。这样可

10、以按指定的条件获取一批记录；（3） 全表扫描，即直接扫描整张表中所有行记录。HBASE按单个Rowkey检索的效率是很高的，耗时在1毫秒以下，每秒钟可获取10002023条记录，但是非key列的查询很慢。2 HBase的RowKey设计2.1 设计原则2.1.1 Rowkey长度原则Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10100个字节，但是建议是越短越好，不要超过16个字节。因素如下：（1）数据的持久化文献HFile中是按照KeyValue存储的，假如Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将

11、近1G数据，这会极大影响HFile的存储效率；（2）MemStore将缓存部分数据到内存，假如Rowkey字段过长内存的有效运用率会减少，系统将无法缓存更多的数据，这会减少检索效率。因此Rowkey的字节长度越短越好。（3）目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍运用操作系统的最佳特性。2.1.2 Rowkey散列原则假如Rowkey是准时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。假如没有散列字段，首字段直接是时

12、间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，减少查询效率。2.1.3 Rowkey唯一原则必须在设计上保证其唯一性。2.2 应用场景基于Rowkey的上述3个原则，应对不同应用场景有不同的Rowkey设计建议。2.2.1 针对事务数据Rowkey设计事务数据是带时间属性的，建议将时间信息存入到Rowkey中，这有助于提醒查询检索速度。对于事务数据建议缺省就按天为数据建表，这样设计的好处是多方面的。按天分表后，时间信息就可以去掉日期部分只保存小时分钟毫秒，这样4个字节即可搞定。加上散列字段2个字节一共

13、6个字节即可组成唯一 Rowkey。如下图所示：事务数据Rowkey设计第0字节第1字节第2字节第3字节第4字节第5字节散列字段时间字段(毫秒)扩展字段065535(0x00000xFFFF)086399999(0x000000000x05265BFF)这样的设计从操作系统内存管理层面无法节省开销，由于64位操作系统是必须8字节对齐。但是对于持久化存储中Rowkey部分可以节省25%的开销。也许有人要问为什么不将时间字段以主机字节序保存，这样它也可以作为散列字段了。这是由于时间范围内的数据还是尽量保证连续，相同时间范围内的数据查找的概率很大，对查询检索有好的效果，因此使用独立的散列字段效果更好

14、，对于某些应用，我们可以考虑运用散列字段所有或者部分来存储某些数据的字段信息，只要保证相同散列值在同一时间（毫秒）唯一。2.2.2 针对记录数据的Rowkey设计记录数据也是带时间属性的，记录数据最小单位只会到分钟（到秒预记录就没意义了）。同时对于记录数据我们也缺省采用按天数据分表，这样设计的好处无需多说。按天分表后，时间信息只需要保存小时分钟，那么01400只需占用两个字节即可保存时间信息。由于记录数据某些维度数量非常庞大，因此需要4个字节作为序列字段，因此将散列字段同时作为序列字段使用也是6个字节组成唯一Rowkey。如下图所示：记录数据Rowkey设计第0字节第1字节第2字节第3字节第4

15、字节第5字节散列字段(序列字段）时间字段(分钟)扩展字段0x000000000xFFFFFFFF)01439(0x00000x059F)同样这样的设计从操作系统内存管理层面无法节省开销，由于64位操作系统是必须8字节对齐。但是对于持久化存储中Rowkey部分可以节省25%的开销。预记录数据也许涉及到多次反复的重计算规定，需保证作废的数据能有效删除，同时不能影响散列的均衡效果，因此要特殊解决。2.2.3 针对通用数据的Rowkey设计通用数据采用自增序列作为唯一主键，用户可以选择按天建分表也可以选择单表模式。这种模式需要保证同时多个入库加载模块运营时散列字段（序列字段）的唯一性。可以考虑给不同的

16、加载模块赋予唯一因子区别。设计结构如下图所示。通用数据Rowkey设计第0字节第1字节第2字节第3字节散列字段(序列字段）扩展字段（控制在12字节内）0x000000000xFFFFFFFF)可由多个用户字段组成2.2.4 支持多条件查询的RowKey设计HBase按指定的条件获取一批记录时，使用的就是scan方法。 scan方法有以下特点：（1）scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；（2）scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应当

17、在同一个Region下），可以在遍历结果时获得很好的性能。（3）scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。在满足长度、三列、唯一原则后，我们需要考虑如何通过巧妙设计RowKey以运用scan方法的范围功能，使得获取一批记录的查询速度能提高。下例就描述如何将多个列组合成一个RowKey，使用scan的range来达成较快查询速度。例子：我们在表中存储的是文献信息，每个文献有5个属性：文献id（long，全局唯一）、创建时间（long）、文献名（String）、分类名（String）、所有者（User）。我们可以输入的查询条件：文献创建时间区间（比如从2023

18、0901到20230914期间创建的文献），文献名（“中国好声音”），分类（“综艺”），所有者（“浙江卫视”）。假设当前我们一共有如下文献：IDCreateTimeNameCategoryUserID120230902中国好声音第1期综艺1220230904中国好声音第2期综艺1320230906中国好声音外卡赛综艺1420230908中国好声音第3期综艺1520230910中国好声音第4期综艺1620230912中国好声音选手采访综艺花絮2720230914中国好声音第5期综艺1820230916中国好声音录制花絮综艺花絮2920230918张玮独家专访花絮31020230920加多宝凉茶广

19、告综艺广告4这里UserID应当相应另一张User表，暂不列出。我们只需知道UserID的含义：1代表 浙江卫视； 2代表 好声音剧组； 3代表 XX微博； 4代表赞助商。调用查询接口的时候将上述5个条件同时输入find(20230901,20231001,”中国好声音”,”综艺”,”浙江卫视”)。此时我们应当得到记录应当有第1、2、3、4、5、7条。第6条由于不属于“浙江卫视”应当不被选中。我们在设计RowKey时可以这样做：采用 UserID + CreateTime + FileID组成RowKey，这样既能满足多条件查询，又能有不久的查询速度。需要注意以下几点：（1）每条记录的RowK

20、ey，每个字段都需要填充到相同长度。假如预期我们最多有10万量级的用户，则userID应当统一填充至6位，如000001，000002（2）结尾添加全局唯一的FileID的用意也是使每个文献相应的记录全局唯一。避免当UserID与CreateTime相同时的两个不同文献记录互相覆盖。按照这种RowKey存储上述文献记录，在HBase表中是下面的结构：rowKey（userID 6 + time 8 + fileID 6） name category .020230010400000206000003080000041000000514000007120230061600000818000009

21、20230010如何用这张表？在建立一个scan对象后，我们setStartRow(01)，setEndRow(14)。这样，scan时只扫描userID=1的数据，且时间范围限定在这个指定的时间段内，满足了按用户以及准时间范围对结果的筛选。并且由于记录集中存储，性能很好。然后使用 SingleColumnValueFilter（org.apache.hadoop.hbase.filter.SingleColumnValueFilter），共4个，分别约束name的上下限，与category的上下限。满足按同时按文献名以及分类名的前缀匹配。（注意：使用SingleColumnValueFilt

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

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

24、lueOf(iNum) + CTRLB + “B”;（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任务比较多且完毕时间比较

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

26、t.buffer.percent（0.7）：reduce从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.pe

27、rcent (0)：当Reduce下载map数据完毕之后，就会开始真正的reduce的计算，reduce的计算必然也是要消耗内存的，那么在读物reduce所需要的数据时，同样需要内存作为buffer，这个参数是决定多少的内存比例作为buffer。默认为0，也就是说reduce所有从磁盘读数据。若redcue计算任务消耗内存很小，那么可以设立这个参数大于0，使一部分内存用来缓存数据。5、 Hbase内部是什么机制？进一步分析HBase RPC(Protobuf)实现机制Binospace2023-08-022730阅读背景在HMaster、RegionServer内部，创建了RpcServer实

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

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

30、onServer之间的通信，RegionServer是RpcServer端，重要实现用户的读写请求。例如get、multiGet、mutate、scan、bulkLoadHFile、执行Coprocessor等。AdminProtocols，Client与RegionServer之间的通信，RegionServer是RpcServer端，重要实现Region、服务、文献的管理。例如storefile信息、Region的操作、WAL操作、Server的开关等。(备注：以上提到的Client可以是用户Api、也可以是RegionServer或者HMaster)HBase-RPC实现机制分析RpcS

31、erver配置三个队列：1）普通队列callQueue，绝大部分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。假如设立priorityHandler

32、Count的个数，会创建与callQueue相称容量的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 =Que

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

34、e callBlockingMethod(MethodDescriptor 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函数，使用M

35、essage基类可以接受基于Message的不同的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)AuthMe

36、thod(1Byte)ConnectionHeaderLength(4Byte)ConnectionHeaderRequest“HBas”验证RpcServer的CURRENT_VERSION与RPC报文一致目前支持三类：AuthMethod.SIMPLEAuthMethod.KERBEROSAuthMethod.DIGESTRPC.proto定义RPCProtos.ConnectionHeadermessage ConnectionHeader optional UserInformation userInfo = 1;optional string serviceName = 2;/ Ce

37、ll block codec we will use sending over optional cell blocks. Server throws exception/ if cannot deal.optional string cellBlockCodecClass = 3 default = org.apache.hadoop.hbase.codec.KeyValueCodec;/ Compressor we will use if cell block is compressed. Server will throw exception if not supported./ Cla

38、ss must implement hadoops CompressionCodec Interfaceoptional string cellBlockCompressorClass = 4;序列化之后的数据整个Request存储是通过编码之后的byte数组，涉及如下几个部分：RequestHeaderLength(RawVarint32)RequestHeaderParamSize(RawVarint32)ParamCellScannerRPC.proto定义：message RequestHeader / Monotonically increasing callId to keep t

39、rack of RPC requests and their responseoptional uint32 callId = 1;optional RPCTInfo traceInfo = 2;optional string methodName = 3;/ If true, then a pb Message param follows.optional bool requestParam = 4;/ If present, then an encoded data block follows.optional CellBlockMeta cellBlockMeta = 5;/ TODO:

40、 Have client specify priority序列化之后的数据并从Header中确认是否存在Param和CellScanner，假如确认存在的情况下，会继续访问。Protobuf的基本类型Message，Request的Param继承了Message，这个需要获取的Method类型决定。从功能上讲，RpcServer上包含了三个模块，1）Listener。包含了多个Reader线程，通过Selector获取ServerSocketChannel接受来自RpcClient发送来的Connection，并从中重构Call实例，添加到CallQueue队列中。”IPC Server li

41、stener on 60021 daemon prio=10 tid=0x00007f7210a97800 nid=0x14c6 runnable 0x00007f720e8d0000java.lang.Thread.State: RUNNABLEat sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorIm

42、pl.java:65)at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)- locked (a sun.nio.ch.Util$2)- locked (a java.util.Collections$UnmodifiableSet)- locked (a sun.nio.ch.EPollSelectorImpl)at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)at sun.nio.ch.SelectorImpl.select(SelectorImpl.ja

43、va:84)at org.apache.hadoop.hbase.ipc.RpcServer$Listener.run(RpcServer.java:646)2）Handler。负责执行Call，调用Service的方法，然后返回Pair“IPC Server handler 0 on 60021 daemon prio=10 tid=0x00007f7210eab000 nid=0x14c7 waiting on condition 0x00007f720e7cf000java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.pa

44、rk(Native Method)- parking to wait for (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)at j

45、ava.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1804)3) Responder。负责把Call的结果返回给RpcClient。”IPC Server Responder” daemon prio=10 tid=0x00007f7210a97000 nid=0x14c5 runnable 0x00007f720e9d1000java.lang.Thread.S

46、tate: RUNNABLEat sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)- locked (a sun.nio.ch.Util$2)- loc

47、ked (a java.util.Collections$UnmodifiableSet)- locked (a sun.nio.ch.EPollSelectorImpl)at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)at org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRunLoop(RpcServer.java:833)at org.apache.hadoop.hbase.ipc.RpcServer$Responder.run(RpcServer.java:816)RpcCl

48、ient为Rpc请求建立Connection，通过Connection将Call发送RpcServer，然后RpcClient等待结果的返回。思考1）为什么HBase新版本使用了Protobuf，并实现RPC接口？HBase是Hadoop生态系统内重要的分布式数据库，Hadoop2.0广泛采用Protobuf作为中间数据组织方式，整个系统内Wire-Compatible的统一需求。2）HBase内部实现的Rpc框架对于服务性能的影响？目前使用Protobuf作为用户请求和内部数据互换的数据格式，采用更为紧缩编码格式，可以提高传输数据的效率。但是，有些优化仍然可以在该框架内探索：实现多个Requ

49、est复用Connection(把多个短连接合并成一个长连接)；在RpcServer内创建多个CallQueue，分别解决不同的Service，分离管理逻辑与应用逻辑的队列，保证互不干扰；Responder单线程的模式，是否高并发应用的瓶颈所在？是否可以分离Read/Write请求占用的队列，以及解决的handler，从而使得读写性能可以更加平衡？针对读写应用的特点，在RpcServer层次内相应用进行分级，建立不同优先级的CallQueue，按照Hadoop-FairScheduler的模式，然后配置中心调度(类似OMega或者Spallow轻量化调度方案)，保证实时应用的低延迟和非实时应用

50、的高吞吐。优先级更好的Call会优先被调度给Handler，而非实时应用可以实现多个Call的合并操作，从而提高吞吐。3）Protobuf内置编码与传统压缩技术是否可以配合使用？使用tcpdump获取了一段HMaster得到的RegionServer上报来的信息：以上的信息几乎是明文出现在tcp-ip连接中，因此，是否在Protobuf-RPC数据格式采用一定的压缩策略，会给scan、multiGet等数据交互较为密集的应用提供一种优化的思绪。6、 我们在开发分布式计算job的，是否可以去掉reduce（）阶段？7、 hdfs的数据压缩算法 在海量存储系统中，好的压缩算法可以有效的减少存储开销

51、，减轻运营成本。Hadoop基本上已经是主流的存储系统了，但是由于自身是Java实现，在压缩性能上受到语言的限制；此外该压缩算法还得支持Hadoop Mapreduce的split机制，不然压缩后文献只能被一个mapper解决，会大大的影响效率。Twitter之前实现过一个lzo的压缩框架，很好的将lzo引入到hadoop中。借助其原理我实现了一个更加通用的压缩框架，姑且叫做Nsm（Native Splittable Multi-method）Compression，可以方便的将一个Native（C/C+）实现的Encoder/Decoder整合到Hadoop Compression IO机制

52、中，并支持Mapreduce时的切分；此外我还基于lzma2实现了一个更高效的通用日记压缩算法，压缩比为zlib的1/2，压缩速度为原lzma2的两倍。一方面看最基本的压缩算法。Bigtable里提到了一种针对网页的long common string压缩，在网页按url聚集后可以达成十几倍的压缩比。然而在日记系统中，由于日记自身有过优化，很难出现网页那样大段反复的情况，也无法进行相似日记的聚集，long common string的优势体现不出来，反而不如zlib这样的短窗口压缩。另一方面，基于可读性的考虑，日记中整数，md5，timestamp，ip这样的数据往往以文本形式表达。因此，一个自然而然的想法是先把文献预解决，将上述数据由文本转换为二进制，再交给通用压缩算法进行压缩。故意思的是，通过预解决后的原文献虽然往往大小可以缩小一半，但再由通用压缩算法压缩后的结果，却和直接压缩的大小相差无几；这重要是通用压缩算法都会对结果进行哈夫曼或者算术编码，因此预解决的作用并不明显（往往只能减少10左右）。虽然预解决对最终压缩比影响不大，但是由于预解决速度快，并减少了通用压缩算法要解决的数据量，因此往往可以提高压缩速度，特别是对lzma2这种慢速压缩算法。在我的实现里，预解决平均可以将原文献大小缩小到1/2，预解决+lzma2对比单纯