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

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

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

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

　　External data source API

　　連城表示，因?yàn)樵谔幚砗芏嗤獠繑?shù)據(jù)源中出現(xiàn)的擴(kuò)展問題，Spark在1.2版本發(fā)布了External data source API。通過External data source API，Spark將不同的外部數(shù)據(jù)源抽象成一個(gè)關(guān)系表格，從而實(shí)現(xiàn)更貼近無縫的操作。

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

　　連城表示，在1.2版本之前，開發(fā)者其實(shí)已經(jīng)實(shí)現(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ù)源）兩個(gè)方面：

　　Column pruning。主要包括縱橫的兩種剪枝。在列剪枝中，Column pruning可以完全忽視無需處理的字段，從而顯著地減少IO。同時(shí)，在某些條件查詢中，基于Parquet、ORC等智能格式寫入時(shí)記錄的統(tǒng)計(jì)信息（比如最大值、最小值等），掃描可以跳過大段的數(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并沒有實(shí)現(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)存緩存表的支持都是非常重要的一個(gè)特性。他表示，雖然在1.1和之前版本中的列式內(nèi)存表的性能已然不錯(cuò)，但是還會出現(xiàn)一些問題：第一，大數(shù)據(jù)量下緩存超大體積表時(shí)（雖然不推薦，但不缺現(xiàn)實(shí)用例），會出現(xiàn)OOM等問題；第二，在列式存儲中，像Parquet、ORC這種收集統(tǒng)計(jì)信息然后通過這些信息做partition skipping等操作在之前版本中并沒有完全實(shí)現(xiàn)。這些問題在1.2版本中都得到了解決，本節(jié)，連城主要介紹了語義統(tǒng)一、緩存實(shí)體化、基于緩存共享的查詢計(jì)劃、Cache大表時(shí)的OOM問題、表格統(tǒng)計(jì)（Table statistics）等方面。

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

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

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

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

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

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

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

　　百度分布式計(jì)算團(tuán)隊(duì)從2011年開始持續(xù)關(guān)注Spark，并于2014年將Spark正式引入百度分布式計(jì)算生態(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三個(gè)方面的內(nèi)容。