|
大家好，我是来自第四范式的胡时伟，今天很高兴能够和我们的算法科学家涂威威一起跟大家分享我们在AI开发平台“先知”产品的一些经验，共同探讨机器学习从系统和工程方面的优化方向。 接下来主要从如下几个方面来讲述：
首先先从人工智能发展说起，人工智能并不是一个最近出现的概念，早在60年代就有著名学者曾经预言二十年内机器将能够完成人能做到的一切工作。到今天我们又听到说20年之内，一大半的工作岗位将被机器人替代。那么60年代到今天发生的最大的区别是什么？这其中发生了两个重大的变化，第一个是计算能力的突飞猛进，今天的手机一个核的计算能力就足以秒杀当年的超级计算机。第二个是我们拥有了大数据，TB级的数据存储、处理在今天已经不再困难，而20年前，GB级的硬盘才刚刚兴起。 因此我们说今天人工智能=机器学习+大数据，那么什么样是好的人工智能呢？这里引入一个“VC维”的概念。“VC”维是1960年代到1990年代由Vapnik及Chervonenkis建立的一套统计学习理论。VC维反映了函数集的学习能力，VC维越大则模型或函数越复杂，学习能力就越强。之前，统计建模曾经进入过一个误区，就是去追求经验风险最小化，什么意思呢？就是说我希望建立一个模型，在给定的样本上不要有误差，这样感觉非常好，但是往往这么一来，在实际的预测中非常糟糕，这是为什么呢？是因为采用了一些VC维很高的模型，虽然函数集学习能力是强了，但是由于数据不够，所以导致置信风险变大产生了一些类似过拟合的情况，最后这个模型还是不好用。 但是今天我们进入了大数据时代，样本的数量，包括样本的特征丰富程度有了极大提升，这就又带来了提升VC维的新机会。我们经常说经验主义害死人，过去的建模就是害怕经验主义，所以呢就把这个大脑变笨，降低VC维，使得模型更有效。但是今天的大数据情况下，可以通过补充更多的阅历（数据），来避免经验主义，那么一个阅历丰富的聪明的人，自然是要比一个笨的记不住东西的人要好的。因此我们说大数据人工智能时代，提升VC维变成了一个好的人工智能系统的关键因素。 那么机器学习中的高维度从何而来？传统方法只能利用可以放在特征矩阵这个平面中的数据，对于立体的数据，多维度的数据，因为它们多不是数字，所以传统机器学习模型无法处理，只能选择舍弃。但在实际工业应用中，这类非数字化的数据所包含的信息，往往信息价值很高，比如它可能对个性化推荐很有影响，可能对泛化处理有帮助。为了能成分利用这些数据，我们对特征矩阵外的立体的数据通过切片等算法进行变换，使得变换后的数据成为特征矩阵的一部分，同时还对不同特征之间进行交叉组合等操作，这样特征矩阵的每一行的列数就从原始数据的列数，变成了每一行都是一个巨大（比如2的64次方）的向量，形成超高维度的模型。 高维度模型真正的意义何在？通过对原来立体数据切片处理，可以使得某些过去只能有简单线性表达的数据，比如年龄等，获得更接近真实情况的细腻体现；此外，原来机器学习不能利用的非数字、没有排序关系的数据，比如姓名等，也可以发挥其价值所在。举个例子，在个性化推荐的场景中，体现个性化信息的数据之间通常是不可比的，比如，我们先只考虑热度、推荐序号和用户ID三个变量，其中用户ID这个变量就是传统机器学习模型所不能利用的，只有通过将这个数据切片处理，获得一个高维度模型，才可以真正将用户信息这个数据发挥出价值。 要获得一个成功的高维度模型，就需要好的机器学习系统，这个系统应当具备两个特征：横向可扩展的高计算性能和算法本身在收敛过程中的正确性。为此，我们的算法工程团队开发了一系列的基础设施组件，组成了大规模分布式机器学习框架GDBT（General Distributed Brain Technology）。GDBT是一个由C++编写的，完全分布式的适合于机器学习计算场景的计算框架，可以运行在单机、MPI、Yarn、Mesos等多个分布式环境。 大规模分布式机器学习框架GDBT 机器学习是一种数据驱动的实现人工智能的方式，机器学习在实际应用中的大数据、高维度背景导致需要一个高效计算的平台，同时，监督学习领域著名的No Free Lunch定理指出，没有一个机器学习模型能够对所有的问题都是最有效的。所以在不同的实际问题里，需要使用不同的机器学习算法或者对机器学习算法做适应性地调整，去达到更好的实际效果。因此在实际的应用中，需要能够非常容易地开发出适应实际问题的机器学习算法。相比于传统的ETL计算，机器学习算法的计算过程有很多自身的要求和特点。 在框架设计上，没有普适的最好的框架，只有最适合自身应用场景的框架。GDBT框架的设计初衷主要就是打造一个专门为分布式大规模机器学习设计的计算框架，兼顾开发效率和运行效率。GDBT框架不是某一种算法，而是一种通用的机器学习算法计算框架，使算法工程师可以基于GDBT开发各种传统或者创新算法的分布式版本，而不用过多地关心分布式底层细节。 目前比较流行的计算框架比如Hadoop、Spark其重点任务大多是ETL类的任务。前面提到机器学习计算任务相比于传统的ETL计算任务有很多自身的特点，时间有限这里可以简单地展开一下。 在计算方面：相比于ETL会做的一些相对“简单”的运算，机器学习算法会对数据做相对复杂的运算，一些非线性的模型，比如深度学习模型会需要比较密集的计算；在实际的应用中，需要考虑不同计算资源的特性；分布式计算中，由于分布式带来的通讯、同步、灾备等等的overhead需要调整计算模式来尽可能地降低。 在通讯方面：很多机器学习算法在计算过程中会频繁使用到全局或者其他节点的信息，对网络吞吐和通讯延迟的要求要远高于ETL任务。同时，很多机器学习任务对于一致性的要求要低于ETL任务，在系统的设计上可以使用放松的一致性要求。 在存储方面：ETL需要处理来源不同的各种数据，比较少的反复迭代运算，很多机器学习算法会对数据做反复的迭代运算，可能会有大量的不断擦写的中间数据产生，对存储的使用效率、访问效率有着更高的需求。 在灾备和效率的权衡方面：容灾策略有两方面的额外开销，一方面来自于执行过程中为了容灾所需要做的额外的诸如状态保存之类的操作，另一方面来自于灾难恢复时所需要进行的额外重复计算开销。这两方面的开销是此消彼长的。与ETL计算任务不同，机器学习计算任务流程相对复杂，中间状态较多，在较细的粒度上进行容灾会增加执行过程中的额外开销。因此在容灾策略和容灾粒度上，机器学习计算任务和ETL计算任务之间的权衡点不一样。 GDBT计算框架针对机器学习任务在计算、通讯、存储、灾备等方面做了深入的优化。时间有限，这里可以简单的讲一点GDBT的工作，有兴趣了解更多的同学可以会后再和我们联系，或者加入第四范式一起解决这些有趣的问题：） 在计算方面，计算硬件发展到今天，提升计算能力的主要方式是堆积计算能力的分布式并行计算，比如现在做深度学习非常流行的GPU本身也是一种并行计算硬件，针对不同需求的计算硬件的种类也在变多，比如FPGA等等。对于大数据、高维度、复杂的机器学习计算任务，GDBT框架充分考虑了分布式并行计算的特点，针对不同的硬件资源、不同的算法场景做了调度、计算模式、机器学习算法部件的抽象等的优化。GDBT框架本身在设计上也刻意避免了现在一些框架设计容易走入的误区。比如：为了分布式而分布式，但是忘记了分布式带来的overhead。GDBT框架针对单机、分布式模式分别进行了优化，框架本身会对不同规模的计算任务、不同的计算环境做自适应的调整选择更高效的实现。 然后在通讯方面，通信效率是分布式机器学习系统中至关重要的部分。首先,相比于ETL任务,很多机器学习算法在计算过程中会频繁使用到全局或者其他节点的信息,对网络吞吐和通讯延迟的要求都很高。其次,一些机器学习算法在通信时可能有很多可以合并处理的通讯需求。再次,很多机器学习算法并不要 求在所有环节保证强一致性。最后,对于不同的网络拓扑,最优的通讯方式也会不一样。因为存在可能的合并处理、非强一致性需求、网络拓扑敏感等,就会存在有别于传统通讯框架的优化。先知的GDBT计算框架内部,针对机器学习计算任务单独开发了一套通信框架,为机器学习任务提供了更高效、更易用的支持点对点异步、点对点同步、深入优化的组通讯(比如类MPI的Broadcast、 AllReduce、Gather、Scatter等等)的通信框架,同时为应用层提供了简便易用的合并、本地缓存 等等功能。 然后介绍下我们在参数服务器（Parameter Server）方面的工作，很多机器学习算法的学习过程都是在“学习”一组参数,对于分布式机器学习任务,不同的节点需要对“全局”的这组参数进行读取和更新,由于是分布式并行的计算任务,因此存在着一致性的问题,不同的机器学习算法或者同一个机器学习算法的不同实现对一致性的要求会不尽相同,不同的 一致性策略对整体算法的效率会产生很大的影响。参数服务器就是为了解决分布式并行机器学习任务中多机协同读取、更新同一组参数设计的,设计上需要提供简单易操作的访问接口方便机器学习专家开发算法,同时也需要提供可选择的一致性策略、灾备等等。 另外，由于是为机器学习任务设计，参数服务器的设计目标是高吞吐、低延迟。GDBT中的参数服务器针对不同的应用场景做了更 加深入的优化,结合高效缓存、智能合并等优化策略以及基于GDBT自带的高效异步通讯框架,同 时,还针对稀疏、稠密等不同的参数场景进行了针对性优化;内置提供了丰富的一致性策略可供用户选择或自定义一致性策略；GDBT将参数服务器看成一种特殊的Key-Value存储系统,对其进行了独立的灾备设计,同时提供不同粒度的灾备选项,便于在实际的部署中选择合适的灾备策略提升效率。 这次我主要讲计算框架方面的工作，以后有机会可以再详细分享我们在机器学习算法框架以及机器学习算法方面的设计工作。针对机器学习算法计算，GDBT框架做了进一步的抽象，比如数据流、优化算子、多模型框架等等，这里简单介绍下数据流的设计。对于研究并实现机器学习算法的专家而言，算法的核心就是数据的各种变换和计算。GDBT框架为了让机器学习专家更容易、更快速地开发出不同的机器学习算法提供了数据流的抽象，使得机器学习专家通过描述数据流DAG图的方式编写机器学习算法。机器学习专家只需要关注数据的核心变换和计算逻辑，GDBT计算框架将机器学习专家描述的数据流图进行高效的分布式计算。 数据流计算框架的抽象一方面有助于降低机器学习专家的开发门槛、提升开发速度（他们不需要关注底层分布式、并行细节），另一方面也为GDBT框架提供了更大的空间去进行数据流执行优化，能够进一步提升执行效率（如果GDBT框架只在底层模块进行优化，将会非常乏力；但是数据流的抽象使得GDBT框架能够更全面地了解计算任务的pattern，可以做更多的优化工作）。 在存储、灾备设计等方面，GDBT也做了深入的优化，比如多级缓存的设计、框架层面对存储读取写入、网络访问、计算过程等等的灾备设计，对不同计算规模采取不同的灾备粒度等等，这里时间有限，就不做过多介绍了。机器学习算法部分的工作以后有机会可以再一起交流。 GDBT定制的通信框架、算法框架以及参数服务器，为进行大规模机器学习训练提供了基石。当然GDBT还有一个很大的特性是算法开发者友好，对于算法开发来说，学术研究和工业应用之间存在一定的取舍。一些其他的算法框架比如Tensorflow，比较注重研究上的易用性，从而在效率上有所舍弃，而一些注重于生产应用的算法框架特别是分布式框架，在算法二次开发和扩展上则捉襟见绌。GDBT提供的是工业级的开发者易用性，从语言级别，GDBT整体基于C++ 14标准，为算法的开发提供了更大的自由。从功能抽象上，GDBT提供了对参数服务器和算子的良好包装，在GDBT上，只需要数百行代码就可以实现像逻辑回归、矩阵分解等算法的分布式版本。 机器学习算法框架的语言选择问题 关于机器学习算法框架的语言选择问题，因为今天很多的大数据框架都是基于Hadoop/Spark这一套的，都是JVM上的东西，因此基于JVM从整体来说接入生态是比较容易的，但其实有三点理由让我们选择C++而不是基于JVM去做这件事情。 首先我们前面讲过，目前虽然计算能力对传统应用来说井喷，我们经常说CPU过剩、GPU过剩。但是对于高维机器学习过程来说，依然是资源非常紧张的，这里面包括计算、网络、内存等多个方面，我们看Spark的Project Tungsten也做了大量堆外内存管理的工作以提升数据的处理效率，但是对机器学习来说，基本上整个过程都需要对内存和计算过程进行精细控制，以及避免不可控的GC过程。 其次，C++的一些语言特性，比如运算符重载机制也可以使得框架上层的算法应用的语法比较简单优雅，不会变成巨大的一坨，而大规模机器学习很多时候和字符串组成的离散特征打交道，C++对字符串处理的效率也要高出JVM-Based语言非常多。 再次，Spark目前的机制和Parameter Server的结合很难做到优雅和完美，强行对接PS会破坏Spark自身的灾备、任务调度等特性。如果不对接，那么就基本上只能靠降低模型大小来确保效率，和高维度的目标南辕北辙。所以综合考虑，我们还是选择C++来实现整个一套的系统，而将和大数据框架的对接以及开发门槛降低这个任务交给整个机器学习系统的架构。 整体架构 上面讲了很多机器学习算法框架，但有过实践经验的朋友都知道，光有一个算法框架只相当于汽车有了发动机，离开起来还很远。我们总结一个完整的机器学习系统需要有如下部分： - 数据引入和预处理 - 特征工程 - 模型训练算法（支持参数灵活调整和二次开发） - 模型评估 - 模型上线（批量预估、实时API调用、线上特征实时计算） 那么对于这所有的部分，我们开发了一个叫『先知』的整体平台产品，我们先看一下先知的整体架构图：
这套架构能够给我们带来如下几个优势： 1. 把整个机器学习过程作为一个整体来看待，做到各模块的深度整合。下面是我们产品的一个截图
同时呢，这个DAG图的背后我们还做了很多工作，一个比较有意思的就是对存储的抽象和适配。我们有的客户是用AWS作为基础设施，而有的客户用阿里云做基础设施，有的客户则选择在IDC内构建自己的机房。这里面就有块存储、云盘、SSD、内存盘等多种存储服务。 另外，一个完整的机器学习过程，往往还要从数据库里面导入数据，最终要把数据导出到某个指定的位置。导数据在逻辑上的复杂性和由于某些开源模块不支持内存缓存和SSD导致的性能的低下都是困扰数据科学家的问题。 对此设计了一个两层的存储抽象层API，第一层是一个开源项目alluxio，就是以前的tachyon，alluxio这个东西是非常好的，好在哪里呢？他用一套解决方案一下子解决了几个问题，第一是可以支持很多分布式的文件系统，包括S3、Ceph等。第二还能够比较透明的解决内存和SSD加速的问题。针对Alluxio这个项目，我们将整个的数据处理、模型训练、预估体系，包括我们自己开发的GDBT框架都和alluxio做了深度的融合集成，也针对开源的产品在访问调度、吞吐、SSD优化上做了一些增强和修补的工作。 第二层是DataManager，我们知道企业的应用，特别在意安全性，那么如果我们直接把底层的文件系统暴露给使用者，会导致权限隔离等个方面的隐患。Datamanager提供了一个数据的逻辑沙箱，使得每个使用者在自己的DAG里面只能用一个唯一的名字来访问到自己安全容器内部的数据，这样不仅保证了安全，也避免了使用者直接去处理各种各样的长的数据文件的URI。 2. 给开发者提供比较好的体验，相信使用大数据系统的朋友都有一个感受，就是在分布式时代，调试变得难了。一方面很多时候日志太过于复杂，不知道错误在哪里，另外一方面经常出现跑了几个小时报一个错前功尽弃的情况。先知平台从产品上做了很多工作，比如说Schema推断
3. 支持模型的上线，模型上线有几个技术上的难点，一是线上线下的一致性，而是性能。线上线下一致性为什么难，因为你看到训练过程是那么复杂一个DAG图，那么对应的线上多个数据源，也要经过一个组合、变换的过程，那如果每次都去手动开发，这个代价就不得了。 先知的架构支持从线下的DAG导出线上服务的核心部分，那么特征工程、模型计算就可以直接获得一个可用的API，可以极大的节省开发者的代价。另外一个难题就是性能，因为线下批量的训练，可以花很长时间，而线上如果是实时预估，那么就要毫秒级的响应，也要求很高的QPS。 我们在线上有一个叫Cannon的分布式KV框架，可以支持到数十T分布式内存的模型高性能存储和查询。而模型计算的部分也可以复用GDBT的代码，既减少了开发量，又为一致性提供了保证。这里面也有很多有意思的工程优化，比如说如何解决机器数变大、网络条件变差情况下的可用性塌方式下降。今天时间有限就不展开说了，有机会可以再跟大家分享。 小结 非常感谢大家耐心听我们分享了上面我们做的这些微小的工作。第四范式是一个工程师为主的公司，我们有数十个来自于各大国内外公司顶尖机器学习团队的优秀工程师，各路ACM冠军选手每天在各个方向上做很多深入的产品和工程优化工作，希望能够促进机器学习和AI在各行各业的发展，也希望能够给从业者们带来更好用的平台和工具。 当然做出好的机器学习解决方案，最关键的还是要和行业结合，工具和平台系统只是其中的一小部分，所以还希望能够向各位同仁多多学习。这里打个小广告，现在先知平台公有云版本已经向业务场景成熟的企业客户有限名额的开放合作，如果有风控、内容推荐、客户经营等场景，数据量较大的朋友，我们也可以一起互相切磋，互相学习。谢谢大家。 Q&A Q1：请问先知平台用到深度学习框架了么？
Q2：是通过何种机制做到数百倍的加速的？
Q3：有没有提出一些最优化框架，比如SVRG等来加速收敛？
Q4：超参数学习这块是通过bayes还是强化学习呢？
Q5：在何种情况下如何判定自动特征不能起作用而改为人工特征呢？
Q6：先知在实现过程中用到参数服务器了没有？ 模型的训练，是采用异步asp，还是同步bsp，还是半异步的ssp这种？ 如果是异步，如何解决收敛困难的问题？
Q7: 第四范式的先知和谷歌的Tensor flow有什么区别？
Q8：GDBT有没有解决模型并行训练问题？还是只依靠数据并行？
Q9：GDBT怎么能够同时支持连续、离散的这两种数据的融合训练？
Q10：请问GDBT对于异构计算的支持情况如何？
Q11：第四范式的人工智能平台先知可以直接替代 Spark 么？
Q12：什么样的企业用得起机器学习来辅助运营？使用你们机器学习系统的门槛是什么?
Q13：电商推荐平台，怎么样能最快地应用机器学习的精准推荐？
Q14：机器学习目前哪些企业和行业应用比较广泛？国内有哪些成功案例。
Q15：自动特征这套做法，跟百度凤巢的那套是一样的对吧？ 百度有公开论文，是gradient boosting factorization machine，这个方法比深度学习那个自动特征相比如何
另外：对于FPGA和GPU的未来我们有一段简单的思考，之前有准备过一段，之前没用上，现在贴这里：
讲师介绍 胡时伟 第四范式联合创始人，研发副总裁 在大规模机器学习、广告、搜索、行业垂直应用、系统运维、研发团队管理等领域拥有丰富经验。 曾主持架构了百度“知心”系统和链家网系统，在百度任职期间作为系统架构负责人，主持了百度商业客户运营、凤巢新兴变现、“商业知心”搜索、阿拉丁生态等多个核心系统的架构设计工作。在担任链家网研发负责人期间，从0开始完成了链家网新主站、经纪人新作业系统、绩效变革系统的整体架构设计以及研发团队的建设管理，参与规划及推动了链家系统和研发体系的互联网化转型。 现任第四范式研发总工程师，负责产品技术团队以及第四范式核心产品『先知』机器学习平台的研发工作。 涂威威 第四范式数据建模专家 在大规模分布式机器学习系统架构、大规模机器学习算法设计和应用、在线营销系统方面有深厚积累。 百度最高奖triity发起人之一。 首次将FPGA应用于在线营销深度学习预估系统。 设计开发百度机器学习计算框架ELF。 |
|
|
来自： openlabzeng > 《待分类》
