数据分析实战

　　推荐序
　　程序员、科学家、工程师之间有什么差别？
　　这个问题，我问过许多“软件工程师”，大家似乎都没法说得特别清楚，常见的答案是从名字上来区分：程序员只关心代码，工程师负责的是系统，科学家的理论知识非常深厚。它的潜台词是：你看，我是个工程师，我不只关心代码，我还为系统负责，但是，你没法对我的理论知识做太多要求。
　　看来，实际情况也确实如此。前些年，我在一支颇有效率的开发团队里，组织大家“补习”数据结构和算法。我惊奇地发现，不少主力开发人员做起业务功能来异常拿手，毫不畏惧，但面对简单的“理论问题”—比如如何从一个数组中找到和最大的两个元素—竟然束手无策。而且很多人都认为，这不是问题。
　　我想，这就是很大的问题。
　　“工程”这回事，是什么时候出现，并让大家意识到它不等于“手艺”的呢？具体时间或者不可考，但有个故事很能说明问题。
　　1742年，教皇本尼迪克特十四世（Benedict XIV）需要派人诊断罗马圣彼得大教堂拱顶出现的裂纹。传统上，这种事情总是要找建造经验最丰富的工匠。但是这次不一样，教皇把任务指派给了三位数学家，其中一位还曾编辑和注释过艾萨克·牛顿的《自然哲学的数学原理》。在那个年代，他们的诊断方法和结论都引发了巨大的争议，因为其违背了无数工匠的经验和直觉。按照三位数学家的结论，拱顶的箍环承受不了水平的推力，必须新增三个带链条和铁钉的铁环，才能确保建筑的完整。
　　他们的建议被采纳了。今天，如果你去罗马，仍然可以看到完整的圣彼得大教堂。
　　土木工程师兼历史学家斯特劳布评论说：这份报告在土木工程史上有划时代的意义……重要性在于，与所有的传统和常规相反，对建筑结构的稳定性的勘测，不是建立在经验规则和静态感觉的基础之上，而是建立在科学的分析和研究之上。
　　从此大家逐渐相信，建筑不再是一门“手艺”，要想建造更复杂、更伟大的建筑，科学和研究是无论如何离不开的。今天，如果土木工程师在工作时不依照模型、理论、计算，而是完全按照经验和直觉，哪怕他的经验再丰富，也不能称为“工程师”。
　　在我看来，软件开发，在某种程度上也处于相同的时间点。我承认，之前的大量开发工作，不需要太多理论和科学知识，单纯凭经验和直觉就可以完成。但是如今，我们已经无可避免地被卷入大数据的洪流之中—哪怕是“传统”的互联网开发，也已经大不相同了。我们写的每一个功能，都可能被成千上万人，在成千上万的场景下，成千上万次地使用。在整个过程中，成千上万的埋点、成千上万的传感器，会留下巨细靡遗的数据。如何还原场景、找到问题、做出改进，答案往往就藏在这些数据当中，谁看得懂、玩得转这些数据，谁就能找到答案。
　　拿简单的“上课前给用户打电话通知”来说，它绝不再是“调用供应商接口发一个语音”那么简单。提前多久给用户打电话反馈最好？什么样的语音信息最容易接受？各地用户有什么特别偏好？不同年龄段的用户接受程度如何？……如果我们承认“用户体验”重要，那么搞清楚这些问题便也很重要。公司搞不清楚，就会被用户嫌弃。工程师搞不清楚，就只能被动接受产品经理的指挥。而这些问题的答案，只能来自对数据的积累和分析。
　　不要妄想“数据科学家”能帮忙解决这些问题，“数据科学家”太宝贵了，只能用在业务价值最关键的场合。更多的场合，工程师只能挽起袖子自己上场。然而，大部分工程师目前的数据处理能力还局限于极值、算数平均、方差等等少数几项。许多工程师也承认，数据分析能力很重要，也希望学习，可是打开数据分析的专门教材，一看到密集的公式，就已经打了退堂鼓。
　　怎么办？
　　我认为，阅读《数据分析实战》是个不错的出路。之所以这么说，有四个原因：第一，这本书的风格是“代码先行”，而且是可以运行的Python代码先行，对于要用到的各种工具包、类库的安装，都有详细的说明，这种风格对于工程师来说，天然有亲切感；第二，例子都是非常实际的，无论是银行电话营销数据分析，还是电网的发电量分析，以及影评文本分析，都很容易和生活经验结合起来，容易理解；第三，非常注重出图，全书用了相当多的篇幅讲述画图，而且是用JavaScript直接出图，图形非常有助于建立直观的认识，JavaScript画图几乎可以保证“人人都可以完成”；第四，译者是工程师出身，在数据分析这个行业有足够丰富的经验，同时也足够谦虚，对于译文的质量来说，这都是很好的保证。
　　实际上在我看来，普通的技术人员，无论之前做的是什么工作，只要不是极端排斥数据分析，那么阅读这本书，都可以建立对数据分析的准确认知，并且还能真刀真枪地玩上几下：看，数据分析就是这样。一旦掌握了基础的知识和技能，无论把它们当作继续深入学习的基础，还是直接应用到现有工作当中去，都会有巨大的收获。
　　不要在1742年以后再当一个不懂数学的建筑工匠，不要在大数据时代当一个完全不懂数据分析的工程师。如果认同这个判断，欢迎你把本书当成高性价比的选择。
　　余晟