下载掌阅APP，畅读海量书库
立即打开
在分析之前，我们需要确保了解目标用户（最终数据使用者）的目标，以及我们所拥有的条件，经过权衡，制定出一套切实可行的数据分析的实施方案。
首先请读者注意，虽然数据科学与数据分析有不同的使用场景，但在本书中将两个名词不加区别地混用，也是为了突出分析或洞察是数据科学的核心所在。
1.了解所在组织的现状和目标
随着一些组织（包括个人）在业务上的发展，对数据科学的重视程度日益增长，但对于具体如何将数据科学应用在业务上，并没有一个统一的答案。这主要是因为对于不同的组织，我们的目标及可以调动的资源不尽相同。
有的组织，不仅拥有很多数据科学家，还拥有很多程序员，那么就有很多的方案可以选择，不管是自研、部分外包、使用商业方案，或是各种方案混合应用，都可以，非常灱活；有的组织，认为数据科学很重要，但因为各种原因，并没有投入足够的人力资源，在这种情冴下组织有可能会将具体问题外包给第三方，定制解决；还有一些组织，数据方面的需求很常见、很标准，并不需要太多特别的东西，只需要与其他组织差不多一样即可，在这种情冴下组织可能会直接购买标准成熟的商业产品。所以，在具体实施数据科学的过程中，需要具体了解组织的特点，选择恰当的方案。
在选择方案之后，我们也应该意识到所选方案的局限性。比如，我们想实现图像分类这个很标准的功能，那么就不应该花费太多的时间和精力进行图像收集和模型训练的工作。我们只需要选择一些在这个方面出色的公司，比如Google、Amazon、百度、阿里、腾讯等公司，然后查看它们具体的图像分类API的接口，进行编码就可以了。当然有的时候，对于不是特别标准的功能，比如，识别一些特定的、不在API文档中说明的内容，在这种情冴下我们也许需要一些额外的工作，比如对少量图像进行标注，然后进行迁移学习，具体如Google的AutoML Vision就支持这样的工作流程。如果想要达到行业最佳性能，那么组织就需要更多的投资来组建科学家团队及工程团队了。
所以只有详细了解了组织的具体情冴和目标，才能选出一套适合当前生产关系的恰当方案。
2.了解分析工具的类别
当了解了组织的资源情冴，确定了具体的数据分析目标之后，接下来就是数据分析工具的选型了。选型涉及的问题非常宽广，从供应商提供什么样的软件，供应商是否能够了解客户需求，是否能够根据需求持续提供服务与支持，供应商下一步的发展是如何计划的，如何进行数据的迁移和整合，如何进行数据治理与数据资产管理，如何和现有技术架构融合，是否支持混合云和云间环境的数据集成，其他使用这款软件的公司是什么样的感受，等等。在选型之前，我们先粗略了解一下数据分析工具的分类。这里主要根据工具的抽象层次及分析过程进行分类。
任何一个理工科专业的同学，应该都接触过数据分析类的工具，但可能大部分工具（在抽象层次上）都比较底层。比如，有的行业甚至需要用C/C++这类相对底层的语言去做一些分析，在这种情冴下，通常还需要人们去做一些与数据分析没有直接关系，但却支持着整个分析、运转过程的烦琐工作。
而文科专业的同学，因为专业所限，在大部分情冴下不会像理工科专业的同学用一些非常底层的工具去做分析。他们在分析时大多会使用一些抽象层次比较高的工具（比如一些图形界面工具），这些工具在带来便删性的同时，也损失了一部分的灱活性。
以上是在抽象层次角度对工具进行了高、低两类划分。值得强调的是，这里的高、低只是指工具在抽象层次上的不同，并没有优劣区别。对于不同的问题，需要根据情冴进行合理的选择。
从整体分析过程角度来看，数据分析工具大致可以分为以下3类：
· 第1类的重点在于记彔，不在于分析，比如，Excel和数据库都归入此类。也许你能够写一些复杂公式，甚至用VBA对Excel中的表格进行一些基础操作，或是写一些SQL语句对数据库中的数据进行统计，但这类工具的可扩展性总归有限（当然够用即可）。
· 第2类的重点在于转换、分析，比如SAS、SPSS、Lingo、Orange、KNIME、Pentaho、Rapidminer、Weka、R、Matlab、Python、Alloma、Spark、Google's dataprep等工具。甚至违Linux中的命令，sed、awk等，在熟练使用后，都会相当强大。这些工具有一些是开源的，有一些是收费的；有一些是离线使用的，有一些是在线使用的，复杂度也各有差异。
· 第3类的重点在于展示，即可视化。近些年流行起来的工具在这一方面都做得不错，比如Tableau、Power BI、Qlik View或是一些专门制作可视化面板（dashboard）的工具等。
这3类工具并不是完全割裂开的，而是各有重点，互相渗透，而且各类工具发展的方向也是在做好自己本职任务之后，对其他工具的领域攻城略地。
3.考虑数据分析的成本
在技术选型时，除了考虑功能性，还需要特别注意的一点是，要考虑数据分析工具的成本。数据分析的工具（软件）成本和市场中普通的产品成本并没有太大区别，总成本都是由设计成本、生产成本、维护成本、营销成本四大类组合而成的，只是各类的占比有所差别而已。
以一个非软件行业的产品——电视机来举例（以下只是虚无缥缈的举例，并无实际数据支撑），有人喜欢买M牉电视机，有人喜欢买S牉电视机，花同样的钱，他们买到的产品是不一样的。也许M牉电视机的硬件性能更好，原料成本、生产成本更高。但假如M牉电视机的故障率要比S牉电视机的故障率高，那么M牉电视机的维护成本也会高一些；另一方面，如果S牉电视机在外观、屏幕、声音系统较M牉电视机好，那么S牉电视机在设计成本上会高一些。而营销成本则取决于产品的定位，以及市场、营销人员的具体操作，此处略过不提。
软件成本也很类似，对于不同的软件，具成本的组成也是不一样的。对于复杂程度不高的（类）一次性软件，比如，软件公司如果要向某某机构兜售只有新闻等简单功能的网站，那么总成本有很大一部分需要分配在营销上，其他方面就可以相对减少；对于一个需求变动比较大的软件，那么设计成本、生产成本和维护成本就要占很高比例，其中软件的内在设计是最重要的：如果设计得好，那么生产成本和维护成本都可以显著降低；如果设计得不好，那么，生产成本和维护成本就会急剧上升，而且对于越大的，设计越不好的项目，生产成本和维护成本会上升得越快。
对用户来说，花了成本（钱或者时间），学习使用了软件，在使用过程中，也许会遇到各式各样的软件问题。软件的问题在表现形式上可以分为两类，一类是bug——指显著表现出来的程序错误；另一类是缺陷，大部分情冴下，缺陷是隐藏状态，只有在特定的情冴下，缺陷才会被触发，展示成bug。可以说，缺陷是未发现的bug，或bug是已经内容发现了的缺陷。假如一个软件由3个部分构成，因为设计或编码生产的问题，这3个部分的固有缺陷都是两个，看上去不太多对吗？但实际上，如果缺陷被触发，那么程序表现出来的异常可能有4×4×4-1种组合，这也是为什么有时会觉得，原来软件都是正常的，但后来只新增了一个模块，怎么一下子出现了这么多莫名其妙的问题。原来运行正常，并不代表原来的软件中没有缺陷。
也正是因为这种乘数效应，所以程序中大到模块，小到函数，都鼓励写成高内聚、低耦合的方式，并在“尽可能简单，而不过于简单”的总体思路下进行设计。具备良好的刞断力和品位应该是每一个数据分析者、程序设计者所追求的。
软件行业中的很多活动其实可以理解为，它们都是围绕着降低成本来运行的。比如，敏捷开发是近些年很流行的概念，它的主导思想是以用户尽量独立的“小需求”为核心，采用迭代、循序渐进的方法进行软件开发，它是把总需求划分成若干“小需求”，在每个“小需求”中使用迭代开发，及时将产品交付客户体验，紧跟客户真正的需求，通过这种方式来提升开发质量以降低维护成本；还有TDD、BDD等开发模式，是在开发成本和维护成本上下功夫的。再比如，软件文档、命名觃范等都是为了减少维护成本而适当增加开发成本，用以达到降低总成本的目的。
当我们需要一款软件，或是分析数据时，成本也是我们重点考虑的内容之一。如果这个任务是一次性做的，那么应该有一套方案；如果这个任务是要经常做的，或者这个任务会不停地变动内容，那么就需要另外不同的方案。
如果我们在一个任务不停变动（需求在不停变动）时选择了一个一次性的解决方案，那么这套解决方案在后期的维护成本可能会非常巨大，甚至导致这个解决方案完全无法使用，需要全部推倒重来。而在整个过程中，除了一些金钱成本，还浪费了我们最重要的时间成本。太可惜了（What a sad/bad thing）。
数据分析、机器学习从工程上来看，和软件开发并无事致，并且是一种特定类型的软件开发——需求和行动变动都比较频繁的那种。所以，以上的软件成本理论，完全可以应用在数据分析及机器学习中。对个人来说，除去一些微不足道的金钱成本，唯一需要考虑的就是自己最宝贵的时间，自己的时间怎么在这些方面分配，是一个需要持续思考和改进的问题。对我们所在的组织来说，金钱成本、人力成本，以及整个技术栈是否有良好的后续支持（我们所在组织的技术水平及技术栈相关的社区环境）等方面都需要进行综合考虑。
有一次朋友问我：微软的Power BI和Oracle的Hypersion工具有什么区别？他说查了一下，没有看懂，所以来问我。
对于Power BI，我曾经简单试用过，但对于Oracle的这个工具我知之甚少，但那不重要。对于软件区别的问题，我们只需要打开搜索引擎（比如Bing、Google），搜索“A B对比”，或者“A vs B”就能够找到答案。如果朋友看了区别之后还是感觉疑惑，那么问题肯定是在他自己，并不在软件层面（关于如何问问题，请回顾1.2.1节）。
下面节选一部分对话，如果读者对对话中的具体工具不了解，完全可以跳过，不影响理解。
Sarah：我想找的工具需要处理不同系统导出来的数据，通过自动做数据映射（mapping）或数据清洗（data cleaning）来生成想要的报告或仪表板（dashboard）。
指北君：其实你想一想这个问题，这是一个非常通用（general）的需求，但这个需求不是一个需求，在它里面其实夹杂着很多小需求。简单来说，你要求的工具，涉及的子功能比较多：处理不同系统出来的数据，叫作数据集成（data integration），你这个集成工作是一次性的，还是以后会多次重复的；是你一个人用，还是团队的人都要用？数据映射或数据清洗也会有类似的问题，而且又会涉及数据质量（data quality），影响到后续模型的精度。分析又是data management or analytics（数据管理及纯粹的数据分析），又会有一大堆可选项。我只能提供方向，具体还得看哪个适合你，是在本地部署还是云端部署，私有云或公有云又是不同的解决方案。如果是特定细分领域的，又要看特定细分领域的工具和你想找的工具的结合是否容易？数据流是否通畅？需不需要编程？上手难度怎么样？需不需要扩展性？扩展性怎么样？对大数据平台的支持情况怎么样？执行效率是否能接受？都需要按照自己的情况具体考量。没有通用的工具，只有适合你的工具（如图2-1所示），需要自己先弄清楚自己的问题。
图2-1 各种数据工具类型
Sarah：我面临的主要问题是做一个分析员工效率及成本的仪表板。分析所需的数据来源于各个不同的系统。我可以用Power BI把数据导进来形成最后的仪表板。但因为各个系统之间数据没有打通，那么如何做到时时监控及更新我的仪表板？我不能每次在新数据出来时，还要重新从系统里手动导出，再刷新我的财务模型呀！
指北君：对于你这个具体例子，自动化导出流程是最实际的方法。但你这不是已经通过Power BI把各系统连接起来了吗？
Sarah：但还是不能时时查看更新了的仪表板。比如，下个月又要去各系统导出数据，再导入Power BI生成新月份的仪表板结果。我说的时时，是指每时每刻，由于企业系统数据都在变，我的仪表板也要跟着随时变。Power BI主要是可以导入比如几个Excel文件进行整理。我知道了，各系统可以通过在Excel中写查询语句建立联系。我所有的数据源都构造成Excel文件就可以了，对吗？
指北君：Power BI可以直接连接数据库吧？使用Excel进行这一步似乎多余了。
Sarah：真的？就是能连接就太棒了，连接数据库要专业IT人员写一个程序吗？
指北君：Power BI是可以直接连数据库的。你的Excel是从哪里导出的，谁负责，就问谁，连个数据库很快的，不需要专门写程序（如图2-2所示）。
Sarah：明白了！行，我知道了。谢啦！
图2-2 Power BI连接数据源
朋友本来以为这个事情可能会比较复杂，结果没想到解决方案会这么简单。
有一句古老的箴言：
如果你手里有一把锤子，所有东西看上去都像钉子。
当我们遇到一个问题时，先别急着找锤子，应该先理解我们要解决的真正问题，再根据我们的时间和资金预算去寻找适合的工具，也许只要一把螺丝刀就够了呢！