小议机器学习平台

“好的平台才能体现人生的价值”

虽然

Spark框架

尝试提供“通用”的大数据计算平台，其优势是可满足近乎80%的计算需求，但劣势也正恰恰是无法满足特定20%的计算场景，而当这20%的场景恰好又要支撑80%的业务价值产出时，则需要单独优化了。

举个例子，各互联网巨头的搜索、广告和推荐系统，是各公司的主要利润来源，如何保证算法高效、稳定的运行并不断提升优化，这已不是单一的算法问题了，涉及更多的工程架构问题，需要搭建特定场景下的算法平台，例如本文将讨论的大规模可扩展的机器学习平台。

机器学习算法并行化有两个基本思路，分别是数据并行以及模型并行。

所谓数据并行，是指将数据拆为多份，每份数据单独训练，然后再将模型集成融合。该思路的优势是简单直接，并且不限于具体的机器学习算法类型。但缺点也很明显，独立的训练过程没有考虑模型参数之间的相关性，当数据量不充足时可能导致各个弱分类器都弱，集成效果也不明显。

所谓模型并行，则是将机器学习模型对应的不同任务分布在不同的机器上计算。直观理解是TensorFlow的设计实现机制，将神经网络的计算任务分解为有向无环图的形式，每个节点均可单独在任意机器上计算，而边决定了不同任务的依赖关系，相当于在集群上组成了一条并行生产的高效“流水线”。

然而，当在大规模数据场景下，上亿的特征对应的模型参数也可能上千万，因此，如何高效的存储模型参数并与不同计算节点高效通信成为了平台性能的瓶颈，由此，参数服务器的思路运用而生。

简单的，可以将模型参数统一存储到高性能的KV数据库中。但针对不同规模的问题场景和物理资源限制，还可能需要对模型参数进行拆分，或者对每个模型计算任务进行拆分。拆分意味着后续还要组合，并且如何减少不同节点的通信耗时也是需考虑的问题。

当然，不论何种并行方式，大规模系统平台本质上都是将一个单机功能系统转变为一个分布式系统。分布式计算在带来规模和效率提升的同时，也带来了复杂性，时钟同步、资源调度、存储容错等等工作都需要是额外的工作保证。

回到开头，并非所有场景都需要独立建设特定的技术平台，例如离线场景通过脚本和作业的方式控制即可；而小规模实时计算场景，通过Restful API或将模型封装为PMML格式供后端服务调用等方式；再者还可以使用第三方开源平台如基于Spark的PredictionIO，或者付费购买第三方平台服务等。