大数据面试题.docx
- 文档编号:297094
- 上传时间:2022-10-08
- 格式:DOCX
- 页数:92
- 大小:586.08KB
大数据面试题.docx
《大数据面试题.docx》由会员分享,可在线阅读,更多相关《大数据面试题.docx(92页珍藏版)》请在冰豆网上搜索。
大数据面试题
1、Hive内部表与外部表的区别?
先来说下Hive中内部表与外部表的区别:
Hive创建内部表时,会将数据移动到数据仓库指向的路径;若创建外部表,仅记录数据所在的路径, 不对数据的位置做任何改变。
在删除表的时候,内部表的元数据和数据会被一起删除, 而外部表只删除元数据,不删除数据。
这样外部表相对来说更加安全些,数据组织也更加灵活,方便共享源数据。
需要注意的是传统数据库对表数据验证是schemaonwrite(写时模式),而Hive在load时是不检查数据是否 符合schema的,hive遵循的是schemaonread(读时模式),只有在读的时候hive才检查、解析具体的 数据字段、schema。
读时模式的优势是loaddata非常迅速,因为它不需要读取数据进行解析,仅仅进行文件的复制或者移动。
写时模式的优势是提升了查询性能,因为预先解析之后可以对列建立索引,并压缩,但这样也会花费要多的加载时间。
下面来看下Hive如何创建内部表:
1
create table test(useridstring);
2
LOAD DATAINPATH '/tmp/result/20121213' INTO TABLE testpartition(ptDate='20121213');
这个很简单,不多说了,下面看下外部表:
01
hadoopfs-ls/tmp/result/20121214
02
Found2items
03
-rw-r--r-- 3junesupergroup 12402012-12-2617:
15/tmp/result/20121214/part-00000
04
-rw-r--r-- 1junesupergroup 12402012-12-2617:
58/tmp/result/20121214/part-00001
05
--建表
06
create EXTERNAL table IF NOT EXISTStest(useridstring)partitioned by (ptDatestring)ROWFORMATDELIMITEDFIELDSTERMINATED BY '\t';
07
--建立分区表,利用分区表的特性加载多个目录下的文件,并且分区字段可以作为where条件,更为重要的是
08
--这种加载数据的方式是不会移动数据文件的,这点和loaddata不同,后者会移动数据文件至数据仓库目录。
09
alter table test add partition(ptDate='20121214')location '/tmp/result/20121214';
--注意目录20121214最后不要画蛇添足加/*,我就是linuxshell用多了,加了这玩意,调试了一下午。
。
。
注意:
location后面跟的是目录,不是文件,hive会把整个目录下的文件都加载到表中:
1
create EXTERNAL table IF NOT EXISTSuserInfo(id int,sexstring,age int, name string,emailstring,sdstring,edstring) ROWFORMATDELIMITEDFIELDSTERMINATED BY '\t' location '/hive/dw';
否则,会报错误:
FAILED:
Errorinmetadata:
MetaException(message:
Gotexception:
org.apache.hadoop.ipc.RemoteExceptionjava.io.:
Parentpathisnotadirectory:
/hive/dw/record_2013-04-04.txt
最后提下还有一种方式是建表的时候就指定外部表的数据源路径,
但这样的坏处是只能加载一个数据源了:
CREATEEXTERNALTABLEsunwg_test09(idINT,namestring) ROWFORMATDELIMITED FIELDSTERMINATEDBY‘\t’ LOCATION‘/sunwg/test08′; 上面的语句创建了一张名字为sunwg_test09的外表,该表有id和name两个字段, 字段的分割符为tab,文件的数据文件夹为/sunwg/test08 select*fromsunwg_test09; 可以查询到sunwg_test09中的数据。
在当前用户hive的根目录下找不到sunwg_test09文件夹。
此时hive将该表的数据文件信息保存到metadata数据库中。
mysql>select*fromTBLSwhereTBL_NAME=’sunwg_test09′; 可以看到该表的类型为EXTERNAL_TABLE。
mysql>select*fromSDSwhereSD_ID=TBL_ID; 在表SDS中记录了表sunwg_test09的数据文件路径为hdfs:
//hadoop00:
9000/hjl/test08。
#hjl为hive的数据库名 实际上外表不光可以指定hdfs的目录,本地的目录也是可以的。
比如:
CREATEEXTERNALTABLEtest10(idINT,namestring) ROWFORMATDELIMITED FIELDSTERMINATEDBY‘\t’
2、Hbase的rowkey怎么创建比较好?
列簇怎么创建比较好?
?
HBase是一个分布式的、面向列的数据库,它和一般关系型数据库的最大区别是:
HBase很适合于存储非结构化的数据,还有就是它基于列的而不是基于行的模式。
既然HBase是采用KeyValue的列存储,那Rowkey就是KeyValue的Key了,表示唯一一行。
Rowkey也是一段二进制码流,最大长度为64KB,内容可以由使用的用户自定义。
数据加载时,一般也是根据Rowkey的二进制序由小到大进行的。
HBase是根据Rowkey来进行检索的,系统通过找到某个Rowkey(或者某个Rowkey范围)所在的Region,然后将查询数据的请求路由到该Region获取数据。
HBase的检索支持3种方式:
(1)通过单个Rowkey访问,即按照某个Rowkey键值进行get操作,这样获取唯一一条记录;
(2)通过Rowkey的range进行scan,即通过设置startRowKey和endRowKey,在这个范围内进行扫描。
这样可以按指定的条件获取一批记录;
(3)全表扫描,即直接扫描整张表中所有行记录。
HBASE按单个Rowkey检索的效率是很高的,耗时在1毫秒以下,每秒钟可获取1000~2000条记录,不过非key列的查询很慢。
2HBase的RowKey设计
2.1设计原则
2.1.1Rowkey长度原则
Rowkey是一个二进制码流,Rowkey的长度被很多开发者建议说设计在10~100个字节,不过建议是越短越好,不要超过16个字节。
原因如下:
(1)数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,1000万列数据光Rowkey就要占用100*1000万=10亿个字节,将近1G数据,这会极大影响HFile的存储效率;
(2)MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率。
因此Rowkey的字节长度越短越好。
(3)目前操作系统是都是64位系统,内存8字节对齐。
控制在16个字节,8字节的整数倍利用操作系统的最佳特性。
2.1.2Rowkey散列原则
如果Rowkey是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将Rowkey的高位作为散列字段,由程序循环生成,低位放时间字段,这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。
如果没有散列字段,首字段直接是时间信息将产生所有新数据都在一个RegionServer上堆积的热点现象,这样在做数据检索的时候负载将会集中在个别RegionServer,降低查询效率。
2.1.3Rowkey唯一原则
必须在设计上保证其唯一性。
2.2应用场景
基于Rowkey的上述3个原则,应对不同应用场景有不同的Rowkey设计建议。
2.2.1针对事务数据Rowkey设计
事务数据是带时间属性的,建议将时间信息存入到Rowkey中,这有助于提示查询检索速度。
对于事务数据建议缺省就按天为数据建表,这样设计的好处是多方面的。
按天分表后,时间信息就可以去掉日期部分只保留小时分钟毫秒,这样4个字节即可搞定。
加上散列字段2个字节一共6个字节即可组成唯一Rowkey。
如下图所示:
事务数据Rowkey设计
第0字节
第1字节
第2字节
第3字节
第4字节
第5字节
…
散列字段
时间字段(毫秒)
扩展字段
0~65535(0x0000~0xFFFF)
0~86399999(0x00000000~0x05265BFF)
这样的设计从操作系统内存管理层面无法节省开销,因为64位操作系统是必须8字节对齐。
但是对于持久化存储中Rowkey部分可以节省25%的开销。
也许有人要问为什么不将时间字段以主机字节序保存,这样它也可以作为散列字段了。
这是因为时间范围内的数据还是尽量保证连续,相同时间范围内的数据查找的概率很大,对查询检索有好的效果,因此使用独立的散列字段效果更好,对于某些应用,我们可以考虑利用散列字段全部或者部分来存储某些数据的字段信息,只要保证相同散列值在同一时间(毫秒)唯一。
2.2.2针对统计数据的Rowkey设计
统计数据也是带时间属性的,统计数据最小单位只会到分钟(到秒预统计就没意义了)。
同时对于统计数据我们也缺省采用按天数据分表,这样设计的好处无需多说。
按天分表后,时间信息只需要保留小时分钟,那么0~1400只需占用两个字节即可保存时间信息。
由于统计数据某些维度数量非常庞大,因此需要4个字节作为序列字段,因此将散列字段同时作为序列字段使用也是6个字节组成唯一Rowkey。
如下图所示:
统计数据Rowkey设计
第0字节
第1字节
第2字节
第3字节
第4字节
第5字节
…
散列字段(序列字段)
时间字段(分钟)
扩展字段
0x00000000~0xFFFFFFFF)
0~1439(0x0000~0x059F)
同样这样的设计从操作系统内存管理层面无法节省开销,因为64位操作系统是必须8字节对齐。
但是对于持久化存储中Rowkey部分可以节省25%的开销。
预统计数据可能涉及到多次反复的重计算要求,需确保作废的数据能有效删除,同时不能影响散列的均衡效果,因此要特殊处理。
2.2.3针对通用数据的Rowkey设计
通用数据采用自增序列作为唯一主键,用户可以选择按天建分表也可以选择单表模式。
这种模式需要确保同时多个入库加载模块运行时散列字段(序列字段)的唯一性。
可以考虑给不同的加载模块赋予唯一因子区别。
设计结构如下图所示。
通用数据Rowkey设计
第0字节
第1字节
第2字节
第3字节
…
散列字段(序列字段)
扩展字段(控制在12字节内)
0x00000000
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据 试题