python做数据库统计速度快吗_【原创经验】你需要什么样的统计工具？——R/SAS/Python/MySQL...

一、你需要什么样的统计软件：SAS or R

我被问得最多的问题是“xx软件好用吗？”、“xx软件难不难”之类。其实会xx软件的人都清楚，这种问题是最难回答的，毕竟难者不会，会者不难。楼主认为，初学者应该改变自己最初的问题，与其问一个软件难不难，不如问“我要实现xx需求，xx软件能满足我吗？如何满足？语法是否灵活简介？性能是否足够？商业/社区支持是否充分？”。这些问题基本决定了你适合学习什么软件，由于统计软件的使用具有强大的路径依赖性，同时使用多个软件远不如精通一门来得高效，所以在选择你的语言之前，仔细思考以上问题对你大有裨益。楼主比较熟练的有SAS与R，故下文主要就这两门语言进行讨论，期间会偶尔涉及到其他语言，例如MySQL、python、Matlab，以及非常小众但迅速发展的Julia。此外再次重申，下文所有比较与结论都仅针对大多数的经济学研究

语法灵活性(syntax)

对于90%的人的90%的需求，其实绝大多数语言都可以胜任，关键在于寻找语法最简洁、最灵活的那一种语言。假设解决你的问题有两种方法：第一种，使用半个小时来编写直观、易懂、简短的程序，然后花一个小时来运行；第二种，使用一个小时来写一段晦涩的代码，然后只要30分钟就能跑出结果，你选择哪一种？这几年论文写作与数据处理的经验告诉我：在syntax(readability)和performance之间，我宁愿选择前者，这也是我现在从SAS阵营转战到R阵营的最大原因。(另外原因包括楼主英文名以R开头，以及微软收购了商业化R语言公司RevolutionAnalytics。对，楼主是微软脑残粉，写python的IDE都用的是VisualStudio，所以微软看上的都是好东西(捂脸)……)

为什么楼主认为在经济学的研究中，SAS的代码会更长更晦涩？还是从我们的需求看起，经济学研究中用到的数据处理，主要有两个特点：I/O intensive以及interactive，而R语法的灵活非常适合应对这两个特点。先来看I/O intensive,我们进行的数据处理，大致可以分为CPU intensive与I/O intensive两类。顾名思义，前者需要大量的CPU运算，这在模拟中非常常见，后者需要大量的磁盘读写操作，这在数据清洗中非常常见。绝大多数的经济学研究中遇到的数据处理需求是I/O intensive的，这由学科性质所决定：社会科学注定要搜集大量原始的“脏”数据并进行诸如删除缺失值、连接表(table join)等各种I/O操作(你想想看你自己写代码的时候是不是把绝大部分时间花在这些事上了)，而自然科学的数据一般更加规范，它们会花更多时间在计算上，你看matlab的字符串函数远不如SAS的字符串函数强大就知道理工科其实对于数据处理的要求远没社会科学多。

其次，我们的编程活动又可以分为interactive与programmatic(在SAS中称为batch mode)两类，前者是一个探索的过程，这在我们写论文的时候很常见。因为几乎没有时候我们一开始就知道模型应该如何设定，大牛们写文章也是各种“play with your data”、“try-and-error”过来的，因此我们需要不断尝试与修改我们的代码，往往在所有coding时间中，95%的是用来调试，而只有5%的时间是用来复用最终版本的代码。甚至在我们获得那个“最终版本”的代码后，我们的文章也写完了，代码也就没用了。相反，在生产环境中，更多需要的是programmatic的编程，比如程序员花了5%的时间在开发环境中写完了一段代码，剩下95%的时间都是这段代码在生产环境中的不断复用。

为什么说这两大特征使得R的语法产生优势了呢？首先，I/O intensive决定了你大多数coding的时间都会花在数据清洗上，因而你需要寻找一门在data manipulation上语法非常简洁的语言；其次，interactive的编程需要你拥有快速将想法转化为代码的能力，转化代码的时间越少，转化后的代码越短，越有利于你思考问题。在这两方面，R都具有优势。

举特例子，现在我有全国每个省的GDP，然后我想比较下每个省和全国的均值相差多少。如果用SAS，那么我首先需要用proc means来统计全国的均值，然后通过output语句将结果输出，假设输出数据集是means吧，然后我还得把数据集means给join回原来的数据集，关键是在join的过程中还要用到 if _n_ eq 1 then set...这种非常tricky的技巧，这对于初学者和不懂PDV的人简直是噩梦啊！更关键的是，类似的操作我可能经常进行，每次都走一遍proc means – output – join的过程不仅非常繁琐，还可能出错。楼主在coding的过程中经常写了一半回过头看前面，就已经不知道前面的代码是要干什么的了，因为满满的全是proc means和proc sort，这时更别说回过头去看十天半个月前些的代码了，这时唯一能做的就是keep my head beating against the wall了啊！另外作为一个完美主义者，楼主希望每个数据集都能被优雅地、有意义地命名，但是看着那么多proc means输出的数据集楼主真是想死的心都有了啊！逼死强迫症啊！更加更加关键的是，也是我在此着重强调的：不到万不得已，千万不要join table！因为跨表操作，例如join，其过程往往非常抽象，你需要考虑一对多，多对一，多对多这几种SAS中会出现的情况，如果你以前学过SQL，那么可能还会和inner join、outer join、Cartesian product等各种情况搅和在一起，绝对让你欲哭无泪！

那么R是如何解决的呢？如果你使用了R/data.table，那么一行代码就可以搞定：

Dt[,gdp_delta := gdp – means(gdp)]

另外一个SAS中常遇到的问题是“retain/sort的诅咒”(我自创的词，囧)。我们都知道，SAS基本上是逐条处理数据的(sequentially access)的，处理过的数据就被丢弃，如果需要用到前几条的数据，不得不用retain/by或者lag语句，而为了使用retain/by语句，必须提前做一个proc sort步。但可谓成也萧何败也萧何，这种特性给予了SAS处理无限大数据的可能，但是严重影响了语句的灵活性。举一个最简单的例子，我现在有个数据集，记录了某人每天的消费，然后我想建立一个变量统计他的“累计”消费，在SAS中需要用到retain语句，如果有很多个人，我可能还要按照个人ID分组，然后使用first与last变量，代码如下：

procsort data = expense;by id, date;run;

dataa;

retain cum 0;

set expense;

by id date;

if first.date thencum = 0;

cum + expense;

run;

而在R中也只需一行代码：

Dt[,sum := cumsum(expense), by = id]

为了实现一个小小的需求，我不得不多写8行代码，在写这8行代码的过程中，可能我就忘了当初是要做什么了。大家因此可以看出语法的简洁对于interactive编程来说是多么重要。原来，由于SAS语法在处理有些数据的时候不是那么简洁，楼主是MySQL语法和SAS语法混着用的(在SAS中调用SAS/ACCESS访问MySQL)，现在，除了数据实在太大放不进内存只好用SQL语法，楼主处理数据已经全部换成了R。这种转换带来的最直观的变化是代码行数要少了很多，这为我日后回顾代码带来了巨大的便利。

以上是我一直在强调经济学研究编程I/O intensive与interactive特性的原因：虽然SAS data step – proc step的philosophy可能在总体上有着更好的performance和robustness，但是毕竟我的目标是学术探索，代码是我思考的工具而不是卖给别人的产品，因此我需要有一种语法尽可能直观简介地表达我的需求，而不是某种运行更快但是冗长的语法，我在coding上花的时间越少，我在research上花的时间就越多。我在这引用R社区开发大神HadleyWickha的话，这个戴耳钉的assistant professor在谈到为什么会开发plyr、dplyr等包的时候说到：“程序员都说数据挖掘中70%的时间都花在数据清洗上面了，数据清洗不仅是数据挖掘的第一步，而且还会在整个数据挖掘的过程中不断重复，但是似乎专门研究如何减少这70%的数据清洗时间的研究还很少。我的plyr/dplyr/tidyr包就是为此而生的。我希望你们能用宝贵的时间去做更多更重要的事。”Thanks Hadley,thanks Matt, both of you you save my life.