【Spark学习笔记】- 数据科学面临的挑战

「数据科学」有几个硬道理是不可违背的，Cloudera数据科学团队的一项重要职责就是宣扬这些硬道理。一个系统要想在海量数据的复杂分析方面取得成功，必须的明白这些硬道理，至少不能违背。

1. 成功的分析中，绝大部分的工作是数据预处理。数据是混乱的，在让数据产生价值之前，必须对数据进行清洗，处理，融合，挖掘和其他操作。特别是大数据集，由于人们很难直接检查，为了知道需要哪些预处理步骤，甚至需要采用计算方法。一般情况下，即使在模型调优阶段，在整个数据处理管道的各个作业中，花在特征提取和选择上的时间比选择和实现算法的时间还要多。

   比如，在构建网站欺诈交易检测模型时，数据科学家需要从许多可能的特征中进行选择。这些特征包括必填项、IP地址信息，登录次数，用户浏览网站时的点击日志等。在将特征转换成试用于机器学习算法的向量时，每个特征可能都会有不同的问题。系统需要支持更灵活的转换，远远不止是将二维双精度数组转换成一个数学模型那么简单。

2. 迭代是数据科学的基础之一。建模和分析经常需要对一份数据集进行多次遍历，这其中一方面是有机器学习算法和统计过程本身造成的。常用的优化过程，比如随机梯度下降和最大拟然估计，在收敛前都需要多次扫描输入数据，数据科学家自身的工作也涉及迭代。在初步调查和理解数据集时，一个查询的结果往往给下一个查询带来启示。在构建模型时，数据科学家往往很难在第一次就得到理想的结果。选择正确的特征，挑选合适的算法，运行恰当的显著性测试，找到合适的超参数，所有这些工作都要反复试验，框架每次访问数据都要读磁盘，这样会增加时延、降低探索数据的速度，限制了数据科学家进行试验的次数。

3. 构建完表现卓越的模型不等于大功告成。数据科学的目标在于让数据对不懂数据科学的人有用。把模型以许多回归权值的形式存成文本文件，放在数据科学家的计算机里，这样做根本没有实现数据科学的目标。数据推荐引擎和实时欺诈检测系统是最常见的数据应用。这些应用中，模型作为生产服务的一部分，需要定期甚至是实时重建。

在这些场景中有必要区别是试验环境下的分析还是生产环境下的分析。在试验环境下，数据科学家进行探索性分析。他们想要理解工作数据集的本质。他们将数据图形化并用各种理论来测试。他们用各种特征做试验，用辅助数据源来增强数据。他们试验各种算法，希望从中找到一两个有效的算法。

在生产环境下，构建数据应用时，数据科学家进行操作式分析。他们把模型打包成服务，这些服务可以作为现实世界中的决策依据。他们跟踪模型随时间的表现。哪怕是将模型准确点提高到一个百分点，他们都会精心调整模型并且乐此不彼。他们关心服务SLA和在线时间。由于历史原因，探索性分析经常使用R之类的语言，在构建生产应用时，数据处理过程完全用Java或C++重写。

当然，如果用于建模的原始代码也可用于生产应用，那就能节省每个人的时间。但想R之类的语言运行缓慢，很难将其与生产基础设施的技术平台进行集成，而Java和C++之类的语言又很难用于探索性分析。他们缺乏交互式数据操作所需的REPL（read-evaluate-pringt-loop，读取-计算-打印-循环）环境，即使是简单的转换，也需要写大量的代码。人们迫切需要一个既能轻松建模又合适生产系统的框架。