创新工场王咏刚：为何 AI 工程师要懂一点架构？

时间 2019-11-24

原文原文链接

本文转载自微信公众号：半轻人
做者：王咏刚

王咏刚 AI科技大本营算法

AI 时代，咱们总说作科研的 AI 科学家、研究员、算法工程师离产业应用太远，这其中的一个含义是说，搞机器学习算法的人，有时候会由于缺少架构（Infrastructure）方面的知识、能力而难以将一个好的算法落地。咱们招的算法工程师里，也有同窗说，我发的顶会 paper 一级棒，或者我作 Kaggle 竞赛一级棒，拿了很多第一名的，不懂架构就不懂呗，我作出一流算法，天然有其余工程师帮我上线、运行、维护的。

鉴于此，我给创新工场暑期深度学习训练营 DeeCamp （ps：这个训练营太火了，只招生 36 名，总共有 1000 多计算机专业同窗报名，同窗们来自 CMU、北大、清华、交大等最好的大学）设计培训课程时，就刻意把第一节课安排为《AI 基础架构：从大数据到深度学习》，后续才给你们讲《TensorFlow 实战》、《天然语言处理》、《机器视觉》、《无人驾驶实战》等框架和算法方向的课。

为何我要说，AI 工程师都要懂一点架构呢？大概有四个缘由吧：

缘由一：算法实现 ≠ 问题解决

学生、研究员、科学家关心的大可能是学术和实验性问题，但进入产业界，工程师关心的就是具体的业务问题。简单来讲，AI 工程师扮演的角色是一个问题的解决者，你的最重要任务是在实际环境中、有资源限制的条件下，用最有效的方法解决问题。只给出结果特别好的算法，是远远不够的。

好比一些算法作得特别好，得过 ACM 奖项或者 Kaggle 前几名的学生到了产业界，会惊奇地发现，原来本身的动手能力还差得这么远。作深度学习的，不会装显卡驱动，不会修复 CUDA 安装错误；搞机器视觉的，没能力对网上爬来的大规模训练图片、视频作预处理或者格式转换；精通天然语言处理的，不知道该怎么把本身的语言模型集成在手机聊天 APP 里供你们试用……

固然能够说，作算法的专一作算法，其余作架构、应用的帮算法工程师作封装、发布和维护工做。但这里的问题不只仅是分工这么简单，若是算法工程师彻底不懂架构，其实，他根本上就很难在一个团队里协同工做，很难理解架构、应用层面对本身的算法所提出的需求。

缘由二：问题解决 ≠ 现场问题解决

有的算法工程师疏于考虑本身的算法在实际环境中的部署和维护问题，这个是很让人头疼的一件事。面向 C 端用户的解决方案，部署的时候要考虑 serving 系统的架构，考虑本身算法所占用的资源、运行的效率、如何升级等实际问题；面向 B 端用户的解决方案要考虑的因素就更多，由于客户的现场环境，哪怕是客户的私有云环境，都会对你的解决方案有具体的接口、格式、操做系统、依赖关系等需求。

有人用 Python 3 作了算法，无法在客户的 Python 2 的环境中作测试；有人的算法只支持特定格式的数据输入，到了客户现场，还得手忙脚乱地写数据格式转换器、适配器；有人作了支持实时更新、自动迭代的机器学习模型，放到客户现场，却发现实时接收 feature 的接口与逻辑，跟客户内部的大数据流程根本不相容……

部署和维护工程师会负责这些麻烦事，但算法工程师若是彻底不懂得或不考虑这些逻辑，那只会让团队内部合做愈来愈累。

缘由三：工程师须要最快、最好、最有可扩展性地解决问题

AI 工程师的首要目的是解决问题，而不是显摆算法有多先进。不少状况下，AI 工程师起码要了解一个算法跑在实际环境中的时候，有哪些可能影响算法效率、可用性、可扩展性的因素。

好比作机器视觉的都应该了解，一个包含大量小图片（好比每一个图片 4KB，一共 1000 万张图片）的数据集，用传统文件形式放在硬盘上是个怎样的麻烦事，有哪些更高效的可替代存储方案。作深度学习的有时候也必须了解 CPU 和 GPU 的链接关系，CPU/GPU 缓存和内存的调度方式，等等，不然多半会在系统性能上碰钉子。

扩展性是另外一个大问题，用 AI 算法解决一个具体问题是一回事，用 AI 算法实现一个可扩展的解决方案是另外一回事。要解决将来可能出现的一大类类似问题，或者把问题的边界扩展到更大的数据量、更多的应用领域，这就要求 AI 工程师具有最基本的架构知识，在设计算法时，照顾到架构方面的需求了。

缘由四：架构知识，是工程师进行高效团队协做的共同语言

AI 工程师的确能够在工做时专一于算法，但不能不懂点儿架构，不然，你跟其余工程师该如何协同工做呢？

别人在 Hadoop 里搭好了 MapReduce 流程，你在其中用 AI 算法解决了一个具体步骤的数据处理问题（好比作了一次 entity 抽取），这时其余工程师里让你在算法内部输出一个他们须要监控的 counter——不懂 MapReduce 的话，你总得先去翻查、理解什么是 counter 吧。这个例子是芝麻大点儿的小事，但小麻烦是会日积月累，慢慢成为团队协做的障碍的。往大一点儿说，系统内部到底该用 protocol buffers 仍是该用 JSON 来交换数据，到底该用 RPC 仍是该用 message queue 来通讯，这些决定，AI 工程师真的都逆来顺受、不发表意见了？

Google 的逆天架构能力是 Google AI 科技强大的重要缘由

这个不用多解释，你们都知道。几个现成的例子：

（1）在前 AI 时代，作出 MapReduce 等大神级架构的 Jeff Dean（其实严格说，应该是以 Jeff Dean 为表明的 Google 基础架构团队），也是如今 AI 时代里的大神级架构 TensorFlow 的开发者。

（2）在 Google 作无人驾驶这类前沿 AI 研发，工程师的幸福感要比其余厂的工程师高至少一个数量级。好比作无人驾驶的团队，轻易就能够用已有的大数据架构，管理超海量的 raw data，也能够很简单的在现有架构上用几千台、上万台机器快速完成一个代码更新在全部已收集的路况数据上的回归测试。离开这些基础架构的支持，Google 这几年向 AI 的全面转型哪会有这么快。

课 件分享：AI 基础架构——从大数据到深度学习

下面是我给创新工场暑期深度学习训练营 DeeCamp 讲的时长两小时的内部培训课程《AI 基础架构：从大数据到深度学习》的所有课件。所有讲解内容过于细致、冗长，这里就不分享了。对每页课件，我在下面只作一个简单的文字归纳。

注：如下这个课件的讲解思路主要是用 Google 的架构发展经验，对大数据到机器学习再到近年来的深度学习相关的典型系统架构，作一个原理和发展方向上的梳理。由于时间关系，这个课件和讲解比较偏重 offline 的大数据和机器学习流程，对 online serving 的架构讨论较少——这固然不表明 online serving 不重要，只是必须有所取舍而已。

这个 slides 是最近三四年的时间里，逐渐更新、逐渐补充造成的。最先是英文讲的，因此后续补充的内容就都是英文的（英文水平有限，错漏不免）。

如何认识 AI 基础架构的问题，直到如今，仍是一个见仁见智的领域。这里提的，主要是我的的理解和经验，不表明任何学术流派或主流观点。

上面这个图，不是说全部 AI 系统/应用都有这样的 full stack，而是说，当咱们考虑 AI 基础架构的时候，咱们应该考虑哪些因素。并且，更重要的一点，上面这个架构图，是把大数据架构，和机器学习架构结合在一块儿来讨论的。

架构图的上层，比较强调云服务的架构，这个主要是由于，目前的 AI 应用有很大一部分是面向 B 端用户的，这里涉及到私有云的部署、企业云的部署等云计算相关方案。

上面这个图把机器学习和深度学习并列，这在概念上不太好，由于深度学习是机器学习的一部分，但从实践上讲，又只好这样，由于深度学习已经枝繁叶茂，不得不单提出来介绍了。

先从虚拟化讲起，这个是大数据、AI 甚至全部架构的基础（固然不是说全部应用都须要虚拟化，而是说虚拟化目前已经太广泛了）。

这个是 Docker 本身画的 VM vs. Container 的图。我跟 DeeCamp 学员讲这一页的时候，是先从 Linux 的 chroot 命令开始讲起的，而后才讲到轻量级的 container 和重量级的 VM，讲到应用隔离、接口隔离、系统隔离、资源隔离等概念。

给 DeeCamp 学员展现了一下 docker（严格说是 nvidia-docker）在管理 GPU 资源上的灵活度，在搭建、运行和维护 TensorFlow 环境时为何比裸的系统方便。

严格说，Kubernetes 如今的应用远没有 Docker 那么普及，但不少作机器学习、深度学习的公司，包括创业公司，都比较须要相似的 container-management system，须要自动化的集群管理、任务管理和资源调度。Kubernetes 的设计理念其实表明了 Google 在容器管理、集群管理、任务管理方面的总体思路，特别推荐这个讲背景的文章：http://queue.acm.org/detail.cfm?id=2898444

讲大数据架构，我基本上会从 Google 的三架马车（MapReduce、GFS、Bigtable）讲起，尽管这三架马车如今看来都是“老”技术了，但理解这三架马车背后的设计理念，是更好理解全部“现代”架构的一个基础。

讲 MapReduce 理念特别经常使用的一个例子，论文引用计数（正向计数和反向计数）问题。

统计一篇论文有多少参考文献，这个超级简单的计算问题在分布式环境中带来两个思考：（1）能够在不用考虑结果一致性的状况下作简单的分布式处理；（2）能够很是快地用增量方式处理数据。

可是，当咱们统计一篇文献被多少篇论文引用的时候，这个事情就不那么简单了。这主要带来了一个分布式任务中常见的数据访问一致性问题（咱们说的固然不是单线程环境如何解决这个问题啦）。

好久之前咱们是用关系型数据库来解决数据访问一致性的问题的，关系型数据库提供的 Transaction 机制在分布式环境中，能够很方便地知足 ACID（Atomicity, Consistency, Isolation, Durability）的要求。可是，关系型数据库明显不适合解决大规模数据的分布式计算问题。

Google 的 MapReduce 解决这个问题的思路很是巧妙，是计算机架构设计历史上绝对的经典案例：MapReduce 把一个可能带来 ACID 困扰的事务计算问题，拆解成 Map 和 Reduce 两个计算阶段，每一个单独的计算阶段，都特别适合作分布式处理，并且特别适合作大规模的分布式处理。

MapReduce 解决引用计数问题的基本框架。

MapReduce 在完美解决分布式计算的同时，其实也带来了一个不大不小的反作用：MapReduce 最适合对数据进行批量处理，而不是那么适合对数据进行增量处理。好比早期 Google 在维护网页索引这件事上，就必须批量处理网页数据，这必然形成一次批量处理的耗时较长。Google 早期的解决方案是把网页按更新频度分红不一样的库，每一个库使用不一样的批量处理周期。

用 MapReduce 带来的另外一个问题是，常见的系统性问题，每每是由一大堆 MapReduce 操做连接而成的，这种连接关系每每造成了复杂的工做流，整个工做流的运行周期长，管理维护成本高，关键路径上的一个任务失败就有可能要求整个工做流从新启动。不过这也是 Google 内部大数据处理的典型流程、常见场景。

Flume 是简化 MapReduce 复杂流程开发、管理和维护的一个好东东。

Apache 有开源版本的 Flume 实现。Flume 把复杂的 Mapper、Reducer 等底层操做，抽象成上层的、比较纯粹的数据模型的操做。PCollection、PTable 这种抽象层，还有基于这些抽象层的相关操做，是大数据处理流程进化道路上的重要一步（在这个角度上，Flume 的思想与 TensorFlow 对于 tensor 以及 tensor 数据流的封装，有殊途同归的地方）。

Flume 更重要的功能是能够对 MapReduce 工做流程进行运行时的优化。

更多关于 Flume 运行时优化的解释图。

Flume 并无改变 MapReduce 最适合于批处理任务的本质。那么，有没有适合大规模数据增量（甚至实时）处理的基础架构呢？

谈到大规模数据增量（甚至实时）处理，咱们谈的实际上是一个兼具关系型数据库的 transaction 机制，以及 MapReduce 的可扩展性的东西。这样的东西有不一样的设计思路，其中一种架构设计思路叫 notification/monitor 模式。

Google percolator 的论文给出了 notification/monitor 模式的一种实现方案。这个方案基于Bigtable，实际上就是在 Bigtable 超靠谱的可扩展性的基础上，增长了一种很是巧妙实现的跨记录的 transaction 机制。

percolator 支持相似关系型数据库的 transaction，能够保证同时发生的分布式任务在数据访问和结果产出时的一致性。

percolator 实现 transaction 的方法：（1）使用 timestamp 隔离不一样时间点的操做；（2）使用 write、lock 列实现 transaction 中的锁功能。详细的介绍能够参考 percolator 的 paper。

Google 的网页索引流程、Google Knowledge Graph 的建立与更新流程，都已经完成了增量化处理的改造，与之前的批处理系统相比，能够达到很是快（甚至近乎实时）的更新速度。——这个事情发生在几年之前，目前 Google 还在持续对这样的大数据流程进行改造，各类新的大数据处理技术还在不停出现。