Hive常见数据格式及存储（二）

上一篇文章中（Hive常见数据格式及存储（一），主要使用Hive 来做出常见的数据格式对文件存储的对比；没看过的小伙伴，建议先看下；
本次，我们来具体聊聊 大数据下的存储格式；

行式存储

在RDBMS数据库中我们存储数据都是按照一行一行来存，也是按照一行一行来读，这种按照行来存储以及来读取数据的存储方式，我们称作为 行式存储 ，这种存储方式在HDFS中存的方式和RDBMS一样，都是将多行数据放在同一个Block中的，如图

如上图所示，行式存储的结构：
假设文件中有ABCD 4列，5行数据，对应于HDFS里面就是Block；那么这种数据结构的优缺点有哪些呢？

优点

对于每一行数据的每一列，必然是在同一个Block里面的，那么在对数据做 insert、update 的时候，必然是很简单的；对于一条数据而言就在自己的Block中做就好了；

缺点

• 缺点，其实已经很明显， 在大数据的查询时，一般而言不肯定查询出表的所有字段，那么假设我只需要表中的其中某几个字段怎么办呢？ 对于行式存储来说，只能将所有的Block扫一遍，然后在给你对于的字段；
• 并且对于一张大宽表而言，每一列的数据类型都不一样，那么在压缩的时候，会带来麻烦，每种类型的压缩比都不一样，无法达到每种类型数据压缩比达到最好的效果

那么对比的行式存储的优缺点之后，出现了一种 列式存储 的数据结构，下面我们就具体聊聊 列式存储；

列式存储

首先一幅图，来看看列数存储的 方式；

从上图可以看出，对于列式存储而言，他的数据存放方式是将每一列的数据分别存放在不同的Block中，
这么做的优点在哪里呢？

优点

• 首先，我们在查询SQL的时候，一般都是 select cloumA from table 这种
  的SQL，我们都会具体查询到某个字段的数据，那么列式存储而言，你要的数据就在一个Block中，不需要扫所有的Bolck，查询性能可想而知，肯定是要比 扫全表的 行式存储 要快上很多的；

• 其次，对于 它而言，同一种类型的数据 一定会存在一个Block中的，那么我们可以针对每一种类型的数据做最合适的压缩方式，那么在存储 和计算 上 能得到最大的优化

缺点

缺点，当你查询的字段越多，扫的Block越多那么，查询上会受到一定的性能影响；

常见的列式存储格式

其实在上一篇中，我已经对比的常见的列式存储的 性能，这次我们就一起来探讨本质原因；

SequenceFile （最鸡肋，建议别用）

上图，来看看 Sequence 是什么鬼~~

• 首先从上图中，我们能看到 Record才是真正存放数据的地方，但是SequenceFile 会格外的存储一些数据比如 Header、Sync… 等等，所以，SequenceFile 是一定会比原始数据要大的；
• 其次，我们能看出，SequenceFile 存储的数据是 按照Key Value 格式存储的，假设 RecordLength的总长度是10 那么 KeyLength是4的话 Value的长度就是6
• 再者，SequenceFile除了存储数据本身外，还会将你记录的长度记录下来，其实为的是 记录数据的offerSet的值，想法是好的，但是听鸡肋的；

RCFile（Record Columnar File）

如上图所示，RCFile是Facebook开源的
RCFile是行列存储混合的（从上图中也可以体现的出来）性能也不怎么样

ORC

ORC存储结构如上图所示，引入了以下几个概念：

• Stripe(一个Stripe为250M)：
  Index Data + Row Data + Stripe Footer
  Index Data：轻量级的索引库
  在一个Stripe里面，如果是数值类型的会存最大与最小值；如果是字符串会存前后缀；这样存下来的好处：
• 当你的SQL语句后面有个where，你写了个id > 100
  如果第1个Stripe里存的是0~99
  第2个Stripe里存的是100~199
  第3个Stripe里存的是200~299
  那么我们刚刚那个SQL语句，第1个Stripe就不会去读了
  这样子，查询的性能肯定是会有提升的
• Stripe Footer：存的是类型； 这个不用太去关注
• 查询数据的时候，先去查索引，如果不满足，那么这个Stripe就不会去读取了

总结

所以，不存在最好的，只有最适合的，我们在选型的时候，需要结合自己业务的场景，对于选择最合适的方式，达到最好的效果~~