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]