机器学习作为近几年的一项热门技术，不仅凭借众多“人工智能”产品而为人所熟知，更是从根本上增能了传统的互联网产品。在近期举办的2018 ArchSummit全球架构师峰会上，个推首席数据架构师袁凯，基于他在数据平台的建设以及数据产品研发的多年经验，分享了《面向机器学习数据平台的设计与搭建》。

一、背景：机器学习在个推业务中的应用场景

作为独立的智能大数据服务商，个推主要业务包括开发者服务、精准营销服务和各垂直领域的大数据服务。而机器学习技术在多项业务及产品中均有涉及：

1、个推能够提供基于精准用户画像的智能推送。其中用户标签主要是基于机器学习，通过训练模型后对人群做预测分类；

2、广告人群定向；

3、商圈景区人流量预测；

4、移动开发领域经常出现虚假设备，机器学习能够帮助开发者识别新增的用户的真伪；

5、个性化内容推荐；

6、用户流失以及留存周期的预测。

二、具体开展机器学习的过程

1、原始数据经过数据的ETL处理，入库到数据仓里。

2、上面蓝色部分代表机器学习：首先把样本数据与我们的自有数据进行匹配，然后洞察这份数据并生成特征，这个过程叫特征工程。接下来基于这些特征，选择合适的算法训练后得到模型，最终把模型具体应用到全量的数据中，输出预测的结果。

标准的机器学习工作流：针对业务上产生的具体问题，我们把它转化成数据问题，或者评估它能否用数据来解决。将数据导入并过滤后，我们需要将数据与业务问题和目标进行相关性分析，并根据具体情况对数据做二次处理。

下一步我们进行特征工程。从数据里找出跟目标有关的特征变量，从而构建或衍生出一些特征，同时要把无意义的特征剔除掉。我们大概需要花80%的时间在特征工程这个环节。选出特征之后，我们会用逻辑回归和RNN等算法进行模型的训练。接下来需要对模型做验证，判断其是否符合目标。不符合目标的原因有可能是数据和目标不相关，需要重新采集；也有可能是我们在探索的时候，工作不到位，因而需要对现有的数据重新探索，再进行特征工程这些步骤。如果最终模型符合业务预期，我们会把它应用在业务线上面。

三、机器学习项目落地的常见问题

虽然上面的流程很清晰，但在具体落地的过程中也会遇到很多问题，这里我就之前的实践经验谈几点。

1、现在大部分公司都已经进入大数据的时代，相比于以往的小数据级的阶段，在机器学习或者数据挖掘等工作方面，对我们的建模人员、算法专家的技能要求变高，工作难度也大大地提升了。

以往大家自己在单机上就可以完成机器学习的数据预处理、数据分析以及最终机器学习的分析和上线。但在海量数据情况下，可能需要接触到Hadoop生态圈。

2、做监督学习时，经常需要匹配样本。数据仓库里面的数据可能是万亿级别，提取数据周期非常长，大把的时间要用于等待机器把这些数据抽取出来。

3、大多数情况下，很多业务由一两个算法工程师负责挖掘，因而经常会出现不同小组的建模工具不太统一或实现流程不规范的情况。不统一会造成很多代码重复率高，建模过程并没有在团队里很好地沉淀下来。

4、很多机器学习算法工程师的背景存在专业的局限性，他们可能在代码工程化意识和经验上相对会薄弱一些。常见的做法是：算法工程师会在实验阶段把特征生成代码和训练代码写好，交给做工程开发的同学，但这些代码无法在全量数据上运行起来。之后工程开发同学会把代码重新实现一遍，保证它的高可用和高效。但即便如此，也常常出现翻译不到位的情况，导致沟通成本高，上线应用周期长。

5、机器学习领域的一大难题在于对数据的使用，它的成本非常高，因为我们把大量时间用于探索数据了。

6、个推有多项业务在使用机器学习，但并不统一，会造成重复开发，缺少平台来沉淀和共享。这就导致已经衍生出来的一些比较好用的特征，没有得到广泛的应用。

四、个推针对机器学习问题的解决方案

首先说一下我们这个平台的目标：

第一点，我们希望内部的建模流程规范化。

第二点，我们希望提供一个端到端的解决方案，覆盖从模型的开发到上线应用整个流程。

第三点，我们希望平台的数据，特别是开发出的特征数据可以运营起来并在公司内不同团队间共享使用。

第四点，这个平台不是面向机器学习零基础的开发人员，更多的是面向专家和半专家的算法工程师，让他们提高建模的效率。同时这个平台要支持多租户，确保保障数据安全。

以下是我们自己的整体方案，主要分成两大块：

下半部分是建模平台，也叫实验平台，它主要供算法工程师使用，建模平台包含：

1、对应IDE。在这个平台上进行数据探索、做数据的实验，并且它能支持项目的管理和共享。

2、我们希望把已经开发好的特征数据管理起来，方便所有平台用户看到数据资产的情况。

3、样本匹配时候，样本ID可能与内部ID不统一，这个时候需要做统一的ID匹配服务。

4、帮助算法工程师从万亿级数据里快速地抽取所需数据，这也是非常重要的一点。

5、做机器学习的过程中，除了基本的算法，实际上还有很多代码是重复或者相似的，我们需要把这些常用代码进行函数化封装。

6、支持对模型服务进行打包部署。

7、模型还要支持版本管理。

8、在实际业务中应用模型，需要实时监控起来，跟进模型的可用性、准确性等。

上半部分是生产环境，运行着数据处理pipeline，同时与数据建模平台对接着。

在生产环境中，模型对应的特征数据分两类：

一类是实时特征数据，比如数据实时采集，生成一些实时的特征，根据不同的业务需求存储在不同的集群里。

另一类是离线特征数据，离线数据加工后存到Hive，供模型应用侧进行使用。

在生产环境中，我们可以提供在线的预测API或 离线预测好的数据 供业务线使用。

五、方案实践具体要点

第一点，我们讲讲jupyter这块：

选择Jupyter作为主要建模IDE而不是自研可视化拖拽建模工具，这样的好处是可以做交互式的分析，建模效率也很高，扩展方便，研发成本低。当然类似微软Azure这样的可视化拖拽建模平台，可以非常清晰地看到整个流程，适合入门级同学快速上手。但我们的目标用户是专家和半专家群体，所以我们选择了最合适的Jupyter。

使用Jupyter时候，为了支持多租户，我们采用Jupyterhub。底层机器学习框架我们用了Tensorflow、Pyspark、Sklearn等。数据处理探索时候，结合sparkmagic，可以非常方便地将写在Jupyter上的Spark代码运行到Spark集群上。

对于Jupyter没有现成的版本管理控制和项目管理， 我们结合git来解决。

另外为了提高建模人员在Jupyter上的效率，我们引入了比较多的插件，例如：把一些典型挖掘pipeline做成Jupyter模板，这样需要再做一个类似业务�