spark（12）
这都是现在大数据下比较火热的两种存储格式，orc和hive的关系可能要密切一点，但spark 对parquet寄予了厚望，
最近我们在测一个有join场景下的多个dataset的读取情况，这里简单写一下测试的一个结果，测试环境是spark1.6，数据在hdfs上，spark是local模式，集群的测试下周进行
join 后group，最后count
user的数据量在4000w左右，字段为4个字段，play选择的是1月1号，记录是1084966
先对比存储：
存储中横向对比了orc格式和parquet格式：
datatype\format
此时存储可以看出两者差别不大，parquet略小于orc，不过在海量数据下这个差距会被放大，此时的字段毕竟只是4个字段的user和3个字段的play
再对比性能：
执行类似：
user.joinWith(play,"$"userUid"===$"playUid","inner").groupBy($"_1.thirdPartyName").count().show()
执行结果：
duration/ms
解释下这张表，left表示在左边的，因为数据量是不完全对称的，而join方式也测试了inner和outer两种jointype，duration是指这个job执行的时间，而format是两种数据格式
不过网络也很重要，在测试时候我的下载大概是3M/s
join 后groupBy 最后avg
第二步我测试了
user.joinWith(play,"$"userUid"===$"playUid","inner").groupBy($"_1.thirdPartyName").toDf.agg(sum("_2.durationsum")).show()
测试结果：
初步看1.6用spark作为执行引擎使用parquet格式性能有一定的提升，后期会集群再测一次，而且我观察到两种格式的shuffle size好像相差挺大，这一个也是后期要看的一个指标
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：25252次
积分：1114
积分：1114
排名：千里之外
原创：89篇
(1)(1)(2)(1)(3)(2)(5)(5)(5)(7)(5)(12)(13)(1)(10)(16)HiveORC和Parquet
相比传统的行式存储引擎，列式存储引擎具有更高的压缩比，更少的IO操作，尤其是在数据列很多，但每次操作仅针对若干列进行查询和计算的情景，列式存储引擎的性价比更高。
目前在开源实现中，最有名的列式存储引擎莫过于Parquet和ORC，并且他们都是Apache的顶级项目，在数据存储引擎方面发挥着重要的作用。
本文将重点讲解ORC文件存储格式，Parquet暂不深入说明。
1、Apache Parquet
源自于google Dremel，Parquet相当于GoogleDremel中的数据存储引擎，而Apache顶级开源项目Drill正是Dremel的开源实现。
Apache Parquet 最初的设计动机是存储嵌套式数据，比如Protocolbuffer，thrift，json等，将这类数据存储成列式格式，以方便对其高效压缩和编码，且使用更少的IO操作取出需要的数据，这也是Parquet相比于ORC的优势，它能够透明地将Protobuf和thrift类型的数据进行列式存储，在Protobuf和thrift被广泛使用的今天，与parquet进行集成，是一件非容易和自然的事情。除了上述优势外，相比于ORC, Parquet没有太多其他可圈可点的地方，比如它不支持update操作（数据写成后不可修改），不支持ACID等。
Hive中创建表时使用Parquet数据存储格式：
create table parquet_table(id int,name string)
2、Apache ORC
ORC(OptimizedRow Columnar) 文件格式存储源自于RC（RecordColumnar File）这种存储格式，RC是一种列式存储引擎，对schema演化（修改schema需要重新生成数据）支持较差，而ORC是对RC改进，但它仍对schema演化支持较差，主要是在压缩编码，查询性能方面做了优化。RC/ORC最初是在Hive中得到使用，最后发展势头不错，独立成一个单独的项目。Hive 1.x版本对事务和update操作的支持，便是基于ORC实现的（其他存储格式暂不支持）。ORC发展到今天，已经具备一些非常高级的feature，比如支持update操作，支持ACID，支持struct，array复杂类型。你可以使用复杂类型构建一个类似于parquet的嵌套式数据架构，但当层数非常多时，写起来非常麻烦和复杂，而parquet提供的schema表达方式更容易表示出多级嵌套的数据类型。
Hive中创建表时使用ORC数据存储格式：
create table orc_table (id int,name string)
3、Parquet与ORC对比
http://parquet.apache.org
http://orc.apache.org
目前都是Apache开源的顶级项目，列式存储引擎
Twitter/Cloudera
Hortonworks
支持多种编码，字典，RLE，Delta等
支持主流编码，与Parquet类似
支持ACID事务
修改操作(update,delete)
(统计信息)
粗粒度索引
block/group/chunk级别统计信息
粗粒度索引
file/stripe/row级别统计信息，不能精确到列建立索引
Orc性能更高一点
Orc压缩比更高
下面看一张图，可以比对一下压缩率：
使用ORC文件格式可以提升Hive读、写与处理数据的性能。
一个ORC文件包含多个stripes（每个stripes由多组行数据组成的），一个包含辅助信息的file footer。
在文件的结尾，一个postscript保存着压缩参数及被压缩的footer的长度。
一个stripes缺省大小是250MB，其大小可以扩展的长度只受HDFS的约束。
file footer包含文件中的一个记录stripes信息的列表、每个stripes中行的数目及每个列的数据类型，它也包含列级的聚合结果：count, min, max, and sum。
我们通过使用hive --orcfiledump来进行分析ORC存储文件，就可以看到这些信息：
hive --orcfiledump
hive --orcfiledump /user/hive/warehouse/helloworld.db/test_orcfile/part-00271
对于Hive 1.1，查看ORC File文件中的内容可以使用如下的方式：
hive --orcfiledump -d
hive --orcfiledump -d /user/hive/warehouse/helloworld.db/test_orcfile/part-00271
从下面的ORC文件结构图可以了解相关信息：
我使用下面的命令，将ORC的分析结果输出到了orcfile文件，方便大家查看对照图分析：
hive --orcfiledump /user/hive/warehouse/helloworld.db/test_orcfile/part-00271 & orcfile
从上图中，我们知道在ORC文件中，每个Stripe包括索引数据(IndexData)、行数据(Row Data)及一个Stripe footer。
Stripe footer包含了用于流定位的目录，Row data用于表扫描。
索引数据（Index Data）包括每个列的最小与最大值，以及它们在每个列的行号，行索引项（Row index entries）记录了压缩块及解压后字节的偏移。需要注意的是，ORC索引只是被用来选择Stripe和行组，而不会被用于返回查询结果。拥有相对频繁的行索引条目，可以为了快速的数据读取而跳过一些行，缺省情况下每次最多可以跳过10000行。ORC有能力基于过滤谓词跳过非常多的行，可以使用第二关键字进行对表进行排序，以达到减少查询执行时间的效果。例如，如果主关键字是交易日期，表可以按照省份、邮编号码或者姓名进行排序，当按照省份查询记录的时候将跳过非目标省份的记录。
下面介绍如何在Hive中使用这种存储格式：
1) 支持的数据格式
boolean (1 bit) tinyint (8 bit) smallint (16 bit) int (32 bit) bigint (64 bit) Floating point
float double String types
string char varchar Binary blobs
binary Date/time
timestamp date Compound types
struct list map union
2) Hive DDL
通过指定stored as orc来使用ORC存储格式：
create table orc_table (
name string
) stored as orc;
可以修改表的存储格式：
alter table simple_tabl
如果simple_table已经存在数据，将导致通过表查询无法访问数据。
3) 创建表时，指定ORC存储格式属性
high level compression = {NONE, ZLIB, SNAPPY}
压缩方法(NONE, ZLIB, SNAPPY)
press.size
compression chunk size
每个压缩块的字节数
orc.stripe.size
268,435,456
memory buffer size in bytes for writing
每个stripe的字节数
orc.row.index.stride
number of rows between index entries
索引项之间的行数
orc.create.index
create indexes?
是否创建行索引
orc.bloom.filter.columns
comma separated list of column names
orc.bloom.filter.fpp
bloom filter false positive rate
比如，创建没有压缩的表：
CREATE TABLE orc_table (
name STRING,
age tinyint
) STORED AS ORC TBLPROPERTIES(&press&=&NONE&);
4) Hive涉及ORC存储文件的配置参数
& hive.default.fileformat
指定Hive创建表的存储文件格式，默认为TextFile。
& hive.exec.press
ORC的压缩编码方式，默认为ZLIB。
& hive.exec.orc.default.buffer.size
ORC的缓冲大小，默认为262,144(256KB)。
& hive.exec.orc.default.block.size
ORC文件的系统块大小，默认为268,435,456(256MB)
& hive.exec.orc.zerocopy
使用zerocopy读ORC文件。Hadoop 2.3以及后续版本支持。
& pute.splits.num.threads
ORC使用多少线程去并行化创建分片
hive.exec.orc.skip.corrupt.data false
If ORC reader encounters corrupt data, this value will be used todetermine whether to skip the corrupt data or throw an exception.
The default behavioris to throw an exception.
& hive.exec.orc.skip.corrupt.data
如果ORC读时遇到损坏的数据，此选项决定是否跳过损坏的数据，还是抛出异常。
默认是抛出异常。
& hive.merge.orcfile.stripe.level
当hive.merge.mapfiles,hive.merge.mapredfiles或者hive.merge.tezfiles设置为true时，此时同时以ORC文件格式写表数据，设置此值为true时将快速以stripe级别合并ORC小文件。
& 其他的参数有的用的很少，大家可以参考Hive官网说明进行配置和调优。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'Hadoop列式存储引擎Parquet/ORC和snappy压缩 - 推酷
Hadoop列式存储引擎Parquet/ORC和snappy压缩
相对于传统的行式存储格式，列式存储引擎具有更高的压缩比，更少的IO操作而备受青睐。列式存储缺点：在column数很多，每次操作大部分列的时候，cpu压力突增，而且增加处理时长。优点：在cloumn数很多，每次操作若干列的场景，列式存储的性价比，性能更高。
在很多大数据的应用场景下面，数据量很大、单列数据字段很多；比如电信行业，
具有一定规则的数据，字段很多，但是每次查询仅仅针对其中少数的几个字段，这个时候列式存储是极佳的选择。目前在大数据开源实现中，有多种列式存储实现，最早hive支持的rcfile，到后面的ORC, 不同的SQL-on-Hadoop解决方案，对不同的列式存储做
过不同的优化：
- Impala推荐使用parquet格式，不支持ORC,Rcfile
- Hive 0.x版本推荐使用rcfile
- PrestoDB推荐使用ORC
- Spark支持ORC,Parquet,Rcfile
Apache Parquet
源自于google Dremel系统（可下载论文参阅），Parquet相当于Google Dremel中的数据存储引擎，而Apache顶级开源项目Drill正是Dremel的开源实现。Apache Parquet 最初的设计动机是存储嵌套式数据，比如Protocolbuffer，thrift，json等，将这类数据存储成列式格式，以方便对其高效压缩和编码，且使用更少的IO操作取出需要的数据，这也是Parquet相比于ORC的优势，它能够透明地将Protobuf和thrift类型的数据进行列式存储，在Protobuf和thrift被广泛使用的今天，与parquet进行集成，是一件非容易和自然的事情。 除了上述优势外，相比于ORC, Parquet没有太多其他可圈可点的地方，比如它不支持update操作（数据写成后不可修改），不支持ACID等。
Apache ORC
ORC（OptimizedRC File）存储源自于RC（RecordColumnar File）这种存储格式，RC是一种列式存储引擎，对schema演化（修改schema需要重新生成数据）支持较差，而ORC是对RC改进，但它仍对schema演化支持较差，主要是在压缩编码，查询性能方面做了优化。RC/ORC最初是在Hive中得到使用，最后发展势头不错，独立成一个单独的项目。Hive 1.x版本对事务和update操作的支持，便是基于ORC实现的（其他存储格式暂不支持）。ORC发展到今天，已经具备一些非常高级的feature，比如支持update操作，支持ACID，支持struct，array复杂类型。你可以使用复杂类型构建一个类似于parquet的嵌套式数据架构，但当层数非常多时，写起来非常麻烦和复杂，而parquet提供的schema表达方式更容易表示出多级嵌套的数据类型。
Parquet与ORC
注意：如果用比较大量的数据转换列式存储格式，对服务器压力是非常大的，时间换空
间，权衡之.不同的SQL-on-Hadoop框架生成的列式存储格式消耗时间也不一致，由于
Spark底层是多线程，目前生成各种列式存储效率最高，其他框架Impala高于PrestoDB.
hbase && snappy
hbase选择Snappy压缩，Hbase做为大数据数据库，兼顾列式存储的开源数据库，NoSQL典型
代表，提供面向列式检索高效反应的场景，基于kv可高度压缩，为了提供CRUD操作，要求结果最终一致性，而update,delete操作需要在hbase存储数据region拆分过程来达到删除数据目的，也就是region：split &&compact；如果入hbase数据量太大，每天几个T数据，
每个region超过100g会自动做region拆分，导致占用大量集群IO，使得集群其他框架比如spark,Impala,PrestoDB效率低下；这个时候为Hbase选择基于列族的高度压缩算法尤为重要，减少数据量大小，降低IO操作，通过预建立region，严格控制region大小=1g左右，关闭自动region split&&compact操作，在一个合理的时间手动做split && compact，降低集群
IO压力，而snappy即是最佳选择，如图：
Hadoop压缩算法选择：
mapreduce.press.codec
mapreduce.press.codec
mapreduce.press.type
org.apache.press.DefaultCodec
org.apache.press.SnappyCodec [最佳选择]
org.apache.press.BZip2Codec /GzipCodec【GzipCodec压缩最高，但是时间上比较耗时】
随着Hadoop技术在各行各业深入使用，而且Hadoop在数据仓库，大规模数据分析型场景
的应用，选择一个合理的列式存储格式和高效的压缩算法尤为重要。列式存储目前也逐渐被应用于各种产品线，比如twitter,facebook已经将大部分数据格式转换为parquet，ORC
等列式存储格式，所占用空间和查询时间减少约35%。Parquet && ORC文件格式的压缩功能
显著降低了使用的磁盘空间，以及执行查询和其他操作所花的时间。
原创文章，转载请注明： 转载自whoami的博客
本博客的文章集合:
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致}