中國IDC圈4月20日報道，數據科學是一個遼闊的規模。我自認是一個數據科學家，但和別的一批數據科學家又有許多的差異。數據科學家凡是分為統計科學家和數據工程師兩個陣營，而我正處于第二陣營。
統計科學家利用交互式的統計東西(好比R)來答復數據中的問題，得到全景的認識。與之對比，數據工程師則更像一名措施員，他們在處事器上編寫代碼，建設和應用呆板進修模子，熟悉C++和Java等系統級語言，常常需要和企業級數據中心的某些組件打交道，好比Hadoop。
而有的數據科學家專注于更細的規模，就像能干R但從未傳聞過Python可能scikit-learn(反之亦然)，即便兩者都提供了富厚的統計庫。
不完美的統計東西
假如可以提供一種統一的東西，運行在統一的架構，用統一的語言編程，并可以同時滿意統計科學家和數據工程師的需求，，那該多好啊。我一開始就能干Java，莫非為了研究數據，我就必需去學一種像Python或R的語言?我一直利用傳統的數據闡明東西，莫非為了應對大局限計較，就必需去懂MapReduce?正是統計東西的不完美培育了這種排場：
R提供了一個富厚的統計闡明和呆板進修的表明器。但R難以在漫衍式條件下執行數據的闡明和清洗，以便開展其所擅長的數據闡明，也不以一種主流的開拓語言為人所知。
Python是一種通用的編程語言，也不乏精彩的第三方數據闡明庫(像Pandas和scikit-learn)，但Python也有和R一樣的缺陷：只能范圍在處理懲罰單性能負載的數據量。
在經典的MapReduce計較框架上開拓漫衍式的呆板進修算法是可行的(參考Mahout)，但措施員需要從零開始，更別說移植巨大計較的難度。
為低落巨大計較移植到MapReduce的難度，Crunch提供一個簡樸的、傻瓜式的Java API，但MapReduce天生抉擇了它在迭代計較方面是低效的，盡量大大都呆板進修算法都需要迭代計較。
其他的數據科學東西一樣無法精細絕倫。基于Java和Hadoop的配景，我開始理想一個抱負的數據科學利器：一個像R和Python的能實現RPEL(讀取-估值-打印-輪回)的自帶統計庫函數的呼吁行表明器，又具備天然的漫衍式可擴展的屬性;擁有像Crunch一樣的漫衍式薈萃，并且能通過呼吁行表明器挪用。
Spark的優勢
這就是Spark讓我歡快的原因。大部門人接頭到Spark時，老是留意到將數據駐留內存以提高計較效率的方面(相對MapReduce)，但對我來說這基礎不是要害。Spark擁有很多的特征，使之真正成為一個融合統計科學和數據工程的交錯點：
Spark附帶了一個呆板進修庫MLib，固然只是在初始階段。
Spark是用Scala語言編寫的，運行在Java虛擬機上，同時也提供像R和Python的呼吁行表明器。
對Java措施員，Scala的進修曲線是較量陡峭的，但所幸Scala可以兼容一切的Java庫。
Spark的RDD(彈性漫衍式數據集)，是Crunch開拓者熟知的一種數據布局。
Spark仿照了Scala的薈萃計較API，對Java和Scala開拓者來說耳熟能詳，而Python開拓者也不難上手，而Scala對統計計較的支持也不錯。
Spark和其底層的Scala語言，并不可是為呆板進修而降生的，除此之外，像數據會見、日志ETL和整合都可以通過API輕松搞定。就像Python，你可以把整個數據計較流程搬到Spark平臺上來，而不只僅是模子擬合和闡明。
在呼吁行表明器中執行的代碼，和編譯后運行的結果溝通。并且，呼吁行的輸入可以獲得及時反饋，你將看到數據透明地在集群間通報與計較。
Spark和MLib尚有待完善：整個項目有不少bug，效率也尚有晉升的空間，和YARN的整合也存在問題。Spark還沒步伐提供像R那樣富厚的數據闡明函數。但Spark已然是世界上最好的數據平臺，足以讓來自任何配景的數據科學家側目。
實戰：Stack Overflow問題的自動標注
Stack Overflow是一個著名的軟件技能問答平臺，在上面提的每個問題有大概被打上若干個隨筆本的標簽，好比java可能sql，我們的方針在于成立一套系統，利用ALS推薦算法，為新問題的標簽提供預測和發起。從推薦系統的角度，你可以把問題想象成user，把標簽想象成item。
首先，從Stack Overflow下載官方提供的停止20140120的問答數據stackoverflow.com-Posts.7z。
這是一個可以或許直接用于漫衍式計較的bzip名目文件，但在我們的場景下，必需先解壓并拷貝到HDFS：
bzcat stackoverflow.com-Posts.7z | hdfs dfs -put – /user/srowen/Posts.xml
解壓后的文件約莫是24.4GB，包括210萬個問題，1800萬個答復，總共標注了930萬個標簽，這些標簽排重之后或許是34000個。
確認呆板安裝了Spark之后，輸入spark-shell即可打開Scala的REPL情況。首先，我們讀取一個存儲在HDFS的Posts.xml文件：
val postsXML = sc.textFile(“hdfs:///user/srowen/Posts.xml”)
這時呼吁行東西會返回：
postsXML: org.apache.spark.rdd.RDD[String] = MappedRDD[1] at textFile at :12
顯示文本文件已轉化為一個String型的RDD，你可以通過挪用RDD的函數，實現任意的查詢運算。好比統計文件的行數：
postsXML.count
這條指令生成大量的輸出，顯示Spark正在操作漫衍式的情況計數，最終打印出18066983。
下一步，將XML文件的每一行都存入形如(questionID, tag)的元組。得益于Scala的函數式編程的氣勢氣魄，RDD和Scala薈萃一樣可以利用map等要領：
val postIDTags = postsXML.flatMap { line => // Matches Id=”…” … Tags=”…” in line
val idTagRegex = “Id=”(\d+)”.+Tags=”([^”]+)””.r // // Finds tags like value from above
val tagRegex = “<([^&]+)>”.r // Yields 0 or 1 matches:
idTagRegex.findFirstMatchIn(line) match { // No match — not a line
case None => None // Match, and can extract ID and tags from m
case Some(m) => {
val postID = m.group(1).toInt
val tagsString = m.group(2) // Pick out just TAG matching group
val tags = tagRegex.findAllMatchIn(tagsString).map(_.group(1)).toList // Keep only question with at least 4 tags, and map to (post,tag) tuples
if (tags.size >= 4) tags.map((postID,_)) else None
}
} // Because of flatMap, individual lists will concatenate
// into one collection of tuples}
你會發明這條指令的執行是當即返回的，而不像count一樣需要期待，因為到今朝為止，Spark并未啟動任何主機間的數據調動。
