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是一個(gè)用于大數(shù)據(jù)實(shí)時(shí)查詢和分析的高容錯(cuò)、高性能開源分布式系統(tǒng)，旨在快速處理大規(guī)模的數(shù)據(jù)，并能夠?qū)崿F(xiàn)快速查詢和分析。尤其是當(dāng)發(fā)生代碼部署、機(jī)器故障以及其他產(chǎn)品系統(tǒng)遇到宕機(jī)等情況時(shí)，Druid仍能夠保持100%正常運(yùn)行。創(chuàng)建Druid的最初意圖主要是為了解決查詢延遲問題，當(dāng)時(shí)試圖使用Hadoop來實(shí)現(xiàn)交互式查詢分析，但是很難滿足實(shí)時(shí)分析的需要。而Druid提供了以交互方式訪問數(shù)據(jù)的能力，并權(quán)衡了查詢的靈活性和性能而采取了特殊的存儲(chǔ)格式。

Druid功能介于PowerDrill和Dremel之間，它幾乎實(shí)現(xiàn)了Dremel的所有功能，并且從PowerDrill吸收一些有趣的數(shù)據(jù)格式。Druid允許以類似Dremel和PowerDrill的方式進(jìn)行單表查詢，同時(shí)還增加了一些新特性，如為局部嵌套數(shù)據(jù)結(jié)構(gòu)提供列式存儲(chǔ)格式、為快速過濾做索引、實(shí)時(shí)攝取和查詢、高容錯(cuò)的分布式體系架構(gòu)等。從官方得知，Druid的具有以下主要特征：

• 為分析而設(shè)計(jì)——Druid是為OLAP工作流的探索性分析而構(gòu)建，它支持各種過濾、聚合和查詢等類；
• 快速的交互式查詢——Druid的低延遲數(shù)據(jù)攝取架構(gòu)允許事件在它們創(chuàng)建后毫秒內(nèi)可被查詢到；
• 高可用性——Druid的數(shù)據(jù)在系統(tǒng)更新時(shí)依然可用，規(guī)模的擴(kuò)大和縮小都不會(huì)造成數(shù)據(jù)丟失；
• 可擴(kuò)展——Druid已實(shí)現(xiàn)每天能夠處理數(shù)十億事件和TB級(jí)數(shù)據(jù)。

Druid應(yīng)用最多的是類似于廣告分析創(chuàng)業(yè)公司Metamarkets中的應(yīng)用場(chǎng)景，如廣告分析、互聯(lián)網(wǎng)廣告系統(tǒng)監(jiān)控以及網(wǎng)絡(luò)監(jiān)控等。當(dāng)業(yè)務(wù)中出現(xiàn)以下情況時(shí)，Druid是一個(gè)很好的技術(shù)方案選擇：

• 需要交互式聚合和快速探究大量數(shù)據(jù)時(shí)；
• 需要實(shí)時(shí)查詢分析時(shí)；
• 具有大量數(shù)據(jù)時(shí)，如每天數(shù)億事件的新增、每天數(shù)10T數(shù)據(jù)的增加；
• 對(duì)數(shù)據(jù)尤其是大數(shù)據(jù)進(jìn)行實(shí)時(shí)分析時(shí)；
• 需要一個(gè)高可用、高容錯(cuò)、高性能數(shù)據(jù)庫(kù)時(shí)。

一個(gè)Druid集群有各種類型的節(jié)點(diǎn)（Node）組成，每個(gè)節(jié)點(diǎn)都可以很好的處理一些的事情，這些節(jié)點(diǎn)包括對(duì)非實(shí)時(shí)數(shù)據(jù)進(jìn)行處理存儲(chǔ)和查詢的Historical節(jié)點(diǎn)、實(shí)時(shí)攝取數(shù)據(jù)、監(jiān)聽輸入數(shù)據(jù)流的Realtime節(jié)、監(jiān)控Historical節(jié)點(diǎn)的Coordinator節(jié)點(diǎn)、接收來自外部客戶端的查詢和將查詢轉(zhuǎn)發(fā)到Realtime和Historical節(jié)點(diǎn)的Broker節(jié)點(diǎn)、負(fù)責(zé)索引服務(wù)的Indexer節(jié)點(diǎn)。

查詢操作中數(shù)據(jù)流和各個(gè)節(jié)點(diǎn)的關(guān)系如下圖所示：

如下圖是Druid集群的管理層架構(gòu)，該圖展示了相關(guān)節(jié)點(diǎn)和集群管理所依賴的其他組件（如負(fù)責(zé)服務(wù)發(fā)現(xiàn)的ZooKeeper集群）的關(guān)系：

Druid已基于Apache License 2.0協(xié)議開源，代碼托管在GitHub，其當(dāng)前最新穩(wěn)定版本是0.7.1.1。當(dāng)前，Druid已有63個(gè)代碼貢獻(xiàn)者和將近2000個(gè)關(guān)注。Druid的主要貢獻(xiàn)者包括廣告分析創(chuàng)業(yè)公司Metamarkets、電影流媒體網(wǎng)站Netflix、Yahoo等公司。Druid官方還對(duì)Druid同Shark、Vertica、Cassandra、Hadoop、Spark、Elasticsearch等在容錯(cuò)能力、靈活性、查詢性能等方便進(jìn)行了對(duì)比說明。更多關(guān)于Druid的信息，大家還可以參考官方提供的入門教程、白皮書、設(shè)計(jì)文檔等。

作者：祝威廉

• 工程數(shù)據(jù)，譬如工單數(shù)量，SLA可用性，基礎(chǔ)資源，故障率，報(bào)警統(tǒng)計(jì)
• 業(yè)務(wù)數(shù)據(jù)，譬如業(yè)務(wù)DashBoard,Trace調(diào)用鏈，業(yè)務(wù)拓?fù)淝袚Q，業(yè)務(wù)指標(biāo)，業(yè)務(wù)基準(zhǔn)數(shù)據(jù)，業(yè)務(wù)日志挖掘
• 數(shù)據(jù)可視化

當(dāng)然，這篇文章談的是運(yùn)維都有哪些數(shù)據(jù)，哪些指標(biāo)，以及數(shù)據(jù)呈現(xiàn)。并沒有談及如何和大數(shù)據(jù)相關(guān)的架構(gòu)做整合，從而能讓這些數(shù)據(jù)真的變得活起來。

比較湊巧的是，原先百度的桑文峰的分享也講到日志的多維度分析，吃完飯的時(shí)候，一位優(yōu)酷的朋友也和我探討了關(guān)于業(yè)務(wù)監(jiān)控的的問題。而我之前發(fā)表在肉餅鋪?zhàn)永锏囊黄恼隆?大數(shù)據(jù)給公司帶來了什么 》也特地提到了大數(shù)據(jù)對(duì)于整個(gè)運(yùn)維的幫助，當(dāng)時(shí)因?yàn)檫@篇內(nèi)容的主旨是羅列大數(shù)據(jù)的用處，自然沒法細(xì)講運(yùn)維和大數(shù)據(jù)的整合這一塊。

上面的文字算引子，在步入正式的探討前，有一點(diǎn)我覺得值得強(qiáng)調(diào)：

雖然這里講的是如何將大數(shù)據(jù)思維/架構(gòu)應(yīng)用于運(yùn)維，平臺(tái)化運(yùn)維工作，但是和大數(shù)據(jù)本質(zhì)上沒有關(guān)系，我們只是將大數(shù)據(jù)處理的方式和思想應(yīng)用在運(yùn)維工作上。所以，即使你現(xiàn)在所在的公司沒有數(shù)據(jù)團(tuán)隊(duì)支撐，也是完全可以通過現(xiàn)有團(tuán)隊(duì)完成這件事情的。

1 運(yùn)維監(jiān)控現(xiàn)狀

很多公司的運(yùn)維的監(jiān)控具有如下特質(zhì)：

只能監(jiān)控基礎(chǔ)運(yùn)維層次，通過zabbix等工具提供服務(wù)器,CPU,內(nèi)存等相關(guān)的監(jiān)控。這部分重要，但確實(shí)不是運(yùn)維的核心。

對(duì)業(yè)務(wù)的監(jiān)控是最復(fù)雜的，而現(xiàn)在很多公司的要么還處于Shell腳本的刀耕火種階段，要么開發(fā)能力較強(qiáng)，但是還是東一榔頭西一棒子，不同的業(yè)務(wù)需要不同的監(jiān)控系統(tǒng)，人人都可以根據(jù)的自己的想法開發(fā)一個(gè)監(jiān)控的工具也好，系統(tǒng)也好，平臺(tái)也好?？傊潜容^凌亂的。

使用第三方的監(jiān)控平臺(tái)。這個(gè)似乎在Rails/NodeJS/Pythone相關(guān)語系開發(fā)的產(chǎn)品中比較常見。我不做過多評(píng)價(jià)，使用后冷暖自知。

當(dāng)然也有抽象得很好的，比如點(diǎn)評(píng)網(wǎng)的運(yùn)維監(jiān)控?fù)?jù)說就做得相當(dāng)好，運(yùn)維很閑，天天沒事就根據(jù)自己的監(jiān)控找開發(fā)的茬，讓開發(fā)持續(xù)改進(jìn)。不過他們的指導(dǎo)思想主要有兩個(gè)：

運(yùn)維自動(dòng)化。怎么能夠?qū)崿F(xiàn)這個(gè)目標(biāo)就怎么搞，這嚴(yán)重依賴于搞的人的規(guī)劃能力和經(jīng)驗(yàn)。

抽象化，根據(jù)實(shí)際面臨的問題做出抽象，得到對(duì)應(yīng)的系統(tǒng)，比如需要發(fā)布，于是又發(fā)布系統(tǒng)，需要管理配置文件，所以有配管系統(tǒng)，需要日志分析所以有了有日志分析系統(tǒng)。然而這樣是比較零散的。

有點(diǎn)扯遠(yuǎn)，我們還是focus在監(jiān)控上。

如果以大數(shù)據(jù)的思維去思考，我們應(yīng)該如何做好監(jiān)控這件事情?

2 羅列出你的數(shù)據(jù)源

《大數(shù)據(jù)對(duì)于運(yùn)維的意義》這篇文章也講了，主要有工程數(shù)據(jù)，業(yè)務(wù)數(shù)據(jù)。所有的數(shù)據(jù)源都有一個(gè)共性，就是 日志 。無論文本的也好，二進(jìn)制的也好。所以日志是整個(gè)信息的源頭。日志包含的信息足以讓我們追查到下面幾件事情：

• 系統(tǒng)健康狀況監(jiān)控
• 查找故障根源
• 系統(tǒng)瓶頸診斷和調(diào)優(yōu)
• 追蹤安全相關(guān)問題
• 從日志我們可以挖掘出什么?

我覺得抽象起來就一個(gè)： 指標(biāo) 。

指標(biāo)可以再進(jìn)行分類：

業(yè)務(wù)層面，如團(tuán)購(gòu)業(yè)務(wù)每秒訪問數(shù)，團(tuán)購(gòu)券每秒驗(yàn)券數(shù)，每分鐘支付、創(chuàng)建訂單等

應(yīng)用層面，每個(gè)應(yīng)用的錯(cuò)誤數(shù)，調(diào)用過程，訪問的平均耗時(shí)，最大耗時(shí)，95線等

系統(tǒng)資源層面：如cpu、內(nèi)存、swap、磁盤、load、主進(jìn)程存活等

網(wǎng)絡(luò)層面： 如丟包、ping存活、流量、tcp連接數(shù)等

每個(gè)分類里的每個(gè)小點(diǎn)其實(shí)都是一個(gè)指標(biāo)。

3 如何統(tǒng)一實(shí)現(xiàn)

千萬不要針對(duì)具體問題進(jìn)行解決，大數(shù)據(jù)架構(gòu)上的一個(gè)思維就是：我能夠提供一個(gè)平臺(tái)讓大家方便解決這些問題么? 而不是，這個(gè)問題我能解決么?

先來看看架構(gòu)圖：

• 推薦
• 搜索
• 統(tǒng)一查詢引擎

所以監(jiān)控的架構(gòu)設(shè)計(jì)略簡(jiǎn)單些。如果你希望進(jìn)行日志存儲(chǔ)以及事后批量分析，則可以采用淘寶的這套架構(gòu)方式：

將日志過濾，格式化，或存儲(chǔ)起來

進(jìn)行實(shí)時(shí)計(jì)算，將指標(biāo)數(shù)據(jù)存儲(chǔ)到HBase里去

到目前為止，我們沒有做任何的開發(fā)，全部使用大數(shù)據(jù)里通用的一些組件。至于這些組件需要多少服務(wù)器，就看對(duì)應(yīng)的日志量規(guī)模了，三五臺(tái)到幾百臺(tái)都是可以的。

需要開發(fā)的地方只有兩個(gè)點(diǎn)，有一個(gè)是一次性的，有一個(gè)則是長(zhǎng)期。

先說說一次性的，其實(shí)就是大盤展示系統(tǒng)。這個(gè)就是從HBase里取出數(shù)據(jù)做展示。這個(gè)貌似也有開源的一套，ELK。不過底層不是用的HBase存儲(chǔ)，而是ES。這里就不詳細(xì)討論。

長(zhǎng)期的則是SparkStreaming(淘寶是使用Storm，我建議用SparkStreaming,因?yàn)镾parkStreaming可以按時(shí)間窗口，也可以按量統(tǒng)一做計(jì)算)，這里你需要定義日志的處理邏輯，生成我上面提到的各項(xiàng)指標(biāo)。

這里有一個(gè)什么好處呢，就是平臺(tái)化了，對(duì)新的監(jiān)控需求響應(yīng)更快了，開發(fā)到上線可能只要幾個(gè)小時(shí)的功夫。如果某個(gè)系統(tǒng)某天需要一個(gè)新的監(jiān)控指標(biāo)，我們只要開發(fā)個(gè)SparkStreaming程序，丟到平臺(tái)里去，這事就算完了。

第一幅圖的平臺(tái)我是已經(jīng)實(shí)現(xiàn)了的。我目前在SparkStreaming上只做了三個(gè)方面比較基礎(chǔ)的監(jiān)控，不過應(yīng)該夠用了。

狀態(tài)碼大盤。 HTTP響應(yīng)碼的URL(去掉query參數(shù))排行榜。比如你打開頁面就可以看到發(fā)生500錯(cuò)誤的top100的URL，以及該URL所歸屬的系統(tǒng)。

響應(yīng)耗時(shí)大盤。 URL請(qǐng)求耗時(shí)排行榜。比如你打開頁面就可以看到5分鐘內(nèi)平均響應(yīng)耗時(shí)top100的URL(去掉query參數(shù))。

還有就是Trace系統(tǒng)。 類似Google的Dapper,淘寶的EagleEye。給出一個(gè)唯一的UUID,可以追蹤到特定一個(gè)Request的請(qǐng)求鏈路。每個(gè)依賴服務(wù)的響應(yīng)情況，比如響應(yīng)時(shí)間。對(duì)于一個(gè)由幾個(gè)甚至幾百個(gè)服務(wù)組成的大系統(tǒng)，意義非常大，可以方便的定位出到底是那個(gè)系統(tǒng)的哪個(gè)API的問題。這個(gè)最大的難點(diǎn)是需要統(tǒng)一底層的RPC/HTTP調(diào)用框架，進(jìn)行埋點(diǎn)。因?yàn)槲沂褂玫氖亲匝械腟erviceFramework框架，通訊埋點(diǎn)就比較簡(jiǎn)單。如果是在一個(gè)業(yè)務(wù)線復(fù)雜，各個(gè)系統(tǒng)使用不同技術(shù)開發(fā)，想要做這塊就要做好心理準(zhǔn)備了。

現(xiàn)在，如果你想要監(jiān)控一個(gè)系統(tǒng)是不是存活，你不在需要取寫腳本去找他的pid看進(jìn)程是不是存在，系統(tǒng)發(fā)現(xiàn)在一定的周期內(nèi)沒有日志，就可以認(rèn)為它死了。而系統(tǒng)如果有異常，比如有大量的慢查詢，大盤一定能展示出來。

描述到這，我們可以看到，這套架構(gòu)的優(yōu)勢(shì)在哪：

基本上沒有需要自己開發(fā)的系統(tǒng)。從日志收集，到日志存儲(chǔ)，到結(jié)果存儲(chǔ)等，統(tǒng)統(tǒng)都是現(xiàn)成的組件。

可擴(kuò)展性好。每個(gè)組件都是集群模式的，沒有單點(diǎn)故障。每個(gè)組件都是可水平擴(kuò)展的，日志量大了，加機(jī)器就好。

開發(fā)更集中了。你只要關(guān)注日志實(shí)際的分析處理，提煉指標(biāo)即可。

4 大數(shù)據(jù)思維

對(duì)于運(yùn)維的監(jiān)控，利用大數(shù)據(jù)思維，需要分三步走：

• 找到數(shù)據(jù)
• 分析定義從數(shù)據(jù)里中我能得到什么
• 從大數(shù)據(jù)平臺(tái)中挑選你要的組件完成搭積木式開發(fā)

所有系統(tǒng)最可靠的就是日志輸出，系統(tǒng)是不是正常，發(fā)生了什么情況，我們以前是出了問題去查日志，或者自己寫個(gè)腳本定時(shí)去分析?，F(xiàn)在這些事情都可以整合到一個(gè)已有的平臺(tái)上，我們唯一要做的就是 定義處理日志的的邏輯 。

這里有幾點(diǎn)注意的：

如果你擁有復(fù)雜的產(chǎn)品線，那么日志格式會(huì)是一個(gè)很痛苦的事情。以為這中間Storm(或者SparkStreaming)的處理環(huán)節(jié)你需要做大量的兼容適配。我個(gè)人的意見是，第一，沒有其他更好的辦理，去兼容適配吧，第二，推動(dòng)大家統(tǒng)一日志格式。兩件事情一起做。我一個(gè)月做不完，那我用兩年時(shí)間行么?總有一天大家都會(huì)有統(tǒng)一的日志格式的。

如果你的研發(fā)能力有富余,或者有大數(shù)據(jù)團(tuán)隊(duì)支撐，那么可以將進(jìn)入到SparkStreaming中的數(shù)據(jù)存儲(chǔ)起來，然后通過SparkSQL等做即席查詢。這樣，有的時(shí)候原先沒有考慮的指標(biāo)，你可以直接基于日志做多維度分析。分析完了，你覺得好了，需要固化下來，那再去更新你的SparkStreaming程序。

后話

我做上面第一幅圖架構(gòu)實(shí)現(xiàn)時(shí)，從搭建到完成SparkStreaming程序開發(fā)，到數(shù)據(jù)最后進(jìn)入HBase存儲(chǔ)，大概只花了一天多的時(shí)間。當(dāng)然為了完成那個(gè)Trace的指標(biāo)分析，我修改ServiceFramework框架大約改了兩三天。因?yàn)門race分析確實(shí)比較復(fù)雜。當(dāng)然還有一個(gè)比較消耗工作量的，是頁面可視化，我這塊自己還沒有能力做，等招個(gè)Web開發(fā)工程師再說了。

End.

華為宣布開源了CarbonData項(xiàng)目，該項(xiàng)目于6月3日通過Apache社區(qū)投票，成功進(jìn)入Apache孵化器。CarbonData是一種低時(shí)延查詢、存儲(chǔ)和計(jì)算分離的輕量化文件存儲(chǔ)格式。那么相比SQL on Hadoop方案、傳統(tǒng)NoSQL或相對(duì)ElasticSearch等搜索系統(tǒng)，CarbonData具有什么樣的優(yōu)勢(shì)呢？CarbonData的技術(shù)架構(gòu)是什么樣子的？未來有什么樣的規(guī)劃？我們采訪了CarbonData項(xiàng)目的技術(shù)負(fù)責(zé)人為大家解惑。

InfoQ：請(qǐng)問CarbonData是什么時(shí)候開始進(jìn)行的項(xiàng)目？為什么現(xiàn)在向Apache孵化器開源呢？開源發(fā)展歷程和項(xiàng)目目前狀態(tài)是怎么樣的？

CarbonData：CarbonData項(xiàng)目是華為公司從多年數(shù)據(jù)處理經(jīng)驗(yàn)和行業(yè)理解中逐步積累起來的，2015年我們對(duì)系統(tǒng)進(jìn)行了一次架構(gòu)重構(gòu)，使其演化為HDFS上的一套通用的列式存儲(chǔ)，支持和Spark引擎對(duì)接后形成一套分布式OLAP分析的解決方案。

華為一直是面向電信、金融、IT企業(yè)等用戶提供大數(shù)據(jù)平臺(tái)解決方案的供應(yīng)商，從眾多客戶場(chǎng)景中我們不斷提煉數(shù)據(jù)特征，總結(jié)出了一些典型的對(duì)大數(shù)據(jù)分析的訴求，逐步形成了CarbonData這個(gè)架構(gòu)。

因?yàn)樵贗T領(lǐng)域，只有開源開放，才能最終讓更多的客戶和合作伙伴的數(shù)據(jù)連接在一起，產(chǎn)生更大商業(yè)價(jià)值。開源是為了構(gòu)建E2E生態(tài)，CarbonData是數(shù)據(jù)存儲(chǔ)層技術(shù)，要發(fā)揮價(jià)值，需要與計(jì)算層、查詢層有效集成在一起，形成完成真正的生態(tài)發(fā)揮價(jià)值。

又因?yàn)锳pache是目前大數(shù)據(jù)領(lǐng)域最權(quán)威的開源組織，其中的Hadoop，Spark已成為大數(shù)據(jù)開源的事實(shí)標(biāo)準(zhǔn)，我們也非常認(rèn)可Apache以Community驅(qū)動(dòng)技術(shù)進(jìn)步的理念，所以我們選擇進(jìn)入Apache，與社區(qū)一同構(gòu)建能力，使CarbonData融入大數(shù)據(jù)生態(tài)。

目前CarbonData開源項(xiàng)目已經(jīng)在6月3日通過Apache社區(qū)投票，成功進(jìn)入Apache孵化器。github地址：https://github.com/apache/incubator-carbondata。歡迎大家參與到Apache CarbonData社區(qū)： https://github.com/apache/incubator-carbondata/blob/master/docs/How-to-contribute-to-Apache-CarbonData.md。

InfoQ：請(qǐng)問是什么原因或機(jī)遇促使您們產(chǎn)生做CarbonData這個(gè)項(xiàng)目的想法的？之前的項(xiàng)目中遇到什么樣的困難？

CarbonData：我們一直面臨著很多高性能數(shù)據(jù)分析訴求，在傳統(tǒng)的做法里，一般是使用數(shù)據(jù)庫(kù)加BI工具實(shí)現(xiàn)報(bào)表、DashBoard和交互式查詢等業(yè)務(wù)，但隨著企業(yè)數(shù)據(jù)日益增大，業(yè)務(wù)驅(qū)動(dòng)的分析靈活性要求逐漸增大，也有部分客戶希望有除SQL外更強(qiáng)大的分析功能，所以傳統(tǒng)的方式漸漸滿足不了客戶需求，讓我們產(chǎn)生了做CarbonData這個(gè)項(xiàng)目的想法。

需求一般來源于幾方面。

第一，在部署上，區(qū)別于以往的單機(jī)系統(tǒng)，企業(yè)客戶希望有一套分布式方案來應(yīng)對(duì)日益增多的數(shù)據(jù)，隨時(shí)可以通過增加通用服務(wù)器的方式scale out橫向擴(kuò)展。

第二，在業(yè)務(wù)功能上，很多企業(yè)的業(yè)務(wù)都處在從傳統(tǒng)數(shù)據(jù)庫(kù)逐漸轉(zhuǎn)移到大數(shù)據(jù)平臺(tái)的遷移過程中，這就要求大數(shù)據(jù)平臺(tái)要有較高兼容老業(yè)務(wù)的能力，這里面主要包含的是對(duì)完整的標(biāo)準(zhǔn)SQL支持，以及多種分析場(chǎng)景的支持。同時(shí)為了節(jié)約成本，企業(yè)希望“一份數(shù)據(jù)支持多種使用場(chǎng)景”，例如大規(guī)模掃描和計(jì)算的批處理場(chǎng)景，OLAP多維交互式分析場(chǎng)景，明細(xì)數(shù)據(jù)即席查詢，主鍵低時(shí)延點(diǎn)查，以及對(duì)實(shí)時(shí)數(shù)據(jù)的實(shí)時(shí)查詢等場(chǎng)景，都希望平臺(tái)能給予支持，且達(dá)到秒級(jí)查詢響應(yīng)。

第三，在易用性上，企業(yè)客戶以往使用BI工具，業(yè)務(wù)分析的OLAP模型是需要在BI工具中建立的，這就會(huì)導(dǎo)致有的場(chǎng)景下數(shù)據(jù)模型的靈活性和分析手段受到限制，而在大數(shù)據(jù)時(shí)代，大數(shù)據(jù)開源領(lǐng)域已經(jīng)形成了一個(gè)生態(tài)系統(tǒng)，社區(qū)隨時(shí)都在進(jìn)步，經(jīng)常會(huì)冒出一些新型的分析工具，所以企業(yè)客戶都希望能跟隨社區(qū)不斷改進(jìn)自己的系統(tǒng)，在自己的數(shù)據(jù)里快速用上新型的分析工具，得到更大的商業(yè)價(jià)值。

要同時(shí)達(dá)到上訴要求，無疑對(duì)大數(shù)據(jù)平臺(tái)是一個(gè)很大的挑戰(zhàn)。為了滿足這些要求，我們開始不斷在實(shí)際項(xiàng)目中積累經(jīng)驗(yàn)，也嘗試了很多不同的解決方案，但都沒有發(fā)現(xiàn)能用一套方案解決所有問題。

大家首先會(huì)想到的是，在涉及到低時(shí)延查詢的分布式存儲(chǔ)中，一般常用的是KV型NoSQL數(shù)據(jù)庫(kù)（如HBase，Cassandra），可以解決主鍵低時(shí)延查詢的問題，但如果業(yè)務(wù)的查詢模式稍作改變，例如對(duì)多維度靈活組合的查詢，就會(huì)使點(diǎn)查變?yōu)槿頀呙?，使性能急劇下降。有的?chǎng)景下，這時(shí)可以通過加入二級(jí)索引來緩解該問題，但這又帶來了二級(jí)索引的維護(hù)和同步等管理問題，所以KV型存儲(chǔ)并不是解決企業(yè)問題的通用方案。

那么，如果要解決通用的多維查詢問題，有時(shí)我們會(huì)想到用多維時(shí)序數(shù)據(jù)庫(kù)的方案（如Linkedin Pinot），他們的特點(diǎn)是數(shù)據(jù)都以時(shí)間序列的方式進(jìn)入系統(tǒng)并經(jīng)過數(shù)據(jù)預(yù)聚合和建立索引，因?yàn)槭穷A(yù)計(jì)算，所以應(yīng)對(duì)多維查詢時(shí)非?？?，數(shù)據(jù)也非常及時(shí)，同時(shí)具備多維分析和實(shí)時(shí)處理的優(yōu)點(diǎn)，在性能監(jiān)控、實(shí)時(shí)指標(biāo)分析的場(chǎng)景里應(yīng)用較多。但它在支持的查詢類型上也有一定限制，因?yàn)樽隽藬?shù)據(jù)預(yù)計(jì)算，所以這種架構(gòu)一般無法應(yīng)對(duì)明細(xì)數(shù)據(jù)查詢，以及不支持Join多表關(guān)聯(lián)分析，這無疑給企業(yè)使用場(chǎng)景帶來了一定的限制。

另外一類是搜索系統(tǒng)（如Apache Solr，ElasticSearch），搜索系統(tǒng)可以做多維匯總也可以查詢明細(xì)數(shù)據(jù)，它也具備基于倒排索引的快速布爾查詢，并發(fā)也較高，似乎正是我們希望尋找的方案。但在實(shí)際應(yīng)用中我們發(fā)現(xiàn)兩個(gè)問題：一是由于搜索系統(tǒng)一般是針對(duì)非結(jié)構(gòu)化數(shù)據(jù)而設(shè)計(jì)的，系統(tǒng)的數(shù)據(jù)膨脹率一般都比較高，在企業(yè)關(guān)系型數(shù)據(jù)模型下數(shù)據(jù)存儲(chǔ)不夠緊湊，造成數(shù)據(jù)量較大，二是搜索系統(tǒng)的數(shù)據(jù)組織方式和計(jì)算引擎密切相關(guān)，這就導(dǎo)致了數(shù)據(jù)入庫(kù)后只能用相應(yīng)的搜索引擎處理，這又一定程度打破了企業(yè)客戶希望應(yīng)用多種社區(qū)分析工具的初衷，所以搜索系統(tǒng)也有他自己的適用場(chǎng)景。

最后一類系統(tǒng)，就是目前社區(qū)里大量涌現(xiàn)的SQL on Hadoop方案，以Hive, SparkSQL, Flink為代表，這類系統(tǒng)的特點(diǎn)是計(jì)算和存儲(chǔ)相分離，針對(duì)存儲(chǔ)在HDFS上的文件提供標(biāo)準(zhǔn)SQL功能，他們?cè)诓渴鹦院鸵子眯陨峡梢詽M足企業(yè)客戶需求，業(yè)務(wù)場(chǎng)景上也能覆蓋掃描，匯聚，詳單等各類場(chǎng)景，可見可以將他們視為一類通用的解決方案。為了提高性能，Spark，F(xiàn)link等開源項(xiàng)目通過不斷優(yōu)化自身架構(gòu)提升計(jì)算性能，但提升重點(diǎn)都放在計(jì)算引擎和SQL優(yōu)化器的增強(qiáng)上，在存儲(chǔ)和數(shù)據(jù)組織上改進(jìn)并不是重點(diǎn)。

所以，可以看出當(dāng)前的很多大數(shù)據(jù)系統(tǒng)雖然都能支持各類查詢場(chǎng)景，但他們都是偏向某一類場(chǎng)景設(shè)計(jì)的，在不是其目標(biāo)場(chǎng)景的情況下要么不支持要么退化為全表掃描，所以導(dǎo)致企業(yè)為了應(yīng)對(duì)批處理，多維分析，明細(xì)數(shù)據(jù)查詢等場(chǎng)景，客戶常常需要通過復(fù)制多份數(shù)據(jù)，每種場(chǎng)景要維護(hù)一套數(shù)據(jù)。

CarbonData的設(shè)計(jì)初衷正是為了打破這種限制，做到只保存一份數(shù)據(jù)，最優(yōu)化地支撐多種使用場(chǎng)景。

InfoQ:能否具體談?wù)凜arbonData的技術(shù)架構(gòu)？有何特征和優(yōu)勢(shì)呢？

CarbonData：整個(gè)大數(shù)據(jù)時(shí)代的開啟，可以說是源自于Google的MapReduce論文，他引發(fā)了Hadoop開源項(xiàng)目以及后續(xù)一系列的生態(tài)發(fā)展。他的“偉大”之處在于計(jì)算和存儲(chǔ)解耦的架構(gòu)，使企業(yè)的部分業(yè)務(wù)（主要是批處理）從傳統(tǒng)的垂直方案中解放出來，計(jì)算和存儲(chǔ)可以按需擴(kuò)展極大提升了業(yè)務(wù)發(fā)展的敏捷性，讓眾多企業(yè)普及了這一計(jì)算模式，從中受益。

雖然MapReduce開啟了大數(shù)據(jù)時(shí)代，但它是通過純粹的暴力掃描+分布式計(jì)算來提升批處理性能，所以并不能解決客戶對(duì)所有查詢場(chǎng)景的低時(shí)延查詢要求。

在目前的生態(tài)中，最接近于客戶要求的其實(shí)是搜索引擎類方案。通過良好的數(shù)據(jù)組織和索引，搜索引擎能提供多種快速的查詢功能，但偏偏搜索引擎的存儲(chǔ)層又和計(jì)算引擎是緊耦合的，并不符合企業(yè)對(duì)”一份數(shù)據(jù)，多種場(chǎng)景”的期望。

這給了我們啟發(fā)，我們何不為通用計(jì)算引擎打造更一個(gè)高效的數(shù)據(jù)組織來滿足客戶需求呢，做到既利用計(jì)算和存儲(chǔ)解耦架構(gòu)又能提供高性能查詢。抱著這個(gè)想法，我們啟動(dòng)了CarbonData項(xiàng)目。針對(duì)更多的業(yè)務(wù)，使計(jì)算和存儲(chǔ)相分離，這也成了CarbonData的架構(gòu)設(shè)計(jì)理念。

確立了這個(gè)理念后，我們很自然地選擇了基于HDFS+通用計(jì)算引擎的架構(gòu)，因?yàn)檫@個(gè)架構(gòu)可以很好地提供Scale out能力。下一步我們問自己這個(gè)架構(gòu)里還缺什么？這個(gè)架構(gòu)中，HDFS提供文件的復(fù)制和讀寫能力，計(jì)算引擎負(fù)責(zé)讀取文件和分布式計(jì)算，分工很明確，可以說他們分別定位于解決存儲(chǔ)管理和計(jì)算的問題。但不難看出，為了適應(yīng)更多場(chǎng)景，HDFS做了很大的“犧牲”，它犧牲了對(duì)文件內(nèi)容的理解，正是由于放棄了對(duì)文件內(nèi)容的理解，導(dǎo)致計(jì)算只能通過全掃描的方式來進(jìn)行，可以說最終導(dǎo)致的是存儲(chǔ)和計(jì)算都無法很好的利用數(shù)據(jù)特征來做優(yōu)化。

所以針對(duì)這個(gè)問題，我們把CarbonData的發(fā)力重點(diǎn)放在對(duì)數(shù)據(jù)組織的優(yōu)化上，通過數(shù)據(jù)組織最終是要提升IO性能和計(jì)算性能。為此，CarbonData做了如下工作。

CarbonData基礎(chǔ)特性

1. 多維數(shù)據(jù)聚集：在入庫(kù)時(shí)對(duì)數(shù)據(jù)按多個(gè)維度進(jìn)行重新組織，使數(shù)據(jù)在“多維空間上更內(nèi)聚”，在存儲(chǔ)上獲得更好的壓縮率，在計(jì)算上獲得更好的數(shù)據(jù)過濾效率。

2. 帶索引的列存文件結(jié)構(gòu)：首先，CarbonData為多類場(chǎng)景設(shè)計(jì)了多個(gè)級(jí)別的索引，并融入了一些搜索的特性，有跨文件的多維索引，文件內(nèi)的多維索引，每列的minmax索引，以及列內(nèi)的倒排索引等。其次，為了適應(yīng)HDFS的存儲(chǔ)特點(diǎn)，CarbonData的索引和數(shù)據(jù)文件存放在一起，一部分索引本身就是數(shù)據(jù)，另一部分索引存放在文件的元數(shù)據(jù)結(jié)構(gòu)中，他們都能隨HDFS提供本地化的訪問能力。

3. 列組：整體上，CarbonData是一種列存結(jié)構(gòu)，但相對(duì)于行存來說，列存結(jié)構(gòu)在應(yīng)對(duì)明細(xì)數(shù)據(jù)查詢時(shí)會(huì)有數(shù)據(jù)還原代價(jià)高的問題，所以為了提升明顯數(shù)據(jù)查詢性能，CarbonData支持列組的存儲(chǔ)方式，用戶可以把某些不常作為過濾條件但又需要作為結(jié)果集返回的字段作為列組來存儲(chǔ)，經(jīng)過CarbonData編碼后會(huì)將這些字段使用行存的方式來存儲(chǔ)以提升查詢性能。

4. 數(shù)據(jù)類型：目前CarbonData支持所有數(shù)據(jù)庫(kù)的常用基本類型，以及Array，Struct復(fù)雜嵌套類型。同時(shí)社區(qū)也有人提出支持Map數(shù)據(jù)類型，我們計(jì)劃未來添加Map數(shù)據(jù)類型。

5. 壓縮：目前CarbonData支持Snappy壓縮，壓縮是針對(duì)每列分別進(jìn)行的，因?yàn)榱写娴奶攸c(diǎn)使得壓縮非常高效。數(shù)據(jù)壓縮率基于應(yīng)用場(chǎng)景不同一般在2到8之間。

6. Hadoop集成：通過支持InputFormat/OutputFormat接口，CarbonData可以利用Hadoop的分布式優(yōu)點(diǎn)，也能在所有以Hadoop為基礎(chǔ)的生態(tài)系統(tǒng)中使用。

CarbonData高級(jí)特性

1. 可計(jì)算的編碼方式：除了常見的Delta，RLE，Dictionary，BitPacking等編碼方式外，CarbonData還支持將多列進(jìn)行聯(lián)合編碼，以及應(yīng)用了全局字典編碼來實(shí)現(xiàn)免解碼的計(jì)算，計(jì)算框架可以直接使用經(jīng)過編碼的數(shù)據(jù)來做聚合，排序等計(jì)算，這對(duì)需要大量shuffle的查詢來說性能提升非常明顯。

2. 與計(jì)算引擎聯(lián)合優(yōu)化：為了高效利用CarbonData經(jīng)過優(yōu)化后的數(shù)據(jù)組織，CarbonData提供了有針對(duì)性的優(yōu)化策略，目前CarbonData社區(qū)首先做了和Spark的深度集成，其中基于SparkSQL框架增強(qiáng)了過濾下壓，延遲物化，增量入庫(kù)等特性，同時(shí)支持所有DataFrame API。相信未來通過社區(qū)的努力，會(huì)有更多的計(jì)算框架與CarbonData集成，發(fā)揮數(shù)據(jù)組織的價(jià)值。

目前這些特性都已經(jīng)合入Apache CarbonData主干，歡迎大家使用。

InfoQ：在哪些場(chǎng)景推薦使用呢？性能測(cè)試結(jié)果如何？有沒有應(yīng)用案例，目前在國(guó)內(nèi)的使用情況和用戶規(guī)模？

CarbonData：推薦場(chǎng)景：希望一份存儲(chǔ)同時(shí)滿足快速掃描，多維分析，明細(xì)數(shù)據(jù)查詢的場(chǎng)景。在華為的客戶使用案例中，對(duì)比業(yè)界已有的列存方案，CarbonData可以帶來5~30倍性能提升。

性能測(cè)試數(shù)據(jù)及應(yīng)用案例等更多信息，請(qǐng)關(guān)注微信公眾號(hào)ApacheCarbonData，及社區(qū)https://github.com/apache/incubator-carbondata。

InfoQ：CarbonData能和當(dāng)前正火的Spark完美結(jié)合嗎？還能兼容哪些主流框架呢？

CarbonData：目前CarbonData已與Spark做了深度集成，具體見上述高級(jí)特性。

InfoQ：您們的項(xiàng)目在未來有什么樣的發(fā)展規(guī)劃？還會(huì)增加什么功能嗎？如何保證開源之后的項(xiàng)目的持續(xù)維護(hù)工作呢？

CarbonData：接下來社區(qū)重點(diǎn)工作是，提升系統(tǒng)易用性、完善生態(tài)集成（如：與Flink,Kafka等集成，實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)導(dǎo)入CarbonData）。

CarbonData開源的第一個(gè)月，就有幾百個(gè)commits提交，和20多個(gè)貢獻(xiàn)者參與，所以后續(xù)這個(gè)項(xiàng)目會(huì)持續(xù)的活躍。10多個(gè)核心貢獻(xiàn)者也將會(huì)持續(xù)參與社區(qū)建設(shè)。

InfoQ：在CarbonData設(shè)計(jì)研發(fā)并進(jìn)入Apache孵化器的過程中，經(jīng)歷了哪些階段，經(jīng)歷過的最大困難是什么？有什么樣的感受或經(jīng)驗(yàn)可以和大家分享的嗎？

CarbonData：CarbonData團(tuán)隊(duì)大多數(shù)人都有參與Apache Hadoop、Spark等社區(qū)開發(fā)的經(jīng)驗(yàn)，我們對(duì)社區(qū)流程和工作方式都很熟悉。最大的困難是進(jìn)入孵化器階段，去說服Apache社區(qū)接納大數(shù)據(jù)生態(tài)新的高性能數(shù)據(jù)格式CarbonData。我們通過5月份在美國(guó)奧斯丁的開源盛會(huì)OSCON上，做CarbonData技術(shù)主題演講和現(xiàn)場(chǎng)DEMO演示，展示了CarbonData優(yōu)秀的架構(gòu)和良好的性能效果。

InfoQ：您們是一個(gè)團(tuán)隊(duì)嗎？如何保證您們團(tuán)隊(duì)的優(yōu)秀成長(zhǎng)？

CarbonData：CarbonData團(tuán)隊(duì)是一個(gè)全球化的（工程師來自中國(guó)、美國(guó)、印度）團(tuán)隊(duì)，這種全球化工作模式的經(jīng)驗(yàn)積累，讓我們能快速的適應(yīng)Apache開源社區(qū)工作模式。

采訪嘉賓：Apache CarbonData的PMC、Committers李昆、陳亮。

FlameGraph

火焰圖 ，簡(jiǎn)單通過x軸橫條寬度來度量時(shí)間指標(biāo)，y軸代表線程棧的層次，簡(jiǎn)單明了， 容易找出具體的可有化點(diǎn)，非常方便，當(dāng)然前提是我們通過profiler工具獲取到profiler 數(shù)據(jù)。

make BITS=64 all

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