数据科学的历史、开拓者和现代趋势

数据科学的历史、开拓者和现代趋势随着数据科学的发展，其他相关专业出现了下降趋势，如统计学和计算机科学。谷歌的公开数据(见http://bit.ly/1aF8D5T)如下

自2010年以来，数据分析师的数量不断增加。

自2005年以来，统计学家的数量有所减少。

自2005年以来，计算机科学家的数量有所减少。

自2012年以来，数据科学家的数量激增。

你可以在LinkedIn或Indeed上找到其他的公开数据(每个招聘广告的申请人数)，不过这个数据跟招聘市场相关。

其他类似的数据显示，所有传统领域的人数都在减少，比如六西格玛、数据挖掘、统计学、运筹学等。谷歌数据表明，在2011年左右大数据开始出现并呈指数增长趋势，到2013年大数据比数据挖掘和六西格玛更流行了。同样也是根据谷歌数据，尽管大数据的崛起引人注目，但开始于2006年对“分析”这个关键词的搜索量更为壮观。在2012年搜它的人数逐渐减少，但仍然比大数据高出6倍。

当然，在2000年，许多专业人士(包括我)，做了统计学、运筹学、计算机科学、六西格玛、精算学、生物统计学，或一些其他的狭义定义的“分析类”活动，积累了丰富的经验、领导能力、广泛的知识、敏锐的商业头脑、跨越许多领域的专业知识。因此他们的职位头衔经历了演变，但他们都有共同点：数据分析行业从业者。同时，数据和现代数据架构的发展，如MapReduce，影响了所有行业，成为许多专业人士的共同特性和必备。

注意 数据科学家比数据挖掘更广泛，包括数据集成、数据采集、数据可视化(包括仪表盘)和数据架构。数据科学家还须度量数据科学活动的投资回报率。

统计学将会复兴

很多人都说统计学会消亡，有些主要的统计学家自己也说统计学会消亡。我相信统计科学最终会复兴，但它会更多地应用于大数据，并适应于大数据，且由更少的模型驱动。它将与计算机科学、预测模型、数据挖掘、机器学习、运筹学和六西格玛的某些方面，以及数据库架构结合在一起，被归纳称为数据科学、业务分析、决策科学、数据情报、分析学，或其他一些尚未被创建或重复使用的术语。我们现在正处于分析学革命的中间阶段。

特别是，像我这样的人，虽然有一个新的职位头衔——数据科学家，但仍然做统计学兼职，有时甚至涉足前沿的理论统计学。对我而言，我已从业25年之久，一直使用那些在1750年被认为太复杂、计算能力不够而被抛弃的，但是足够健壮的技术。在1750年，由于当时计算能力的缺乏，导致了1800年左右一批新颖的、对数学友好的技术出现，它们具有简单的公式、方程形式，如最小二乘回归。这个框架一直延续至今，可能是导致传统统计学家人数减少的原因，现在大数据的健壮性比以往任何时候都更重要，当在分布式系统中(在有MapReduce的云中)几分钟就可以处理10亿字节的数据时，计算的复杂度将不再是问题了。同时，大多数现代科学家、地理学家、医生、计量经济学家、运筹学专业人士、工程师等都具备较好的应用统计知识。然而，软件工程师和计算机科学家有时会像记者一样忽略或误用统计科学，如开发的系统里(例如，推荐引擎)有大量未被发现的虚假评论和欺诈行为。最终，统计科学将开始踏足这些领域。

有人说，大多数数据分析师都是统计学家。在我看来，数据分析师是一个初级头衔，通常是一个有工学学士学位或文学学士学位的人。统计学家有更多的理论背景，在大数据出现之前就使用以前开发好的数据模型，并且拥有硕士或博士学位。每天编写SQL查询和报告的人是数据分析师。

我不当统计学家的部分原因是因为美国统计协会：它改变了统计学家这个关键词的意义，这限制了统计学家的发展前景，使其狭窄且单一，只与医药行业、政府(调查、人口普查、政治事务)、小数据(统计学家的大部分收入来源)相关。在过去15年里，该协会一般不参与或跟随基于大数据的新的统计革命。作为一名比利时公民，我可以对比利时统计协会说同样的话。所以这一趋势不仅限于美国，而且也不仅限于(美式)英语国家，还包括法语和荷兰语国家，以及其他语种国家。

统计学家应该非常熟悉计算机科学、大数据和软件——1万变量的10亿行数据，对真正的统计学家应该是小菜一碟。在云中(甚至在笔记本电脑上的流数据)，这个数据量都能够快速处理。第一步是缩减数据，即使你必须保存所有的观测值和变量，仍然可以缩减数据。一个优秀的计算机科学家也能生成置信区间：你不需要因此而成为一名统计学家，只需会使用本书后面讨论的分析桥第一定理即可。计算机科学家和统计学家之间的区别变得越来越小和模糊。但无须担心，虽然你在学校没有学到这些知识(统计学的课程)，你仍然可以在网上学习。

历史与开拓者

现在，让我们来看看数据科学的历史，以及一些在分析学和数据科学领域堪称先驱的公司。首先，看一看从20世纪80年代末开始流行的关键词，和对2022年的一个预测。

1988年的关键词：人工智能。另外还有：计算统计学、数据分析、模式识别、规则系统。

1995年的关键词：网络分析。另外还有：机器学习、商业智能、数据挖掘、投资回报率、分布式架构、数据架构、量化、决策科学、知识管理、信息科学。

2003年的关键词：业务分析。另外还有：文本挖掘、非结构化数据、语义网、自然语言处理(NLP)、关键绩效指标(KPI)、预测模型、云计算、升力、收益率、NoSQL、商业智能(BI)、实时分析、协同过滤、推荐引擎和移动分析。

2012年的关键词：数据科学。另外还有：大数据、分析学、软件即服务(SaaS)、按需分析、数字分析、Hadoop、NewSQL、内存数据分析、机器对机器(M2M)、传感器数据、医疗保健分析、效用分析、数据治理、列数据库。

2022年的关键词：数据工程。另外还有：分析工程、数据管理、数据整形、优化的艺术、优化科学、优化工程、业务优化、数据智能。

这些里程碑让我们对如何利用数据有更通用、更全局、更全面的理解。大约开始于1995年的大数据运动，谷歌是最重要的贡献者之一。谷歌通过引入谷歌文件系统、MapReduce，解决了传统的分布式系统/数据库管理系统(DBMS)的数据库存储容量限制。(人们经常在2003年至2006年期间的行业会议上讨论谷歌的Bigtable大表方案。)然后是HBase和Hadoop分布式文件系统(HDFS)。除了谷歌，雅虎和Facebook也对Hadoop和开源社区做出了重大贡献，推动了技术进步。

专注于分析的先驱公司，有以下26家，可以在它们各自的维基百科页面，找到很多有趣的历史资料。(警告：这些网页，比如维基百科主题页面，包含商业内容，编写者是有利益冲突的人、内部人士或与这些公司利益有关的人。)

Datawatch (http://en.wikipedia.org/wiki/Monarch)Excel (http://en.wikipedia.org/wiki/Microsoft_Excel)FICO (http://en.wikipedia.org/wiki/FICO)Greenplum (http://en.wikipedia.org/wiki/Greenplum)IMSL(http://en.wikipedia.org/wiki/IMSL_Numerical_Libraries)Informatica (http://en.wikipedia.org/wiki/Informatica)KNIME (http://en.wikipedia.org/wiki/KNIME)KXEN (http://en.wikipedia.org/wiki/KXEN_Inc.)Lavastorm (http://en.wikipedia.org/wiki/Lavastorm)MapReduce (http://en.wikipedia.org/wiki/MapReduce)Mathematica (http://en.wikipedia.org/wiki/Mathematica)Matlab (http://en.wikipedia.org/wiki/Matlab)Netezza (http://en.wikipedia.org/wiki/Netezza)NoSQL (http://en.wikipedia.org/wiki/NoSQL)Oracle (http://en.wikipedia.org/wiki/Oracle_Database)PMML (http:/en.wikipedia.org/wiki/Predictive_Model_Markup_Language)R编程语言(http://en.wikipedia.org/wiki/R_)RapidMiner (http://en.wikipedia.org/wiki/RapidMiner)S-PLUS (TIBCO) (http://en.wikipedia.org/wiki/S-PLUS)SAS (http://en.wikipedia.org/wiki/SAS_Institute)Splunk (http://en.wikipedia.org/wiki/Splunk)SPSS (http://en.wikipedia.org/wiki/SPSS)Statistica (http://en.wikipedia.org/wiki/STATISTICA)Sybase (http://en.wikipedia.org/wiki/Sybase)Tableau (http://en.wikipedia.org/wiki/Tableau_Software)Teradata (http://en.wikipedia.org/wiki/Teradata)

此列表重点关注已经有一定历史的大型数据分析公司。在过去几年，无数的参与者如雨后春笋般涌现，特别是在MapReduce生态系统行业。

现代的趋势

在新技术方面，很多当今技术都跟大型分布式数据库的集成分析有关。要让数据架构师、工程师和数据科学家互相沟通，并做二选一的转变——以前是“数据到分析”(传统数据科学方法)，现在是“分析到数据”(是受数据架构师和数据库公司青睐的更为现代的方法，因为它的速度更快)。分析到数据，意味着分析是在数据库或数据存储环境里就近进行的，而不是把数据下载到本地分析它。这减少了多个数据库用户的情况下大量冗余下载的必要。在本章的最后一节中可以读到更多相关的细节。

当然，这归结为在数据库里或就近位置，运用正确而先进的分析工具(不只是提取(Extract)、转换(Transform)和加载(Load)方面，简写为ETL)。当分析是在数据库内部进行时，有时被称为内存数据分析。它是一种更为强大的“分析到数据”的形式，是将分析集成和嵌入到数据库架构中，且主要在快速存储器(内存)中进行，有时还会使用多个服务器。但其中一个问题是，现代数据库处理涉及更复杂的编程语言，而现在大多数人还在使用SQL，要他们改变旧习惯很难。因此，像Pivotal这样的先驱公司发明了一种名为Fast SQL的系统，使那些习惯SQL的程序员不需要学习新的、更加复杂的语言，并且代码优化是在Hadoop(一种分布式架构)下运行的。

其他现代趋势包括自动化的机器到机器实时通信，在高频交易策略或大规模竞价系统里都有使用。一个例子是eBay基于谷歌的点击付费关键词过去的效果(当历史记录可用时)，或对没有历史记录的新关键词分析计算其得分，每天实时更新1 000万个关键词出价。这些机器到机器的通信都是通过API或AaaS(分析即服务，按需求提供)。API调用无非是HTTP请求(实际上，大多数情况下都是HTTPS请求)，通过查询字符串参数(用XML格式编码的键/值对)，指定所需的服务类型(如关键词的价格和数量的预测)。

此外，现代数据如此不同和独特是因为它的多样性(有时是Twitter推文的非结构化格式，有时是来自移动设备或传感器的结构化良好的数据)、产生速度和数量，这使得传统的统计分析并不总是那么合适。

概括说，下面这些都是数据科学现代趋势的特征。

内存数据分析。MapReduce和Hadoop。NoSQL、NewSQL和图形数据库。Python和R。数据集成：混合非结构化和结构化的数据(如数据存储和安全性、收集数据时的隐私问题，以及数据的合规性)。可视化。分析即服务，简写为AaaS。文本分类或标签和分类系统，以便于从原文本中获取洞见力，给非结构化数据加上结构。

最后提一下Perl，它是伟大的编程语言，5年前比较流行，却是现代编程环境的牺牲品。它已经被Python及它的分析和图形库取代。虽然Perl非常灵活，且无须专注于代码的编写，但Perl程序维护困难且成本高。Perl没能在现代灵活而精简的环境中存活下来。也有些人说，最优秀的分析工具Excel也会消亡，但我并不这么认为。现代版本的Excel使用云服务，从互联网上获取数据，并将其存储在多维数据表里。

最近的问答讨论

最近我与不同社区的数据架构师进行了以下讨论，特别是(但不仅局限于)同LinkedIn上数据仓库研究所(TDWI)的小组成员进行讨论。他们阐述了一些在新的分析革命完成之前，仍然需要解决的挑战。以下是数据架构师和数据库管理员询问的几个问题，以及我的答复。这些问答跟在SQL查询中优化连接操作有关，或干脆跟SQL无关。一些现代数据库提供了许多功能，包括哈希表连接和可以由最终用户进行微调的查询优化程序。该讨论说明了数据科学家、数据架构师和业务分析师之间的冲突。它还涉及许多创新的概念。

问题：你说SQL的瓶颈之一是用户写查询是通过3个连接实现的，这些查询何时可以分成两个查询，每个查询两个连接?你能详细说明吗?

答案：通常，我写SQL代码的方式是将它嵌入到一种编程语言里，如Python，且在内存中储存我需要的所有查找表，如哈希表。所以我很少有做连接操作，当我这样做时，它顶多只是两个表格。

在一些(罕见的)情况下，查找表太大，而无法放入内存中，所以我使用抽样的方法，且使用子集和聚合规则。一个典型的例子是，你的数据集(如网页日志文件)的一个字段是一个用户代理(即浏览器，简称UA)。如果你有更独特的UA数据，在内存中装不下，但只要你保留1 000万个最受欢迎的UA，并把2 000万个罕见的UA分到几百万类别里(基于UA字符串)，在大多数应用中能得到很好的结果。

作为一个算法专家(不是SQL专家)，我花了几分钟通过Python中的哈希表(使用自己的脚本模板)，做了一个高效的四表连接。我所做的绝大部分都是进阶分析，而非数据库聚合：它们涉及先进的算法，但在Python中编码很简单，如隐性决策树。总之，对于非专家级SQL用户，如业务分析师，是培养他们写出更好的SQL代码，包括复杂的连接，还是培养他们学习将Python跟SQL代码混合编程，哪种方法更简单、更有效?

具体而言，我心目中的系统是不需要很频繁地从系统下载查找表(也许一周一次)，但需要比较频繁地访问主表(事实数据表)。如果你必须非常频繁地上传查找表，那么Python方法将失效，且你的同事会不高兴，因为你经常下载，从而降低了整个系统的速度。

问题：像你这样(运行Python或Perl脚本访问数据库)的人会是数据库管理员(DBA)的噩梦。你不觉得你是给DBA带来问题的根源吗?

答案：因为我更擅长Python和Perl而不是SQL，我的Python或Perl代码是无错误、易于阅读、易于维护、最优化、稳健和可重复使用的。如果我用SQL编码，则它的效率是很低的。我所做的大部分工作是算法和分析(机器学习的东西)，而不是查询数据库。我只是偶尔下载查找表到我的本地机器(保存为哈希表和存储为文本文件)，因为大多数情况下每周变化不大。当我需要更新时，我只需提取上次更新后添加的新行(基于时间戳)。在运行处理数据量很大的SQL脚本之前，我会进行一些测试，以了解它会消耗多少时间和资源，看看我能否优化。我是一个SQL用户，就像所有的统计学家或业务分析师一样，不是一个SQL的开发者。

但我同意，我们需要找到一个平衡，以尽量减少数据传输和处理，就近运用更好的分析工具。至少，我们需要能轻松地在非生产数据表和系统里部署Python代码的能力，并且需要合适的磁盘空间(也许200 GB)和内存(至少几GB)。

问题：你偏好的编程语言是什么?

答案：有些人更喜欢使用脚本语言，而不是SQL。人们认为SQL可能不够灵活且易于出错，产生错误后没人注意到，因为连接操作中有Bug。

你可以写简单的Perl代码，易于阅读和维护。Perl可以让你把精力集中于算法，而不是代码和语法。不幸的是，许多Perl程序员写的代码晦涩难懂，这使得Perl有了坏名声(在代码的维护和可移植性方面)。但是，不一定都是这种情况。

你可以使用多个SQL语句和视图，把一个复杂的连接分解成几个较小的连接。你可能认为，数据库引擎会帮你整理这种分解过程，把不那么高效的SQL代码变得更加有效。至少你可以测试这种方法，看看它是否和一个有许多连接的、单一的复杂查询的运行速度一样快。分解多个连接成几个简单的语句，让业务分析师编写简单的SQL代码，也便于其他程序员重用或维持。

看到一些软件自动修正SQL语法错误(不是SQL逻辑错误)是件有趣的事情。这将为很多像我这样的、非专家级的SQL程序员，节省很多时间，因为经常重复发生的拼写错误，可以自动修正了。同时，你可以使用图形用户界面(GUI)生成合适的SQL代码，利用大多数数据库厂商或开放源码提供的工具，如适用于Oracle的Toad。

问题：你为什么说这些内置的SQL组合优化器，对于终端用户是黑盒技术呢?你认为参数不能由终端用户调整吗?

答案：我总喜欢对我做的事情有所控制，虽然不一定是全部控制。例如，我比较满意Perl处理哈希表和内存分配的方式。我宁愿用Perl黑盒内存分配或哈希表管理系统，而不是像C语言那样要自己从头开始，或更糟糕的是，要编写一个编译器。我只是有点担心黑盒优化——我看到过非专家级用户鲁莽地使用黑盒统计软件而造成的危害。如果我至少有一点控制，我会感觉更舒服，甚至只是简单地给DBA发送电子邮件，让她帮助改善我的查询语句，让她帮助解决我的疑问，也许只是微调组合优化器，这对所在组织和其他用户是有必要和有益的。

问题：你不认为你的方法已经过时20年了吗?

答案：结果比方法更重要，只要该过程是可重复的。无论我用什么工具，只要我能打败竞争对手(或者帮助我的客户打败竞争对手)，正如有人曾说过，“如果没有坏掉，就不要修理它。”有时我使用API(例如，谷歌的API)，有时我用网络爬虫收集外部数据，有时使用Excel或优秀的数据库，有时(不使用任何数据)依靠肉眼、敏锐分析和直觉，效果都很好。有时我使用统计模型，有时非常现代的架构也是必要的。很多时候，我使用这些技术的组合。

问题：为什么你要问“数据到分析”方法是否有意义?

答案：我问这个问题的原因是，因为有些事情一直困扰着我：基于不算过时的观察(不超过三四年)，我提到的一些做法在数据分析领域里已经根深蒂固(分析是指机器学习、统计学和数据挖掘，而不是ETL)。这也是一个尝试，看看是否有可能在数据科学家和数据架构师这两个非常不同的社区之间建立一个更好的桥梁。数据库搭建者经常(但并不总是)需要数据科学家对组织好的数据提炼出见解和价值。而数据科学家经常(但并不总是)需要数据架构师建立优秀的、快速的、高效的数据处理系统，这样他们就可以更好地专注于分析了。

问题：所以本质上你维护缓存系统，对查找表的本地副本定期进行小的更新。两个像你一样的用户，做着同样的事情，过一段时间后，会得到两个不同的副本。你如何处理该问题?

答案：你是正确的，两个用户有两个不同的查找表副本(缓存)，造成了问题。虽然对我来说，我倾向于与其他人分享我的缓存，因此它不像5人在研究5个不同版本的查找表。虽然我是一个高级数据科学家，也是一个设计师或架构师，但不是一个数据库的设计师或架构师，所以我倾向于有我自己的、与团队分享的本地架构。有时我的架构存储在一个本地的小数据库里，偶尔会存在生产数据库里，但很多时候是作为有组织的普通文件或哈希表存储在本地驱动器上的，或保存在数据库服务器以外的云里的，但如果数据量大，那么数据库到云的距离不会太远。很多时候，我最重要的“表格”是总结摘要表——要么是很容易用纯SQL生成的简单聚集表，要么是复杂的交易得分(按客户、日期、商户或更细的颗粒度评分)，所用的算法太复杂了，以至于使用SQL不能有效地编码。

我的“缓存”系统的好处是尽量减少耗时，减少对系统内其他人的影响。其缺点是，我需要维护它，并且本质上我是在复制数据库系统本身的进程。

最后，对于研究数据的统计学家来说，只要数据是几乎正确的(是指查找表不是最新版本的，而是“缓存”系统中存储的没有频繁更新的)，甚至说数据只是抽样，这都不是问题。通常，收集的数据是我们试图采集和度量的信号的近似——所以数据难免混乱。对预测模型来说，不管是从数量适量的数据集(我的“缓存”)，还是原始、最新的数据集，或者是认为注入5%噪声的数据，所能得到的投资回报率——在大多数情况下几乎相同。

问题：你可以对代码的维护和可读性做些评论吗?

答案：如果某人写了晦涩的SQL，在他离开公司后，或更糟的是，当SQL移植到不同的环境(不是SQL环境)时，这对于要了解原始代码的新程序员来说，是一场噩梦。如果可读性好的SQL(也许包含更多语句，更少的高维连接)运行速度和复杂的SQL语句一样快，这得益于内部对用户透明的查询优化程序，那么为什么不使用易读的代码代替呢?毕竟，优化程序应该使这两种方法是等价的，对吗?换句话说，如果两段代码(一个短但晦涩难懂;一个较长，易于阅读、维护和移植)具有相同的效率，既然它们本质上会被优化器变成相同的伪代码，那我喜欢较长的版本，因为它的编写、调试、维护等需要更少的时间。

那些能将难看、晦涩但高效的代码变成好看、易于阅读的SQL的工具，如“SQL美化器”，可能有市场。当将代码移植到不同的平台时，它是很有用的。虽然在一定程度上，这已经存在了，但你可以很容易地对数据库系统所有的查询或查询集进行图表化和可视化。SQL美化器在某些方面类似于一个能把汇编语言转化成C++的程序——简而言之，是一个反编译器或解释器。

本文作者 Vincent Granville (美国)， 吴博、张晓峰、季春霖参与编译