處理大數(shù)據(jù)可能會遇到各種各樣的問題，目前沒有任何工具可以完美地處理這一切——即便是Spark。在今年的 Bossie開源大數(shù)據(jù)工具中，你會發(fā)現(xiàn)最新最好的方法是利用大型集群進行索引、搜索、圖形處理、流處理、結構化查詢、分布式OLAP和機器學習，因為眾多處理器和RAM可降低工作量級。

Bossie獎是英文IT網(wǎng)站InfoWorld針對開源軟件頒發(fā)的年度獎項，根據(jù)這些軟件對開源界的貢獻，以及在業(yè)界的影響力評判獲獎對象。本次InfoWorld評選出了13款最佳開源大數(shù)據(jù)工具，Spark、Beam都名列榜單之上。

Spark

Spark是寫在Scala中的內(nèi)存分布式處理框架，在Apache的大數(shù)據(jù)項目中非常火爆。隨著Spark 2.0版本的發(fā)布，它的優(yōu)勢似乎在延續(xù)。除了SQL語句實現(xiàn)等基礎功能，新版本的Spark在性能上也大幅提升。Spark 2.0在DataFrames的基礎上進一步完善，比如新的Structured Streaming API 等。這一切改變使Spark程序員的操作更清楚簡單，但Structured Streaming 可能會有較大改變。

從RDD的批處理進程轉變?yōu)闊o邊界的DataFrame概念，Structured Streaming將使某些特定場景的流處理(比如捕獲數(shù)據(jù)變更和位置更新)更容易實現(xiàn)，允許DataFrame本身的窗口時間序列，而不是進入流管道的新事件，這是Spark流式處理長期以來的痛點，尤其是與Apache Flink和Apache Beam相比，Saprk 2.0終于彌補了這塊空白。如果你至今沒有學會Spark，你就OUT了。

Beam

Google Beam是Apache的孵化器項目，提供了一種不需要每次改變引擎都重寫代碼的方式。目前看來，Spark可能是未來的編程模型，但如果不是呢?此外，如果你對一些擴展功能和Google DataFlow性能感興趣，你可以自己在Beam平臺編寫代碼并在DataFlow，Spark甚至是Flink上運行。我們很喜歡即寫即運行的想法，但Beam不支持類似REPL的開發(fā)者功能，但未來它將是一款不錯的分析工具。

TensorFlow

TensorFlow是Google針對機器學習提出的開源軟件，無論是字符識別，圖像識別，自然語言處理還是其他復雜的機器學習應用，TensorFlow可能都是你的首選。

TensorFlow是用C++寫的，但支持Python。此外，它最終會呈現(xiàn)出一個十分方便的方式運行分布式代碼，優(yōu)化GPS和CPU的并行代碼。這將是下一個大數(shù)據(jù)工具，未來將會持續(xù)進行討論。

Solr

作為Hadoop重量級廠商Hortonworks，Cloudera以及MapR等的選擇，Apache Solr為企業(yè)帶來可信任的、成熟的搜索引擎技術。Solr基于Apache Lucene引擎，這兩個項目共享于許多社區(qū)。你可以在類似Instagram，Zappos，Comcast和DuckDuckGO等企業(yè)場景背后發(fā)現(xiàn) Solr的身影。

Solr中的SolrCloud，是利用Apache ZooKeeper創(chuàng)建可伸縮、分布式的搜索和索引解決方案，并且高度抵御分布式系統(tǒng)類似腦裂等常見問題。伴隨著可靠性，SolrCloud的規(guī)模可按需變化，并且它足夠成熟可以處理數(shù)十億文檔之間的大量查詢請求。

Elasticsearch

Elasticsearch同樣基于Apache Lucene引擎，是針對現(xiàn)在的REST API 和JSON文檔概念的開源分布式搜索引擎。Elasticsearch集群數(shù)據(jù)從GB向PB級擴展十分容易，只需要很低的處理開銷。

作為ELK堆棧的一部分(Elasticsearch，Logastash和Kibana都是由Elasticsearch創(chuàng)造者Elastic創(chuàng)造的)，Elasticsearch已經(jīng)發(fā)現(xiàn)了它作為開源Splunk替代日志分析的殺手級應用。類似于 Nteflix，F(xiàn)acebook，Microsoft以及Linkedln公司在日志基礎架構上會選擇運行大型Elasticsearch集群。此外，ELK堆棧正在尋找其他方向，比如欺詐檢測和特定領域的業(yè)務分析，這將使Elasticsearch在更多企業(yè)得到使用。

SlamData

未來對SlamData來說是一場長途旅行。為什么會選擇使用MongoDB作為分析解決方案呢?可能因為這是一個可操作數(shù)據(jù)庫。然而，正如 SlamData的Jeff Carr所言，它并不瘋狂。有很多MongoDB方向新的公司和年輕的開發(fā)者產(chǎn)生，如果你使用MongoDB數(shù)據(jù)存儲，并且需要運行基礎的分析，你要創(chuàng)建整個Hadoop集群或者其他設施報告嗎?SlamData允許用熟悉的SQL語法來進行JSON數(shù)據(jù)的嵌套查詢，不需要轉換或語法改造。

該技術的主要特點之一是它的連接器。從MongoDB，HBase，Cassandra和Apache的Spark，SlamData同大多數(shù)業(yè)界標準的外部數(shù)據(jù)源可以方便的進行整合，并進行數(shù)據(jù)轉換和分析數(shù)據(jù)。SlamData有基于SQL的引擎，本質上說和MongoDB類似，但不像MongoDB 有自己的解決方案，SlamData并沒有吸納PostgreSQL的所有數(shù)據(jù)，并稱之為BI連接。既然核心技術是開源的，我認為可以期待未來有更多公司采用其技術不斷完善該領域產(chǎn)品。

Impala

Apache Impala是針對Hadoop上SQL處理的Cloudera引擎。如果你正在使用Hive，Impala是一種不需要你重復考慮任何事情就可以達到查詢性能的簡單方法。基于行的分布式大規(guī)模并行處理系統(tǒng)，Impala相比于在Spark上組合Hive更加成熟和徹底。即便沒有太多的調(diào)優(yōu)，Impala 還是可以提高性能，并且一定比你付出同樣努力使用Tez的效果要好。如果你在HDFS的文件之上需要使用SQL，Impala可能是最好的選擇。

Kylin

如果你正在做N維立方體分析和現(xiàn)代大數(shù)據(jù)框架，Kylin很對你的口。如果你從沒聽說過OLAP多維數(shù)據(jù)集，沒關系。如果你正在考慮RDBMS中存在一對多關系表，但有一部分需要計算字段，你可以選擇在SQL里進行查詢和計算，但是這太緩慢了。當我們的關系和計算量更多更復雜時，又該怎么辦呢?不是平面的表，把它們想象成立方體組成的若干塊，每一塊事先預計價值。你可能有N維或多維數(shù)據(jù)。Kylin當然不是第一個實現(xiàn)分布式OLAP的，但它是最先進的技術之一，并且目前可以下載并安裝在云端。

Kafka

Kafka是非常標準的分布式發(fā)布和訂閱標準，現(xiàn)在已經(jīng)用于世界上一些比較大的系統(tǒng)，Kafka的消息傳遞更加可靠，盡管與之前的系統(tǒng)不同，通過分布式提交日志保持耐久性。然而，Kafka的分區(qū)流處理支持高速數(shù)據(jù)加載和大量用戶。比較諷刺的是，盡管所有這些功能已經(jīng)足夠讓人驚訝了，但Kafka十分容易安裝部署，這在大數(shù)據(jù)和消息傳遞規(guī)則里是個例外。

StreamSets

你可能有一些數(shù)據(jù)需要處理，這些數(shù)據(jù)可能在文件夾里(比如網(wǎng)絡日志)或者正在Kafka上傳遞，雖然有很多方法可以實現(xiàn)，但使用StreamSets可以在最短的時間內(nèi)做你想做的任何事情，它比其他解決方案更加完整。也有越來越多的強壯的連接器 (HDFS，Hive，Kafka，Kinesis)，REST API，和GUI來監(jiān)控數(shù)據(jù)流動，這也正是他們一直在努力做的事情。

Titan

直到人們意識到使用圖表進行存儲非常有用，圖形數(shù)據(jù)庫才開始火了起來。一個攜帶所有附件可插拔式存儲的復雜數(shù)據(jù)庫，本質上是指高度可分配的數(shù)據(jù)庫列族。與其他圖形數(shù)據(jù)庫相比，Titan可以擴展。與嚴格的圖形分析框架相比，Titan可以提供更好的性能，相比于Giraph，不需要使用內(nèi)存資源或者時間重構圖形，相當于GiraphX，更不用說潛在的優(yōu)秀的數(shù)據(jù)完整性特征。

Zeppelin

無論你是一個只想要美觀圖形的開發(fā)者，還是想成為數(shù)據(jù)科學家，Zeppelin可能都適合你，它使用似曾相識的類似于IPython的筆記本概念，允許通過寫標記，嵌入式代碼，執(zhí)行代碼，它存在于Spark或其他引擎中，通過生成文本，表格或者圖表形式輸出。Zeppelin仍然缺乏一些特性和多功能DataBrick，但它正在穩(wěn)步前進。如果你使用Spark，Zeppelin就存在于工具包中。