当前位置：主页 > 书籍配套资源 > 数据分析配套资源

《数据分析实战》源代码

更新：2022-02-10
大小：22.1 MB
类别：数据分析
作者：托马兹·卓巴斯
出版：机械工业出版社
格式：PDF

资源介绍
相关推荐

微软数据科学家融合自己多年数据分析实践经验系统讲解数据分析与建模的各种方法、工具及算法，给出一系列Python代码示例，并提供60多个实战技巧，可以帮助深入理解数据分析技术，高效使用Python工具解决现实数据科学任务。
全书共11章，可分为三部分。第一部分（第1~2章）讲授一些实战技巧，用于读取、写入、清洗、格式化、探索与理解数据；第二部分（第3~7章）介绍一些较深入的主题，包括分类问题的处理、多种聚类模型、降维技巧、回归模型和时间序列技术等。第三部分（第8~11章）介绍更高深的主题，从图论到自然语言处理，到离散选择模型，再到模拟。

程序员、科学家、工程师之间有什么差别？

这个问题，我问过许多“软件工程师”，大家似乎都没法说得特别清楚，常见的答案是从名字上来区分：程序员只关心代码，工程师负责的是系统，科学家的理论知识非常深厚。它的潜台词是：你看，我是个工程师，我不只关心代码，我还为系统负责，但是，你没法对我的理论知识做太多要求。
看来，实际情况也确实如此。前些年，我在一支颇有效率的开发团队里，组织大家“补习”数据结构和算法。我惊奇地发现，不少主力开发人员做起业务功能来异常拿手，毫不畏惧，但面对简单的“理论问题”—比如如何从一个数组中找到和最大的两个元素—竟然束手无策。而且很多人都认为，这不是问题。
我想，这就是很大的问题。

“工程”这回事，是什么时候出现，并让大家意识到它不等于“手艺”的呢？具体时间或者不可考，但有个故事很能说明问题。

1742年，教皇本尼迪克特十四世（Benedict XIV）需要派人诊断罗马圣彼得大教堂拱顶出现的裂纹。传统上，这种事情总是要找建造经验最丰富的工匠。但是这次不一样，教皇把任务指派给了三位数学家，其中一位还曾编辑和注释过艾萨克·牛顿的《自然哲学的数学原理》。在那个年代，他们的诊断方法和结论都引发了巨大的争议，因为其违背了无数工匠的经验和直觉。按照三位数学家的结论，拱顶的箍环承受不了水平的推力，必须新增三个带链条和铁钉的铁环，才能确保建筑的完整。

他们的建议被采纳了。今天，如果你去罗马，仍然可以看到完整的圣彼得大教堂。

土木工程师兼历史学家斯特劳布评论说：这份报告在土木工程史上有划时代的意义……重要性在于，与所有的传统和常规相反，对建筑结构的稳定性的勘测，不是建立在经验规则和静态感觉的基础之上，而是建立在科学的分析和研究之上。
从此大家逐渐相信，建筑不再是一门“手艺”，要想建造更复杂、更伟大的建筑，科学和研究是无论如何离不开的。今天，如果土木工程师在工作时不依照模型、理论、计算，而是完全按照经验和直觉，哪怕他的经验再丰富，也不能称为“工程师”。
在我看来，软件开发，在某种程度上也处于相同的时间点。我承认，之前的大量开发工作，不需要太多理论和科学知识，单纯凭经验和直觉就可以完成。但是如今，我们已经无可避免地被卷入大数据的洪流之中—哪怕是“传统”的互联网开发，也已经大不相同了。我们写的每一个功能，都可能被成千上万人，在成千上万的场景下，成千上万次地使用。在整个过程中，成千上万的埋点、成千上万的传感器，会留下巨细靡遗的数据。如何还原场景、找到问题、做出改进，答案往往就藏在这些数据当中，谁看得懂、玩得转这些数据，谁就能找到答案。
拿简单的“上课前给用户打电话通知”来说，它绝不再是“调用供应商接口发一个语音”那么简单。提前多久给用户打电话反馈最好？什么样的语音信息最容易接受？各地用户有什么特别偏好？不同年龄段的用户接受程度如何？……如果我们承认“用户体验”重要，那么搞清楚这些问题便也很重要。公司搞不清楚，就会被用户嫌弃。工程师搞不清楚，就只能被动接受产品经理的指挥。而这些问题的答案，只能来自对数据的积累和分析。

不要妄想“数据科学家”能帮忙解决这些问题，“数据科学家”太宝贵了，只能用在业务价值最关键的场合。更多的场合，工程师只能挽起袖子自己上场。然而，大部分工程师目前的数据处理能力还局限于极值、算数平均、方差等等少数几项。许多工程师也承认，数据分析能力很重要，也希望学习，可是打开数据分析的专门教材，一看到密集的公式，就已经打了退堂鼓。