大資料處理技術的趨勢-五種開源技術介紹

大資料領域的處理，我自己本身接觸的時間也不長，正式的專案還在開發之中，深受大資料處理方面的吸引，所以也就有寫文章的想法的了。 大資料以Hadoop以及"NO SQL"為主的Mongo和Cassandra等資料庫技術在展現。 現在資料的即時分析將可能容易一些。 現在集群的轉換將越來越可靠,20分鐘以內就能夠完成。 因為我們用表來支援?但是這些是僅僅是一些比較新的，未開發的優點和不平凡的大機會超過了這些常規的猜想。

你知道麼，在現在的市場上超過25萬個開源技術出現了。 圍繞在我們身邊，這些越來越複雜的系統，就像我們看到的這樣，看如下圖表：

在最少選擇的情況下我們還是有很多選擇的機會。 哪些是你的目標?哪些是2000家公司接下來的財富?哪些專案是可以在真正的產品階段使用的作為可靠的候選?哪些應該受到特別關注呢?我們做了詳細的研究和測試，讓我們一起看下5種新的撼動大資料的技術。 這些是整理的幾組新的工具，讓我們一起來看看吧。

Storm 和 Kafka 是未來資料流程處理的主要方式，它們已經在一些大公司中使用率餓，包括 Groupon,阿裡巴巴和The Weather Channel等。 Storm,誕生於Twitter,是一個分散式即時計算系統。 Storm 設計用於處理即時計算,hadoop主要用於處理批次處理運算。

kafka是由LinkedIn研發的一款消息系統作為一個資料處理的管道基礎部分存在於系統中。 當你一起使用它們，你就能即時地和線性遞增的獲取資料。

你為什麼需要關心?

使用Storm和Kafka,使得資料流程處理線性的，確保每條消息獲取都是即時的，可靠的。 前後佈置的Storm和Kafka能每秒流暢的處理10000條資料。

像Storm和Kafka這樣的資料流程處理方案使得很多企業引起關注並想達到優秀的ETL(抽取轉換裝載)的資料整合方案。 Storm 和 Kafka 也很擅長記憶體分析和即時決策支援。 企業使用批量處理的Hadoop方案無法也難怪對即時的業務需求。 在企業的大資料解決方案中即時資料流處理是一個必要的模組，因為它很優美的處理了「3v」--volume,velocity 和 variety (容量，速率和多樣性)。 Storm和Kafka這2種技術是我們(infochimps)最推薦的技術，它們也將作為一個正式組成部分存在於我們的平臺中。 Drill和Dremel 實現了快速低負載的大規模，即席查詢資料搜索。 它們提供了秒級搜索P級別資料的可能，來應對即席查詢和預測，及提供強大的虛擬化支援。

Drill和Dremel提供強大的業務處理能力，不僅僅只是為數據工程師提供。 業務端的大家都將喜歡Drill和Dremel.Drill 是Google的Dremel的開源版本。 Dremel是Google提供的支援大資料查詢的技術。 公司將用它來開發自己的工具，這些是導致大家都密切的關注Drill的原因。 雖然這些不是起步，但是開源社區強烈的興趣使得它變得更成熟。

為什麼你應該關心?

Drill和Dremel相比Hadoop更好的分析即席查詢。 Hadoop僅僅提供批量的資料處理工作流，這些也是缺點。

Hadoop生態圈使得MapReduce作為一個很親切有利的工具應用於廣告分析。 從Sawzall到Pig到Hive,很多介面層應用的建立使得Hadoop更為友好，更接近業務，但是，像SQL體系，這些抽象層忽略一個重要的事實--MapReduce(或Hadoop)是為了系統化資料處理流程而存在的。 如果你不擔心跑的哪些任務? 如果你不關心這些產生的問題和去尋求答案，那就保持沉默,保持洞察力。 「即席探索" -- 如果你已經承擔資料處理，你這麼優化處理的速度?你不應該運行一個新的任務或者是等待，有時候考慮的時間還不如在問個新的問題。

在堆對比的工作流基礎的方法論中，很多業務驅動的BI和分析查詢都是很基本的和臨時交互的，低延時分析。 寫Map/Reduce工作流在很多業務分析中是被禁止的。 等待幾分鐘等Jobs啟動，在等幾個小時等執行完成這些無溢于資料的交互體驗，這些對比，和縮放比較最終產生了基本的新的視野。 一些資料科學家早已經推測Drill和Dremel將優於Hadoop，並達成共識，也有一些還在考慮中，還有少部分的狂熱者立即擁抱變化，但是這些是主要的優點在更面向查詢的和低延時的情況下。 在Infochimps我們喜歡使用Elasticsearch全文索引引擎來實現資料庫的資料搜索，但是真的在大資料處理中我們認為Drill將成為主流。

R是開源的強大的統計程式設計語言。 自1997年以來，超過200萬的統計分析師使用R。 這是一門誕生自貝爾實驗室的在統計計算領域的現代版的S語言並迅速地成為了新的標準的統計語言。 R使得複雜的資料科學變得更廉價。 R是SAS和SPASS的重要的領頭者，並作為最優秀的統計師的重要工具。

為什麼你應該關心?

因為它有一個非凡強大的社區在支援著，你可以找到所有的R的類庫，創建虛擬的各類型的科學資料而不用新寫代碼。 R之所以令人興奮是因為維護他的人和新的每天的創造。 R社區是大資料領域令人興奮的地方之一。 R在大資料領域是一個超棒的不會過時的技術。 在最近的幾個月裡，幾千個新特性被日益公開的知識基礎為主的分析類型的分析師們介紹.而且，R和Hadoop協同的很好，作為一個大資料的處理的部分已經被證明了。 保持關注：Julia ，是一個有趣的R的替代者，因為它不喜歡R的死慢死慢的解譯器。 Julia的社區雖然不怎麼強大現在，但是如果你不是立即使用它的話，還是可以等等的。 Gremlin 和 Giraph 説明增強圖形分析，並在圖資料庫像Neo4j和InfiniteGraph中被使用，和與Hadoop協同工作的Giraph中被使用。 Golden Orb是另一個高層面的流處理的圖基礎的專案的例子。 可以看看。 圖資料庫是富有魅力的邊緣化的資料庫。 它們和關聯式資料庫相比，有著很多有趣的不同點，這個是當你在開始的時候總是想用圖理論而不是關聯式理論。

另一個類似的圖基礎的理論是Google的Pregel,相比來說Gremlin和Giraph是其的開源替代。 實際上，這些都是Google技術的山寨實現的例子。 圖在計算網路建模和社會化網路方面發揮著重要作用，能夠連接任意的資料。 另外一個經常的應用是映射和地理資訊計算。 從A到B的地點，計算最短的距離。 圖在生物計算和物理計算領域也有廣泛的應用，例如，他們能繪製不尋常的分子結構。 海量的圖，圖資料庫和分析語言和框架都是一種現實世界上實現大資料中的一部分。 圖基礎的理論是一個殺手級的應用，為什麼這麼說?任何一個解決大型網路節點問題，都是通過節點和節點之間的路徑來處理的。 很多富有創造力的科學家和工程師們，都很明白的用正確的工具來解決對應的問題。 確保他們都能運行的漂亮並能被廣泛傳播。

SAP Hana 是一個全記憶體的分析平臺，它包含了一個記憶體資料庫和一些相關的工具軟體用來創建分析流程和規範正確的格式來進行資料的輸入輸出。

為什麼應該關心?

SAP 開始反對為固化的企業使用者提高強大的產品，供開發免費使用。 這個不僅僅是SAP開始為初創著想，讓其使用Hana。 他們授權培養社區解決方案，這些不尋常的做法是圍繞Hana的結果。

Hana 假設其他的程式處理時候還不夠快的解決遇到的問題，例如，金融建模和決策支援，網站個人化和欺騙檢測等等。 Hana最大的缺點是」全記憶體「這意味著訪問軟狀態的記憶體，這個是很明確的有點，但是這個也是相比磁片存儲來說很昂貴的部分。 據召集人說，不用擔心操作成本，Hana是快速的地延遲的大資料處理工具。

D3 本來不在清單中，但是它的親切感，讓我們認為有提它的價值。 D3是一個javascript面向文檔的視覺化的類庫，。 它強大的創新性的讓我們能直接看到資訊和讓我們進行正常的交互。 它的作者是Michael Bostock一個紐約時報的圖形介面設計師。 例如，你可以使用D3來從任意數量的陣列中創建H™l表格。 你能使用任意的資料來創建交互進度條等。 這裡是一個D3的實際例子，創建2013年奧巴馬的民意情況。 使用D3，程式師能之間創建介面，組織所有的各種類型的資料。

雖然這篇文章不長，但是也費了我一段實際來翻譯，翻譯不足之處希望大家指正。 其實看到這篇文章的時候，我就很想把它分享給喜歡它的人，得益于一個開放的環境，所以美國在IT領域總是這麼的讓人驚喜，當然我們也得跟上了。

開始正式的使用Hadoop已經有近一年的時間的了，這期間從百度出來，到初見在到現在的BitWare，在不同的公司，用不同的技術解決問題。 但是本質上遇到的問題總是那麼幾個，當然現在很多公司也開始嘗鮮的使用Hadoop的了。 這個是大環境是如此，可以理解。

以下說說個人對文章的理解：

Storm和Kafka 從11年起，就開始關注了，Storm在阿裡也有部分二線應用，但是整體而言，剛剛滿一歲的Storm在nathanmarz大俠的打磨下越來越穩定了，並有部分線上的應用了。 所以對這個技術，總體而言，我個人還是很看好的，因為現在使用hadoop無法實現即時的處理，使用HBase來為主要的資料庫來使用了，暫時還是能解決，但是還是想嘗試下Storm,Kafka的關注不是很多，不過這個配合起來使用 ，據說很贊，沒有自己跑過。

Drill這個是Apache的開源專案，之前也看了Google Dremel的論文，無奈看不是很懂，現在也沒有遇到這樣的環境，而且社區才剛剛火起來，所以還沒有很多的時間來跟進，暫時先擱置了。

R語言，之前在百度的時候，隔壁各位做的哥們就在使用R語言幹活，這個可能是只有大公司能夠有能力去真正的挖掘的方面吧，我們現在的業務中基本沒有用到過，對於R還是很陌生，不過我個人任務，在不同的環境下使用不同的技術手段，猶如， 博士聲光電吹盒子，我們架個電風吹，是一樣的實現吧。

對於圖資料庫領域，還真的是沒有遇到過詳細的應用，還沒有機會進入這樣的公司，所以還是束之高閣吧。

SPA這個公司，聽過名字，但是沒有具體的接觸過，現在賣解決方案估計也不好過，弄個東西出來提高下知名度還是必須的。 現在啃老本的時代已經過去的了。

最後一個視覺化的JS類庫，興趣不大，業務現在不去做前端的了，所以也還好。