大数据小视角3:CarbonData,来自华为的中国力量

连续两篇文章都聊了不同的存储格式,这篇我们继续深入来看看在存储格式的演变之上有什么新的"黑科技"。华为公司在2016年开源了类parquet的列存格式:CarbonData,并且贡献给了Apache社区。CarbonData仅仅用了不到一年的时间就成功毕业,成为了Apache社区的顶级项目,CarbonData是首个由华人公司主导的Apache顶级项目,(来源自eBay的Kylin算是首个由华人主导的顶级开源项目)笔者这里还是要向华为的小伙伴们致敬,能够完成这样一个从0到1的突破。 本篇笔者尝试从技术细节来梳理CarbonData与其“前辈”到底有何不同之处,我们在实际应用与设计存储格式时有什么可以借鉴汲取之处。

1.CarbonData

首先我们来看看CarbonData本身的定位,如下图所示:

单一存储数据满足多种数据应用场景

  • 1、支持海量数据扫描并取其中几列;
  • 2、支持根据主键进行查找,并在秒级响应;
  • 3、支持在海量数据进行类似于OLAP的交互式查询,并且查询中涉及到许多过滤条件,这种类型的workload应该在几秒钟内响应;
  • 4、支持快速地抽取单独的记录,并且从该记录中获取到所有列信息;
  • 5、支持HDFS,无缝对接Hadoop生态圈,天生带有分布式基因。

对于OLAP查询来说,存在多种不同类型的查询,存储结构的不同会影响到不同查询的数据表现。所以CarbonData的定位是作为一种通用的查询存储数据,通过Spark SQL来解决海量查询的问题,并且能够与Hadoop生态圈进行无缝对接。CarbonData最初的应用是与Spark SQLSpark DataFrame深度结合,后续由携程团队将CarbonData引入了Presto,滴滴团队将CarbonData引入Hive

其实无论是多维的OLAP查询,还是完整的扫描查询,还是部分范围查询。CarbonData的前辈ORCFile与Parquet都可以同样完成任务,那么作为新人,CarbonData有什么过人之处呢?

快,更快

下图是华为提供进行实测的数据,在绝大多数的测试场景之中CarbonData的性能都略优于Parquet。

TPC-H的查询测试

当然快速的查询是需要付出代价的,查询的快速所牺牲的是压缩率的减小与入库时间的延长。

TPC-H的入库与压缩测试

那我们接下来就是要详尽讨论CarbonData的性能表现与底层设计之间的逻辑关系。

文件结构

下图展示了CarbonData的数据存储格式:

图片.png

  • File Header 文件头的格式比较简单,保存了存储格式的版本和模式信息。(这部分通常是稳定不可变的内容
  • Blocklet 单Blocklet最大的容量阀值为64M,也就是说单个HDFS的Block可以容纳多个Blocklet(视Block的大小而定)。这块内容与ORCFile与Parquet的设计一脉相承,都是利用Pax的存储模型来优化数据查询时的性能表现。
  • File Footer 在文件尾部保存了存储数据的索引和摘要,索引是CarbonData最为核心的关键实现,正是由于索引的存在,大大提高了CarbonData在不同查询场景之下的性能表现

二级索引

CarbonData通过支持了二级索引,大大的提高了CarbonData数据查询的性能表现。

CarbonData的二级索引

由上图所示CarbonData在HDFS Block级别与内部的Blocklet级别都分别建立起索引,这样可以大大减少非必要的任务启动与非必要的磁盘IO操作。众所周知,引入索引的的确确能够加快数据的查询速率,但是天下没有免费的午餐。我想CarbonData压缩率缩减与数据导入时间的延长的原因,想必读者心中也有了答案。

在Blocklet内部索引在内存之中B+树的形式实现

我们可以看到在CarbonData的文件尾部,通过B+树的方式来实现索引。由于HDFS追加写的特性,所以我想读者应该也能明白为何这些索引数据与统计数据需要存放在CarbonData的末尾。

通过二级索引的一次落地查询

上图完整的展现了一次过滤查询的流程,这个过程在二级索引的作用之下,规避了大量非必要的查询交互,由此带来的性能优化是十分明显的。

相对于ORCFile与Parquet相对简要的摘要索引,CarbonData在索引层面颇费心思。通过这样的方式来超越前辈,当然这样的选择设计同样也要付出额外的代价。

全局字典编码

这是CarbonData之中颇具争议的功能,在CarbonData之前的版本是默认添加的内容,目前在1.3版本之中是作为可选项加入其中的。(笔者在华为高斯部门工作的师兄也曾经和笔者吐槽过在生产环境之中,全局字典编码的似乎还存在一些'坑')所以看起来能够运用好字典编码的确是个值得探讨的问题,笔者在此也简单聊一聊:

CarbonData全局字典编码

如上图所示,全局字典编码的方式很简单,就是通过数字和字典来替换表格之中重复出现的数据。 这样的好处很明显:

  • 大大减少了表格数据所需要存储的数据量
  • 某些需要进行group by的字段进行全局字典编码,可以大量减少计算时的shuffle的数据量。以达到性能提升的目的。

但是在将数据导入CarbonData的过程之中,对与重复率较低的列,一旦建立起全局字典,显然会大大拖慢数据的导入速度,并且影响数据的压缩程度。而如果对于数据重复率较高的数据,例如性别,年龄等高重复数据,通过建立全局字典能够大大提升CarbonData的压缩程度,并且对数据导入的速率影响不大。

笔者建议:对于字典编码的使用,还是要根据具体也业务场景进行分析压测,给出较为合适的使用方式,盲目使用字典编码反而会对性能带来负优化。

2.小结

到此为止,笔者也大致聊完了对CarbonData存储结构的理解以及笔者在简单实践之中所引发的思考。 作为华人圈子之中首个由华人公司主导的Apache的顶级项目,笔者也会继续对CarbonData进行关注与学习,也希望将来华人程序员能够在开源圈之中继续扩大影响力。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏更流畅、简洁的软件开发方式

【自然框架】之通用权限:用PowerDesigner重新设计了一下数据库,有ER图和表关系图

      好像以前做的那个数据库设计大家都没太看懂,究其原因似乎大家都比较习惯使用PowerDesinger来设计。而我用Excel画出来的图大家看着特别别扭...

46470
来自专栏数据和云

罗海雄:仅仅使用AWR做报告? 性能优化还未入门(含PPT)

编辑手记:祝贺罗海雄老师加入Oracle ACE社区,他是数据库SQL开发和性能优化专家,也是ITPUB论坛的资深版主,我们整理了罗老师一篇AWR裸数据分析的文...

12420
来自专栏c#开发者

框架设计指导方针[翻译]

原文 http://www.codeplex.com/AppArchGuide 本人英语水平较差献丑了 :) 框架设计指导方针 目的 1明白软件架构的概念 ...

37790
来自专栏web前端教室

如何从零开始,形成自己的模块化思维方式?

计算机这东西不是凭空出现的,它是为了解决一些实际的问题,有很多时候是对现实世界的模拟。遇到问题时,经常会有人说,要有大局观,要具体问题具体分析,也可以牵强的解释...

14320
来自专栏CSDN技术头条

刘奇:如何使用HBase构建NewSQL?

目前主流的数据库或者NoSQL要么在CAP里面选择AP,比较典型的例子是Cassandra,要么选择CP比如HBase,这两个是目前用得非常多的NoSQL的实现...

29050
来自专栏阮一峰的网络日志

USENET简介

普通的互联网用户,可能对USENET知之甚少,或者根本就没有听说过它。但是,这是一种很重要的网络应用,里面有一些真正有趣的东西。 我在网上没有找到比较通俗易懂的...

29290
来自专栏LET

谈谈3D Tiles(3):个人总结

1.1K110
来自专栏沈唁志

详解Linux运维工程师必备技能

37320
来自专栏落影的专栏

三年程序员的日常

前言 汇总平时的一些思考。 正文 如何快速上手一个庞大的工程? 这个问题,我已经经历过多次,现在的方式: 1、整理基本框架,研读代码规范,熟悉团队开发习...

44490
来自专栏一“技”之长

iOS10语音识别框架SpeechFramework应用

        iOS10系统是一个较有突破性的系统,其在Message,Notification等方面都开放了很多实用性的开发接口。本篇博客将主要探讨iOS1...

10620

扫码关注云+社区

领取腾讯云代金券