Today, we’re excited to announce the general availability of Apache Spark 2.0 on Databricks. This release builds on what the community has learned in the past two years, doubling down on what users love and fixing the pain points. This post summarizes the three major themes—easier, faster, and smarter—that comprise Spark 2.0. We also explore many of them in more detail in our anthology of Spark 2.0 content.

Two months ago, we launched a preview release of Apache Spark 2.0 on Databricks. As you can see in the chart below, 10% of our clusters are already using this release, as customers experiment with the new features and give us feedback. Thanks to this experience, we are excited to be the first commercial vendor to support Spark 2.0.

Apache Spark Usage over Time by Version

Now, let’s dive into what’s new in Apache Spark 2.0.

Easier: ANSI SQL and Streamlined APIs

One thing we are proud of in Spark is APIs that are simple, intuitive, and expressive. Spark 2.0 continues this tradition, focusing on two areas: (1) standard SQL support and (2) unifying DataFrame/Dataset API.

On the SQL side, we have significantly expanded Spark’s SQL support, with the introduction of a new ANSI SQL parser and subqueries. Spark 2.0 can run all the 99 TPC-DS queries, which require many of the SQL:2003 features. Because SQL has been one of the primary interfaces to Spark, these extended capabilities drastically reduce the effort of porting legacy applications.

On the programmatic API side, we have streamlined Spark’s APIs:

• Unifying DataFrames and Datasets in Scala/Java: Starting in Spark 2.0, DataFrame is just a type alias for Dataset of Row. Both the typed methods (e.g. map, filter, groupByKey) and the untyped methods (e.g. select, groupBy) are available on the Dataset class. Also, this new combined Dataset interface is the abstraction used for Structured Streaming. Since compile-time type-safety is not a feature in Python and R, the concept of Dataset does not apply to these language APIs. Instead, DataFrame remains the primary interface there, and is analogous to the single-node data frame notion in these languages. Get a peek fromthis notebook and this blog for the stories behind these APIs.
• SparkSession: a new entry point that supersedes SQLContext and HiveContext. For users of the DataFrame API, a common source of confusion for Spark is which “context” to use. Now you can use SparkSession, which subsumes both, as a single entry point, asdemonstrated in this notebook. Note that the old SQLContext and HiveContext classes are still kept for backward compatibility.
• Simpler, more performant Accumulator API: We have designed a new Accumulator APIthat has a simpler type hierarchy and support specialization for primitive types. The old Accumulator API has been deprecated but retained for backward compatibility
• DataFrame-based Machine Learning API emerges as the primary ML API: With Spark 2.0, the spark.ml package, with its “pipeline” APIs, will emerge as the primary machine learning API. While the original spark.mllib package is preserved, future development will focus on the DataFrame-based API.
• Machine learning pipeline persistence: Users can now save and load machine learning pipelines and models across all programming languages supported by Spark. See this blog post for more details and this notebook for examples.
• Distributed algorithms in R: Added support for Generalized Linear Models (GLM), Naive Bayes, Survival Regression, and K-Means in R.
• User-defined functions (UDFs) in R: Added support for running partition level UDFs (dapply and gapply) and hyper-parameter tuning (lapply).

Faster: Apache Spark as a Compiler

According to our 2015 Spark Survey, 91% of users consider performance as the most important aspect of Apache Spark. As a result, performance optimizations have always been a focus in our Spark development. Before we started planning our contributions to Spark 2.0, we asked ourselves a question: Spark is already pretty fast, but can we push the boundary and make Spark 10X faster?

This question led us to fundamentally rethink the way we build Spark’s physical execution layer. When you look into a modern data engine (e.g. Spark or other MPP databases), majority of the CPU cycles are spent in useless work, such as making virtual function calls or reading/writing intermediate data to CPU cache or memory. Optimizing performance by reducing the amount of CPU cycles wasted in these useless work has been a long time focus of modern compilers.

Spark 2.0 ships with the second generation Tungsten engine. This engine builds upon ideas from modern compilers and MPP databases and applies them to Spark workloads. The main idea is to emit optimized code at runtime that collapses the entire query into a single function, eliminating virtual function calls and leveraging CPU registers for intermediate data. We call this technique “whole-stage code generation.”

To give you a teaser, we have measured the time (in nanoseconds) it takes to process a row on one core for some of the operators in Spark 1.6 vs. Spark 2.0. The table below shows the improvements in Spark 2.0. Spark 1.6 also included an expression code generation technique that is used in some state-of-the-art commercial databases, but as you can see, many operators became an order of magnitude faster with whole-stage code generation.

You can see the power of whole-stage code generation in action in this notebook, in which we perform aggregations and joins on 1 billion records on a single machine.

How does this new engine work on end-to-end queries? We did some preliminary analysis using TPC-DS queries to compare Spark 1.6 and Spark 2.0:

Beyond whole-stage code generation to improve performance, a lot of work has also gone into improving the Catalyst optimizer for general query optimizations such as nullability propagation, as well as a new vectorized Parquet decoder that improved Parquet scan throughput by 3X. Read this blog post for more detail on the optimizations in Spark 2.0.

Smarter: Structured Streaming

Spark Streaming has long led the big data space as one of the first systems unifying batch and streaming computation. When its streaming API, called DStreams, was introduced in Spark 0.7, it offered developers with several powerful properties: exactly-once semantics, fault-tolerance at scale, strong consistency guarantees and high throughput.

However, after working with hundreds of real-world deployments of Spark Streaming, we found that applications that need to make decisions in real-time often require more than just a streaming engine. They require deep integration of the batch stack and the streaming stack, interaction with external storage systems, as well as the ability to cope with changes in business logic. As a result, enterprises want more than just a streaming engine; instead they need a full stack that enables them to develop end-to-end “continuous applications.”

Spark 2.0 tackles these use cases through a new API called Structured Streaming. Compared to existing streaming systems, Structured Streaming makes three key improvements:

1. Integrated API with batch jobs. To run a streaming computation, developers simply write a batch computation against the DataFrame / Dataset API, and Spark automaticallyincrementalizes the computation to run it in a streaming fashion (i.e. update the result as data comes in). This powerful design means that developers don’t have to manually manage state, failures, or keeping the application in sync with batch jobs. Instead, the streaming job always gives the same answer as a batch job on the same data.
2. Transactional interaction with storage systems. Structured Streaming handles fault tolerance and consistency holistically across the engine and storage systems, making it easy to write applications that update a live database used for serving, join in static data, or move data reliably between storage systems.
3. Rich integration with the rest of Spark. Structured Streaming supports interactive queries on streaming data through Spark SQL, joins against static data, and many libraries that already use DataFrames, letting developers build complete applications instead of just streaming pipelines. In the future, expect more integrations with MLlib and other libraries.

Spark 2.0 ships with an initial, alpha version of Structured Streaming, as a (surprisingly small!) extension to the DataFrame/Dataset API. This makes it easy to adopt for existing Spark users that want to answer new questions in real-time. Other key features include support for event-time based processing, out-of-order/delayed data, interactive queries, and interaction with non-streaming data sources and sinks.

We also updated the Databricks workspace to support Structured Streaming. For example, when launching a streaming query, the notebook UI will automatically display its status.

Streaming is clearly a broad topic, so stay tuned for a series of blog posts with more details on Structured Streaming in Apache Spark 2.0.

Conclusion

Spark users initially came to Apache Spark for its ease-of-use and performance. Spark 2.0 doubles down on these while extending it to support an even wider range of workloads. Enjoy the new release on Databricks.

Read More

You can also import the following notebooks and try them on Databricks Community Editionwith Spark 2.0.

• SparkSession: A new entry point
• Datasets: A more streamlined API
• Performance of whole-stage code generation
• Machine learning pipeline persistence

Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，旨在快速处理大规模的数据，并能够实现快速查询和分析。尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid仍能够保持100%正常运行。创建Druid的最初意图主要是为了解决查询延迟问题，当时试图使用Hadoop来实现交互式查询分析，但是很难满足实时分析的需要。而Druid提供了以交互方式访问数据的能力，并权衡了查询的灵活性和性能而采取了特殊的存储格式。

Druid功能介于PowerDrill和Dremel之间，它几乎实现了Dremel的所有功能，并且从PowerDrill吸收一些有趣的数据格式。Druid允许以类似Dremel和PowerDrill的方式进行单表查询，同时还增加了一些新特性，如为局部嵌套数据结构提供列式存储格式、为快速过滤做索引、实时摄取和查询、高容错的分布式体系架构等。从官方得知，Druid的具有以下主要特征：

• 为分析而设计——Druid是为OLAP工作流的探索性分析而构建，它支持各种过滤、聚合和查询等类；
• 快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到；
• 高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；
• 可扩展——Druid已实现每天能够处理数十亿事件和TB级数据。

Druid应用最多的是类似于广告分析创业公司Metamarkets中的应用场景，如广告分析、互联网广告系统监控以及网络监控等。当业务中出现以下情况时，Druid是一个很好的技术方案选择：

• 需要交互式聚合和快速探究大量数据时；
• 需要实时查询分析时；
• 具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；
• 对数据尤其是大数据进行实时分析时；
• 需要一个高可用、高容错、高性能数据库时。

一个Druid集群有各种类型的节点（Node）组成，每个节点都可以很好的处理一些的事情，这些节点包括对非实时数据进行处理存储和查询的Historical节点、实时摄取数据、监听输入数据流的Realtime节、监控Historical节点的Coordinator节点、接收来自外部客户端的查询和将查询转发到Realtime和Historical节点的Broker节点、负责索引服务的Indexer节点。

查询操作中数据流和各个节点的关系如下图所示：

如下图是Druid集群的管理层架构，该图展示了相关节点和集群管理所依赖的其他组件（如负责服务发现的ZooKeeper集群）的关系：

Druid已基于Apache License 2.0协议开源，代码托管在GitHub，其当前最新稳定版本是0.7.1.1。当前，Druid已有63个代码贡献者和将近2000个关注。Druid的主要贡献者包括广告分析创业公司Metamarkets、电影流媒体网站Netflix、Yahoo等公司。Druid官方还对Druid同Shark、Vertica、Cassandra、Hadoop、Spark、Elasticsearch等在容错能力、灵活性、查询性能等方便进行了对比说明。更多关于Druid的信息，大家还可以参考官方提供的入门教程、白皮书、设计文档等。

作者：祝威廉

• 工程数据，譬如工单数量，SLA可用性，基础资源，故障率，报警统计
• 业务数据，譬如业务DashBoard,Trace调用链，业务拓扑切换，业务指标，业务基准数据，业务日志挖掘
• 数据可视化

当然，这篇文章谈的是运维都有哪些数据，哪些指标，以及数据呈现。并没有谈及如何和大数据相关的架构做整合，从而能让这些数据真的变得活起来。

比较凑巧的是，原先百度的桑文峰的分享也讲到日志的多维度分析，吃完饭的时候，一位优酷的朋友也和我探讨了关于业务监控的的问题。而我之前发表在肉饼铺子里的一篇文章《 大数据给公司带来了什么 》也特地提到了大数据对于整个运维的帮助，当时因为这篇内容的主旨是罗列大数据的用处，自然没法细讲运维和大数据的整合这一块。

上面的文字算引子，在步入正式的探讨前，有一点我觉得值得强调：

虽然这里讲的是如何将大数据思维/架构应用于运维，平台化运维工作，但是和大数据本质上没有关系，我们只是将大数据处理的方式和思想应用在运维工作上。所以，即使你现在所在的公司没有数据团队支撑，也是完全可以通过现有团队完成这件事情的。

1 运维监控现状

很多公司的运维的监控具有如下特质：

只能监控基础运维层次，通过zabbix等工具提供服务器,CPU,内存等相关的监控。这部分重要，但确实不是运维的核心。

对业务的监控是最复杂的，而现在很多公司的要么还处于Shell脚本的刀耕火种阶段，要么开发能力较强，但是还是东一榔头西一棒子，不同的业务需要不同的监控系统，人人都可以根据的自己的想法开发一个监控的工具也好，系统也好，平台也好。总之是比较凌乱的。

使用第三方的监控平台。这个似乎在Rails/NodeJS/Pythone相关语系开发的产品中比较常见。我不做过多评价，使用后冷暖自知。

当然也有抽象得很好的，比如点评网的运维监控据说就做得相当好，运维很闲，天天没事就根据自己的监控找开发的茬，让开发持续改进。不过他们的指导思想主要有两个：

运维自动化。怎么能够实现这个目标就怎么搞，这严重依赖于搞的人的规划能力和经验。

抽象化，根据实际面临的问题做出抽象，得到对应的系统，比如需要发布，于是又发布系统，需要管理配置文件，所以有配管系统，需要日志分析所以有了有日志分析系统。然而这样是比较零散的。

有点扯远，我们还是focus在监控上。

如果以大数据的思维去思考，我们应该如何做好监控这件事情?

2 罗列出你的数据源

《大数据对于运维的意义》这篇文章也讲了，主要有工程数据，业务数据。所有的数据源都有一个共性，就是 日志 。无论文本的也好，二进制的也好。所以日志是整个信息的源头。日志包含的信息足以让我们追查到下面几件事情：

• 系统健康状况监控
• 查找故障根源
• 系统瓶颈诊断和调优
• 追踪安全相关问题
• 从日志我们可以挖掘出什么?

我觉得抽象起来就一个： 指标 。

指标可以再进行分类：

业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等

应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等

系统资源层面：如cpu、内存、swap、磁盘、load、主进程存活等

网络层面： 如丢包、ping存活、流量、tcp连接数等

每个分类里的每个小点其实都是一个指标。

3 如何统一实现

千万不要针对具体问题进行解决，大数据架构上的一个思维就是：我能够提供一个平台让大家方便解决这些问题么? 而不是，这个问题我能解决么?

先来看看架构图：

• 推荐
• 搜索
• 统一查询引擎

所以监控的架构设计略简单些。如果你希望进行日志存储以及事后批量分析，则可以采用淘宝的这套架构方式：

将日志过滤，格式化，或存储起来

进行实时计算，将指标数据存储到HBase里去

到目前为止，我们没有做任何的开发，全部使用大数据里通用的一些组件。至于这些组件需要多少服务器，就看对应的日志量规模了，三五台到几百台都是可以的。

需要开发的地方只有两个点，有一个是一次性的，有一个则是长期。

先说说一次性的，其实就是大盘展示系统。这个就是从HBase里取出数据做展示。这个貌似也有开源的一套，ELK。不过底层不是用的HBase存储，而是ES。这里就不详细讨论。

长期的则是SparkStreaming(淘宝是使用Storm，我建议用SparkStreaming,因为SparkStreaming可以按时间窗口，也可以按量统一做计算)，这里你需要定义日志的处理逻辑，生成我上面提到的各项指标。

这里有一个什么好处呢，就是平台化了，对新的监控需求响应更快了，开发到上线可能只要几个小时的功夫。如果某个系统某天需要一个新的监控指标，我们只要开发个SparkStreaming程序，丢到平台里去，这事就算完了。

第一幅图的平台我是已经实现了的。我目前在SparkStreaming上只做了三个方面比较基础的监控，不过应该够用了。

状态码大盘。 HTTP响应码的URL(去掉query参数)排行榜。比如你打开页面就可以看到发生500错误的top100的URL，以及该URL所归属的系统。

响应耗时大盘。 URL请求耗时排行榜。比如你打开页面就可以看到5分钟内平均响应耗时top100的URL(去掉query参数)。

还有就是Trace系统。 类似Google的Dapper,淘宝的EagleEye。给出一个唯一的UUID,可以追踪到特定一个Request的请求链路。每个依赖服务的响应情况，比如响应时间。对于一个由几个甚至几百个服务组成的大系统，意义非常大，可以方便的定位出到底是那个系统的哪个API的问题。这个最大的难点是需要统一底层的RPC/HTTP调用框架，进行埋点。因为我使用的是自研的ServiceFramework框架，通讯埋点就比较简单。如果是在一个业务线复杂，各个系统使用不同技术开发，想要做这块就要做好心理准备了。

现在，如果你想要监控一个系统是不是存活，你不在需要取写脚本去找他的pid看进程是不是存在，系统发现在一定的周期内没有日志，就可以认为它死了。而系统如果有异常，比如有大量的慢查询，大盘一定能展示出来。

描述到这，我们可以看到，这套架构的优势在哪：

基本上没有需要自己开发的系统。从日志收集，到日志存储，到结果存储等，统统都是现成的组件。

可扩展性好。每个组件都是集群模式的，没有单点故障。每个组件都是可水平扩展的，日志量大了，加机器就好。

开发更集中了。你只要关注日志实际的分析处理，提炼指标即可。

4 大数据思维

对于运维的监控，利用大数据思维，需要分三步走：

• 找到数据
• 分析定义从数据里中我能得到什么
• 从大数据平台中挑选你要的组件完成搭积木式开发

所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是 定义处理日志的的逻辑 。

这里有几点注意的：

如果你拥有复杂的产品线，那么日志格式会是一个很痛苦的事情。以为这中间Storm(或者SparkStreaming)的处理环节你需要做大量的兼容适配。我个人的意见是，第一，没有其他更好的办理，去兼容适配吧，第二，推动大家统一日志格式。两件事情一起做。我一个月做不完，那我用两年时间行么?总有一天大家都会有统一的日志格式的。

如果你的研发能力有富余,或者有大数据团队支撑，那么可以将进入到SparkStreaming中的数据存储起来，然后通过SparkSQL等做即席查询。这样，有的时候原先没有考虑的指标，你可以直接基于日志做多维度分析。分析完了，你觉得好了，需要固化下来，那再去更新你的SparkStreaming程序。

后话

我做上面第一幅图架构实现时，从搭建到完成SparkStreaming程序开发，到数据最后进入HBase存储，大概只花了一天多的时间。当然为了完成那个Trace的指标分析，我修改ServiceFramework框架大约改了两三天。因为Trace分析确实比较复杂。当然还有一个比较消耗工作量的，是页面可视化，我这块自己还没有能力做，等招个Web开发工程师再说了。

End.

华为宣布开源了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李昆、陈亮。

FlameGraph

火焰图 ，简单通过x轴横条宽度来度量时间指标，y轴代表线程栈的层次，简单明了， 容易找出具体的可有化点，非常方便，当然前提是我们通过profiler工具获取到profiler 数据。

make BITS=64 all

-agentpath:path/to/liblagent.so[:file=name]