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上看看，自己熟悉的就好。