2014年，Spark開源生態(tài)系統(tǒng)得到了大幅增長，已成為大數(shù)據(jù)領(lǐng)域最人氣的開源項目之一，活躍在Hortonworks、IBM、Cloudera、MapR和Pivotal等眾多知名大數(shù)據(jù)公司，更擁有Spark SQL、Spark Streaming、MLlib、GraphX等多個相關(guān)項目。同時值得一提的是，Spark貢獻(xiàn)者中有一半左右的中國人。

　　短短四年時間，Spark不僅發(fā)展為Apache基金會的頂級開源項目，更通過其高性能內(nèi)存計算及其豐富的生態(tài)快速贏得幾乎所有大數(shù)據(jù)處理用戶。2015年1月10日，一場基于Spark的高性能應(yīng)用實踐盛宴由Databricks軟件工程師連城、百度高級工程師甄鵬、百度架構(gòu)師孫垚光、百度美國研發(fā)中心高級架構(gòu)師劉少山四位專家聯(lián)手打造。

　　Databricks軟件工程師連城——Spark SQL 1.2的提升和新特性

　　談及Spark SQL 1.2的提升和新特性，連城主要總結(jié)了4個方面——External data source API（外部數(shù)據(jù)源API）、列式內(nèi)存存儲加強（Enhanced in-memory columnar storage）、Parquet支持加強（Enhanced Parquet support）和Hive支持加強（Enhanced Hive support）。

　　External data source API

　　連城表示，因為在處理很多外部數(shù)據(jù)源中出現(xiàn)的擴展問題，Spark在1.2版本發(fā)布了External data source API。通過External data source API，Spark將不同的外部數(shù)據(jù)源抽象成一個關(guān)系表格，從而實現(xiàn)更貼近無縫的操作。

　　External data source API在支持了多種如JSON、Avro、CSV等簡單格式的同時，還實現(xiàn)了Parquet、ORC等的智能支持；同時，通過這個API，開發(fā)者還可以使用JDBC將HBase這樣的外部系統(tǒng)對接到Spark中。

　　連城表示，在1.2版本之前，開發(fā)者其實已經(jīng)實現(xiàn)了各種各樣外部數(shù)據(jù)源的支持，因此，對比更原生的支持一些外部數(shù)據(jù)源，External data source API的意義更在于針對相應(yīng)數(shù)據(jù)源進(jìn)行的特殊優(yōu)化，主要包括Column pruning（列剪枝）和Pushing predicates to datasources（將predicates貼近數(shù)據(jù)源）兩個方面：

　　Column pruning。主要包括縱橫的兩種剪枝。在列剪枝中，Column pruning可以完全忽視無需處理的字段，從而顯著地減少IO。同時，在某些條件查詢中，基于Parquet、ORC等智能格式寫入時記錄的統(tǒng)計信息（比如最大值、最小值等），掃描可以跳過大段的數(shù)據(jù)，從而省略了大量的磁盤掃描負(fù)載。

　　Pushing predicates to datasources。在更復(fù)雜的SQL查詢中，讓過濾條件維度盡可能的接近數(shù)據(jù)源，從而減少磁盤和網(wǎng)絡(luò)IO，最終提高整體端到端的性能。

　　使用External data source API之前

　　使用External data source API之后

　　搭載了如Parquet和ORC這樣的智能格式

　　連城表示，在Spark 1.2版本中，External data source API并沒有實現(xiàn)預(yù)期中的功能，在Roadmap中，F(xiàn)irst class分片支持（First class partitioning support with partition pruning）、Data sink（insertion）API、將Hive作為外部數(shù)據(jù)源等。

　　Enhanced in-memory columnar storage

　　連城表示，不管Shark，還是Spark，內(nèi)存緩存表的支持都是非常重要的一個特性。他表示，雖然在1.1和之前版本中的列式內(nèi)存表的性能已然不錯，但是還會出現(xiàn)一些問題：第一，大數(shù)據(jù)量下緩存超大體積表時（雖然不推薦，但不缺現(xiàn)實用例），會出現(xiàn)OOM等問題；第二，在列式存儲中，像Parquet、ORC這種收集統(tǒng)計信息然后通過這些信息做partition skipping等操作在之前版本中并沒有完全實現(xiàn)。這些問題在1.2版本中都得到了解決，本節(jié)，連城主要介紹了語義統(tǒng)一、緩存實體化、基于緩存共享的查詢計劃、Cache大表時的OOM問題、表格統(tǒng)計（Table statistics）等方面。

　　緩存實體化。SQLContext.cacheTable(“tbl”)默認(rèn)使用eager模式，緩存實體化將自動進(jìn)行，不會再等到表被使用或觸發(fā)時，避免手動做“SELECT COUNT(*) FROM src;”。同時，新增了“CACHE [LAZY] TABLE tbl [AS SELECT …]”這樣的DML。

　　語義統(tǒng)一。早期時候，SchemaRDD.cache()和SQLContext.cacheTable(“tbl”)這兩個語義是不同的。其中，SQLContext.cacheTable會去建立一些列式存儲格式相關(guān)優(yōu)化，而SchemaRDD.cache()卻以一行一個對象的模式進(jìn)行。在1.2版本中，這兩個操作已被統(tǒng)一，同時各種cache操作都將得到一個統(tǒng)一的內(nèi)存表。

　　基于緩存共享的查詢計劃。兩個得到相同結(jié)果的cache語句將共享同一份緩存數(shù)據(jù)。

　　避免Cache大表時的OOM問題。優(yōu)化內(nèi)存表的建立和訪問，減少開銷，進(jìn)一步提升性能；在緩存大表時，引入batched column buffer builder，將每一列切成多個batch，從而避免了OOM。

　　表格統(tǒng)計。Table statistics，類似Parquet、ORC使用的技術(shù)，在1.2版本中主要實現(xiàn)了Predicate pushdown（實現(xiàn)更快的表格掃描）和Auto broadcast join（實現(xiàn)更快的表格join）。

　　最后，連城還詳細(xì)介紹了一些關(guān)于加強Parquet和Hive支持的實現(xiàn)，以及Spark未來的一些工作。

　　百度基礎(chǔ)架構(gòu)部高級工程師甄鵬——Spark在百度開放云BMR中的實戰(zhàn)分享

　　百度分布式計算團(tuán)隊從2011年開始持續(xù)關(guān)注Spark，并于2014年將Spark正式引入百度分布式計算生態(tài)系統(tǒng)中，在國內(nèi)率先面向開發(fā)者及企業(yè)用戶推出了支持Spark并兼容開源接口的大數(shù)據(jù)處理產(chǎn)品BMR（Baidu MapReduce）。在甄鵬的分享中，我們主要了解了百度Spark 應(yīng)用現(xiàn)狀、百度開放云BMR和Spark On BMR三個方面的內(nèi)容。