列式存储和行式存储是针对数据在存储介质中的排序形式而言的,假设存在一张table,那么:
图1-1所示为行式存储和列式存储的示意图,一张table包含5个字段(列)即rowid、date/time、customer name以及quantity,共7行,图中的红色箭头表示存储顺序。
存储形式的差异决定了适用场景的不同:
综合来看,列式存储比较适合大数据量(压缩比高)、分析型 *** 作(针对少数几列);不适合频率较高的删除(全列检索)、更新(重新压缩) *** 作 。
图2-1所示为列式存储中将某张table基于字典表进行编码压缩的示例,图中左边为源表,假设该table中的customers和material字段的取值均只有右上表所示的5种,那么当源表的行数很大时,customers和material字段就会存在大量重复的取值,为了节省存储空间对这两个字段进行编码,即使用一个字典表(右上图)记录该两个字段的distinct取值,又下表则用右上表字段取值对应的index(整数1、2、3、4、5)来代替原来的string,由于string占用的存储空间比这几个index占用的存储空间大多了,因此可以较大程度上压缩占用的存储空间。
基于列式存储的两个典型实现是:hbase和parquet,其中:
parquet的文件结构如图3-1所示:
从图中可以看出,1个parquet文件由header(1个)、block(可以多个)、footer(1个)组成,分别负责:
图3-2所示为parquet文件中,block、rowgroup、columnchunk以及page的关系:
简而言之:
因此如果将一个parquet文件类比成一张大excel 表,那么:
parquet格式的表在生产环境中经常被使用到,具有列式存储和压缩等特点,我们怎么在hive中存储parquet格式的表呢。
这里使用oracle的emp表
加载本地数据到hive表
执行查询
发现报错
emp使用parquet格式存储,其中imputFormat和outputFormat都是parquet的相关的,也就是我的imputFormat是parquent的,但是你传过来的是text,我不认识
我们看一下emp的相关信息,可以看到这里的都是parquet的format的,这是导致这次错误的原因。
这就导致了我们需要每次都先把text文件转化为parquet的文件,然后parquent表进行加载才可以,下面介绍官方推荐的使用方法。
查看emp_tmp的表的信息,这里可以看到,默认的是TextImputFormat和TextOutputFormat的。
然后加载数据到emp_tmp,查看数据,是正常显示的
然后现在把之前的emp里面的数据给删除
然后把emp_tmp表里面的数据加载到emp
查询一下,数据正常显示,这个方式使用起来还行,就是每次都需要对临时表进行 *** 作,还是比较麻烦的。
感觉这个问题是经常出现,为什么会这样呢。这个和hive的版本有一定的关系。
可以看出hive官方将inputformat和outputformat进行了整合,这样使用起来也是比较方便的。
但是可能有人想,那我修改inputformat不就行了,下面我介绍一下,看是否可以
创建emp2表,是parquet的存储格式的
修改inputformat 和serde,这里inputFormat是TextInputFormat,SEDE使用的是LazySimpleSerDe,Outputformat任然是Parquet的,这里需要带上。
查看emp2表的信息,如下图表示修改成功
加载数据到emp2
查询数据,执行成功
到这里,修改inputformat和serde的方法也介绍完成了,我们以为成功了,但是上hdfs上一看,文件还是txt格式的,所以通过修改inputformat和serde的方法不行。
肯定有人想使用这个方法
这个方法我也尝试了,但是返回的值全都是null
在仅仅使用hive的时候,如果想把txt文件里面的数据保存到parquet表里面的话,可以使用建立临时表的方法,这个方法也是比较好 *** 作的。
但是其实如果使用spark,flink等分布式计算引擎的话,是可以直接的读取txt数据保存到parquet表里面的,框架帮我们做了转化。这种方式也是我们在工作中经常使用的。
上面也介绍了修改inputformat和ser的方式,秀给inputformat是可以让txt文件里面的数据被读进来的,如果同时还修改了serde为lazysimpleserde的话,这个是把数据保存为text格式的,已经完全和parquet没有关系了,保存的文件还是txt格式的。仅修改inputformat,但是使用的serde是parquet的,但是数据进出不一致,也是有问题的。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)