华为开源数据格式CarbonData项目，实现大数据即席查询秒级响应
华为宣布开源了CarbonData项目，该项目于6月3日通过Apache社区投票，成功进入Apache孵化器。CarbonData是一种低时延查询、存储和计算分离的轻量化文件存储格式。那么相比SQL on Hadoop方案、传统NoSQL或相对ElasticSearch等搜索系统，CarbonData具有什么样的优势呢？CarbonData的技术架构是什么样子的？未来有什么样的规划？我们采访了CarbonData项目的技术负责人为大家解惑。
InfoQ：请问CarbonData是什么时候开始进行的项目？为什么现在向Apache孵化器开源呢？开源发展历程和项目目前状态是怎么样的？
CarbonData：CarbonData项目是华为公司从多年数据处理经验和行业理解中逐步积累起来的，2015年我们对系统进行了一次架构重构，使其演化为HDFS上的一套通用的列式存储，支持和Spark引擎对接后形成一套分布式OLAP分析的解决方案。
华为一直是面向电信、金融、IT企业等用户提供大数据平台解决方案的供应商，从众多客户场景中我们不断提炼数据特征，总结出了一些典型的对大数据分析的诉求，逐步形成了CarbonData这个架构。
因为在IT领域，只有开源开放，才能最终让更多的客户和合作伙伴的数据连接在一起，产生更大商业价值。开源是为了构建E2E生态，CarbonData是数据存储层技术，要发挥价值，需要与计算层、查询层有效集成在一起，形成完成真正的生态发挥价值。
又因为Apache是目前大数据领域最权威的开源组织，其中的Hadoop，Spark已成为大数据开源的事实标准，我们也非常认可Apache以Community驱动技术进步的理念，所以我们选择进入Apache，与社区一同构建能力，使CarbonData融入大数据生态。
目前CarbonData开源项目已经在6月3日通过Apache社区投票，成功进入Apache孵化器。github地址：https://github.com/apache/incubator-carbondata。欢迎大家参与到Apache CarbonData社区： https://github.com/apache/incubator-carbondata/blob/master/docs/How-to-contribute-to-Apache-CarbonData.md。
InfoQ：请问是什么原因或机遇促使您们产生做CarbonData这个项目的想法的？之前的项目中遇到什么样的困难？
CarbonData：我们一直面临着很多高性能数据分析诉求，在传统的做法里，一般是使用数据库加BI工具实现报表、DashBoard和交互式查询等业务，但随着企业数据日益增大，业务驱动的分析灵活性要求逐渐增大，也有部分客户希望有除SQL外更强大的分析功能，所以传统的方式渐渐满足不了客户需求，让我们产生了做CarbonData这个项目的想法。
需求一般来源于几方面。
第一，在部署上，区别于以往的单机系统，企业客户希望有一套分布式方案来应对日益增多的数据，随时可以通过增加通用服务器的方式scale out横向扩展。
第二，在业务功能上，很多企业的业务都处在从传统数据库逐渐转移到大数据平台的迁移过程中，这就要求大数据平台要有较高兼容老业务的能力，这里面主要包含的是对完整的标准SQL支持，以及多种分析场景的支持。同时为了节约成本，企业希望“一份数据支持多种使用场景”，例如大规模扫描和计算的批处理场景，OLAP多维交互式分析场景，明细数据即席查询，主键低时延点查，以及对实时数据的实时查询等场景，都希望平台能给予支持，且达到秒级查询响应。
第三，在易用性上，企业客户以往使用BI工具，业务分析的OLAP模型是需要在BI工具中建立的，这就会导致有的场景下数据模型的灵活性和分析手段受到限制，而在大数据时代，大数据开源领域已经形成了一个生态系统，社区随时都在进步，经常会冒出一些新型的分析工具，所以企业客户都希望能跟随社区不断改进自己的系统，在自己的数据里快速用上新型的分析工具，得到更大的商业价值。
要同时达到上诉要求，无疑对大数据平台是一个很大的挑战。为了满足这些要求，我们开始不断在实际项目中积累经验，也尝试了很多不同的解决方案，但都没有发现能用一套方案解决所有问题。
大家首先会想到的是，在涉及到低时延查询的分布式存储中，一般常用的是KV型NoSQL数据库（如HBase，Cassandra），可以解决主键低时延查询的问题，但如果业务的查询模式稍作改变，例如对多维度灵活组合的查询，就会使点查变为全表扫描，使性能急剧下降。有的场景下，这时可以通过加入二级索引来缓解该问题，但这又带来了二级索引的维护和同步等管理问题，所以KV型存储并不是解决企业问题的通用方案。
那么，如果要解决通用的多维查询问题，有时我们会想到用多维时序数据库的方案（如Linkedin Pinot），他们的特点是数据都以时间序列的方式进入系统并经过数据预聚合和建立索引，因为是预计算，所以应对多维查询时非常快，数据也非常及时，同时具备多维分析和实时处理的优点，在性能监控、实时指标分析的场景里应用较多。但它在支持的查询类型上也有一定限制，因为做了数据预计算，所以这种架构一般无法应对明细数据查询，以及不支持Join多表关联分析，这无疑给企业使用场景带来了一定的限制。
另外一类是搜索系统（如Apache Solr，ElasticSearch），搜索系统可以做多维汇总也可以查询明细数据，它也具备基于倒排索引的快速布尔查询，并发也较高，似乎正是我们希望寻找的方案。但在实际应用中我们发现两个问题：一是由于搜索系统一般是针对非结构化数据而设计的，系统的数据膨胀率一般都比较高，在企业关系型数据模型下数据存储不够紧凑，造成数据量较大，二是搜索系统的数据组织方式和计算引擎密切相关，这就导致了数据入库后只能用相应的搜索引擎处理，这又一定程度打破了企业客户希望应用多种社区分析工具的初衷，所以搜索系统也有他自己的适用场景。
最后一类系统，就是目前社区里大量涌现的SQL on Hadoop方案，以Hive, SparkSQL, Flink为代表，这类系统的特点是计算和存储相分离，针对存储在HDFS上的文件提供标准SQL功能，他们在部署性和易用性上可以满足企业客户需求，业务场景上也能覆盖扫描，汇聚，详单等各类场景，可见可以将他们视为一类通用的解决方案。为了提高性能，Spark，Flink等开源项目通过不断优化自身架构提升计算性能，但提升重点都放在计算引擎和SQL优化器的增强上，在存储和数据组织上改进并不是重点。
所以，可以看出当前的很多大数据系统虽然都能支持各类查询场景，但他们都是偏向某一类场景设计的，在不是其目标场景的情况下要么不支持要么退化为全表扫描，所以导致企业为了应对批处理，多维分析，明细数据查询等场景，客户常常需要通过复制多份数据，每种场景要维护一套数据。
CarbonData的设计初衷正是为了打破这种限制，做到只保存一份数据，最优化地支撑多种使用场景。
InfoQ:能否具体谈谈CarbonData的技术架构？有何特征和优势呢？
CarbonData：整个大数据时代的开启，可以说是源自于Google的MapReduce论文，他引发了Hadoop开源项目以及后续一系列的生态发展。他的“伟大”之处在于计算和存储解耦的架构，使企业的部分业务（主要是批处理）从传统的垂直方案中解放出来，计算和存储可以按需扩展极大提升了业务发展的敏捷性，让众多企业普及了这一计算模式，从中受益。
虽然MapReduce开启了大数据时代，但它是通过纯粹的暴力扫描+分布式计算来提升批处理性能，所以并不能解决客户对所有查询场景的低时延查询要求。
在目前的生态中，最接近于客户要求的其实是搜索引擎类方案。通过良好的数据组织和索引，搜索引擎能提供多种快速的查询功能，但偏偏搜索引擎的存储层又和计算引擎是紧耦合的，并不符合企业对”一份数据，多种场景”的期望。
这给了我们启发，我们何不为通用计算引擎打造更一个高效的数据组织来满足客户需求呢，做到既利用计算和存储解耦架构又能提供高性能查询。抱着这个想法，我们启动了CarbonData项目。针对更多的业务，使计算和存储相分离，这也成了CarbonData的架构设计理念。
确立了这个理念后，我们很自然地选择了基于HDFS+通用计算引擎的架构，因为这个架构可以很好地提供Scale out能力。下一步我们问自己这个架构里还缺什么？这个架构中，HDFS提供文件的复制和读写能力，计算引擎负责读取文件和分布式计算，分工很明确，可以说他们分别定位于解决存储管理和计算的问题。但不难看出，为了适应更多场景，HDFS做了很大的“牺牲”，它牺牲了对文件内容的理解，正是由于放弃了对文件内容的理解，导致计算只能通过全扫描的方式来进行，可以说最终导致的是存储和计算都无法很好的利用数据特征来做优化。
所以针对这个问题，我们把CarbonData的发力重点放在对数据组织的优化上，通过数据组织最终是要提升IO性能和计算性能。为此，CarbonData做了如下工作。
CarbonData基础特性
1. 多维数据聚集：在入库时对数据按多个维度进行重新组织，使数据在“多维空间上更内聚”，在存储上获得更好的压缩率，在计算上获得更好的数据过滤效率。
2. 带索引的列存文件结构：首先，CarbonData为多类场景设计了多个级别的索引，并融入了一些搜索的特性，有跨文件的多维索引，文件内的多维索引，每列的minmax索引，以及列内的倒排索引等。其次，为了适应HDFS的存储特点，CarbonData的索引和数据文件存放在一起，一部分索引本身就是数据，另一部分索引存放在文件的元数据结构中，他们都能随HDFS提供本地化的访问能力。
3. 列组：整体上，CarbonData是一种列存结构，但相对于行存来说，列存结构在应对明细数据查询时会有数据还原代价高的问题，所以为了提升明显数据查询性能，CarbonData支持列组的存储方式，用户可以把某些不常作为过滤条件但又需要作为结果集返回的字段作为列组来存储，经过CarbonData编码后会将这些字段使用行存的方式来存储以提升查询性能。
4. 数据类型：目前CarbonData支持所有数据库的常用基本类型，以及Array，Struct复杂嵌套类型。同时社区也有人提出支持Map数据类型，我们计划未来添加Map数据类型。
5. 压缩：目前CarbonData支持Snappy压缩，压缩是针对每列分别进行的，因为列存的特点使得压缩非常高效。数据压缩率基于应用场景不同一般在2到8之间。
6. Hadoop集成：通过支持InputFormat/OutputFormat接口，CarbonData可以利用Hadoop的分布式优点，也能在所有以Hadoop为基础的生态系统中使用。
CarbonData高级特性
1. 可计算的编码方式：除了常见的Delta，RLE，Dictionary，BitPacking等编码方式外，CarbonData还支持将多列进行联合编码，以及应用了全局字典编码来实现免解码的计算，计算框架可以直接使用经过编码的数据来做聚合，排序等计算，这对需要大量shuffle的查询来说性能提升非常明显。
2. 与计算引擎联合优化：为了高效利用CarbonData经过优化后的数据组织，CarbonData提供了有针对性的优化策略，目前CarbonData社区首先做了和Spark的深度集成，其中基于SparkSQL框架增强了过滤下压，延迟物化，增量入库等特性，同时支持所有DataFrame API。相信未来通过社区的努力，会有更多的计算框架与CarbonData集成，发挥数据组织的价值。
目前这些特性都已经合入Apache CarbonData主干，欢迎大家使用。
InfoQ：在哪些场景推荐使用呢？性能测试结果如何？有没有应用案例，目前在国内的使用情况和用户规模？
CarbonData：推荐场景：希望一份存储同时满足快速扫描，多维分析，明细数据查询的场景。在华为的客户使用案例中，对比业界已有的列存方案，CarbonData可以带来5~30倍性能提升。
性能测试数据及应用案例等更多信息，请关注微信公众号ApacheCarbonData，及社区https://github.com/apache/incubator-carbondata。
InfoQ：CarbonData能和当前正火的Spark完美结合吗？还能兼容哪些主流框架呢？
CarbonData：目前CarbonData已与Spark做了深度集成，具体见上述高级特性。
InfoQ：您们的项目在未来有什么样的发展规划？还会增加什么功能吗？如何保证开源之后的项目的持续维护工作呢？
CarbonData：接下来社区重点工作是，提升系统易用性、完善生态集成（如：与Flink,Kafka等集成，实现数据实时导入CarbonData）。
CarbonData开源的第一个月，就有几百个commits提交，和20多个贡献者参与，所以后续这个项目会持续的活跃。10多个核心贡献者也将会持续参与社区建设。
InfoQ：在CarbonData设计研发并进入Apache孵化器的过程中，经历了哪些阶段，经历过的最大困难是什么？有什么样的感受或经验可以和大家分享的吗？
CarbonData：CarbonData团队大多数人都有参与Apache Hadoop、Spark等社区开发的经验，我们对社区流程和工作方式都很熟悉。最大的困难是进入孵化器阶段，去说服Apache社区接纳大数据生态新的高性能数据格式CarbonData。我们通过5月份在美国奥斯丁的开源盛会OSCON上，做CarbonData技术主题演讲和现场DEMO演示，展示了CarbonData优秀的架构和良好的性能效果。
InfoQ：您们是一个团队吗？如何保证您们团队的优秀成长？
CarbonData：CarbonData团队是一个全球化的（工程师来自中国、美国、印度）团队，这种全球化工作模式的经验积累，让我们能快速的适应Apache开源社区工作模式。
采访嘉宾：Apache CarbonData的PMC、Committers李昆、陈亮。
欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流
QQ群：26931708
Hadoop源代码研究群
兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop
QQ群：288410967
