上面這些調(diào)查數(shù)據(jù)來(lái)自美國(guó)，中國(guó)的情況有所區(qū)別，但是還是有一定的借鑒意義的。國(guó)內(nèi)的Spark應(yīng)用也越來(lái)越多：騰訊的Spark規(guī)模到了8000+節(jié)點(diǎn)，日處理數(shù)據(jù)1PB+。阿里巴巴運(yùn)行著目前最長(zhǎng)時(shí)間的Spark Job：1PB+數(shù)據(jù)規(guī)模的Spark Job長(zhǎng)達(dá)1周的時(shí)間。百度的硅谷研究院也在探索Spark+Tachyon的應(yīng)用場(chǎng)景。
Spark MLlib的ALS算法已經(jīng)在很多互聯(lián)網(wǎng)公司用于其推薦系統(tǒng)中?；旧现髁鞯幕ヂ?lián)網(wǎng)公司都已經(jīng)部署了Spark平臺(tái)并運(yùn)行了自己的業(yè)務(wù)。上面說(shuō)的更多的互聯(lián)網(wǎng)的應(yīng)用，實(shí)際上Spark的應(yīng)用場(chǎng)景有很多。在Databricks公司的調(diào)查中顯示主要應(yīng)用依次是：商務(wù)智能、數(shù)據(jù)倉(cāng)庫(kù)、推薦系統(tǒng)、日志處理、欺詐檢測(cè)等。
除了互聯(lián)網(wǎng)公司以外，傳統(tǒng)IT企業(yè)也把Spark作為其產(chǎn)品的一個(gè)重要組成。IBM在今年6月的Spark summit期間宣布重點(diǎn)支持Spark這個(gè)開(kāi)源項(xiàng)目，同時(shí)還開(kāi)源了自己的機(jī)器學(xué)習(xí)系統(tǒng)SystemML并推進(jìn)其與Spark的更好合作。美國(guó)大數(shù)據(jù)巨頭Cloudera，Hortonworks和MapR都表示Spark是其大數(shù)據(jù)整體解決方案的核心產(chǎn)品?？梢灶A(yù)見(jiàn)Spark是未來(lái)若干年最火的大數(shù)據(jù)項(xiàng)目。
在深度學(xué)習(xí)方面2015年可謂非常熱鬧，如Google開(kāi)源其第二代機(jī)器學(xué)習(xí)系統(tǒng)TensorFlow，F(xiàn)acebook開(kāi)源Torch和人工智能硬件服務(wù)器Big Sur等等。Spark社區(qū)也不甘落后，在1.5版本中發(fā)布了一個(gè)神經(jīng)網(wǎng)絡(luò)分類(lèi)器MultiplayerPerceptronClassifier作為其深度學(xué)習(xí)的雛形。雖然這個(gè)模型還有很多地方需要優(yōu)化，大家不妨嘗試下，畢竟它是唯一一個(gè)基于通用計(jì)算引擎的分布式深度學(xué)習(xí)系統(tǒng)。
除了現(xiàn)在非常火的深度學(xué)習(xí)，在傳統(tǒng)統(tǒng)計(jì)和機(jī)器學(xué)習(xí)領(lǐng)域，Spark這一年也有非常大的變化，包括GLM的全面支持，SparkR GLM的支持，A/B test，以及像WeightesLeastSquares這樣的底層優(yōu)化算法等。
具體內(nèi)容可以看梁堰波在InfoQ上的年終回顧：《 解讀2015之Spark篇：新生態(tài)系統(tǒng)的形成 》。
Elasticsearch：
Elasticsearch 是一個(gè)可伸縮的開(kāi)源全文搜索和分析引擎。它可以快速地存儲(chǔ)、搜索和分析海量數(shù)據(jù)。Elasticsearch 基于成熟的 Apache Lucene 構(gòu)建，在設(shè)計(jì)時(shí)就是為大數(shù)據(jù)而生，能夠輕松的進(jìn)行大規(guī)模的橫向擴(kuò)展，以支撐PB級(jí)的結(jié)構(gòu)化和非結(jié)構(gòu)化海量數(shù)據(jù)的處理。Elasticsearch生態(tài)圈發(fā)展?fàn)顟B(tài)良好，整合了眾多外圍輔助系統(tǒng)，如監(jiān)控Marvel，分析Logstash，安全Shield等。近年來(lái)不斷發(fā)展受到廣泛應(yīng)用，如Github、StackOverflow、維基百科等，是數(shù)據(jù)庫(kù)技術(shù)中倍受關(guān)注的一匹黑馬。
Elasticsearch在今年下半年發(fā)布了2.0版本，性能提升不少，主要改變?yōu)椋?/p>
Pipeline Aggregation
流式聚合，像管道一樣，對(duì)聚合的結(jié)果進(jìn)行再次聚合。原來(lái)client端需要做的計(jì)算工作，下推到ES，簡(jiǎn)化 client代碼，更容易構(gòu)建強(qiáng)大的查詢(xún)。
Query/Filter 合并
取消filters，所有的filter語(yǔ)句自動(dòng)轉(zhuǎn)換為query語(yǔ)句。在上下文語(yǔ)義是query時(shí)，進(jìn)行相關(guān)性計(jì)算;上下文語(yǔ) 義是filter時(shí)，簡(jiǎn)單排除b不匹配的doc，像現(xiàn)在的filter所做的一樣。這個(gè)重構(gòu)以為著所有的query執(zhí)行會(huì)以最 有效的順序自動(dòng)優(yōu)化。例如，子查詢(xún)和地理查詢(xún)會(huì)首先執(zhí)行一個(gè)快速的模糊步驟，然后用一個(gè)稍慢的精確 步驟截?cái)嘟Y(jié)果。在filter上下文中，cache有意義時(shí)，經(jīng)常使用的語(yǔ)句會(huì)被自動(dòng)緩存。
可配置的store compression
存儲(chǔ)的field，例如_source字段，可以使用默認(rèn)的LZ4算法快速壓縮，或者使用DEFLATE算法減少index size。對(duì)于日志類(lèi)的應(yīng)用尤其有用，舊的索引庫(kù)在優(yōu)化前可以切換到best_compression。
Hardening
Elasticsearch運(yùn)行于 Java Security Manager之下，在安全性上標(biāo)志著一個(gè)巨大的飛躍。Elasticsearch難于探測(cè)，黑客在系統(tǒng)上 的影響也被嚴(yán)格限制。在索引方面也有加強(qiáng)： indexing請(qǐng)求ack前，doc會(huì)被fsync，默認(rèn)寫(xiě)持久化 所有的文件都計(jì)算checksum，提前檢測(cè)文件損壞 所有的文件rename操作都是原子的(atomic)，避免部分寫(xiě)文件 對(duì)于系統(tǒng)管理員來(lái)講，一個(gè)需求較多的變化是，可以避免一個(gè)未配置的node意外加入Elasticsearch集群網(wǎng)絡(luò)：默認(rèn)綁 定localhost>社區(qū)合作
在開(kāi)源后的一年時(shí)間內(nèi)，Apache Kylin也和其他社區(qū)建立了良好的合作關(guān)系，Apache Calcite作為Kylin 的SQL引擎被深入的整合進(jìn)來(lái)，我們也向Calcite提交了很多改進(jìn)和修復(fù)，Calcite的作者，Julian Hyde也是Kylin的mentor。HBase是Kylin的存儲(chǔ)層，在實(shí)際運(yùn)維中，我們碰到過(guò)無(wú)數(shù)問(wèn)題，從可靠性到性能到其他各個(gè)方面，Kylin社區(qū)和HBase社區(qū)積極合作解決了絕大部分關(guān)鍵問(wèn)題。另外，現(xiàn)在越來(lái)越多的用戶(hù)考慮使用Apache Zeppelin作為前端查詢(xún)和展現(xiàn)的工具，為此我們開(kāi)發(fā)了Kylin Interperter并恭喜給了Zeppelin，目前可以直接從最新版的Zeppelin代碼庫(kù)中看到這快。同樣，我們也和其他各個(gè)社區(qū)積極合作，包括Spark，Kafka等，為構(gòu)建和諧的社區(qū)氛圍和形成良好合作打下了堅(jiān)實(shí)的基礎(chǔ)。