golang大數據框架
1、Python語言
如果你的數據科學家不使用R，他們可能就會徹底了解Python。十多年來，Python在學術界當中一直很流行，尤其是在自然語言處理（NLP）等領域。因而，如果你有一個需要NLP處理的項目，就會面臨數量多得讓人眼花繚亂的選擇，包括經典的NTLK、使用GenSim的主題建模，或者超快、准確的spaCy。同樣，說到神經網路，Python同樣游刃有餘，有Theano和Tensorflow；隨後還有面向機器學習的scikit-learn，以及面向數據分析的NumPy和Pandas。
還有Juypter/iPython――這種基於Web的筆記本伺服器框架讓你可以使用一種可共享的日誌格式，將代碼、圖形以及幾乎任何對象混合起來。這一直是Python的殺手級功能之一，不過這年頭，這個概念證明大有用途，以至於出現在了奉行讀取－讀取－輸出－循環（REPL）概念的幾乎所有語言上，包括Scala和R。
Python往往在大數據處理框架中得到支持，但與此同時，它往往又不是「一等公民」。比如說，Spark中的新功能幾乎總是出現在Scala/Java綁定的首位，可能需要用PySpark編寫面向那些更新版的幾個次要版本（對Spark Streaming/MLLib方面的開發工具而言尤為如此）。
與R相反，Python是一種傳統的面向對象語言，所以大多數開發人員用起來會相當得心應手，而初次接觸R或Scala會讓人心生畏懼。一個小問題就是你的代碼中需要留出正確的空白處。這將人員分成兩大陣營，一派覺得「這非常有助於確保可讀性」，另一派則認為，我們應該不需要就因為一行代碼有個字元不在適當的位置，就要迫使解釋器讓程序運行起來。
2、R語言
在過去的幾年時間中，R語言已經成為了數據科學的寵兒——數據科學現在不僅僅在書獃子一樣的統計學家中人盡皆知，而且也為華爾街交易員，生物學家，和矽谷開發者所家喻戶曉。各種行業的公司，例如Google，Facebook，美國銀行，以及紐約時報都使用R語言，R語言正在商業用途上持續蔓延和擴散。
R語言有著簡單而明顯的吸引力。使用R語言，只需要短短的幾行代碼，你就可以在復雜的數據集中篩選，通過先進的建模函數處理數據，以及創建平整的圖形來代表數字。它被比喻為是Excel的一個極度活躍版本。
R語言最偉大的資本是已圍繞它開發的充滿活力的生態系統：R語言社區總是在不斷地添加新的軟體包和功能到它已經相當豐富的功能集中。據估計，超過200萬的人使用R語言，並且最近的一次投票表明，R語言是迄今為止在科學數據中最流行的語言，被61%的受訪者使用(其次是Python，39%)。
3、JAVA
Java，以及基於Java的框架，被發現儼然成為了矽谷最大的那些高科技公司的骨骼支架。 「如果你去看Twitter，LinkedIn和Facebook，那麼你會發現，Java是它們所有數據工程基礎設施的基礎語言，」Driscoll說。
Java不能提供R和Python同樣質量的可視化，並且它並非統計建模的最佳選擇。但是，如果你移動到過去的原型製作並需要建立大型系統，那麼Java往往是你的最佳選擇。
4、Hadoop和Hive
一群基於Java的工具被開發出來以滿足數據處理的巨大需求。Hadoop作為首選的基於Java的框架用於批處理數據已經點燃了大家的熱情。Hadoop比其他一些處理工具慢，但它出奇的准確，因此被廣泛用於後端分析。它和Hive——一個基於查詢並且運行在頂部的框架可以很好地結對工作。
㈡ golang的goku框架怎麼部署
你下載spring後，就會知道它有什麼功能了。它的所有模塊都區分好了。 spring-aop spring-beans spring-context spring-core spring-jdbc spring-orm spring-tx spring-webmvc spring-web
㈢ golang有哪些不錯的游戲伺服器框架
為什麼golang的開發效率高？
golang是一編譯型的強類型語言，它在開發上的高效率主要來自於後發優勢，不用考慮舊有惡心的歷史，又有一個較高的工程視角。良好的避免了程序員因為「 { 需不需要獨佔一行 」這種革命問題打架，也解決了一部分趁編譯時間找產品妹妹搭訕的階級敵人。
它有自己的包管理機制，工具鏈成熟，從開發、調試到發布都很簡單方便；
有反向介面、defer、coroutine等大量的syntactic sugar；
編譯速度快，因為是強類型語言又有gc，只要通過編譯，非業務毛病就很少了；
它在語法級別上支持了goroutine，這是大家說到最多的內容，這里重點提一下。首先，coroutine並不稀罕，語言並不能超越硬體、操作系統實現神乎其神的功能。golang可以做到事情，其他語言也可以做到，譬如c++，在boost庫裡面自己就有的coroutine實現（當然用起來跟其他boost庫一樣惡心）。golang做的事情，是把這一套東西的使用過程簡化了，並且提供了一套channel的通信模式，使得程序員可以忽略諸如死鎖等問題。
goroutine的目的是描述並發編程模型。並發與並行不同，它並不需要多核的硬體支持，它不是一種物理運行狀態，而是一種程序邏輯流程。它的主要目的不是利用多核提高運行效率，而是提供一種更容易理解、不容易出錯的語言來描述問題。
實際上golang默認就是運行在單OS進程上面的，通過指定環境變數GOMAXPROCS才能轉身跑在多OS進程上面。有人提到了的pomelo，開源本來是一件很不錯的事情，但是基於自己對callback hell的偏見，我一直持有這種態度：敢用nodejs寫大規模游戲伺服器的人，都是真正的勇士 : ) 。
2、Erlang與Golang的coroutine有啥區別，coroutine是啥？
coroutine本質上是語言開發者自己實現的、處於user space內的線程，無論是erlang、還是golang都是這樣。需要解決沒有時鍾中斷；碰著阻塞式io，整個進程都會被操作系統主動掛起；需要自己擁有調度控制能力（放在並行環境下面還是挺麻煩的一件事）等等問題。那為啥要廢老大的勁自己做一套線程放user space裡面呢？
並發是伺服器語言必須要解決的問題；
system space的進程還有線程調度都太慢了、佔用的空間也太大了。
把線程放到user space的可以避免了陷入system call進行上下文切換以及高速緩沖更新，線程本身以及切換等操作可以做得非常的輕量。這也就是golang這類語言反復提及的超高並發能力，分分鍾給你開上幾千個線程不費力。
不同的是，golang的並發調度在i/o等易發阻塞的時候才會發生，一般是內封在庫函數內；erlang則更誇張，對每個coroutine維持一個計數器，常用語句都會導致這個計數器進行rection，一旦到點，立即切換調度函數。
中斷介入程度的不同，導致erlang看上去擁有了preemptive scheling的能力，而golang則是cooperative shceling的。golang一旦寫出純計算死循環，進程內所有會話必死無疑；要有大計算量少io的函數還得自己主動叫runtime.Sched()來進行調度切換。
3、golang的運行效率怎麼樣？
我是相當反感所謂的pingpong式benchmark，運行效率需要放到具體的工作環境下面考慮。
首先，它再快也是快不過c的，畢竟底下做了那麼多工作，又有調度，又有gc什麼的。那為什麼在那些benchmark裡面，golang、nodejs、erlang的響應效率看上去那麼優秀呢，響應快，並發強？並發能力強的原因上面已經提到了，響應快是因為大量非阻塞式io操作出現的原因。這一點c也可以做到，並且能力更強，但是得多寫不少優質代碼。
然後，針對游戲伺服器這種高實時性的運行環境，GC所造成的跳幀問題確實比較麻煩，前面的大神 @達達 有比較詳細的論述和緩解方案，就不累述了 。隨著golang的持續開發，相信應該會有非常大的改進。一是屏蔽內存操作是現代語言的大勢所趨，它肯定是需要被實現的；二是GC演算法已經相當的成熟，效率勉勉強強過得去；三是可以通過incremental的操作來均攤cpu消耗。
用這一點點效率損失換取一個更高的生產能力是不是值得呢？我覺得是值得的，硬體已經很便宜了，人生苦短，讓自己的生活更輕松一點吧: )。
4、基於以上的論述，我認為採用go進行小范圍的MMORPG開發是可行的。
㈣ golang 有哪些比較穩定的 web 開發框架
推薦beego和revel
beego:國人開發，中文文檔。
https://github.com/astaxie/beego
revel：重量級框架，你想要的基本都能滿足。
https://github.com/revel/revel
㈤ iris 真的是最快的Golang 路由框架嗎
對各種Go http路由框架的比較， Iris明顯勝出，它的性能遠遠超過其它Golang http路由框架。
但是，在真實的環境中，Iris真的就是最快的Golang http路由框架嗎？
Benchmark測試分析
在那篇文章中我使用的是Julien Schmidt的 測試代碼,他模擬了靜態路由、Github API、Goolge+ API、Parse API的各種情況，因為這些API是知名網站的開放的API，看起來測試挺真實可靠的。
但是，這個測試存在著一個嚴重的問題，就是Handler的業務邏輯非常的簡單，各個框架的handler類似，比如Iris的Handler的實現：
funcirisHandler(_ *iris.Context) {}funcirisHandlerWrite(c *iris.Context) { io.WriteString(c.ResponseWriter, c.Param("name"))}funcirisHandlerTest(c *iris.Context) { io.WriteString(c.ResponseWriter, c.Request.RequestURI)}
幾乎沒有任何的業務邏輯，最多是往Response中寫入一個字元串。
這和生產環境中的情況嚴重不符!
實際的產品肯定會有一些業務的處理，比如參數的校驗，數據的計算，本地文件的讀取、遠程服務的調用、緩存的讀取、資料庫的讀取和寫入等，有些操作可能花費的時間很多，一兩個毫秒就可以搞定，有的卻很耗時，可能需要幾十毫秒，比如：
從一個網路連接中讀取數據 寫數據到硬碟中 調用其它服務，等待服務結果的返回 ……
這才是我們常用的case,而不是一個簡單的寫字元串。
因此那個測試框架的Handler還應該加入時間花費的情況。
模擬真實的Handler的情況
我們模擬一下真實的情況，看看Iris框架和Golang內置的Http路由框架的性能如何。
首先使用Iris實現一個Http Server:
packagemainimport("os""strconv""time""github.com/kataras/iris")funcmain() { api := iris.New() api.Get("/rest/hello",func(c *iris.Context) { sleepTime, _ := strconv.Atoi(os.Args[1])ifsleepTime >0{ time.Sleep(time.Duration(sleepTime) * time.Millisecond) } c.Text("Hello world") }) api.Listen(":8080")}
我們可以傳遞給它一個時間花費的參數sleepTime，模擬這個Handler在處理業務時要花費的時間，它會讓處理這個Handler的暫停sleepTime毫秒，如果為0,則不需要暫停，這種情況類似上面的測試。
然後我們使用Go內置的路由功能實現一個Http Server:
packagemainimport("log""net/http""os""strconv""time")// There are some golang RESTful libraries and mux libraries but i use the simplest to test.funcmain() { http.HandleFunc("/rest/hello",func(w http.ResponseWriter, r *http.Request) { sleepTime, _ := strconv.Atoi(os.Args[1])ifsleepTime >0{ time.Sleep(time.Duration(sleepTime) * time.Millisecond) } w.Write([]byte("Hello world")) }) err := http.ListenAndServe(":8080",nil)iferr !=nil{ log.Fatal("ListenAndServe: ", err) }}
編譯兩個程序進行測試。
1、首先進行業務邏輯時間花費為0的測試
運行程序 iris 0,然後執行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello進行並發100,持續30秒的測試。
iris的吞吐率為46155 requests/second。
運行程序 gomux 0,然後執行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello進行並發100,持續30秒的測試。
Go內置的路由程序的吞吐率為55944 requests/second。
兩者的吞吐量差別不大，iris略差一點
2、然後進行業務邏輯時間花費為10的測試
運行程序 iris 10,然後執行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello進行並發100,持續30秒的測試。
iris的吞吐率為97 requests/second。
運行程序 gomux 10,然後執行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello進行並發100,持續30秒的測試。
Go內置的路由程序的吞吐率為9294 requests/second。
3、最後進行業務邏輯時間花費為1000的測試
這次模擬一個極端的情況，業務處理很慢，處理一個業務需要1秒的時間。
運行程序 iris 1000,然後執行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello進行並發100,持續30秒的測試。
iris的吞吐率為1 requests/second。
運行程序 gomux 1000,然後執行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello進行並發100,持續30秒的測試。
Go內置的路由程序的吞吐率為95 requests/second。
可以看到，如果加上業務邏輯的處理時間，Go內置的路由功能要遠遠好於Iris, 甚至可以說Iris的路由根本無法應用的有業務邏輯的產品中，隨著業務邏輯的時間耗費加大，iris的吞吐量急劇下降。
而對於Go的內置路由來說，業務邏輯的時間耗費加大，單個client會等待更長的時間，但是並發量大的網站來說，吞吐率不會下降太多。
比如我們用1000的並發量測試 gomux 10和 gomux 1000。
gomux 10: 吞吐率為47664 gomux 1000: 吞吐率為979
這才是Http網站真實的情況，因為我們要應付的網站的並發量，網站應該支持同時有盡可能多的用戶訪問，即使單個用戶得到返回頁面需要上百毫秒也可以接受。
而Iris在業務邏輯的處理時間增大的情況下，無法支持大的吞吐率，即使在並發量很大的情況下(比如1000),吞吐率也很低。
深入了解Go http server的實現
Go http server實現的是每個request對應一個goroutine (goroutine per request), 考慮到Http Keep-Alive的情況，更准確的說是每個連接對應一個goroutine(goroutine per connection)。
因為goroutine是非常輕量級的，不會像Java那樣 Thread per request會導致伺服器資源不足，無法創建很多的Thread， Golang可以創建足夠多的goroutine，所以goroutine per request的方式在Golang中沒有問題。而且這還有一個好處，因為request是在一個goroutine中處理的，不必考慮對同一個Request/Response並發讀寫的問題。
如何查看Handler是在哪一個goroutine中執行的呢?我們需要實現一個函數來獲取goroutine的Id:
funcgoID()int{varbuf[64]byte n := runtime.Stack(buf[:], false) idField := strings.Fields(strings.TrimPrefix(string(buf[:n]),"goroutine "))[0] id, err := strconv.Atoi(idField)iferr !=nil{panic(fmt.Sprintf("cannot get goroutine id: %v", err)) }returnid}
然後在handler中列印出當前的goroutine id:
func(c *iris.Context) { fmt.Println(goID()) ……}
和
func(w http.ResponseWriter, r *http.Request) { fmt.Println(goID()) ……}
啟動 gomux 0,然後運行 ab -c 5 -n 5 http://localhost:8080/rest/hello測試一下，apache的ab命令使用5個並發並且每個並發兩個請求訪問伺服器。
可以看到伺服器的輸出：
因為沒有指定 -k參數，每個client發送兩個請求會創建兩個連接。
你可以加上 -k參數，可以看出會有重復的goroutine id出現，表明同一個持久連接會使用同一個goroutine處理。
以上是通過實驗驗證我們的理論，下面是代碼分析。
net/http/server.go的 第2146行 go c.serve()表明，對於一個http連接，會啟動一個goroutine:
func(srv *Server) Serve(l net.Listener) error {deferl.Close()iffn := testHookServerServe; fn !=nil{ fn(srv, l) }vartempDelay time.Duration// how long to sleep on accept failureiferr := srv.setupHTTP2(); err !=nil{returnerr }for{ rw, e := l.Accept() …… tempDelay =0 c := srv.newConn(rw) c.setState(c.rwc, StateNew) // before Serve can returngoc.serve() }}
而這個 c.serve方法會從連接中 讀取request交由handler處理:
func(c *conn) serve() { ……for{ w, err := c.readRequest() …… req := w.req serverHandler{c.server}.ServeHTTP(w, w.req)ifc.hijacked() {return } w.finishRequest()if!w.shouldReuseConnection() {ifw.requestBodyLimitHit || w.closedRequestBodyEarly() { c.closeWriteAndWait() }return } c.setState(c.rwc, StateIdle) }}
而 ServeHTTP的實現如下，如果沒有配置handler或者路由器，則使用預設的 DefaultServeMux。
func(sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) { handler := sh.srv.Handlerifhandler ==nil{ handler = DefaultServeMux }ifreq.RequestURI =="*"&& req.Method =="OPTIONS"{ handler = globalOptionsHandler{} } handler.ServeHTTP(rw, req)}
可以看出這里並沒有新開goroutine,而是在同一個connection對應的goroutine中執行的。如果試用Keep-Alive,還是在這個connection對應的goroutine中執行。
正如注釋中所說的那樣：
// HTTP cannot have multiple simultaneous active requests.[*] // Until the server replies to this request, it can't read another, // so we might as well run the handler in this goroutine. // [*] Not strictly true: HTTP pipelining. We could let them all process // in parallel even if their responses need to be serialized. serverHandler{c.server}.ServeHTTP(w, w.req)
因此業務邏輯的時間花費會影響單個goroutine的執行時間，並且反映到客戶的瀏覽器是是延遲時間latency增大了，如果並發量足夠多，影響的是系統中的goroutine的數量以及它們的調度，吞吐率不會劇烈影響。
Iris的分析
如果你使用Iris查看每個Handler是使用哪一個goroutine執行的，會發現每個連接也會用不同的goroutine執行，可是性能差在哪兒呢？
或者說,是什麼原因導致Iris的性能急劇下降呢？
Iris伺服器的監聽和為連接啟動一個goroutine沒有什麼明顯不同，重要的不同在與Router處理Request的邏輯。
原因在於Iris為了提供性能，緩存了context,對於相同的請求url和method,它會從緩存中使用相同的context。
func(r *MemoryRouter) ServeHTTP(res http.ResponseWriter, req *http.Request) {ifctx := r.cache.GetItem(req.Method, req.URL.Path); ctx !=nil{ ctx.Redo(res, req)return } ctx := r.getStation().pool.Get().(*Context) ctx.Reset(res, req)ifr.processRequest(ctx) {//if something found and served then add it's clone to the cache r.cache.AddItem(req.Method, req.URL.Path, ctx.Clone()) } r.getStation().pool.Put(ctx)}
由於並發量較大的時候，多個client的請求都會進入到上面的 ServeHTTP方法中，導致相同的請求會進入下面的邏輯：
ifctx := r.cache.GetItem(req.Method, req.URL.Path); ctx !=nil{ ctx.Redo(res, req)return}
ctx.Redo(res, req)導致不斷循環，直到每個請求處理完畢，將context放回到池子中。
所以對於Iris來說，並發量大的情況下,對於相同的請求(req.URL.Path和Method相同)會進入排隊的狀態，導致性能低下。
㈥ 有哪些不錯的golang開源項目
根據官方1.4版本的發布時候（2014.12）判斷（官方說大概六個月後出新版本）預計五月底六月初。因為這次的版本改進幅度有點大，不排除延遲發布的可能。
㈦ go語言在大數據，雲計算時代不行嗎
go就是為雲而生的語言
㈧ 有沒有人用golang實現過restful框架的實例
有不少開源項目支持Golang rest框架，可以參考下：
https://github.com/ant0ine/go-json-rest
https://github.com/ungerik/go-rest
https://github.com/codehack/go-relax
㈨ 大家推薦哪個 golang 的日誌框架，說說理由
glog 這個是google的日誌框架，kubernetes是使用這個的
inconshreveable/log15這個是結構化輸出的，之前也有用過。
Sirupsen/logrus這個用的也很多，記得docker是有這個的。
還有很多其他的，你可以github上看看，自己熟悉的就好。