机器如何学习？
人脑具备不断积累经验的能力，依赖经验我们便具备了分析处理的能力，比如我们要去菜场挑一个西瓜，别人或者自己的经验告诉我们色泽青绿、根蒂蜷缩、纹路清晰、敲声浑响的西瓜比较好吃。
我们具备这样的能力，那么机器呢？机器不是只接收指令，处理指令吗？和人脑类似，可以喂给机器历史数据，机器依赖建模算法生成模型，根据模型便可以处新的数据得到未知属性。以下便是机器学习与人脑归纳经验的类别图：
平台设想
在同程内部，我们对应用机器学习的一些团队做了了解，发现他们普遍的处理步骤如下：
这个过程中存在一些痛点：
线上数据到线下搬运耗时
训练数据量难均衡，如果训练数据量较大，用 R 或者 Python 做单机训练将会非常耗时。如果训练数据量较小，训练出来的模型容易过拟合。
对分析和挖掘人员的编码能力有一定的要求。
因此我们觉得可以构建一套平台化的产品直接对线上数据进行建模实验，节省机器学习的开发成本，降低机器学习的应用门槛。
平台构建
设计目标
支持大数据量的建模实验，通过并行计算缩短耗时
抽象出最小执行单元，配置简单。通过拖拽以及连线的形式构建建模流程
支持常用的机器学习学习算法处理回归、分类、聚类等问题支持常用的特征工程组件，如标准化、归一化、缺失值处理等
支持算法评估结果可视化
算法库
在算法库方面，我们选择了 Spark，相比于 R 或者 Python，Spark 具备分布式计算的能力，更高效。
ml 和 mllib 都是 Spark 中的机器学习库，目前常用的机器学习功能两个个库都能满足需求。ml 主要操作的是 DataFrame，相比于 mllib 在 RDD 提供的基础操作，ml 在 DataFrame 上的抽象级别更高，数据和操作耦合度更低。
ml 提供 pipeline，和 Python 的 sklearn 一样，可以把很多操作 (算法 / 特征提取 / 特征转换) 以管道的形式串起来，对于任务组合非常便利，如 StringToIndexer、IndexerToString、VectorAssembler 等。
组件化设计
从架构设计上来说，不管是算法单元、特征工程单元、评估单元或者其他工具单元，我们认为都可以以组件的形式来设计。借助通用的接口行为以及不同的实现可以达到松耦合、易扩展的目的。
上图是整个设计类图的一部分，实际上我们做了较多层次的抽象以及公用代码。下面看看核心类 BaseTask：
run 方法的实现是一套模板，步骤如下：
每个组件只要实现自己的核心逻辑 execute 方法就可以了。
平台迭代
v1.0（平台核心架构）
基于上述的设计目标，机器学习平台第一个版本的架构如下：
用户通过界面拖拽组件构建建模流程，并将组件配置以及依赖关系保存到 DB 中
用户可以在界面上触发建模试验的运行，实际上通过 spark-submit 提交一个 spark 任务
Ml Engine 负责这个任务的执行，在 Driver 端会从 DB 中获取当前试验的依赖组件以及流程关系。这些组件将依次运行，涉及 RDD 相关的操作时会提交到 Spark Executor 进行并行计算
流程 & 评估视图
第一个版本我们并没有提供太多的算法组件，只有线性回归和逻辑回归，但是基于组件化的思想，我们非常有信心在后期快速迭代。
除了算法较少外，结合业务反馈与自身思考。我们觉得机器学习平台可以做更多的事：
平台定位不仅仅是实验控制台，增加预测结果落地的功能（离线计算）
训练模型随着历史数据的不断扩充在大部分情况下都应该是个周期性的事情。我们希望在平台层面能够帮助用户托管这个过程。
v2.0（扩充组件 & 离线计算 & 周期性调度）
第二个版本中，我们首先基于原有的设计框架扩充完善了相关实用组件:
同时在第二个版本中，我们在细节上又做了一些完善：
建模实验运行状态流程展示，用户可以观察到每个组件的运行时间，状态，日志等
依赖完整的组件可以进行局部运行，在一个较复杂的建模实验中，完全可以先进行局部验证以及参数调整
建模实验支持克隆
离线计算
我们提供了‘字段落地’的工具组件，可以将预测结果以 csv 的格式落入 hdfs 中：
周期性调度 & 宏变量支持
我们的另一款产品：大数据开发套件（BDK），函盖周期性调度的功能，机器学习平台的建模实验可以以子任务的形式嵌入其中，结合宏变量（某种规则的语法替换，例如’/%Y/%m/%d’可以表示为当前天等等）用户可以在我们的平台中托管他们的建模试验，从而达到周期性离线计算的目的。
架构
综上，丰富组件及完善功能、离线计算结果落地、结合 BDK 进行周期性离线计算是我们平台第二个版本主要关注的，具体架构有了以下演进：
v3.0（实时预测 & 交叉验证）
实时预测
在我们的平台中可以通过建模实验训练模型，模型可以通过 PMML 这样的标准导出，同样也可以通过我们的模型导出功能将模型以 parquet 格式保存在 Hdfs 相应的目录上。用户可以得到这些模型标准，自己去实现一些功能。但是我们觉得实时预测的功能在我们平台上也可以抽象出来。于是 3.0 的架构中我们开发了提供实时预测服务的 tcscoring 系统：
tcscoring 系统的依赖介质就是模型的 PMML 文件，用户可以在机器学习平台上直接部署训练完成了的模型对应的 PMML 文件，或者通过其他路径生成的 PMML 文件。部署成功后会返回用于预测的 rest 接口供业务使用：
当然，PMML 的部署也可以结合 BDK 设置成周期性调度，这些结合模型的周期性训练，整个训练 + 预测的过程都可以交给机器学习平台 +BDK 实现托管。
交叉验证
在机器学习平台的第三个版本中，我们还有个关注点就是交叉验证，之前的版本中用户一次只能实验一组超参数，有了交叉验证，用户便可以在一次实验中配置多组超参数，在训练集中在按比例进行循环拆分，一部分训练，一部分验证，从而得到最优模型：
平台展望
个性化
迭代完 3 个版本后，机器学习平台抽象出了很多通用的东西，但是还有一些个性化的东西没有办法很好地变现。我们的想法是对于用户来说，最好的个性化途径就是让用户自己写代码，我们会尝试开放接口自定义插件，同时利用动态编译技术加载这些个性化的组件，融合进建模流程中。
融合其他算法包
我们目前也在尝试融合 spark ml 之外的算法包，如使用度较广的 xgboost 等。另一方面目前的算法还是基于传统的机器学习算法，对于深度学习，不管是嵌入 tensorflow 还是使用一些第三方的深度学习库，如 Deeplearning4j 等。我们接下来会尝试融合这些 spark ml 之外的算法包。