❶ 我为什么说 Python 是大数据全栈式开发语言 怎样成为数据分析师
就像只要会javaScript就可以写出完整的应用，只要会Python，就可以实现一个完整的大数据处理平台。
云基础设施
这年头，不支持云平台，不支持海量数据，不支持动态伸缩，根本不敢说自己是做大数据的，顶多也就敢跟人说是做商业智能（BI）。
云平台分为私有云和公有云。私有云平台如日中天的 OpenStack
，就是Python写的。曾经的追赶者CloudStack，在刚推出时大肆强调自己是Java写的，比Python有优势。结果，搬石砸脚，2015年
初，CloudStack的发起人Citrix宣布加入OpenStack基金会，CloudStack眼看着就要寿终正寝。
如果嫌麻烦不想自己搭建私有云，用公有云，不论是AWS，GCE，Azure，还是阿里云，青云，在都提供了Python SDK，其中GCE只提供Python和JavaScript的SDK，而青云只提供Python SDK。可见各家云平台对Python的重视。
提到基础设施搭建，不得不提Hadoop，在今天，Hadoop因为其MapRece数据处理速度不够快，已经不再作为大数据处理的首选，但
是HDFS和Yarn——Hadoop的两个组件——倒是越来越受欢迎。Hadoop的开发语言是Java，没有官方提供Python支持，不过有很多第
三方库封装了Hadoop的API接口（pydoop，hadoopy等等）。
Hadoop MapRece的替代者，是号称快上100倍的 Spark ，其开发语言是Scala，但是提供了Scala，Java，Python的开发接口，想要讨好那么多用Python开发的数据科学家，不支持Python，真是说不过去。HDFS的替代品，比如GlusterFS， Ceph 等，都是直接提供Python支持。Yarn的替代者， Mesos 是C++实现，除C++外，提供了Java和Python的支持包。
DevOps
DevOps有个中文名字，叫做 开发自运维 。互联网时代，只有能够快速试验新想法，并在第一时间，安全、可靠的交付业务价值，才能保持竞争力。DevOps推崇的自动化构建/测试/部署，以及系统度量等技术实践，是互联网时代必不可少的。
自动化构建是因应用而易的，如果是Python应用，因为有setuptools, pip, virtualenv, tox,
flake8等工具的存在，自动化构建非常简单。而且，因为几乎所有Linux系统都内置Python解释器，所以用Python做自动化，不需要系统预
安装什么软件。
自动化测试方面，基于Python的 Robot Framework 企业级应用最喜欢的自动化测试框架，而且和语言无关。Cucumber也有很多支持者，Python对应的Lettuce可以做到完全一样的事情。 Locust 在自动化性能测试方面也开始受到越来越多的关注。
自动化配置管理工具，老牌的如Chef和Puppet，是Ruby开发，目前仍保持着强劲的势头。不过，新生代 Ansible 和 SaltStack ——均为Python开发——因为较前两者设计更为轻量化，受到越来越多开发这的欢迎，已经开始给前辈们制造了不少的压力。
在系统监控与度量方面，传统的Nagios逐渐没落，新贵如 Sensu 大受好评，云服务形式的New Relic已经成为创业公司的标配，这些都不是直接通过Python实现的，不过Python要接入这些工具，并不困难。
除了上述这些工具，基于Python，提供完整DevOps功能的PaaS平台，如 Cloudify 和 Deis ，虽未成气候，但已经得到大量关注。
网络爬虫
大数据的数据从哪里来？除了部分企业有能力自己产生大量的数据，大部分时候，是需要靠爬虫来抓取互联网数据来做分析。
网络爬虫是Python的传统强势领域，最流行的爬虫框架Scrapy，HTTP工具包urlib2，HTML解析工具beautifulsoup，XML解析器lxml，等等，都是能够独当一面的类库。
不过，网络爬虫并不仅仅是打开网页，解析HTML这么简单。高效的爬虫要能够支持大量灵活的并发操作，常常要能够同时几千甚至上万个网页同时抓取，传统的
线程池方式资源浪费比较大，线程数上千之后系统资源基本上就全浪费在线程调度上了。Python由于能够很好的支持协程（ Coroutine ）操作，基于此发展起来很多并发库，如Gevent，Eventlet，还有Celery之类的分布式任务框架。被认为是比AMQP更高效的ZeroMQ也是最早就提供了Python版本。有了对高并发的支持，网络爬虫才真正可以达到大数据规模。
抓取下来的数据，需要做分词处理，Python在这方面也不逊色，著名的自然语言处理程序包NLTK，还有专门做中文分词的Jieba，都是做分词的利器。
数据处理
万事俱备，只欠东风。这东风，就是数据处理算法。从统计理论，到数据挖掘，机器学习，再到最近几年提出来的深度学习理论，数据科学正处于百花齐放的时代。数据科学家们都用什么编程？
如果是在理论研究领域，R语言也许是最受数据科学家欢迎的，但是R语言的问题也很明显，因为是统计学家们创建了R语言，所以其语法略显怪异。而且
R语言要想实现大规模分布式系统，还需要很长一段时间的工程之路要走。所以很多公司使用R语言做原型试验，算法确定之后，再翻译成工程语言。
Python也是数据科学家最喜欢的语言之一。和R语言不同，Python本身就是一门工程性语言，数据科学家用Python实现的算法，可以直
接用在产品中，这对于大数据初创公司节省成本是非常有帮助的。正式因为数据科学家对Python和R的热爱，Spark为了讨好数据科学家，对这两种语言
提供了非常好的支持。
Python的数据处理相关类库非常多。高性能的科学计算类库NumPy和SciPy，给其他高级算法打了非常好的基础，matploglib让
Python画图变得像Matlab一样简单。Scikit-learn和Milk实现了很多机器学习算法，基于这两个库实现的 Pylearn2 ，是深度学习领域的重要成员。 Theano 利用GPU加速，实现了高性能数学符号计算和多维矩阵计算。当然，还有 Pandas ，一个在工程领域已经广泛使用的大数据处理类库，其DataFrame的设计借鉴自R语言，后来又启发了Spark项目实现了类似机制。
对了，还有 iPython ，这个工具如此有用，以至于我差点把他当成标准库而忘了介绍。iPython是一个交互式Python运行环境，能够实时看到每一段Python代码的结果。默认情况下，iPython运行在命令行，可以执行 ipython notebook 在网页中运行。用matplotlib绘制的图可以直接嵌入式的显示在iPython Notebook中。
iPython Notebook的笔记本文件可以共享给其他人，这样其他人就可以在自己的环境中重现你的工作成果；如果对方没有运行环境，还可以直接转换成HTML或者PDF。
为什么是Python
正是因为应用开发工程师、运维工程师、数据科学家都喜欢Python，才使得Python成为大数据系统的全栈式开发语言。
对于开发工程师而言，Python的优雅和简洁无疑是最大的吸引力，在Python交互式环境中，执行 import this
，读一读Python之禅，你就明白Python为什么如此吸引人。Python社区一直非常有活力，和NodeJS社区软件包爆炸式增长不
同，Python的软件包增长速度一直比较稳定，同时软件包的质量也相对较高。有很多人诟病Python对于空格的要求过于苛刻，但正是因为这个要求，才
使得Python在做大型项目时比其他语言有优势。OpenStack项目总共超过200万行代码，证明了这一点。
对于运维工程师而言，Python的最大优势在于，几乎所有Linux发行版都内置了Python解释器。Shell虽然功能强大，但毕竟语法不够优雅，写比较复杂的任务会很痛苦。用Python替代Shell，做一些复杂的任务，对运维人员来说，是一次解放。
对于数据科学家而言，Python简单又不失强大。和C/C++相比，不用做很多的底层工作，可以快速进行模型验证；和Java相比，Python语法简
洁，表达能力强，同样的工作只需要1/3代码；和Matlab，Octave相比，Python的工程成熟度更高。不止一个编程大牛表达过，Python
是最适合作为大学计算机科学编程课程使用的语言——MIT的计算机入门课程就是使用的Python——因为Python能够让人学到编程最重要的东西——
如何解决问题。
❷ golang 协程什么时候切换
应puppet大拿刘宇的邀请，我去西山居运维团队做了一个简短分享，谈谈为什么我要将我们的项目从python转向go。
坦白的讲，在一帮python用户面前讲为什么放弃python转而用go其实是一件压力蛮大的事情，语言之争就跟vim和emacs之争一样，是一个永恒的无解话题，稍微不注意就可能导致粉丝强烈地反击。所以我只会从我们项目实际情况出发，来讲讲为什么我最终选择了go。
为什么放弃python
首先，我其实得说说为什么我们会选择python。在我加入企业快盘团队之前，整个项目包括更早的金山快盘都是采用python进行开发的。至于为什么这么选择，当时的架构师葱头告诉我，主要是因为python上手简单，开发迅速。对于团队里面大部分完全没服务端开发经验的同学来说，python真的是一个很好的选择。
python的简单高效，我是深有体会的。当时私有云项目也就几个程序员，但是我们要服务多家大型企业，进行定制化的开发，多亏了python，我们才能快速出活。后来企业快盘挂掉之后，我们启动轻办公项目，自然也使用python进行了原始版本的构建。
python虽然很强大，但我们在使用的时候也碰到了一些问题，主要由如下几个方面：
动态语言
python是一门动态强类型语言。但是，仍然可能出现int + string这样的运行时错误，因为对于一个变量，在写代码的时候，我们有时候很容易就忘记这个变量到底是啥类型的了。
在python里面，可以允许同名函数的出现，后一个函数会覆盖前一个函数，有一次我们系统一个很严重的错误就是因为这个导致的。
上面说到的这些，静态语言在编译的时候就能帮我们检测出来，而不需要等到运行时出问题才知道。虽然我们有很完善的测试用例，但总有case遗漏的情况。所以每次出现运行时错误，我心里都想着如果能在编译的时候就发现该多好。
性能
其实这个一直是很多人吐槽python的地方，但python有它适合干的事情，硬是要用python进行一些高性能模块的开发，那也有点难为它了。
python的GIL导致无法真正的多线程，大家可能会说我用多进程不就完了。但如果一些计算需要涉及到多进程交互，进程之间的通讯开销也是不得不考虑的。
无状态的分布式处理使用多进程很方便，譬如处理http请求，我们就是在nginx后面挂载了200多个django server来处理http的,但这么多个进程自然导致整体机器负载偏高。
但即使我们使用了多个django进程来处理http请求，对于一些超大量请求，python仍然处理不过来。所以我们使用openresty，将高频次的http请求使用lua来实现。可这样又导致使用两种开发语言，而且一些逻辑还得写两份不同的代码。
同步网络模型
django的网络是同步阻塞的，也就是说，如果我们需要访问外部的一个服务，在等待结果返回这段时间，django不能处理任何其他的逻辑（当然，多线程的除外）。如果访问外部服务需要很长时间，那就意味着我们的整个服务几乎在很长一段时间完全不可用。
为了解决这个问题，我们只能不断的多开django进程，同时需要保证所有服务都能快速的处理响应，但想想这其实是一件很不靠谱的事情。
异步网络模型
tornado的网络模型是异步的，这意味着它不会出现django那样因为外部服务不可用导致这个服务无法响应的问题。话说，比起django，我可是非常喜欢tornado的，小巧简单，以前还写过几篇深入剖析tornado的文章了。
虽然tornado是异步的，但是python的mysql库都不支持异步，这也就意味着如果我们在tornado里面访问数据库，我们仍然可能面临因为数据库问题造成的整个服务不可用。
其实异步模型最大的问题在于代码逻辑的割裂，因为是事件触发的，所以我们都是通过callback进行相关处理，于是代码里面就经常出现干一件事情，传一个callback，然后callback里面又传callback的情况，这样的结果就是整个代码逻辑非常混乱。
python没有原生的协程支持，虽然可以通过gevent，greenlet这种的上patch方式来支持协程，但毕竟更改了python源码。另外，python的yield也可以进行简单的协程模拟，但毕竟不能跨堆栈，局限性很大，不知道3.x的版本有没有改进。
开发运维部署
当我第一次使用python开发项目，我是没成功安装上项目需要的包的，光安装成功mysql库就弄了很久。后来，是一位同事将他整个python目录打包给我用，我才能正常的将项目跑起来。话说，现在有了docker，是多么让人幸福的一件事情。
而部署python服务的时候，我们需要在服务器上面安装一堆的包，光是这一点就让人很麻烦，虽然可以通过puppet，salt这些自动化工具解决部署问题，但相比而言，静态编译语言只用扔一个二进制文件，可就方便太多了。
代码失控
python非常灵活简单，写c几十行代码才能搞定的功能，python一行代码没准就能解决。但是太简单，反而导致很多同学无法对代码进行深层次的思考，对整个架构进行细致的考量。来了一个需求，啪啪啪，键盘敲完开速实现，结果就是代码越来越混乱，最终导致了整个项目代码失控。
虽然这也有我们自身的原因，譬如没好的代码review机制，没有好的项目规范，但个人感觉，如果一个程序员没经过良好的编码训练，用python很容易就写出烂的代码，因为太自由了。
当然，我这里并不是说用python无法进行大型项目的开发，豆瓣，dropbox都是很好的例子，只是在我们项目中，我们的python代码失控了。
上面提到的都是我们在实际项目中使用python遇到的问题，虽然最终都解决了，但是让我愈发的觉得，随着项目复杂度的增大，流量性能压力的增大，python并不是一个很好的选择。
为什么选择go
说完了python，现在来说说为什么我们选择go。其实除了python，我们也有其他的选择，java，php，lua(openresty)，但最终我们选择了go。
虽然java和php都是最好的编程语言（大家都这么争的），但我更倾向一门更简单的语言。而openresty，虽然性能强悍，但lua仍然是动态语言，也会碰到前面说的动态语言一些问题。最后，前金山许式伟用的go，前快盘架构师葱头也用的go，所以我们很自然地选择了go。
go并不是完美，一堆值得我们吐槽的地方。
error，好吧，如果有语言洁癖的同学可能真的受不了go的语法，尤其是约定的最后一个返回值是error。项目里面经常会充斥这样的代码:
if _, err := w.Write(data1); err != nil {
returun err
}
if _, err := w.Write(data2); err != nil {
returun err
}
难怪有个梗是对于一个需求，java的程序员在写配置的时候，go程序员已经写了大部分代码，但是当java的程序员写完的时候，go程序员还在写err != nil。
这方面，errors-are-values倒是推荐了一个不错的解决方案。
包管理，go的包管理太弱了，只有一个go get，也就是如果不小心更新了一个外部库，很有可能就导致现有的代码编译不过了。虽然已经有很多开源方案，譬如godep以及现在才出来的gb等，但毕竟不是官方的。貌似google也是通过vendor机制来管理第三方库的。希望go 1.5或者之后的版本能好好处理下这个问题。
GC，java的GC发展20年了，go才这么点时间，gc铁定不完善。所以我们仍然不能随心所欲的写代码，不然在大请求量下面gc可能会卡顿整个服务。所以有时候，该用对象池，内存池的一定要用，虽然代码丑了点，但好歹性能上去了。
泛型，虽然go有inteface，但泛型的缺失会让我们在实现一个功能的时候写大量的重复代码，譬如int32和int64类型的sort，我们得为分别写两套代码，好冗余。go 1.4之后有了go generate的支持，但这种的仍然需要自己根据go的AST库来手动写相关的parser，难度也挺大的。虽然也有很多开源的generate实现，但毕竟不是官方的。
当然还有很多值得吐槽的地方，就不一一列举了，但是go仍旧有它的优势。
静态语言，强类型。静态编译能帮我们检查出来大量的错误，go的强类型甚至变态到不支持隐式的类型转换。虽然写代码感觉很别扭，但减少了犯错的可能。
gofmt，应该这是我知道的第一个官方提供统一格式化代码工具的语言了。有了gofmt，大家的代码长一个样了，也就没有花括号到底放到结尾还是新开一行这种蛋疼的代码风格讨论了。因为大家的代码风格一样，所以看go的代码很容易。
天生的并行支持，因为goroutine以及channel，用go写分布式应用，写并发程序异常的容易。没有了蛋疼的callback导致的代码逻辑割裂，代码逻辑都是顺序的。
性能，go的性能可能赶不上c，c++以及openresty，但真的也挺强悍的。在我们的项目中，现在单机就部署了一个go的进程，就完全能够胜任以前200个python进程干的事情，而且CPU和MEM占用更低。
运维部署，直接编译成二进制，扔到服务器上面就成，比python需要安装一堆的环境那是简单的太多了。当然，如果有cgo，我们也需要将对应的动态库给扔过去。
开发效率，虽然go是静态语言，但我个人感觉开发效率真的挺高，直觉上面跟python不相上下。对于我个人来说，最好的例子就是我用go快速开发了非常多的开源组件，譬如ledisdb，go-mysql等，而这些最开始的版本都是在很短的时间里面完成的。对于我们项目来说，我们也是用go在一个月就重构完成了第一个版本，并发布。
实际项目中一些Go Tips
到现在为止，我们几乎所有的服务端项目都已经转向go，当然在使用的时候也遇到了一些问题，列出来算是经验分享吧。
godep，我们使用godep进行第三方库管理，但是godep我碰到的最大的坑就是build tag问题，如果一个文件有build tag，godep很有可能就会忽略这个文件。
IO deadline，如果能自己在应用层处理的都自己处理，go的deadline内部是timer来控制，但timer内部采用一个array来实现的heap，全局共用一个锁，如果大并发量，并且timer数量过多，timeout变动太频繁，很容易就引起性能问题。
GC，这个前面也说了，多用内存池，对象池，另外，我还发现，如果对象的生命周期跟goroutine一致，对性能的提升也不错，也在go的group问过相关问题，大家猜测可能是因为一些对象其实是在goroutine的8k栈上面分配的，所以一起回收没有额外GC了。
Go gob，如果要做RPC服务，gob并不是一个很好的选择，首先就跟python的pickle不通用，然后为了做不同系统的数据传入，任何包都必须带上类型的详细信息，size太大。go里面现在还没一套官方的RPC方案，gRPC貌似有上位的可能。
❸ python爬虫和大数据什么关系
大数据发掘需要一些工具比如python的爬虫、hadoop统计分析等。
❹ 刚刚，阿里开源 iOS 协程开发框架 coobjc！
阿里妹导读：刚刚，阿里巴巴正式对外开源了基于 Apache 2.0 协议的协程开发框架 coobjc，开发者们可以在 Github 上自主下载。
coobjc是为iOS平台打造的开源协程开发框架，支持Objective-C和Swift，同时提供了cokit库为Foundation和UIKit中的部分API提供了 协程 化支持，本文将为大家详细介绍coobjc的设计理念及核心优势。
从2008年第一个iOS版本发布至今的11年时间里，iOS的异步编程方式发展缓慢。
基于 Block 的异步编程回调是目前 iOS 使用最广泛的异步编程方式，iOS 系统提供的 GCD 库让异步开发变得很简单方便，但是基于这种编程方式的缺点也有很多，主要有以下几点：
针对多线程以及尤其引发的各种崩溃和性能问题，我们制定了很多编程规范、进行了各种新人培训，尝试降低问题发生的概率，但是问题依然很严峻，多线程引发的问题占比并没有明显的下降，异步编程本来就是很复杂的事情，单靠规范和培训是难以从根本上解决问题的，需要有更加好的编程方式来解决。
上述问题在很多系统和语言开发中都可能会碰到，解决问题的标准方式就是使用协程，C#、Kotlin、Python、Javascript 等热门语言均支持协程极其相关语法，使用这些语言的开发者可以很方便的使用协程及相关功能进行异步编程。
2017 年的 C++ 标准开始支持协程，Swift5 中也包含了协程相关的标准，从现在的发展趋势看基于协程的全新的异步编程方式，是我们解决现有异步编程问题的有效的方式，但是苹果基本已经不会升级 Objective-C 了，因此使用Objective-C的开发者是无法使用官方的协程能力的，而最新 Swift 的发布和推广也还需要时日，为了让广大iOS开发者能快速享受到协程带来的编程方式上的改变，手机淘宝架构团队基于长期对系统底层库和汇编的研究，通过汇编和C语言实现了支持 Objective-C 和 Swift 协程的完美解决方案 —— coobjc。
核心能力
内置系统扩展库
coobjc设计
最底层是协程内核，包含了栈切换的管理、协程调度器的实现、协程间通信channel的实现等。
中间层是基于协程的操作符的包装，目前支持async/await、Generator、Actor等编程模型。
最上层是对系统库的协程化扩展，目前基本上覆盖了Foundation和UIKit的所有IO和耗时方法。
核心实现原理
协程的核心思想是控制调用栈的主动让出和恢复。一般的协程实现都会提供两个重要的操作：
我们基于线程的代码执行时候，是没法做出暂停操作的，我们现在要做的事情就是要代码执行能够暂停，还能够再恢复。 基本上代码执行都是一种基于调用栈的模型，所以如果我们能把当前调用栈上的状态都保存下来，然后再能从缓存中恢复，那我们就能够实现yield和 resume。
实现这样操作有几种方法呢？
上述第三种和第四种只是能过做到跳转，但是没法保存调用栈上的状态，看起来基本上不能算是实现了协程，只能算做做demo，第五种除非官方支持，否则自行改写编译器通用性很差。而第一种方案的 ucontext 在iOS上是废弃了的，不能使用。那么我们使用的是第二种方案，自己用汇编模拟一下 ucontext。
模拟ucontext的核心是通过getContext和setContext实现保存和恢复调用栈。需要熟悉不同CPU架构下的调用约定(Calling Convention). 汇编实现就是要针对不同cpu实现一套，我们目前实现了 armv7、arm64、i386、x86_64，支持iPhone真机和模拟器。
说了这么多，还是看看代码吧，我们从一个简单的网络请求加载图片功能来看看coobjc到底是如何使用的。
下面是最普通的网络请求的写法：
下面是使用coobjc库协程化改造后的代码：
原本需要20行的代码，通过coobjc协程化改造后，减少了一半，整个代码逻辑和可读性都更加好，这就是coobjc强大的能力，能把原本很复杂的异步代码，通过协程化改造，转变成逻辑简洁的顺序调用。
coobjc还有很多其他强大的能力，本文对于coobjc的实际使用就不过多介绍了，感兴趣的朋友可以去官方github仓库自行下载查看。
我们在iPhone7 iOS11.4.1的设备上使用协程和传统多线程方式分别模拟高并发读取数据的场景，下面是两种方式得到的压测数据。
从上面的表格我们可以看到使用在并发量很小的场景，由于多线程可以完全使用设备的计算核心，因此coobjc总耗时要比传统多线程略高，但是由于整体耗时都很小，因此差异并不明显，但是随着并发量的增大，coobjc的优势开始逐渐体现出来，当并发量超过1000以后，传统多线程开始出现线程分配异常，而导致很多并发任务并没有执行，因此在上表中显示的是大于20秒，实际是任务已经无法正常执行了，但是coobjc仍然可以正常运行。
我们在手机淘宝这种超级App中尝试了协程化改造，针对部分性能差的页面，我们发现在滑动过程中存在很多主线程IO调用、数据解析，导致帧率下降严重，通过引入coobjc，在不改变原有业务代码的基础上，通过全局hook部分IO、数据解析方法，即可让原来在主线程中同步执行的IO方法异步执行，并且不影响原有的业务逻辑，通过测试验证，这样的改造在低端机(iPhone6及以下的机器)上的帧率有20%左右的提升。
简明
易用
清晰
性能
程序是写来给人读的，只会偶尔让机器执行一下。——Abelson and Sussman
基于协程实现的编程范式能够帮助开发者编写出更加优美、健壮、可读性更强的代码。
协程可以帮助我们在编写并发代码的过程中减少线程和锁的使用，提升应用的性能和稳定性。
本文作者：淘宝技术