作者：（美）布瑞恩·戈德西（Brian Godsey）
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
数据即未来：大数据王者之道试读：
前言
2012年，《哈佛商业评论》中的一篇文章将数据科学家誉为“21世纪最性感的职业”。公平地说，在本世纪剩下的87年里，这个说法可能会有所改变。虽然现在数据科学家的确得到了很多关注，介绍数据科学的书籍也正在激增。但是，仅仅把从别处能够找到的文字重复一下或者将其重新包装成另一本书毫无意义。在研究了数据科学的新文献后，我发现大多数作者愿意解释如何使用各种最新的工具和技术，却不愿意详细地讨论数据科学中解决问题的过程。有抱负的数据科学家在熟读了几本书并掌握了最新算法和数据存储知识后，仍然会问同一个问题：应该从哪里开始？
所以，虽然这也是一本介绍数据科学的书，但本书试图引导读者通过存在很多歧路、陷阱并且目的地未知的数据科学之路，对可能发生的意外提出警告，让读者做好准备，并给出如何应对意外的建议。虽然本书将会讨论哪些工具可能最有用及其原因，但主要目标始终是为学习数据科学的过程引路导航，以便在现实生活中智慧、高效、成功地找到以数据为中心的问题的实际解决方案。致谢
感谢Manning出版社中每一位曾帮助我让本书成为现实的人，也感谢Manning出版人Marjan Bace给我这个机会。
我还要感谢Mike Shepard对本书技术方面所做的评估，感谢在手稿写作过程中提供了有益反馈的审稿人。这些人包括Casimir Saternos、Clemens Baader、David Krief、Gavin Whyte、Ian Stirk、Jenice Tom、ukasz Bonenberg、Martin Perry、Nicolas Boulet-Lavoie、Pouria Amirian、Ran Volkovich、Shobha Iyer和Valmiky Arquissandas。
最后，我要特别感谢在Unoceros和Panopticon实验室的现任及前任队友，他们以多种形式为本书提供了充足的素材，包括：软件研发和数据科学的经验与知识、富有成果的对话、疯狂的想法、有趣的故事、尴尬的错误，最重要的是愿意满足我的好奇心。关于本书
数据科学目前仍然戴着新领域的光环。它的主要组成部分（包括统计学、软件研发以及基于证据的问题求解等）都是从成熟甚至传统领域直接继承而来的。但数据科学似乎是一个新组合，由某些新的或者至少在当前公共交流场合感觉是新的的东西组成。
像许多新领域一样，数据科学还没有找到自己的立足点。与其他相关领域的界限仍然模糊。数据科学依赖（但是不等同于）数据库架构与管理、大数据工程、机器学习或者高性能计算等。
数据科学的核心并不关注数据库的具体实现或者编程语言，即使这些内容对从业者而言是不可缺少的。其核心在于数据内容之间的相互作用，给定项目的目标以及用于实现这些目标的数据分析方法。当然，数据科学家必须使用必要的软件来进行管理，但选择哪些软件以及如何实施，这些细节在我的想象中已经被抽象化，好像是存在于某个遥远未来的现实。
本书试图预见未来，把数据科学中那些常见的、生搬硬套的、机械性的任务剥离，只剩下核心：将科学方法应用于数据集以实现项目目标。这就像传统的科学家要用到试管、烧瓶和本生灯一样，数据科学的过程涉及作为必要工具的软件。但关键在于了解内部发生的事情：数据怎么了，我们得到了什么样的结果以及为什么会这样。
本书将介绍各种各样的软件工具，但只做简单描述。因为读者总可以从其他地方找到更全面的介绍，并且我希望深入探讨这些工具可以为你做些什么以及如何助力研发工作。本书内容始终聚焦在数据科学项目中特有的概念和挑战，以及组织与利用现有资源和信息实现项目目标的过程。
要从本书中获得最大的收益，就应该掌握初级统计学（这可能是大学中的一两门课程），同时具备编程语言的基本知识。如果你是统计学、软件研发或者数据科学方面的专家，可能会觉得本书某些部分的讨论进度缓慢或者微不足道。但没关系，你可以跳过这些内容。我不希望更新任何人的知识和经验，但希望通过提供一个概念性的框架，为完成数据科学项目的工作提供必要的补充，并以建设性的方式来分享自己的一些经验。
如果你是数据科学的初学者，欢迎来到这个领域！本书试图使具有一定技术能力的人能够理解所描述的概念和主题。同样，数据科学家与研发人员的同事和经理也可以通过阅读本书，从内部更好地了解数据科学过程的机制。
对于每个读者，我希望本书都能够生动地描绘数据科学作为一个过程所具有的许多细微差别、注意事项和不确定性。数据科学的力量不在于弄清楚下一步将会发生什么，而是能够意识到下一步将会发生什么，并最终发现下一步到底发生了什么。我真诚地希望你能喜欢本书，更重要的是能学到一些东西，以提高未来项目成功的机会。路线图
本书分为三部分，分别代表数据科学过程的三个主要阶段。
第一部分将介绍准备阶段：
·第1章描述面向过程的数据科学项目观点，并介绍一些贯穿本书的主题和概念。
·第2章涵盖为项目设定合适目标的细致且重要的步骤。强调与客户互动以提出要解决的实际问题，同时对解决这些问题的数据能力持务实的态度。
·第3章深入数据科学项目的探索阶段，该阶段试图发现有用的数据源。这一章会讨论有用的数据发现和存取方法，以及选择项目中使用的数据源时要考虑的重要事项。
·第4章简要介绍数据整理，即处理好未加梳理的原始数据或非结构化数据以供应用的过程。
·第5章讨论数据评估。在发现并选择数据源以后，本章将介绍如何对所拥有的数据进行初审，以便更明智地制定后续的项目计划，并对数据用途有合理的预期。
第二部分涵盖构建阶段：
·第6章介绍如何利用学到的探索和评估方法，制定实现项目目标的计划。这一章特别关注规划未来产出与结果的不确定性。
·第7章将转到统计学领域，介绍各种重要的概念、工具和方法，特别是它们的主要功能以及如何在其帮助下达成项目目标。
·第8章将讨论统计软件，目的是让你有足够的知识为项目选择合适的软件。
·第9章对一些流行的非专业统计软件工具进行概述。虽然这些软件工具属于非统计专业，但也有可能让产品的构建和使用变得更容易或者更有效。
·第10章利用前面学到的统计和软件知识，通过讨论项目计划的执行，将第7章、第8章和第9章的内容融合起来，同时考虑有些难以识别的细微差别以及在处理数据、统计和软件过程中遇到的许多陷阱。
第三部分讨论完成阶段：
·第11章将讨论优化和策划产品内容及形式所带来的好处，从而简明地把结果传达给客户，有效地解决问题并实现项目目标。
·第12章将讨论产品交付后可能发生的事情，包括发现缺陷、客户使用效率低以及产品需要改进或修改等。
·第13章将对如何清楚地保存项目，传承所吸取的经验教训，以提高未来项目成功的机会给出建议。
除第1章外，每章结尾都附有练习题，练习题的答案和样例在本书的最后提供。关于原书封面插图
本书封面上的人物是“斯特雷利茨的武器警卫兵”。斯特雷利茨（Strelitz）警卫是18世纪俄罗斯帝国莫斯科军队的一部分。该图来自于1757年到1772年间伦敦出版的托马斯·杰弗里斯（Thomas Jefferys）的《A Collection of the Dresses of Different Nations,Ancient and Modern》。该画为加了阿拉伯树胶的手工彩色铜版画。托马斯·杰弗里斯（1719～1771）被称为地理学家中的“乔治三世”，这位英国制图人是当时领先的地图供应商，为政府和其他官方机构刻印地图，并且出版了大量商业地图和地图集，特别是关于北美洲的。制图者的工作激发了他对所绘地图上各地区服饰习俗的兴趣，这些图画在四卷图集中被很好地展示出来。
在18世纪，迷恋遥远的土地和旅行乐趣是相对较新的现象，而通过画卷向旅行者和坐在扶手椅子上的神游者们介绍其他国家居民的做法则较为流行。杰弗里斯在画卷上把一个世纪前世界各国的特点娓娓道来。而后，着装的规范发生了变化，地区和国家一度如此丰富的多样性，也已经在逐渐消失。现在已经很难把来自于不同大陆的居民分辨出来。当然，对此或许我们可以试着乐观地看待，我们已经把文化与视觉的多样性转换为更加多样化的个人生活或更加多元和有趣的智力与技术生活。
在这个计算机书籍变得日渐相同的时代，我们选择了托马斯·杰夫里斯的画作为封面，从而将我们带回到过去的生活中，并赞颂计算机产业所具有的创造性、主动性和趣味性。第一部分 准备和收集数据与知识
数据科学的过程从准备开始。你需要弄清楚自己到底知道什么，拥有什么，能得到什么，起点在哪里以及终点在哪里。最后一个问题至关重要，数据科学项目需要有目的及其相应的目标。只有明确了目标，才能开始调查可用资源以及实现该目标的所有可能性。
本书的第一部分将从面向过程的视角讨论数据科学项目。此后，迈出为项目设定合适目标的细致而且重要的一步。随后三章将涵盖过程中三个以数据为中心的重要步骤：探索、整理与评估。在第一部分的结尾，你会熟悉所拥有的数据和可以获得的相关数据。更重要的是，可以知道它们是否有助于实现项目目标。第1章 数据科学的逻辑本章内容：
·数据科学家的角色及其与软件研发人员的区别
·意识是数据科学家最宝贵的资产，特别是存在重大不确定性时
·阅读本书的前提：软件研发和统计学的基础知识
·设定项目的优先级，同时保持大局观
·最佳实践：使项目过程更加轻松的小贴士
接下来，我将把数据科学作为以数据为中心的项目中指导项目开展和决策的一系列过程和概念来进行介绍。这个观点与“数据科学是一组统计学和软件工具以及使用这些工具的知识”有所不同，根据我的经验，该观点在关于数据科学的对话和文字中更加流行（见图1-1中幽默的数据科学观点）。并不是说这两个观点互相矛盾，实际上它们是互补的。但是，厚此薄彼是愚蠢的，所以本书无论从实践上还是思想上都将侧重于讨论得较少的那一边，即过程论。图1-1 一些关于数据科学的固有观点
以木工作类比，知道如何使用锤子、钻头和锯并不等于知道如何做一把椅子。同样地，如果知道怎么做一把椅子，并不意味着你在制作过程中可以很好地使用锤子、钻头和锯。要做一把好椅子，就必须知道如何使用工具，特别是如何一步一步地使用它们。在本书中，针对工具，我试图讨论到足以了解它们是如何工作的为止，但我会更加注重介绍应该在什么时候用、怎么用以及为什么用。我会不断地提出和回答问题：下一步应该做什么？
本章将使用相对高层的描述和例子，讨论为什么数据科学家的思考过程比所用的工具更重要，以及某些概念是如何渗透到数据科学工作的几乎所有方面的。1.1 数据科学与本书
作为研究或者职业，数据科学起源于统计学与软件研发之间。如果统计学是设计图，那么软件就是机器。无论在概念上还是在实际上，数据都与统计学和软件相关，数据科学之所以能够在最近几年备受青睐，实际上归功于那些统计学和软件交叉而产生的传统领域，诸如运筹学、分析学和决策学。
除了统计学和软件以外，许多人认为数据科学还包括第三个主要部分，即与主题有关的专业知识。在试图解决问题之前清楚地理解问题固然很重要，但更为重要的是优秀的数据科学家可以在不同专业之间切换，并能够很快地发挥作用。就像一个出色的会计师能快速地掌握新行业在财务方面的细微差别一样，一个优秀的工程师可以抓住不同种类产品的特点从而完成设计，一个好的数据科学家也可以切换到全新的领域并在短时间内开始发挥作用。这并不是说专业知识的价值不大，只是与软件研发和统计学相比，数据科学家通常需要在最短的时间掌握足以帮助其解决涉及数据的问题的专业知识。这也是三个组成部分中唯一的可换部分。如果你胜任数据科学的工作，那么你可以参加全新的以数据为中心的项目规划会议，房间里几乎每个人都有你所需要的专业知识，但几乎没人有能力编写良好且可以解决问题的分析软件。
在本书中，你可能已经注意到，在描述软件、项目和问题时，我选择使用术语“以数据为中心”而不是更流行的“数据驱动”，因为我发现数据驱动的概念具有误导性。只有当所构建的软件被明确地用于移动、存储或以其他方式处理数据时，才能称为数据驱动。如果软件是为了处理项目或业务目标，那么不应由数据驱动。那样做将会本末倒置。问题和目标的存在独立于任何数据、软件或其他资源，但这些资源可用于解决问题和实现目标。“以数据为中心”反映了数据是解决方案的组成部分，并且我相信，使用“以数据为中心”而非“数据驱动”说明不是从数据角度，而是从目标（即数据可以帮助解决问题）的角度看待问题。
有关适当角度的陈述在本书中经常出现。每一章都试图让读者聚焦在最重要的事情上，当项目结果存在不确定性时，我会试着给予指导，帮助你确定重点。从某种意义上说，我认为能够定位并持续专注于项目中最重要的方面是最有价值的技能之一，也是本书试图讲授的内容。数据科学家必须拥有许多硬技能，其中包括软件研发和统计学的知识，但是，在解决以数据为中心的问题时，保持适当的角度并意识到许多动态因素对大部分数据科学家而言，是重要的软技能，掌握该技能虽然非常困难，但是十分有益。
有时候，重点是数据质量；有时候，重点则是数据规模、处理速度、算法参数、结果解读或问题的许多其他方面。当它变得重要但却被忽略时，就可能陷入危险甚至使后续结果完全无效。数据科学家的目标是确保项目的重点不被忽视。也就是说，当某件事情出错或将要出错时，能注意到并解决它。本书将不断强调保持对项目各方面意识的重要性，特别是那些结果可能存在着潜在的不确定性的地方。
如图1-2所示，数据科学项目的生命周期可以分为三个阶段。本书将围绕着这三个阶段展开讨论。第一部分讨论准备工作，强调在项目开始时投入时间和精力去收集信息以避免后期出现令人头疼的问题。第二部分讨论把计划付诸行动，利用从第一部分了解到的知识，以及统计学和软件可以提供的所有工具，为客户构建产品。第三部分讨论项目的完成，包括交付、反馈、修改、支持及干净收尾。每个阶段的讨论也包括了一些复盘的内容，经常要求读者重新考虑前面步骤中已经完成的工作，如果有好主意则可以采用其他的方式。作为想利用数据来获取有价值结果的数据科学家，在读完本书后，你应该能够在决策过程中牢固地掌握这些思考过程和注意事项。图1-2 数据科学的过程1.2 意识的可贵
如果每次某个分析软件工具崩溃就给我1块钱，那么我会成为一个大富翁。我并不认为所有的分析软件工具都好用或毫无用途，情况肯定不是这样的，但我认为这引发了一场讨论，即在数据科学家与纯软件研发人员的视角之间存在着极大的差异，因为软件研发人员通常不与原始或“未经整理”的数据打交道。
有个很好的例子能说明这种差异。一个刚起步的初创公司的创始人来问我，他想从与即将到来的旅行相关的电子邮件中提取姓名、地点、日期和其他关键信息，以便将这些数据用于移动应用，从而跟踪用户的旅行计划。创始人的问题具有共性：电子邮件和其他文档的格式及大小不同，从中分析出有用的信息具有很大的挑战性。很难提取旅行相关的特定数据，因为来自于不同航空公司、酒店、预订网站等的电子邮件的格式不同，更不用说这些格式还会频繁变化。谷歌和其他公司似乎在自己的应用中拥有更好的工具来提取数据，但很可惜这些工具一般不对外提供。
创始人和我都意识到，解决这个难题一般有两个方案：手工处理和脚本处理，也可以两者混用。由于手工处理需要为每种邮件的格式创建模板，每当电子邮件的格式发生改变，就需要生成新模板，我们都不想走这条路。脚本可以解析任何电子邮件并提取相关的信息，这个方案听起来很棒，但却相当复杂，几乎无法完成。同往常一样，在这两种极端方法之间加以折衷似乎是最好的。
在与该公司的创始人和软件研发负责人讨论后，我建议他们在人工处理和纯脚本分析之间折衷：针对最常见的格式研发一些简单的模板，用于检查相似度和常见的结构模式，然后写一个简单的脚本，在新邮件中寻找与熟悉的HTML或文本模板匹配的部分，从这些部分中已知的位置提取数据。我称这个不好也不坏的办法为算法模板。这个建议显然不能完全解决问题，但却是在正确的方向上迈出了一步，更重要的是，可以基于最常见的格式洞察共同结构模式，并聚焦未知但可能容易解决的具体挑战。
软件研发人员提到，他已经开始使用一种流行的自然语言处理（NLP）工具来构建解决方案，该系统可以识别和提取日期、姓名和地点。他认为自然语言处理工具将解决这个问题，并且在完全实现后通知我。我告诉他自然语言的分解和分析都很棘手，我对自然语言处理工具的信心没有他那么大，但希望他是正确的。
几星期后，我再次见到该公司的创始人和软件研发负责人，被告知自然语言处理工具不能解决问题，所以他们再次请求我的帮助。自然语言处理工具可以识别大多数的日期和地点，但是，他们向我转述了一个事实，“大多数情况下，在有关航班订票的电子邮件中，首先出现预订日期信息，然后才是出发日期、到达日期，然后可能是回程航班的日期。但对于一些HTML格式的电子邮件，预订日期出现在出发日期和到达日期之间。对此，我们应该怎么办呢？”
很明显，自然语言处理工具不能100%解决问题，但一定程度上确实解决了一些问题，比如识别姓名和日期，即使不能准确地把这些信息放在旅行计划中。我不想夸大其辞或断章取义，对数据科学家来说这是个棘手的问题，对其他人而言更是个棘手的问题。第一次尝试无法解决这个问题并不是彻底失败。后来项目的这个部分被搁置了几星期，期间我们三个人试图寻找一位经验丰富的数据科学家，让他有足够的时间来帮助解决这个问题。但对于初创企业或任何公司来说，这样的延迟代价昂贵。
我从这个案例中学习到的教训是：当处理涉及数据的问题时，意识是非常有价值的。一个优秀的研发人员，使用良好的工具来解决一个似乎非常容易处理的问题，如果没有考虑到许多会出现的可能性，当代码开始处理数据时，可能会遇到麻烦。
不确定性是冷冰冰的逻辑算法的对手，知道这些算法在某些情况下可能会出问题，就能在问题发生时加快解决问题的进程。数据科学家的主要职责是尝试想象所有的可能性，解决每种可能性中出现的问题，并在每一次成功和失败后重新评估。这就是为什么无论写多少代码，作为数据科学家，我可以提供的最有价值的东西依旧是对不确定性的意识。有些人可能会告诉你不要在工作中做白日梦，但如果你能想象到某件事会出错，并为此做好准备的话，想象力就是数据科学家最好的朋友。1.3 研发人员与数据科学家
优秀的软件研发人员（或工程师）与优秀的数据科学家拥有共同的品质。他们都擅长设计和构建由许多相互关联的部分组成的复杂系统；他们都熟悉构建这些系统所需要的许多不同的工具和框架；他们都善于在系统实现之前，预见到系统中可能存在的问题。但是，在一般情况下，软件研发人员设计由许多定义良好的组件构成的系统，而数据科学家使用的系统，至少有一个组件在构建之前没有被很好地定义，并且该组件通常与数据处理或分析密切相关。
软件研发人员和数据科学家的系统可以分别与数学概念中的逻辑和概率类比。“若A，则B”这样的逻辑语句可以很容易地用编程语言完成编码，在某种意义上，每个计算机程序都是由许多这样的语句根据各种场景构成。“若A，则可能B”这样的概率语句并没有那么简单。任何良好的以数据为中心的应用都包含许多这样的语句，例如谷歌搜索引擎（“很可能是最相关的网页”）、亚马逊网站上的产品推荐（“我们觉得你可能会喜欢这些东西”）、网站分析（“你的网站访问者可能来自于北美洲，每次访问可能会浏览三个页面”）。
数据科学家专注于创建依赖数据和结果的概率陈述的系统。在前面从电子邮件中发现旅游信息的案例中，我们可以做这样的陈述，例如，“如果知道邮件包含出发日期，那么自然语言处理工具就可能提取这些数据。”对于优秀的自然语言处理工具而言，有一点儿蛛丝马迹，陈述就有可能是真实的。但如果因为过于自信而在重新声明时不用“可能”一词，这个新的陈述就不太可能是真的。尽管有时候可能是真的，但肯定不会总是真的。这种确定性概率的混乱，正是大多数软件研发人员在数据科学项目开始时所必须克服的挑战。
软件研发人员来自于软件规范、记录完备或开源代码库的世界，产品功能要么好用要么不好用（“报告一个缺陷！”），软件似乎与不确定性概念无关。可以大致上把软件比作汽车，如果拥有所有合适的部件，并把它们以正确的方式装配起来，汽车就能运转良好。如果有操作手册，就可以开着汽车去任何想去的地方。如果汽车不能正常运转，那么很可能是哪里出了问题并且可以修好。在我看来，这和纯软件研发没有差别。而制造能穿越沙漠的自动驾驶赛车更像数据科学。这并不是说数据科学像自动驾驶赛车那样酷，而是说你永远都无法知道汽车是否会到达终点，或者任务是否能完成。在这个过程中存在着太多的未知因素和随机变量，根本无法保证汽车会跑到哪里，甚至无法保证汽车可以完成比赛，直到有一辆汽车到达终点。
如果有一辆自动驾驶汽车完成了赛程的90%，但在途中被暴雨冲到沟里，那么说这辆自动驾驶汽车不工作是不恰当的。同样，如果汽车在技术上没有穿过终点线，而是绕过终点并继续行驶了100英里，说它不工作也是不恰当的。此外，如果驾驶为正常道路设计的自动驾驶汽车去参加沙漠越野赛，结果车被困在沙丘上，随后宣布该车不合格，这么做也是不恰当的。我觉得这就像当将专门设计的以数据为中心的工具应用于其他目的时，得到的结果不好，便宣布该工具不行一样，这同样是不合适的。
有个更具体的例子，假设某网站告诉你“典型用户会访问我们网站的前四页”。假设你利用新数据集对网站的使用情况进行分析，结果发现用户平均会访问网站的8个页面。这是否意味着有错误？该用中位数时，误用平均数了吗？新数据包括了不同类型的用户或访问方法了吗？这些问题通常是数据科学家，而不是软件研发人员要回答的，因为它们涉及数据探索和不确定性。基于这些问题和答案所实施的软件解决方案，肯定可以从软件研发人员的专业知识中获益，但探索本身必然涉及统计学，而这正好属于数据科学家的工作范畴。在第5章中，我们将把数据评估作为预防和诊断问题的有利工具，有助于避免某些看似已完成的软件产品在某种条件下失败的情况。
值得注意的是，尽管这里似乎把数据科学家和软件研发人员对立起来，但这种冲突也可能发生在同一个体身上。在研究数据科学项目时，我经常发现自己的角色在数据科学家和软件研发人员之间切换，尤其是在编写产品代码时。我之所以认为他们是两个不同的角色，是因为有时可能会有利益冲突，因为两者之间的优先级可能会有所不同。正如本书所描述的那样，公开讨论这些冲突有助于阐释解决这些分歧的方法，无论分歧是发生在两个人或多人之间，还是发生在具有不同角色的同一个体身上。1.4 需要成为软件研发者吗
前面讨论了数据科学家和软件研发人员之间的区别，看起来好像仅有这两个选项，但事实并非如此。要想从本书学到些东西，你可以不必是其中的任何一个角色。
统计软件工具的知识实际上是实践数据科学的先决条件，该工具可以是简单的通用电子表格处理程序（例如，褒贬不一但几乎无处不在的微软Excel）。从理论上讲，数据科学家可能从来不接触计算机或其他设备。只要有人可以根据你的意图编写代码，你只需要了解问题、数据及其统计方法就够了。而实际上，这种情况并不多见。
相反，你可能经常与数据科学家一起工作，并且想了解这个过程而不必了解数据科学技术。在这种情况下，本书也有适合你的内容。主要目标之一是列举在解决以数据为中心的问题时必须要考虑的众多因素。在大多数情况下，我会在本书中用过去和现在的一些半虚构的同事为例来做解释：生物学家、财务主管、产品负责人、经理或者其他曾经可能为我提供数据的人，这些人通常会问我：“能帮我分析这些数据吗？”大家希望能把数据分析的情况详细地描述出来并给出大量的案例，但我想再次重申，事情从来就没有那么简单。分析需要提出问题，我将深入讨论这两个相关的问题。
本书内容主要是关于数据科学的思考和实践过程，但显然不能忽视软件。作为一个行业，软件产品是数据科学家的工具箱。得心应手地运用艺术工具使艺术作品的产生成为可能。本书将对软件做必要且有限的讨论，探讨现有软件工具的优劣，并通过具体案例加以说明。我会抽象但切合实际地讨论软件，让尽可能多的人理解，这种说明无论是否具有技术性，哪怕几年后已经迁移到更新的软件语言与产品中，也仍然会有价值。1.5 需要明白统计学吗
与软件一样，专业统计学知识当然会有所帮助，但却并非必需。说到底，因为我是数学家兼统计学家，所以最有可能转向这些技术性特别强的领域。但是我比大多数人更不喜欢专业术语和假定的知识，所以本书会努力把统计概念解释得通俗易懂，希望足以让那些具有一般想象力和毅力的读者受益。在江郎才尽时，我会把读者引导到那些可以得到更透彻解释的地方。我一直主张使用网络搜索来寻找更多与你感兴趣的话题相关的信息，但在去统计学网页探秘之前，至少在某些情况下，还是先多看几页书较多。
同时，为了让你在概念上有所准备，可以把统计学看成是日常数据产生过程的理论体现。网站的匿名用户是个随机变量，其可能会根据自己的想法任意点击网站上的一些东西。社交媒体数据反映的是民众的关注点与想法。消费品的购买行为既取决于消费者的需求，也取决于商品市场的营销活动。无论如何，都必须研究无形的想法、需求和反应最终如何转化为能创造数据的可度量行动。统计学提供了研究框架。本书将在统计模型的复杂理论讨论上投入较少的精力，而把更多的时间用在形成数据生成过程的思维模式上，并讨论如何把这些思维模式转换成统计学的术语、等式，并在最终形成代码。1.6 优先级：知识、技术、观点
本节的标题也是我的座右铭。我用它来帮助解决数据科学项目中各种因素所引发的无休止纠纷，例如软件与统计学、业务需求变更与项目计划、数据质量与结果准确性。在项目进展的过程中，每个因素都会推动或牵引其他的因素，只要关于其中两个因素的行动方案出现差异，我们将被迫做出选择。为此，我研发了一个简单的框架。
通常，任何项目在开始时都需要知识、技术和观点，这是将数据转化为答案的三要素。知识是知道的事实；技术是处理问题需要的一套工具；观点是那些想考虑但还不太清楚的事实。重要的是建立思考过程的层次，不要因为更容易、更受欢迎或因为有预感就避重就轻。
实践中，这种思考过程的层次如下：
·知识第一——采取行动前，理解问题、数据、方法和目标，并在头脑中记住它们。
·技术第二——软件是为你服务的工具，既可为你赋能也可以约束你。除非情况特殊，否则不应该主观认定它是解决问题的方法。
·观点最后——意见、直觉和一厢情愿的想法不是任何项目的重点，而只能作为指导，只有经过验证才能够成为理论。
我不主张在每个决策中总是知识优先于技术，技术优先于观点，如果有很好的理由，则可以颠倒层次结构。例如，有大量数据和用来评估参数的统计模型时，就应该主动颠倒层次结构。此外，可以利用工具来加载数据并采用被称为最大似然估计（MLE）的方法来优化统计参数。数据和统计模型非常复杂，很可能会产生许多合理的参数值，因此用MLE来确定最可能引发不可预知结果的参数值。虽然可能存在功能更强大的替代方案，但目前还没有实现。为此，你有两个选择：
1）构建新的可以进行参数评估的更强大工具。
2）使用现有的工具去做MLE。
如果有足够的时间和资源，知识告诉你应该选择A，但是技术却指明该选择B，因为A需要投入大量的资源。实际决定可能是选择B，但这颠倒了层次结构。如前所述，你可以这样做，但一定是有很好的理由并经过深思熟虑。好的理由往往可以解释为什么投入在A和B上的时间和金钱存在差异，经过“深思熟虑”意味着不应轻易做出决定，也不该忘记层次结构。如果选择了B，那么就应把牺牲质量所带来的后果与所节约的成本联系起来，而且应该在文档和技术报告中做好相应的记录。因此，要适当地加强质量控制，专门检查MLE优化误差及偏差测试的执行。如果做出决定而不复盘会导致平庸或误导。
观点带来更模糊的挑战。有时人们会被真正惊人的潜在结果所蒙蔽，忘记考虑如果这些结果在数据中无法显现会怎么样。在大数据的全盛时期，许多初创型的软件公司试图利用社交媒体，特别是推特（Twitter）及其数据接口，来推测各种商业市场的发展趋势，他们经常遇到比预期大得多的障碍。例如，计算和数据的规模，要分析仅有140个字符的自然语言，往往涉及依靠杂乱的数据来推断随机变量。只有那些顶尖的公司才能够从这些数据中提取有意义的重要知识并赚取利润。剩下的那些公司只能改弦易辙甚至彻底放弃。在某种程度上，这些初创型企业必须决定是否要投入更多的时间和金钱去追求基于希望而非现实的目标。我敢肯定，他们中有许多人在决定放弃时，后悔自己走了太远，花了太多钱。
人们常常被自己认为可能的事情蒙蔽了双眼，忘记去考虑不可能或者需要更多的投入时该怎么办。这些都是观点和猜测而不是知识，他们不应该在数据分析和产品研发中起主要作用。虽然目标不一定能够实现，但这是任何项目都需要的，所以当务之急不是把目标及其实现的可能性当成理所当然。应该首先考虑当前的知识，然后寻求不断扩大知识量，直到实现目标或被迫放弃。前面提到的实现目标可能性的不确定性在软件研发和数据科学的理念上存在着鲜明的差异。在数据科学中，不太可能实现原定的目标。在软件研发人员或菜鸟数据科学家的环境里，要特别警惕那些毫无证据地鼓吹目标能够100%实现的人。
记住：先是知识，再为技术，后是观点。这不是完美的框架，但我发现它很实用。1.7 最佳实践
作为应用数学家、博士研究生、生物信息学软件工程师、数据科学家或其他身份，在多年的数据分析和代码编写过程中，我遇到过一些涉及项目管理不善的问题。有好多年，当没人接触或检查我的研究项目时，我经常不会完善代码文档说明，长此以往以至于我竟然忘记了应该如何去做。我也经常忘记哪个版本的结果是最新的。在离职时，几乎无人能接管我的项目。这些都是无心之举，主要是疏忽，但也源于对最佳实践的无知，即无论把项目材料和代码束之高阁还是转交给别人，都可以让其他人迅速上手。
在团队工作时，特别是那些有着经验丰富的软件研发人员的团队，通常会建立一套编写文档和保存项目材料及代码的最佳实践。每个成员一般都要遵守团队的策略，但是如果团队没有策略或者你自己独立工作，那么从长远来看，可以用些规避措施来让你数据科学家的生涯更加轻松。下面的小节介绍了我最喜欢的有助于保持项目有条不紊的几种方式。1.7.1 文档
设想一下，如果你突然离开，某位同事在接管项目时会是怎么样的情景吗？那将是一次可怕的经历吗？如果回答是肯定的，那么请你帮助这些未来的同事和你自己维护好当下的文档。以下是一些小窍门：
·为代码做注释，以便不熟悉这部分工作的同事可以理解这些代码的作用。
·对已研发完成的软件，即使只是简单的脚本，也要写一段使用描述，然后把它与代码存放在一起（例如，保存在同一个文件夹里）。
·确保包括文件、文件夹、文档等的名字意义明确。1.7.2 代码库与版本管理
用来管理软件源代码的专业软件产品称为源代码库，它可以从不同的角度为你带来极大的帮助。
首先，大部分现代的代码库都基于版本管理系统，当然这非常好。版本管理系统可以追踪代码的变化，允许产生和比较不同版本的代码，总体来说，一旦习惯使用版本管理系统，你的代码编写和修改过程会更加快乐。代码库和版本管理系统的问题是需要花时间学习并将其融入日常工作。当然，所花费的时间是值得的。在编写代码时，bitbucket.org和github.com提供免费的网上代码库服务，这两个网站既为公众也为私人提供服务，所以别不小心把自己的源代码公诸于世成为开源。Git是目前最受欢迎的版本管理系统，与前面提到的两个代码库集成得非常好。可以在网页上找到教你上手的教程。
远程托管代码库近乎无法割舍的另外一个原因是，我发现它可以起到备份的作用。即使计算机不幸被参加沙漠越野赛的自动驾驶汽车撞碎（尽管对我来说这样的事尚未发生），代码也将会安然无恙。我已经养成了习惯，几乎每天都把最新的代码推送到远程的托管端，已经快变成类似标准数据备份服务那样的定时自动备份了。
有些代码托管服务提供了非常友好的网络界面，可以查找代码历史、不同版本、研发状态等信息，甚至变成团队在大型项目合作中的标准工具。对个人和小项目而言同样，它也很有帮助，特别是当你需要返回到某个旧项目，或者试图找出在过去的某个时间点做了哪些变更时非常有用。
最后，远程代码库支持用户从世界上任何地方通过互联网存取代码。计算机上不需要有相应的编辑器和环境就可以浏览代码。是的，在这些网络界面上，通常除了浏览外（可以做简单的改动），你无法做比较大的代码修改，最好的网络界面具有可以显示与特定编程语言相关的代码关键词标注，以及其他一些使代码浏览更加方便有效的功能。
下面是些关于代码库和版本管理的小窍门：
·对大部分编程团队而言，采用远程源代码库已经是标准实践。
·绝对值得花时间学习Git或者是另外一种版本管理系统。
·定期把修改过的代码检入代码库，可以每天一次，也可以每完成一个特定任务就执行一次。把变更推送到远程代码库，在做好备份的同时与团队的其他成员共享。
·假如改动可能会带来某些问题，那么应该在不影响到团队其他成员的地方下手，以避免影响到生产版本。例如，在Git上创建一个新的分支。
·用版本、分支和分叉（互联网上有很多相关的教程），而不是从一个地方复制、粘贴到另一个地方，这会造成需要在不同的地方维护和修改多套代码。
·大多数的软件团队都有Git高手。对于如何最好地利用Git，你可以问下他们；现在下功夫学习，将来一定会有所回报。1.7.3 代码组织
有许多关于良好代码实践的书籍，我不想在此复制或替代它们。但是有些指导原则是非常有用的，特别是当你试图共享或者重用代码的时候。有经验的程序员对此可能很熟悉，但对许多不需要代码共享的人，特别是那些在学术机构和其他环境工作的人而言，对此并不熟悉更别提坚持使用它们了。以下是一些指南：
·尽可能使用某种编程语言常用的编码规则。例如Python、R和Java，其在研发人员组织代码的方式上存在差异。任何常用的编程语言资源都包含了为各自编程规则服务的用例和指南。
·为变量和其他对象使用有意义的名称，这将使代码更易被新合作者和未来的自己理解。
·多使用有意义的注释，原因如前所述。
·不要复制和粘贴。同一段代码分别出现在两个不同的地方，在修改时意味着工作量加倍。采用函数、方法、对象或者库的方式把这样的代码封装起来，那么后续的改动只会在一个地方发生。
·尝试把特定的功能写在同一段代码中。对脚本而言，这意味着注释良好的代码段（也可以放在不同的文件或库中），每段完成一个特定的功能。对应用而言，这意味着使用相对简单的函数、对象和方法，并且各自保持独立。有个很好的通用规则是，当无法为代码段、函数、方法取恰当的名字，即无法从总体上描述该段代码所要完成的任务时，就应该把这段代码分成更小的代码段。
·不要在未成熟时进行优化，这是程序员的通病。确保代码的逻辑性和一致性，只有发现所实现的代码效率不高时，才需要通过减少计算和内存量来优化。
·假装有人会在某个时间点加入项目。自问：“他们能读懂代码，知道我想做什么吗？”如果答案是不，那么花些时间组织代码，并尽快增加各种注释。1.7.4 提出问题
这听起来是显而易见或者微不足道的事，但它却非常重要，以至于我不得不把它放在这里。前面曾经提过，意识是数据科学家最重要的能力之一；与此类似，不愿意通过各种方式提高意识能力可能是数据科学家最大的弱点。你可能对内向的学究留给人们羞于求助的印象很熟悉，但是对拥有博士学位无所不知的数据科学家而言，你是否听说过他们太过骄傲以至于不承认自己对某些事情不了解呢？当然有这种情况。对于数据科学家来说，骄傲也许是比羞怯更大的陷阱，但是要同时关注这两者。
软件工程师、业务策略人员、销售人员、市场营销人员、研究人员和其他科学家对他们自己的领域或项目的了解都比你更深，如果因为羞怯、骄傲或者其他原因而忽略其所拥有的丰富知识将是一种耻辱。在企业环境中，几乎每个人的角色都不同，这为你提供了充分了解公司和行业的机会。这就是我在前面曾经提到过的专长或领域知识。在我的经验中，非技术专业的业务人员有把数据科学家当成聪明人的倾向，但是别忘了那些业务人员对项目目标和业务问题的了解比数据科学家清楚得多，这两个方面极为重要。永远都不要犹豫去和那些了解你手头项目和待解决问题的业务人员进行深入探讨。我经常发现这种交流会使我以新的方式来了解项目，有时带来策略上的改变，但是无论如何总会增加项目成功完成所必需的专业知识。1.7.5 紧靠数据“紧靠数据”意味着确保应用在数据上的方法和算法不要过多，以免模糊焦点。另外一种解释是：“所采用的方法不要过于复杂，对犯错误的可能性保持清醒的认识。”
许多人会对该建议提出异议，我同意这些批评者的观点，许多复杂的方法证明了它们的价值。机器学习领域是这种方法来源的最好例证。在复杂方法（有些例子是黑盒方法）带来相当大好处的案例中，紧靠数据的概念可能意味着适应性：确保复杂方法的某些结果可以通
试读结束[说明：试读内容隐藏了图片]