星星之火,可否燎原 —— 关于深度学习和大数据系统融合现状的认识

2020 年 10 月 23 日 AINLP

在我博士毕业的 2016 年,我就关注到了一个比较小众的算法工程方向——深度学习和大数据系统的融合。具体来说,就是将深度学习放在大数据系统上(当时主要指 Spark),从而实现分布式深度学习。当时我觉得,这个方向会在未来工业应用中占有一席之地。


但是现在 2020 年来看,深度学习和大数据系统融合这个方向已经沉寂了。



一、红旗还能打多久?



深度学习和大数据系统融合这个沉寂的辽原上,有一些零散的星火。


  1.  TensorFlow on Spark


    2017年 2 月 13 日,雅虎宣布开源 TensorFlowOnSpark (https://github.com/yahoo/TensorFlowOnSpark)。TensorFlowOnSpark 为 Apache Hadoop 和 Apache Spark 集群带来可扩展的深度学习。

     

  2.  Horovod on Spark


    Horovod (https://github.com/horovod/horovod) 是一个支持TensorFlow、Keras、PyTorch和Apache MXNet的分布式训练框架。Horovod的目标是让分布式深度学习更快更易用。 目前 Horovod 已经支持了 Spark。


  3.  Flink-AI-Extend


    Flink-AI-Extended (https://github.com/alibaba/flink-ai-extended) 由阿里于2019 年 6月 28 号推出,其结合了TensorFlow和Flink,为用户提供了更方便有用的工具。


我司内部 Spark-Fuel 是 TensorFlow on Spark  的加强版本。


深度学习和大数据系统融合的这些项目,不过是昏暗草原上的零散几个小火堆。整个草原还是沉闷还是沉寂。我这个“小娃娃”就要问了,深度学习和大数据系统融合的红旗到底还能打多久?


大约在 2014-2016 年,分布式习开始在工业界落地。在工业界落地的第一件事就是找到一个合适的集群编排系统,进而管理用于深度学习的机器把我们自己代入分布式深度学习进行工业化的人们,我们会发现,当时Mesos 和 K8S 做集群编排和管理都不成熟,久经考验的成熟系统只有是跑着 Spark 的 Yarn这个时候,我们的第一反应是将深度学习嵌入到 Spark 上,解决掉集群编排管理的问题。但现在已经是 2020 年了,K8S 在和 Mesos 的竞争中,干死了 Mesos ,自身也成熟起来,成为了集群编排管理的工业实际标准。人们已经能够方便地在 K8S 的基础上构建起分布式深度学习能力。


同时,随着 NLP 和 CV 等领域模型越来越复杂,比如现在的 Bert 等,CPU 已经扛不住这类模型的深度学习了。深度学习转向 GPU,已经成为大势所趋。用没有成熟 GPU 调度能力的大数据系统去支持类似 Bert 模型的分布式训练,就是脑子有病。


总结起来,深度学习和大数据系统融合,会面临两个问题


  1.  K8S 的问题


    K8S 已经成熟起来在 K8S 上搭建深度学习分布式训练集群,已经有很多成熟的案例。对比之下,在大数据系统搭建深度学习分布式训练集群,显得多余了。


  2. GPU 的问题


    NLP 和 CV 等领域模型越来越复杂,比如现在的 Bert 等,需要 GPU 支持。但大数据系统集群没有成熟的 GPU 调度能力。 


在上述情势下,深度学习嵌入大数据系统,目标是解决什么问题,又能解决什么问题?现在继续推动深度学习嵌入大数据系统,是不是逆技术趋势而动?




二、革命目标是什么



当前 K8S 的成熟,和对 GPU 的需求,都让深度学习和大数据系统融合这个技术领域的前途似乎一片黑暗。但是对于深度学习和大数据系统融合的前途,我却有不同的理解。


如下图所示,最近几年,广告推荐搜索领域的算法推陈出新,我们作为小团队也尝试过其中几种方法,也取得了一定效果。



但我们在线上用的这些模型和超级大场景团队用的这些模型,有没有区别呢?区别大了去了,我们的模型用了用户几百几千维特征和道具几十几百维特征,交叉也不敢做。不要问为什么只能用这些特征,问就是训练组件支持不了更大的模型。也不要问为什么 LR 的训练能支持千万级特征,问就是我们退步了。像我们这样,占工业界绝大数的大腰部和底部的广告推荐搜索场景的算法工程师,并没有相应超大规模深度学习系统的支持。其实这些腰部和底部数据量没有金字塔尖的超级大场景那么大,只需要也只能够一个轻量的深度学习分布式训练框架训练一个亿级乃至十亿级 embedding 模型便能带来可观的效果提升。如果我们能够改造深度学习框架,并且支持基本所有广告推荐搜索团队都要使用的大数据集群(不然没法处理大量的样本和特征),我们一个小团队立马获得了大规模深度学习能力的工程能力。


另外,当前广告推荐搜索算法工程师们不管是出于快速迭代模型的考虑,还是出于尝试强化学习的考虑,都对在线学习有比较强烈的述求。而这个也是大数据系统的强项。大数据系统中的 Storm 和 Flink 是工业界标准的实时数据处理框架,具备的 Exactly-Once (数据不重复) 、多数据流时间窗口聚合和反压机制(平滑数据流速度)特性都是在长期的工业实践中锤炼出来的。如果我们成熟地完成深度学习和大数据系统中的实时数据处理系统结合,我们一个小团队就能立马获得在线学习和强化学习的工程基础。


通过上面到场景,我们了解到,通过深度学习和大数据系统融合做的分布式训练组件,满足了一些特性之后,还是有一些需求的。


  1. 轻量级


    不需要算法团队搭建训练集群,复用现有大数据系统集群就有分布式训练能力。还有一个附带的好处是,直接在大数据系统集群训练,不需要频繁地进行大数据的转移。


  2. 离线以及在线


    同时具备离线和在线训练能力

  3. 大规模广告推荐搜索深度学习模型

    针对广告推荐搜索领域的大规模模型。这类模型计算相对简单,但容量达到亿级乃至十亿级 Embedding。


如果我们将深度学习和大数据系统融合的目标设定为,轻量级的离线以及在线的大规模广告推荐搜索深度学习模型的分布式训练组件,那么事情还有作为的空间。这个目标换成人话来说,广告推荐搜索领域的算法人员可以很方便地离线或者在线地训练亿级乃至十亿级的大规模模型。聚焦上面的目标之后,上一章提到的问题便可以解决。


  1.  解决 K8S 的问题


    K8S 集群上的超大规模深度学习分布式训练组件肯定是非轻量级的。对于占大部分的腰部和底部的广告推荐搜索领域,轻量级也就是拿来就能训练亿级乃至十亿级的大规模模型,是有相当的吸引力。


  2. 解决 GPU 的问题


    广告推荐搜索领域的亿级乃至十亿级的大规模模型,模型很大,但计算复杂性缺不高。模型大量的是 ID 类特征的 Embedding, lookup 操作是比较快速的。对于这类模型,CPU 是能扛得住的。 



三、北上 VS 南下路线之争



一旦我们确立了,深度学习和大数据系统融合的目标是,轻量级的离线以及在线的大规模广告推荐搜索深度学习模型的分布式训练组件,下面就是要确定路线。


现在的深度学习和大数据系统融合工作,在做的过程中,可能都没有意识到深度学习和大数据系统融合,其实有两条路线可以走。哪两条路线呢?深度学习和大数据系统融合,本质上是将深度学习放置在大数据系统之上,具体做法无非, 1)南下——改下层的大数据系统,使大数据系统能够适应深度学习框架;2)北上——改上层深度学习框架,使之能运行在大数据系统上。



现在不管 TensorFlow on Spark 还是 Horovod on Spark 或者 Flink AI Extend,都是南下 “改大数据系统使之适应深度学习框架” 的路线上的。


南下 “改大数据系统使之适应深度学习框架” 的路线,最大的特点就是简单。只要大数据系统改动,满足深度学习框架需要的环境就可以了。但是啊,所有命运赠送的礼物,早已在暗中标好价格。



简单意味着施展空间太小。


  1.  超大规模深度学习能力缺失


    当前的深度学习框架 TensorFlow 和 Pytorch 自带的 PS 模块都相对简单,并不天然具备亿级乃至十亿级规模模型的训练能力。如果只改动大数据系统的话,那么深度学习和大数据系统融合之后,并不具备超大规模深度学习能力。


  2.  易用性下降


    由于是对大数据系统进行改造,因此部署深度学习和大数据系统融合的时候,必须对现有集群进行改造。这样方便性和易用性下降。


  3.  稳定性下降


    大数据系统系统基本上都是 scala 写的,集群分配内存资源是分配给 JVM 的。但是 Tensorflow 和 Pytorch 深度学习框架底层是 C++,可以直接申请机器上的内存。当模型特别大,比如上亿乃至上十亿级 Embedding 模型,C++ 直接申请机器上的内存比较多。训练这类模型的任务多了,很容易冲击大数据集群的内存分配,造成稳定性下降。


那么我们是不是走北上路线—— “改深度学习框架,使之能运行在大数据系统上” 呢?这条路线复杂度高,需要大量的工程工作。具体的工作包括,实现一个 Parameter Server,将这个 Parameter Server 嵌入深度学习框架,改造深度学习框架改变其运行的模式。说起来很简单的样子,但是实现起来好复杂。


四、当前的形式和我们的任务



为什么我突然又关心起,很久之前关注的深度学习和大数据系统融合呢?当然是我们在这方面有了一些自己的工作。这篇文章比较详细地阐释了我们对深度学习和大数据系统融合的理解,这些理解凝聚在我们的工作里。


当然,为了实现我们对深度学习和大数据系统融合的理解,我们引入了一个非常非常奇怪的设定,可能会成为杀死我们工作的达摩克里斯之剑。这个下篇文章会详细介绍。



我们看准了深度学习和大数据系统融合方向的价值,也对当前实现路线有了自己的理解。那便要躬身入局,全力一搏。




由于微信平台算法改版,公号内容将不再以时间排序展示,如果大家想第一时间看到我们的推送,强烈建议星标我们和给我们多点点【在看】。星标具体步骤为:

(1)点击页面最上方"AINLP",进入公众号主页。

(2)点击右上角的小点点,在弹出页面点击“设为星标”,就可以啦。

感谢支持,比心

欢迎加入AINLP技术交流群
进群请添加AINLP小助手微信 AINLPer(id: ainlper),备注NLP技术交流

推荐阅读

这个NLP工具,玩得根本停不下来

征稿启示| 200元稿费+5000DBC(价值20个小时GPU算力)

完结撒花!李宏毅老师深度学习与人类语言处理课程视频及课件(附下载)

从数据到模型,你可能需要1篇详实的pytorch踩坑指南

如何让Bert在finetune小数据集时更“稳”一点

模型压缩实践系列之——bert-of-theseus,一个非常亲民的bert压缩方法

文本自动摘要任务的“不完全”心得总结番外篇——submodular函数优化

Node2Vec 论文+代码笔记

模型压缩实践收尾篇——模型蒸馏以及其他一些技巧实践小结

中文命名实体识别工具(NER)哪家强?

学自然语言处理,其实更应该学好英语

斯坦福大学NLP组Python深度学习自然语言处理工具Stanza试用

关于AINLP

AINLP 是一个有趣有AI的自然语言处理社区,专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享,主题包括文本摘要、智能问答、聊天机器人、机器翻译、自动生成、知识图谱、预训练模型、推荐系统、计算广告、招聘信息、求职经验分享等,欢迎关注!加技术交流群请添加AINLPer(id:ainlper),备注工作/研究方向+加群目的。


阅读至此了,分享、点赞、在看三选一吧🙏

登录查看更多
0

相关内容

专知会员服务
220+阅读 · 2020年8月1日
【综述】金融领域中的深度学习,附52页论文下载
专知会员服务
163+阅读 · 2020年2月27日
金融时序预测中的深度学习方法:2005到2019
专知会员服务
166+阅读 · 2019年12月4日
【干货】大数据入门指南:Hadoop、Hive、Spark、 Storm等
专知会员服务
95+阅读 · 2019年12月4日
深度学习自然语言处理综述,266篇参考文献
专知会员服务
229+阅读 · 2019年10月12日
Perseus(擎天):统一深度学习分布式通信框架
云栖社区
4+阅读 · 2019年3月10日
Java 工程师快速入门深度学习,可以从 Deeplearning4j 开始
人工智能头条
13+阅读 · 2018年12月14日
面向云端融合的分布式计算技术研究进展与趋势
中国计算机学会
19+阅读 · 2018年11月27日
TensorFlow 2.0和PyTorch谁更好?大牛们争了好几天
阿里新一代实时计算引擎:Blink
InfoQ
3+阅读 · 2018年3月26日
【机器学习】推荐13个机器学习框架
产业智能官
8+阅读 · 2017年9月10日
Arxiv
0+阅读 · 2021年1月24日
Fast AutoAugment
Arxiv
5+阅读 · 2019年5月1日
Arxiv
22+阅读 · 2018年8月30日
VIP会员
相关VIP内容
相关资讯
Top
微信扫码咨询专知VIP会员