华为宣布开源了 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 孵化器。
相关社区信息如下：Apache CarbonData 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 基础特性
- 多维数据聚集：在入库时对数据按多个维度进行重新组织，使数据在“多维空间上更内聚”，在存储上获得更好的压缩率，在计算上获得更好的数据过滤效率。
- 带索引的列存文件结构：首先，CarbonData 为多类场景设计了多个级别的索引，并融入了一些搜索的特性，有跨文件的多维索引，文件内的多维索引，每列的 minmax 索引，以及列内的倒排索引等。其次，为了适应 HDFS 的存储特点，CarbonData 的索引和数据文件存放在一起，一部分索引本身就是数据，另一部分索引存放在文件的元数据结构中，他们都能随 HDFS 提供本地化的访问能力。
- 列组：整体上，CarbonData 是一种列存结构，但相对于行存来说，列存结构在应对明细数据查询时会有数据还原代价高的问题，所以为了提升明显数据查询性能，CarbonData 支持列组的存储方式，用户可以把某些不常作为过滤条件但又需要作为结果集返回的字段作为列组来存储，经过 CarbonData 编码后会将这些字段使用行存的方式来存储以提升查询性能。
- 数据类型：目前 CarbonData 支持所有数据库的常用基本类型，以及 Array，Struct 复杂嵌套类型。同时社区也有人提出支持 Map 数据类型，我们计划未来添加 Map 数据类型。
- 压缩：目前 CarbonData 支持 Snappy 压缩，压缩是针对每列分别进行的，因为列存的特点使得压缩非常高效。数据压缩率基于应用场景不同一般在 2 到 8 之间。
- Hadoop 集成：通过支持 InputFormat/OutputFormat 接口，CarbonData 可以利用 Hadoop 的分布式优点，也能在所有以 Hadoop 为基础的生态系统中使用。
CarbonData 高级特性
- 可计算的编码方式：除了常见的 Delta，RLE，Dictionary，BitPacking 等编码方式外，CarbonData 还支持将多列进行联合编码，以及应用了全局字典编码来实现免解码的计算，计算框架可以直接使用经过编码的数据来做聚合，排序等计算，这对需要大量 shuffle 的查询来说性能提升非常明显。
- 与计算引擎联合优化：为了高效利用 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 李昆、陈亮。
InfoQ高级编辑
中国开源发展研究分析 2022
本次报告为开发者，技术管理者，开源社区运营、市场，开源办公室工作人员带来信息上的增量以及对开源趋势、...
评论