http://lastorder.me/tag/parquet.html

https://blog.twitter.com/2013/dremel-made-simple-with-parquet

对于优化『关系型数据库上的分析任务』,列式存储(Columnar  Storage)是个比较流行的技术.  这一技术对处理大数据集的好处是有据可查的,可以参见诸多学术资料,以及一些用作分析的商业数据库.(http://people.csail.mit.edu/tdanford/6830papers/stonebraker-cstore.pdf, http://www.vldb.org/pvldb/,http://www.monetdb.org/)

我们的目标是,对于一个查询,尽量只读取对这个查询有用的数据,以此来让磁盘 IO 最小.  用 Parquet,我们做到了把 Twitter 的大数据集上的 IO 缩减到原来的 1/3.  我们也做到了『指哪打哪』,也就是遍历(scan)一个数据集的时候,如果只读取部分列,那么读取时间也相应会缩短,时间缩短的比例就是那几列的数据量占全部列数据量的比例.  原理很简单,就是不采用传统的按行存储,而是连续存储一列的数据. 如果数据是扁平的(比如二维表形式),那列改成按列存储毫无难度,处理嵌套的数据结构才是真正的挑战.

我们的开源项目 Parquet 是 Hadoop 上的一种支持列式存储文件格式,起初只是 Twitter 和 Coudera 在合作开发,发展到现在已经有包括 Criteo公司 在内的许多其他贡献者了. Parquet 用 Dremel 的论文中描述的方式,把嵌套结构存储成扁平格式. 由于受益于这种技术,我们决定写篇更通俗易懂的文章来向大家介绍它. 首先讲一下嵌套数据结构的一般模型,然后会解释为什么这个模型可以被一坨扁平的列(columns)所描述,最后讨论为什么列式是高效的.

何谓列式存储?看下面的例子,这就是三个列 A B C.

如果把它换成行式存储的,那么数据就是一行挨着一行存储的

Whereas in a column-oriented storage, it is laid out one column at a time:

按列存,有几个好处:

  • 按列存,能够更好地压缩数据,因为一列的数据一般都是同质的(homogenous). 对于hadoop集群来说,空间节省非常可观.
  • I/O 会大大减少,因为扫描(遍历/scan)的时候,可以只读其中部分列. 而且由于数据压缩的更好的缘故,IO所需带宽也会减小.
  • 由于每列存的数据类型是相同的,we can use encodings better suited to the modern processors’ pipeline by making instruction branching more predictable. (没想好怎么翻译,各位自己理解吧)

嵌套结构的模型

首先是嵌套结构的模型,此处选取的模型就跟 PB 类似. 多个 field 可以形成一个 group,一个 field 可以重复出现(叫做 repeated field),这样就简单地描述了嵌套和重复,没有必要用更复杂的结构如 Map / List / Sets,因为这些都能用 group 和 repeated field 的各种组合来描述. (熟悉 PB 的人,对这里说的东西应该很清楚,因为这就是跟 PB 一样的,如果此处有疑惑,最好的方法是立即左转出门去看一下 PB)

整个结构是从最外层一个 message 开始的. 每个 field 有三个属性:repetition、type、name. 一个 field 的 type 属性,要么是 group,要么是基本类型(int, float, boolean, string),repetition 属性,有以下三种:

  • required:出现,且只能出现 1 次.
  • 出现 1 或 0 次.
  • repeated:0 到 任意多次

例如,下边是一个 address book 的 schema.

  1. message AddressBook {
  2. required string owner;
  3. repeated string ownerPhoneNumbers;
  4. repeated group contacts {
  5. required string name;
  6. optional string phoneNumber;
  7. }
  8. }

Lists(或者 Sets)可以用 repeated field 表示.

Maps,首先有一个 repeated field 在外面,里面每个 field,是一个 group,group 里面是 key-value 对,其中key 是 required 的.

列式存储格式

列式存储,简单来说就是三件事:1. 把一个嵌套的结构,映射为若干列  2. 把一条嵌套的数据,写入这些列里. 3. 还能根据这些列,把原来的嵌套结构拼出来. 做到这三点,目的就达到了.

译注:直观来看,嵌套结构含有两种信息:1. 字段的嵌套关系 2. 最终每个字段的值. 所以如何转换成列式也可以从这里下手,分别解决『值』和『嵌套关系』.

Parquet 的做法是,为嵌套结构的 schema 中每个基本类型的 field,建立一个列. 若用一棵树描述schema,基本类型的 field,就是树的叶子.

上边的 address book 结构用树表示:

观察上图,其实最终的值,都是在基本类型的 field 中的,group 类型的 field 本身不含有值,是基本类型组合起来的.

对上图蓝色叶子节点,每个对应一个列,就可以把结构中所有的值存起来了,如下表.

现在,『值』的问题解决了,还剩『嵌套关系』,这种关系,用叫做 repetition level 和 definition level 的两个值描述. 有了这俩值,就可以把原来的嵌套结构完全还原出来,下文将详细讲解这两个值到底是什么.

Definition Level

( 这俩 Level 容易把人看糊涂,如果看文字描述没明白,请看例子回头再看文字描述)

为支持嵌套结构,我们需要知道一个 field,到哪一层,变成 null 了(就是指field没有定义),这就是 definition level 的功能.  设想,如果一个field 有定义,则它的parents 也肯定有定义,这是很显然的. 如果一个 field 是没有定义的,那有可能它的上级是没定义的,但上上级有定义;也有可能是它的上级 和 上上级都没定义,所以需要知道到底是从哪一级开始没定义的,这是还原整条记录所必须知道的.

译注:(假设有一种一旦出现就每代必须遗传的病)如果你得了这个病,那么有可能你是第一个,你爸爸没这个病; 也可能是从你爸爸开始才出现这种病的(你爷爷还没这种病);  也有可能是从你爷爷开始就已经得病了.  反过来,如果你爸爸没这个病,那么你爷爷肯定也是健康的.  你需要一个值,描述是从你家第几代开始得病的,这个值就类似 definition level. 希望这比喻有助于理解.

对于扁平结构(就是没有任何嵌套),optional field 可以用一个 bit 来表示是否有定义: 有:1, 无:0 .

对于嵌套结构,我们可以给每一级的 optional field 都加一个 bit 来记录是否有定义,但其实没有必要,因为如上一段所说,因为嵌套的特性上层没定义,那下层当然也是没定义的,所以只要知道从哪一级开始没定义就可以了.

最后,required field 因为总是有定义的,所以不需要 definition level.

还是看例子,下边是一个简单的嵌套的schema:

  1. message ExampleDefinitionLevel {
  2. optional group a {
  3. optional group b {
  4. optional string c;
  5. }
  6. }
  7. }

转换成列式,它只有一列 a.b.c,所有 field 都是 optional 的,都可能是 null. 如果 c 有定义,那么 a b 作为它的上层,也将是有定义的.  当 c 是 null 时候,可能是因为它的某一级 parent 为 null 才导致 c 是 null 的,这时为了记录嵌套结构的状况,我们就需要保存最先出现 null 的那一层的深度了. 一共三个嵌套的 optional field,所以最大 definition level 是 3.

以下是各种情形下,a.b.c 的 definiton level:

这里 definition level 不会大于3,等于 3 的时候,表示 c 有定义; 等于 0,1,2 的时候,指明了 null 出现的层级.

required 总是有定义的,所以不需要 definition level. 下面把 b 改成 required,看看情况如何.

  1. message ExampleDefinitionLevel {
  2.   optional group a {
  3. required group b {
  4.       optional string c;
  5.     }
  6.   }
  7. }

现在最大的 definition level 是 2,因为 b 不需要 definition level. 下面是各种情形下,a.b.c 的 definition level:

不要让 definition level 太大,这很重要,目标是所用的比特越少越好(后面会说)

Repetition level

对于一个带 repeated field 的结构,转成列式表示后,一列可能有多个值,这些值的一部分是一坨里的,另一部分可能是另一坨里的,但一条记录的全部列都放在一列里,傻傻分不清楚,所以需要一个值来区分怎么分成不同的坨. 这个值就是 repetition level:对于列中的一个值,它告诉我这个值,是在哪个层级上,发生重复的.  这句话不太好理解,还是看例子吧.

这个结构转成列式的,实际也只有一列: level1.level2,这一列的各个值,对应的 repeatiton level 如下:

为了表述方便,称在一个嵌套结构里,一个 repeated field 连续出现的一组值为一个 List(只是为了描述方便),比如 a,b,c 是一个 level2 List, d,e,f,g 是一个level2 List,h 是一个level2 List,i,j 是一个level2 List。a,b,c,d,e,f,g 所在的两个 level2 list 是同一个 level1 List 里的,h,i,j 所在的两个 level2 List 是同一个 level1 List里的。

那么:repetition level 标示着新 List 出现的层级:

  • 0 表示整条记录的开始,此时应该创建新的 level1 List 和 level2 List
  • 1 表示 level1 List 的开始,此时应该创建一个 level2 List
  • 2 表示 level2 List中新的值产生,此时不新建 List,只在 List 里插入新值.

下图可以看出,换句话说就是 repetition level 告诉我们,在从列式表达,还原嵌套结构的时候,是在哪一级插入新值的.

repetiton = 0,标志着一整条新 record 的开始.  在扁平化结构里,没有 repetition 所以 repetition level 总是 0.   Only levels that are repeated need a Repetition level: optional 和 required 永远也不会重复,在计算 repetition level 的时候,可将其跳过.

拆分与组装

  1. message AddressBook {
  2.   required string owner;
  3.   repeated string ownerPhoneNumbers;
  4.   repeated group contacts {
  5.     required string name;
  6.     optional string phoneNumber;
  7.   }
  8. }

现在我们同时用这两种标识(definition level, repetition level),重新考虑 Address book 的例子. 下表显示了每一列 两种标识可能出现的最大值,并解释了为什么要比列所在深度小.

单说 contacts.phoneNumber 这一列,如果 手机号有定义,则 definition level 达到最大即2,如果有一个联系人是没有手机号的,则 definition level是 1. 如果联系人是空的,则 definition level 是0.

  1. AddressBook {
  2.   owner: "Julien Le Dem",
  3.   ownerPhoneNumbers: "555 123 4567",
  4.   ownerPhoneNumbers: "555 666 1337",
  5.   contacts: {
  6.     name: "Dmitriy Ryaboy",
  7.     phoneNumber: "555 987 6543",
  8.   },
  9.   contacts: {
  10.     name: "Chris Aniszczyk"
  11.   }
  12. }
  13. AddressBook {
  14.   owner: "A. Nonymous"
  15. }

现在我们拿 contacts.phoneNumber 这一列来做说明.

若一条记录是如下这样的:

  1. AddressBook {
  2.   contacts: {
  3.     phoneNumber: "555 987 6543"
  4.   }
  5.   contacts: {
  6.   }
  7. }
  8. AddressBook {
  9. }

转成列式之后,列中存储的东西应该是这样的(R = Repetiton Level, D = Definition Level):

为了将这条嵌套结构的 record 转换成列式,我们把这个 record 整个遍历一次,

  • contacts.phoneNumber: “555 987 6543”
    • new record: R = 0
    • value is defined: D = maximum (2)
  • contacts.phoneNumber: null
    • repeated contacts: R = 1
    • only defined up to contacts: D = 1
  • contacts: null
    • new record: R = 0
    • only defined up to AddressBook: D = 0

最后列中存储的东西是:

注意,NULL 值在这里列出来,是为了表述清晰,但是实际上是不会存储的.  列中小于最大 definition 值的(这个例子里最大值是2),都应该是 NULL.

为了通过列是存储,还原重建这条嵌套结构的记录,写一个循环读列中的值,

  • R=0, D=2, Value = “555 987 6543”:
    • R = 0 这是一个新的 record. 从根开始按照schema 重建结构,直到 repetition level 达到 2
    • D = 2 是最大值,值是有定义的,所以此时将值插入.
  • R=1, D=1:
    • R = 1  level1 的 contact list 中一条新记录
    • D = 1  contacts 有定义,但 phoneNumber 没定义,所建一个空的 contacts 即可.
  • R=0, D=0:
    • R = 0 一条新 record. 可以重建嵌套结构,直到达到 definition level 的值.
    • D = 0 => contacts 是 null,所以最后拼装出来的是一个空的 Address Book

高效存储 Definition Levels 和 Repetiton Levels.

在存储方面,问题很容易归结为:每一个基本类型的列,都要创建三个子列(R, D, Value). 然而,得益于我们所采用的这种列式的格式,三个子列的总开销其实并不大. 因为两种 Levels的最大值,是由 schema 的深度决定的,并且通常只用几个 bit 就够用了(1个bit 就可表达1层嵌套,2个bit就可以表达3层嵌套了,3个bit就能够表达7层嵌套了, [ 译注:四层嵌套编程的时候就已经很恶心了,从编程和可维护角度,也不应该搞的嵌套层次太深(个人观点) ]),对于上面的 AddressBook 实例,owner这一列,深度为1,contacts.name 深度为2,而这个表达能力已经很强了. R level 和 D level 的下限 总是0,上限总是列的深度. 如果一个 field 不是 repeated 的,就更好了,可以不需要 repetition level,而 required field 则不需要 definition level,这降低了两种 level 的上限.

考虑特殊情况,所有 field 全是 required(相当于SQL 中的NOT NULL),repetition level 和 definition level 就完全不需要了(总是0,所以不需要存储),直接存值就ok了. 如果我们要同时支持存储扁平结构,那么两种 level也是一样不需要存储空间的.

由于以上这些特性,我们可以找到一种结合 Run Length Encoding 和 bit packing(https://github.com/Parquet/parquet-mr/tree/master/parquet-column/src/main/java/parquet/column/values/rle) 的高效的编码方式.  一个很多值为 NULL 的稀疏的列,压缩后几乎不怎么占空间,与此相似,一个几乎总是有值的 optional 列,will cost very little overhead to store millions of 1s(在这个也没想好怎么翻译,总之是开销很小的意思了). 现实状况是,用于存储 levels 的空间,可以忽略不计. 以存储一个扁平结构为例(没有嵌套),直接顺序地把一列的值写入,如果某个field是 optional 的,那就取一位用来标识是否为 null.

Dremel made simple with Parquet的更多相关文章

  1. [翻译] Dremel made simple with Parquet

    首先自己的 blog 好久没有写技术相关的东西了,今天又动笔了,好高兴!然后转载请注明出处.最后开始正题: 原文:Dremel made simple with Parquet | Twitter E ...

  2. 大数据:Parquet文件存储格式

    一.Parquet的组成 Parquet仅仅是一种存储格式,它是语言.平台无关的,并且不需要和任何一种数据处理框架绑定,目前能够和Parquet适配的组件包括下面这些,可以看出基本上通常使用的查询引擎 ...

  3. 大数据:Parquet文件存储格式【转】

    一.Parquet的组成 Parquet仅仅是一种存储格式,它是语言.平台无关的,并且不需要和任何一种数据处理框架绑定,目前能够和Parquet适配的组件包括下面这些,可以看出基本上通常使用的查询引擎 ...

  4. Parquet 格式文件

    Apache Parquet是Hadoop生态圈中一种新型列式存储格式,它可以兼容Hadoop生态圈中大多数计算框架(Hadoop.Spark等),被多种查询引擎支持(Hive.Impala.Dril ...

  5. Parquet存储格式 - 论文翻译【转】

    Apache Parquet是Hadoop生态圈中一种新型列式存储格式,它可以兼容Hadoop生态圈中大多数计算框架(Mapreduce.Spark等),被多种查询引擎支持(Hive.Impala.D ...

  6. [DE] How to learn Big Data

    打开一瞧:50G的文件! emptystacks jobstacks jobtickets stackrequests worker 大数据加数据分析,需要以python+scikit,sql作为基础 ...

  7. kudu

    Kudu White Paper http://www.cloudera.com/documentation/betas/kudu/0-5-0/topics/kudu_resources.html h ...

  8. MaxCompute技术人背后的故事:从ApacheORC到AliORC

    2019大数据技术公开课第一季<技术人生专访>来袭,本季将带领开发者们探讨大数据技术,分享不同国家的工作体验.本文整理自阿里巴巴计算平台事业部高级技术专家吴刚的专访,将为大家介绍Apach ...

  9. 万亿级日志与行为数据存储查询技术剖析——Hbase系预聚合方案、Dremel系parquet列存储、预聚合系、Lucene系

    转自:http://www.infoq.com/cn/articles/trillion-log-and-data-storage-query-techniques?utm_source=infoq& ...

随机推荐

  1. 有关ftp批量传送文件或文件夹

    以ftp 批量上传文件时 可以用 mput file1 file2 .. 但是这样没传送一个就会问是否传送下一个 ,那么可以使用prompt这个命令.这是个双向开关,执行一次是取消提示,在执行一次是打 ...

  2. 单机c/s软件如何让老板在异地看销售营业报表

    单机软件,让人的感觉就只能在本地使用. 单机版c/s软件,数据存放在本机上,老板想要查看销售报表的话,需要跑到公司的那台电脑上才能查看,这对于在外面四处跑业务的老板来说,基本上是不可能做到的.但每天的 ...

  3. jboss eap6出现Tags_$$_javassist_26 cannot be cast to javassist.util.proxy.ProxyObject的解决办法

    使用了spring,hibernate.部署在jboss eap6中时,查询时出现java.lang.ClassCastException: com.vteba.product.base.model. ...

  4. 如何在线缩小jpg图片的大小

    直接使用在线PS保存成更小格式,即可! 在线PS网址:http://www.webps.cn/ 打开图片 点击保存 直接拖动滑动条就可以改变图片大小

  5. 使用 StoryBoard 的时候加入用户引导页面

    如果想让一个APP加上引导页面是一个非常完美的举动 但是,总会遇到一些问题 (不要忘记在APDelegate里面加上用户引导页面的头文件和程序启动时的第一个页面哦) 情况一:纯代码 判断是否是第一次启 ...

  6. MyBatis简介与配置MyBatis+Spring+MySql

    MyBatis学习 之 一.MyBatis简介与配置MyBatis+Spring+MySql MyBatis学习 之 二.SQL语句映射文件(1)resultMap MyBatis学习 之 二.SQL ...

  7. Yii中CDbCriteria常用方法

    最近在使用Yii 下面是常用到的方法,这里保存一下方便查看 $criteria =newCDbCriteria; $criteria->addCondition("id=1" ...

  8. 图像的稀疏表示——ScSPM和LLC的总结

    前言 上一篇提到了SPM.这篇博客打算把ScSPM和LLC一起总结了.ScSPM和LLC其实都是对SPM的改进.这些技术,都是对特征的描述.它们既没有创造出新的特征(都是提取SIFT,HOG, RGB ...

  9. careercup-中等难度 17.7

    17.7 给定一个整数,打印该整数的英文描述(例如“One Thousand,Two Hundred Thirty Four”). 解法: 举个例子,在转换19 323 984时,我们可以考虑分段处理 ...

  10. devenv.exe - Assert Failure visual studio 2010

    安装完成devexpress后启动vs提示 devenv.exe - assert failure  第一种在博客园找到的解决方案: 原因是机器上安装了framework 4.5 和4.5中文包,卸载 ...