机器学习作为近几年的热门技术，不仅以众多“人工智能”产品为人熟知，更从根本上为传统互联网产品赋能。下面这篇文章将结合我负责的个推大数据平台建设，与大家分享我在个推数据平台架构方面的经验和踩过的一些坑。一、背景：机器学习在个推业务的应用场景作为独立的智能大数据服务商，个推的主营业务包括开发者服务、精准营销服务和各垂直领域的大数据服务。而机器学习技术在很多业务和产品中都有涉及：1.个推可以根据精准的用户画像提供智能推送。其中，用户标签主要是基于机器学习，在训练模型后对人群进行预测和分类；2、针对广告人群；3、商圈、景区人流量预测；4、移动开发领域经常出现虚假设备，机器学习可以帮助开发者识别新增用户的真伪；5、个性化内容推荐；6、用户流失及留存期预测。二、机器学习的具体过程1、原始数据经过ETL处理后存入数据仓库。2.上图蓝色部分代表机器学习：首先将样本数据与我们自己的数据进行匹配，然后洞察这个数据并生成特征。这个过程称为特征工程。接下来，根据这些特征，选择合适的算法进行训练得到模型，最后将模型应用到全量数据上，输出预测结果。标准的机器学习工作流程：对于具体的业务问题，我们将其转化为数据问题，或者评估是否可以用数据解决。数据导入过滤后，我们需要分析数据与业务问题和目标的关联性，根据具体情况对数据进行二次加工。接下来我们进行特征工程。从数据中找出与目标相关的特征变量，从而构造或推导出一些特征，同时去除无意义的特征。我们需要将大约80%的时间花在特征工程上。选择特征后，我们将使用逻辑回归和RNN等算法来训练模型。接下来，我们需要验证模型以确定它是否符合目标。不符合目标的原因可能是数据与目标无关，需要重新采集；也可能是我们在探索的时候，工作不到位，需要重新探索现有的数据，然后进行特征工程的这些步骤。如果最终模型符合业务预期，我们会应用到业务线。3.机器学习项目实施中的常见问题上面的过程虽然很清晰，但是在具体实施过程中会遇到很多问题。这里我就从之前的实践经验谈几点。1、现在大部分企业已经进入大数据时代。相比前一阶段的小数据层面，无论是机器学习还是数据挖掘，对我们的建模师和算法专家的技能要求都变高了，工作难度也有了很大的提升。过去，每个人都可以在一台机器上完成机器学习的数据预处理、数据分析，以及最终的机器学习分析和上线。但是在海量数据的情况下，可能需要接触Hadoop生态。2、在做监督学习的时候，经常需要匹配样本。数据仓库中的数据可能是万亿级别的，数据提取周期很长，大量的时间花在等待机器提取数据上。3.大多数情况下，很多业务都是由一两个算法工程师来挖掘的，所以经常会出现不同组的建模工具不统一或者实现过程不规范的情况。不一致会造成很大的代码重复率，建模流程在团队中也没有很好的落户。4.很多机器学习算法工程师的背景有专业局限性，代码工程意识和经验可能比较薄弱。一个普遍的做法是：算法工程师会在实验阶段编写特征生成代码和训练代码，交给做工程开发的同学，但这些代码无法在全量数据上运行。之后工程开发同学会重新实现代码，保证其高可用和高效。但即便如此，也经常会出现翻译不到位的情况，导致沟通成本高，申请周期长。5.机器学习领域的一个大问题是数据的使用。它的成本非常高，因为我们花了很多时间去探索数据。6、个推有多个业务使用机器学习，但不统一，会导致重复开发，缺乏沉淀和分享的平台。结果，一些已经派生出来的有用特性并没有被广泛使用。4.推动机器学习问题的解决方案首先，让我们谈谈我们平台的目标：首先，我们希望内部建模过程标准化。第二，我们希望提供一个端到端的解决方案，涵盖从模型开发到在线应用的全过程。第三点，我们希望平台的数据，尤其是开发出来的特色数据，能够在公司内部不同团队之间进行操作和共享。第四点，这个平台不是面向机器学习零基础的开发者，而是面向专家级和半专家级的算法工程师，让他们提高建模效率。同时，平台必须支持多租户以保证数据安全。下面是我们自己的总体规划，主要分为两部分：下半部分是建模平台，也叫实验平台，主要是给算法工程师使用。建模平台包括：1.相应的IDE。在此平台上进行数据探索和数据实验，支持项目管理和共享。2、我们希望对已开发的特征数据进行管理，让所有平台用户都能看到数据资产的状态。3.样本匹配时，样本ID可能与内部ID不一致。这时候就需要一个统一的身份匹配服务。4、帮助算法工程师从万亿数据中快速提取需要的数据也很重要。5.在做机器学习的过程中，除了基本的算法之外，其实还有很多重复或者相似的代码。我们需要对这些常用的代码进行功能封装。6.支持模型服务打包部署。7.模型还支持版本管理。8.将模型应用到实际业务中，需要实时监控，跟进模型的可用性和准确性。上半部分是生产环境，运行数据处理流水线，连接数据建模平台。在生产环境中，模型对应的特征数据有两类：一类是实时特征数据，比如实时采集数据，生成一些实时特征，根据不同的业务存储在不同的集群中要求。另一类是离线特征数据，离线数据处理后存储在Hive中，供模型应用端使用。在生产环境中，我们可以提供在线预测API或离线预测数据供业务线使用。五、程序实践的具体要点***重点，说说jupyter：选择Jupyter作为主要的建模IDE，而不是自研的可视化拖拽式建模工具。这样做的好处是可以进行交互分析，提高建模效率。也很高，容易扩展，研发成本低。当然，像MicrosoftAzure这样的可视化拖拽式建模平台，可以非常清楚地看到整个过程，适合入门级的同学快速上手。但是我们的目标用户是专家和半专家群体，所以我们选择了最适合的Jupyter。在使用Jupyter时，为了支持多租户，我们使用Jupyterhub。我们使用了Tensorflow、Pyspark、Sklearn等作为机器学习的底层框架。在探索数据处理的时候，结合sparkmagic，可以很方便的把Jupyter上写的Spark代码跑到Spark集群上。对于Jupyter，没有现成的版本管理控制和项目管理，我们结合git来解决。另外，为了提高建模者在Jupyter上的效率，我们引入了更多的插件，例如：将一些典型的挖矿管道制作成Jupyter模板，这样当你需要做类似的业务时，只需要扩展基于模板的开发。很好地解决了非标准化问题，避免了很多重复代码，也为实验代码转化为生产代码奠定了基础。第二点说说工具功能：我们内部主要提供了机器学习相关的功能库和工具：1）标准化的IDMapping服务API。2）创建数据抽取的API，无论是哪种存储，分析师只需要统一调用这个API即可。3）可视化具有标准化的函数库和工具类。4）Jupyter2AzkabanFlow：可以将原来在Jupyter上编写的代码或脚本自动转换成AzkabanFlow，解决了特征工程阶段的代码复用问题。第三点是关于Tensorflow的使用：在使用Tensorflow的时候，我们选择的是TensorflowOnSpark。原生的Tensorflow分布式支持不够好，需要指定一些节点信息，使用起来比较困难。TensorflowOnSpark可以解决原生TensorflowCluster的分布问题，代码无需任何改动即可轻松迁移到TensorflowOnSpark。同时，使用yarn可以支持GPU和CPU混合集群，资源可以轻松复用。第四点是关于模型交付的应用：在模型交付的问题上，我们把整个预测代码框架化了，提供了多种标准框架供分析师直接选择。输出模型文件有格式要求，例如：只能选择pmml格式或tensorflowpb格式。标准化后，建模者的工作和系统开发者的工作可以解耦，只要使用标准的预测函数库即可。***分享一些经验：***，TensorflowOnSpark上的PS数量有限，Worker和PS节点的资源分配不是很灵活，都是大小相等的。其次，在使用Jupyter时需要自己做一些修改，部分开源库版本存在兼容性问题。第三，PMML的使用存在性能瓶颈。有的是java对象的反复重构，有的是格式转换丢失。具体可以抓取jvm资料进行分析优化。第四，在实施过程中使用Spark和Hive的问题，需要提供简单易用的诊断工具。建模人员不是Spark和Hive方面的专家，可能不熟悉如何诊断和优化。第五，模型和特征库应该被视为资产，定期评估其价值，管理好其生命周期。第六，一些更底层的问题，例如：硬件选择可能需要注意带宽、内存和GPU平衡。最后，需要平衡技术栈增加和维护的成本，避免引入过多的新工具和新技术，导致运维困难。
