本周四，雷锋网 AI 研习社邀请了跨国 IT 巨头 ThoughtWorks 的资深数据架构师白发川，主讲线上公开课，为大家讲解 TensorFlow 在工程项目中的应用。
讲师
白发川：自我介绍一下，我是 ThoughtWorks 白发川，之前一直从事大数据，后来我们开始做人工智能方向的一些尝试和工作。我们致力于将人工智能、机器学习、大数据结合在一块。在研究了了很多相关的机器学习框架之后，我们也做了自己的深度学习框架——deeplearning.scala。它由 scala 编写，目前是开源的，大家可以了解下。
这是公开课的录制视频：
公开课文字版
不方便看视频的童鞋，可阅读以下雷锋网对本次公开课的文字转录。
由于篇幅较长，本次公开课的文字转录被拆为上下两部分，这是下篇。上篇请见雷锋网(公众号：雷锋网) TensorFlow在工程项目中的应用 公开课视频+文字转录（上） | AI 研习社。
白发川：上文我们提到了几种不同的大数据架构，它们和之前提到的数据成熟度评估模型相关——我们首先会评估一个企业的数据到达了怎样一个级别，才知道在目前哪一种解决方案最为适合。
人工智能与大数据
现在我们来谈谈人工智能。
其实人工智能这个概念并不是近期才有的，很早、几十年前大家就已经在提人工智能了。人工智能的核心目标是我们希望机器像人一样的思考。那机器怎样才能像人一样思考？
这里面发展出了两个分支：一个是早期的概率论模型，另一个是神经网络。
我们常见的 HMM、贝叶斯，都是属于概率论的。概率论对于数据的处理，你基本上存在一个抽样或者以概率形式去计算的。所以在很早的时候数据量不是特别大的情况下，概率论会是一个特别好的选择。
另外，概率论可以处理不太大的数据集，所以说相对来讲它会更加常用。比如说我们使用 HMM 去做分词，这也是个非常要好的一个场景。另外一个分支是神经网络。神经网络很早就提出了，但近几年才是各种深度神经网络框架逐渐火起来的一个时代。因为在最近我们发现，计算机的计算能力被提高了——神经网络在数据量越大的情况下，它的效果越好；在神经网络层次越深的情况下，它的效果更好；而这一切背后依靠的都是计算机的计算能力。神经网络也有好几种，比如说深度神经网络、递归神经网络、卷积等。如果计算机的计算能力没有发展，我们谈的人工智能将继续的停留在实验室。所以背后如果没有数据的支撑，AI 基本上谈不上任何效果。
我们不可能拿十条数据来训练，如果我们要上生产环境。这样的数据在本质上达不到生产需求。在很早的时候，数据一直在发展的过程中，其实人工智能也是在发展的，只是它发展的阶段不一样。在很早的时候，人工智能可能只是停留在理论阶段，我们知道有算法有论文，但是真正要应用到生产中，让它商业化、市场化，其实有很大的跨度。在这之后，我们会进入到一个新阶段：很多企业会做 AI lab，去开一个实验室来根据现有数据做尝试，看有没有更好的方法。
再下一个阶段，就到了大数据时代。这时，数据的处理性能变得特别的高。我们发现，AI 本来就是依赖于数据的，既然数据的处理能力提高了，AI 一定会迎来非常好的发展。这就是目前我们所面临的情况。很多企业会借助于大数据平台来对数据做处理。有了大数据之后，很多企业也会以人工智能来更好地服务于自身业务。
这里是一个生产中使用的、比较好的人工智能架构方案。
正如上篇提到的，数据和人工智能，两者是可以完全分开，但两者结合才是最终的解决方案。拿掉人工智能，我们可以把数据作为一个大数据平台去使用。有了人工智能，我们可以在大数据平台之上扩充，让它变成一个更完美的架构，所以这就是为什么数据架构非常重要——你的人工智能到底能不能很好的接入。图中可以看到，数据平台主要负责的是数据处理、数据存储、数据检索以及数据探索等一系列数据准备相关的工作。
当数据准备好了之后，对于机器学习这一块，它只是根据你的数据做特征提取、做模型训练，很大的一部分工作都会在数据平台上。最简单来讲，有的企业可能对数据的隐秘性要求比较高——会有数据加密、各种加密。那在运算过程中会有数据解密，加密这个过程、解密这个动作是没有办法让神经网络去做的，只能放在数据平台。所以数据平台对于数据的处理能力要求非常高，直接决定了后面的效果。
当我们的数据平台搭建完成了之后，本质上来讲就已经有了数据分布式环境。这是我们要做的，只是说有一个系统可以很好地加在分布式数据上，训练出一个模型。目前 TensorFlow 已经支持模型分布式，这是一个非常好的效果。
在很早的时候，模型训练是不支持分布式训练的，就是你的模型在一台机器上训练，就独立地训练出来。没有办法让两台机器配合去训练一个模型。而在目前来讲 TensorFlow 已经做得非常好，支持模型分布式训练，当然这得借助于它的计算图概念。
对于 Tensorflow 计算图这一系列很细的技术问题，后面"TensorFlow & 神经网络算法高级应用班”课程都会讲到—— Tensorflow 怎样支持模型的分布式训练。在这个架构里边，我们底层有 GPU、CPU 系统的人工智能集群，在这之上，我们创建的模型分布式训练会产生模型。数据平台还会提供另外一个功能，就是的实时流。
大家看到的这架构里边有一个分支，就是实时流。它与人工智能结合起来就是实时预测，实时预测之后，数据展示出来直接以决策的形式反馈给使用者，实际上实时流另外还有一个功能就是模型的持续训练。而在使用的这个地方，大家还能看到有个箭头，就是数据又进入了大数据平台。这是我们目前提倡的一个架构，叫数据驱动架构。就用户产生数据，数据服务于用户。如果说你的这个过程是良性的：比如说我用这个系统，系统服务于我，这个过程是良性的，越来越好；当我用的系统越多，它对我的体验越好，那这个系统就会自我进化，变得越来越好，所以这种架构也是我们目前在所有实施中采用地方案。
TensorFlow 的工程实践
TensorFlow 本身是一个深度神经网络框架。它的计算模块，也就是核心 Core 是由 C++ 写的。它对外提供了很多 API，早期只有 Python，1.0 之后增加了 Java API，但还处于测试阶段，不是特别稳定，也不是特别完善。所以对于 TensorFlow 我们还是优先使用 Python。
对于 Python 来讲，我们会把机器学习这一块包装成一个服务，或者说以其他形式来提供使用。在这一块，它对外提供的是 Python，它内部是 C++，中间就有一个数据交换，发生在内存中——就是将 Python 需要的计算逻辑转成 C++ ，由底层计算之后再返回结果。
在一个完整的人工智能系统里，分布式存在于两个地方：数据分布式和模型分布式。数据分布式主要是由数据湖支撑的，我们的数据被分布式存储。分布式数据存储的好处在于，我可以快速地把数据从不同节点拿过来。这个时候对于系统来讲，要扩展的仅仅是带宽。
在真正的生产里边，对于企业来讲，做一个专线搭建 GB 级网络带宽，在本质上的成本会远远低于提高计算机硬件。这也是数据分布式为什么会存在、并且做得越来越好的一个原因。
另外，TensorFlow 支持模型分布式。当我们数据分布式之后，我们的模型分布式，两者结合起来整个训练的速度会变得特别快。在 Tensorflow 里，模型计算可以根据你自己写的训练模型代码生成计算图，然后根据你的计算图将独立的每一个计算图分布到不同的节点，然后进行训练，最终产生一个唯一的模型，这也是 TensorFlow 在分布式训练方面做得非常好的一点。
但是我们回头来看，TensorFlow 在本质上、在使用过程中，它就是一个python库。所以当我们在做一个神经网络工程项目的时候，我们可以讲 TensorFlow 是我们的一个库，我们用了它。相对来讲，它所占的是我们系统中的一小个模块。
TensorFlow 是一个深度的神经网络框架，但是它并不是唯一的，像 Caffe、MXnet、Theano，还有 Java 版的 Deeplearning4j。这类框架早就存在了。那么为什么说 TensorFlow 是我们认为一个比较好的选择？
在开发中来讲，大家对它的定义是“工程化做的最好的深度神经网络框架”，因此倾向于选择于 TensorFlow。其他的框架在很多场景之下，像实验室或者高校大家也会用；但对工程师来讲，我们希望更友好的方式包 API 使用方式，能让工程师更容易懂；降低门槛，降低对数学的要求。
一个神经网络框架，设计得越原始，对数学的要求越高。这对工程师不是特别友好。而 TensorFlow 是介于这两者中比较一个折中的一个方案。
Python
既然 TensorFlow 说白了就是一个 Python 库，那么当我们开发人工智能项目的时候，本质上我们的开发就演变成了如何做好python项目的开发。
目前无论是做机器学习还是做数据分析，Python 有非常好的势头，大家都在用它。而更多的平台提供出来的，其实也是 Python作为api的方式， Python 在占的比重是非常大的。因此做人工智能项目，学习 Python 是非常重要的。就是说要研究 TensorFlow，之前得打好基础先学好 Python。
对于 Python 来讲，有 Python2 和 3，我们目前建议用 Python3。在 Python 里会涉及到非常多的库，我们需要管理库，它就和 yum 一样，我们可以使用 pip 来对我们的库做一些管理，下面有个 virtualenv。对于 Python 的这种轻量级语言来讲，在我们系统里边，有时会涉及不同版本的 Python 项目存在，这就需要一个好的隔离环境，让我们的两个环境隔离起来，不要相互影响。比如说我一个项目是 Python2，另外一个项目是 Python3，我希望这两个工程在我系统里面同时运行，virtualenv 提供了非常好的这样一个功能：封装了 Python 的环境，可以让你不一样的版本、不一样的库在一个系统里同时存在。对于 virtualenv 来讲，它提供的就是一个 Python 虚拟环境，我们在生产过程中会发现，当你的 virtualenv 非常多的时候，管理起来特别困难。于是我们会选择 virtualenvwrapper，它的作用是管理系统里边所有的 virtualenv，包括你的创建你的切换，都可以完整管理起来。
当我们有开发环境——就是前面提到的几种工具，都是开发过程中随时会用的。有了这些工具之后，下一步就是开发代码。
对于 Python 来讲，工具非常多。IPython Notebook 是一个轻量级的一个 Python web IDE，我们可以在网页上进行 Python 代码编写。它分为不同阶段，可以局部执行代码，能很快地把我们的代码所见即所得。这也是我们在做数据探索或者一些尝试的时候优先的选择。我们可以很快分析出，我们的整个操作到底对不对，还需不需要继续。
所以这里解释了我们为什么要用 virtualenv——我们需要一个独立的环境来运行我们的工程。这种思想和目前的 Docker 有一点类似。另外，当做一个比较大的项目的时候，我们可能会借助于集成开发环境地 IDE，像 Pycharm 式目前在开发中非常常用的，基本上百分之百会用到的 IDE。在正式环境之下，特别是一个 team，大家协助开发的时候特别会用到。
CI/CD
对于工程开发来讲，我们的一个项目在开发之后，我们需要上线，我们需要测试，我们需要部署；对于非人工智能的项目，我们会有 CI/CD。代码写完之后，我们需要部署、需要测试、需要运行，这一系列我们可以自动化，便是 CI/CD。
我们的代码提到版本控制器，CI/CD 会自动监听到代码发生变化，然后把代码打包、运型测试。成功之后给你部署，把结果以可视化的形式展示出来。这是我们一般项目开发中常用的 CI/CD 工具，那么在一个 AI 项目里，我们会不会做 CI/CD？
其实是会做的。
首先，人工智能的 CI/CD 和一般项目来讲流程差不多，但会有一些差异化的地方。前边还是一样，代码逻辑发生更改之后会触发整个 CI/CD 的 pipeline，还有一个分支：数据 pipeline 触发。
数据 pipeline 是什么？
前面提到人工智能数据，分为两块：一个是数据部分，一个是人工智能部分。这就意味着在我们的人工智能项目里边，它有逻辑，在数据里面它有数据。当我有新数据进来，或者说我的模型逻辑代码发生变更，这两者都会触发你的 CI/CD 。
CI/CD 被触发之后，除了和一般的项目一样要做基本的单元测试评估之外，我们多了一个功能，就是模型评估。这一部分功能的话，更多的是在 CI/CD 上做改造。
什么是模型评估？对于一般的系统来讲，什么样的情况之下，我们认为这个测试是挂的。就是它的真正输出和我们期望的输出不一致，我们就可以认为它挂了。
那对于 AI 来讲，什么样的情况下，我们认为这个这一次的开发是失败的？那就是模型在变坏，一次一次的变坏。比如我第一次训练出来的模型准确度 90%，第二次 80%，第三次 70%。从这个角度来讲，虽然说代码运行非常正确，但效果在降低，而这个评估应该被 CI/CD 记录下来。最后提交代码、模型训练出来之后，相比上一次的模型，如果它的效果更差，那你这次的 CI/CD 是挂地，整个 task 是不通过的。
这样，我们可以保证整个开发的性能是在上升的，就避免了一个 team 闷头开发代码不停地换方法，最后发现模型一次比一次差。
TensorFlow 应用场景
本质上讲，AI 是为了更好地帮助人来进行思考和辅助人做决策，所以场景相对来讲会比较广泛，也比较通用。但差别点是在于：你要在这个通用场景里，实现怎样的需求？
图像识别
比如一提到人工智能或者深度学习，或者卷积神经网络，大家都会想到图像识别，这是一个非常通用的领域。但对于在这个领域之内，要达到怎样地细化程度，就是需要我们进行评估和实现的。比如在我们之前做的项目里边，我们曾经做过一个电商的系统，是用来分析它的图片的——一个电商卖家可能会上传特别多的图片，对于整个电商平台来讲，它希望对图片做分析，知道上传地图片里边包含哪些物体，比如说我们在这个图片里边能够识别出这个是沙发、另外一个是人，等等这一系列的一些物体识别。
仓储机器人
这就是利用 TensorFlow 在图像识别领域细分领域的一个实现。除此之外的话，除了图像领域、对于 AI 这个概念，很多人提到 AI 大家会想到机器人。而实际上在工业界，机器人应用非常广泛，特别是在仓库来讲，仓储机器人以亚马逊为首开始率先带领这个行业。目前已经变得非常的常用，至少大家都在对这方面进行投入、研发。
仓储机器人的主要功能是搬迁货物。上图中大家可以看到，一个仓储机器人驮了一个货架。早期仓库的运作是“人到货”，人到货物前边把要的东西拿过来，这个效果非常差。
有了新型的 AI 配合的仓储机器人，我们的目标是“货到人”——我人站着不动，我需要什么货由机器人搬过来。那这里会遇到一个什么问题？
那就是多个机器人在仓库里边移动的时候，要保证安全性——两个机器人不撞在一块。另外它们要找到最短的路径，这被叫做仓储机器人路径规划：你到底应该按照怎样的方式去走。这也是 AI 的一个应用场景。那么这也是用 TensorFlow 做的实现。
智能评卷系统
以前对卷子进行评分，一般是都是人来做，甚至多个人打分。但在人工智能领域，我们发现这种人靠经验做的东西，其实计算机也可以做。在我们使用 TensorFlow 这个框架的时候，有一个功能叫递归神经网络，它主要是用来处理时间序列训练。在自然语言这一块，它也有特别好的优势，可以用来做这个事儿。所以这个本质上的项目目的，是用机器打分来替换人来给卷子评分。
智能招聘
智能招聘的目的是为了让求职者、应聘者和招聘方，双方有一个非常好的 match，让最合适的人去最需要他的地方。这样的话，我们就需要对双方做非常多的数据分析，而数据除了来自于个人本身，还会来自于社交或者其他地方，然后根据双方所有数据做一个 match。
在线广告投放系统
看起来它和推荐系统有点类似，但是当我们在做这个系统的时候，其实你会发现在线广告投放系统和推荐系统会有本质上的差别的。
说推荐系统受益者是用户使用者，而对于一个广告系统，它的受益者是平台或广告主。另外，推荐系统要找出的是符合使用者个体的最优推荐方案；但在线广告投放系统要达到的是利润最大化。
其次它有一种规则，比如说我设计好这个广告，不管它是否合理，我就是要投放。那这里的话有更多的规则干涉，配合及其学习，共同实现一个在线广告投放系统。这一块相对来讲比推荐系统复杂很多。
推荐系统
推荐系统在很多地方都会用，甚至在任何涉及到对用户进行服务的时候，其实都是涉及到推荐。比如我们用的很多 APP，会给你推送很多新闻，本质上这些新闻都是经过筛选之后的。在推荐这个领域。已经有很多存在的并且被广泛应用的方法。比如说基于人或者基于物的协同过滤，已经被广泛使用了。现在我们更多的尝试的事，是使用深度神经网络让推荐的效果变得更好。这里边有模型有算法，其实就是 TensorFlow 应用的一个场景。
最下边的数据服务我要强调一点：我们做任何一个 AI 系统，重点一定不是建一个模型，而是数据集、数据架构。这一块才是最重要的。
智能问答
其实我们可以把智能问答理解为常见的聊天机器人。这一块的话，在实践来讲很早的时候，我们可以直接通过关键字搜索，静态的给你返回，利用搜索引擎给你一个反馈。本质上来讲，这个时代算不上智能问答，只能说是一个文献检索。后来的话，什么样的情况才叫智能问答？
智能问答并不是简单地根据关键字，它能够明白我说的这句话到底是什么意思。
这样除了找出结果之外，它有一个很重要的功能，就是理解你说话。这就涉及一个技术：自然语言处理。所以在智能问答里边，我们除了要做一个相关的检讨之外，我们还要做自然语言处理。
另外，对于客户端来讲，我们的输入除了文本，可能还有语音，还有图片检索；所以你的思路也会变得特别多。这个领域目前来讲，是人工智能发展的还不错的一个领域。而这一块我们做的聊天机器人，其实它的模型基本上也是用 TensorFlow 来做的。
用 TensorFlow 给企业构建一个智能问答，它的好处到底在哪？
目前来讲，其实我们有很多云方面的、相关的、通用的一些解决方案。但对于行业来讲，垂直的智能问答并不是通用智能问题能解决的问题。比如说一个行业，它有很多行话，而这个行话不是时常被提及的，所以在这种方面对于企业来讲，它会构造一个属于自己的垂直行业的智能问答，可以快速给自己做服务，比如售后服务。当用户买了产品出了问题需要售后，这个时候机器人就可以派上用场了，而没有必要百分之百的放很多的客服人员进行问答。
生产中的问题
做一个人工智能项目的开发过程中，TensorFlow 只是你的一个框架。它做了相关的算法的实现，给了你比较友好的API，让你可以特别好得创建各种神经网络，进行各种训练。这方面来讲，更多是编程语言方面的熟悉或者说基础知识的理解。比如说什么是损失函数，什么是梯度下降。这种细节的编程级别的知识，在后面的培训课里我们会非常详细的提到。这里边提到的问题，更多的是在整个工程来讲——因为我们既然把 TensorFlow 应用到工程中，构建一个人工智能项目，肯定不是为了玩一玩，而是希望用它解决生产上的现实问题。
所以这一章要谈谈我前面提到的数据探索。在很早的时候，我们发现构建的数据湖缺少数据探索功能。一个数据湖放了好几 PB 的数据都在那儿，但是我连一个快速检索管理元数据，这种快速查找功能都做不到。后来我们会做一个数据探索服务来解决这个问题，进行各种预览，给数据科学家提供非常好的支撑。
文件处理
在下边的话就是对于小文件。首先，我们的 TensorFlow 所处理的数据一定是前期规整后的。也就是说 TensorFlow 没有办法直接接入生产环境，拿到未经处理的数据自己做处理。这一系列功能都发生在大数据架构，所以大数据架构本质上是给人工智能、TensorFlow 这一层提供良好的数据处理。
在这个过程中我们会遇到小文件的问题。比如说我的文件有几百亿个，曾经我们会遇到数据湖里面放的百亿千亿的文件。这个时候就面临文件个数多、文件小这种问题。对于这种文件处理的话，我们一般会有好几种场景。
第一种如果是静态文件，比如我这个数据，一批次导入几千万个文件就是这么多，可能不会再有持续进来，那最简单的方式就是压缩。压缩有多种方式，对不一样的实践，比如 Hadoop 有自己 的 sequence file 的方式。
除了这种方式，还有第二种场景数据处理，会应用在数据实时进入的情况下。比如我数据一直在来，每次来的都是小文件。持续进来，这个时候采用静态压缩方式就不合适了，因为数据一直在来。你可能把 10个1kb 压到 1个10kb，但没有什么意义。所以对于这种情况，我们之前在数据湖里设计了一个系统，叫小文件系统。它用来拦截所有数据请求，把小文件存下来之后，在后台有一个独立的后台线程，专门干什么事——做后台压缩。当你的文件个数或者说某一个特征触发了这个阀值之后，它会触发一个线程，把小文件进行压缩。
在这个小文件服务里边，它要记录的是被压缩之后这个文件里边包含哪些文件，分别 index 在哪个地方把它索引起来。这样，当我们有一个请求要访问小文件的时候，这个请求首先被小文件服务拦截下来，根据它要查找的文件通过管理系统去看它在哪个位置，然后拿到那个大文件将它解压出来再把小文件返回去，这样的话就可以解决掉一个小文件的问题。这种场景对于文件持续不断的进来，但是文件个数少可以作为一个非常好的解决。
实际上对于小文件，还有另外一种方式，就是我们可以把小文件放在kafka，它对于小文件处理是非常好的。但是卡夫卡有一个问题是处理不了大文件，特别是当文件差异过大，比如小文件一两 K、大文件几个 G，那基本卡夫卡就抓瞎了。
前面提到的是我们对少量文件处理。下边是我们曾经遇到的文件个数多问题——多达百亿以上。
我们知道，对于一个集 Hadoop 作为实施的数据服务系统来讲，他的所有元数据是放在 NameNode。而 NameNode 里有很大的一个 hashtable 用来存储元数据，记录了这个元数据在哪个 DataNode 之上。当我们要访问某一个文件的时候，先找 NameNode ，根据 哈希table 找到这个文件在哪个 DataNode 之上，把这个地址返回客户端，客户端拿着这个东西再去请求 DataNode，于是这一个文件请求过程就完成了。
所以瓶颈在哪个地方？
你的 DataNode 如果存放的文件记录特别多，就会导致你的整个内存爆掉。因为每一个文件进来，原信息要占一定的内存空间的。虽然说 Hadoop 号称是以廉价小型机为基础，但是它强调 NameNode 配置一定要高于其他节点，至少是高配的，这样才能保证你的整个集群可以运行得很好。早期 NameNode 提供了仅仅是 HA 的功能，你的所有的原信息都在一个 NameNode 里边，等你的文件过多，它基本就会产生非常大的问题。
按照生产环境真正来讲，一个 NameNode 能够存放的最大文件个数可能就在 700 万左右。就他的这个问题并不是因为 哈希table 到达上限，而是因为你每一个源文件进来，你的数据会占一部分存储，你的内存没办法扩展那么大，所以这个才是瓶颈。
在这个之后，出了一个 Hadoop 2.0 联盟。联盟就是把 NameNode 分摊到不同的节点之上，每一个节点挂载在不同的目录之下，于是把目录水平拆分，我一个 NameNode 的只负责一个目录，那这样的结构带来的好处是什么：它并不是简单的拆分。
在我们整个IT开发过程中，我们后来产生了一个微服务，这种思想其实它本质上是为了做什么，是把你的业务独立拆分开，就我们的一个大系统的问题在哪？当你的系统一宕机之后，你的整个需求全部出问题，都没法访问。但是当我们将业务拆分成不同的子系统，我其中一个宕机之后，我剩下的系统可以继续使用。
在 Hadoop 联盟之后出来之后，我们会发现，某一个文件夹出问题之后，我剩下的数据还可以继续使用。那这样的话，我们在设计数据的时候会怎么做？不一样的目录，我们可能面对的是不一样的业务场景，或者说不一样的部门。这样的话，一个大数据平台提供给企业之之后，我们有一个非常好的容错性，就是当某一个企业部门的数据出现问题之后，不会影响到其他地方。很好地直接在这一层做了安全隔离。对于一个企业来讲，它不太可能会做几套大数据平台，一般会有一套大数据平台，给整个企业提供一个统一的服务，并且在之上构建人工智能系统，这样的话对我们底层的数据设施要求非常高。而这一块 Hadoop 除了处理文件个数多之外，还提供了这种安全隔离，很好地解决这个问题。
集群搭建方式
下面这里大家看到的是集群搭建方式。
在应用 TensorFlow 和大数据进行整合的时候，我们会有好几种不同的处理方式，比如说数据平台和 AI 集群独立开。我们都知道，TensorFlow 的优势还是要利用 GPU。当然这并不是 TensorFlow 的问题，而是对于任何数值计算的框架，GPU 是最高效的。因为 GPU 做苦力活、做纯粹的数值计算非常擅长；而 CPU 对逻辑计算更擅长，那这样的话大家会倾向于用 GPU 来做数值计算，而深度神经网络里边本质上就是不同的矩阵，各种纯粹的数学运算。所以在企业里边我们都会搭建统一的 GPU 集群，专门用来训练模型。
这样就面临一个问题：我们在做一个企业级 AI 系统的时候，我们的数据平台到底应该怎样和 AI 系统进行整合，合并在一块？
我们可以完全的独立，一个数据平台，一个AI系统。我们也可以把 AI 系统和数据系统部署在一块。就是我们同一台服务器里面部署的 CPU，还有数据服务相关的东西。当我们计算的时候，我们的模型训练在 GPU 上，数据处理在其他地方，这也就整合成了一套。所以有两种部署方式，一种是独立的，一种是一体的，那对哪一种更好？肯定是一体的最好。为什么？
因为对于独立的来讲，我们如果独立，意味着虽然说数据是分布式可以快速获取到，但是你不可避免的有一个 suffle 的动作，你需要把数据从不同节点拉到一个节点之上，再把这个数据拿出来递给 AI 系统，让它在 GPU 里面进行训练。看起来在我们目前来讲，如果我们有非常高的带宽以及计算性能这个都不是问题，但在我们用的过程中，我们会发现其实更好的方式还是将它合为一体。
这样的好处是在于，首先，我们前面提到 Tensorflow 支持模型分布式。我可以在不同节点上进行训练。而数据在大数据平台之上，它有一个数据分布式，同时 Tensorflow 支持直接从分布式文件系统例如 hdfs上面直接 load数据。这样的情况下一个比较好的布置方式是怎样的？
我们的模型分布式进行训练，在当前节点之上训练的时候就直接加载当前节点的数据，这样的话直接省掉了整个网络带宽，直接在当前 节点 进行训练了，这是我们最理想的情况，所以也是把所有集群部署在一体上最好的体验方式。
当然这个在实施过程中可能会根据不一样的生产的客观环境会有一部分调整，所以这种问题一般也只能现场遇到现场解释。但对于集群搭建来讲，我们会有这两种方法。
TensorFlow On Spark
我前面提到 Tensorflow 有一个模型分布式。实际上后来 TensorFlow 也可以支持在 Spark 上运行，就是 TensorFlow On Spark。对于这个来讲，其实思路也是我前面提到的：我挪的只是计算，根本不用挪数据。我既然要训练模型，那我把我训练的模型挪到数据之上就可以了。所以整个 TensorFlow 可以跑在 Spark 集群里边。
之前我们在生产中运行来看的话，这样的效果其实并不是很好。首先来讲，你在 Spark 里面运行 TensorFlow，它是一个独立的。因为Spark 本身是分布式的，如果 TensorFlow 再是分布式，两个分布式一重叠就出问题了。所以说在这个场景里边，其实 TensorFlow 是单机独立地运行在一个 Spark executor面。这样的话，它产生的是多个模型，最终的话它会运算出一个最好的模型，然后再来使用。只是在这个过程中有一个分布式的交叉验证，让所有的测试训练验证的过程更通用，提高我们在整个模型训练过程中的速度。
调试
在我们开发 TensorFlow 或者说其他的 AI 架构的时候，我们都会面临一个问题：调试。其实不单单是在AI 里边，如果我们做一般的开发，做多线程的时候，调试也是一个非常困难的事情。而我们现在做 AI，TensorFlow 这种可以分布式训练，还可以分布式读取数据，两者分布式叠在一块调试就变得更加困难。
对于 TensorFlow 来讲，在开始的时候我们可能只有一个 Tensorboard，我们把计算图导出来，通过 Tensorboard 来查看整个模型的计算图是怎样的，变量是怎样变化的，这样变化下去会不会有问题，通过这个方面来监控我们的训练过程。
另外，在 1.0 之后提出了 TFDBG。这种调试方式其实可以支持我们以断点的形式去做处理，但是前面我们提到，TensorFlow 支持模型分布式训练，那在这个 debug 里面，分布式的这种多线程的训练会变得特别困难。所以一旦我们使用了 DBG，其实它就把你的分布式训练给废掉了，直接把你的分布式拉成了当前的一个 同步的训练，否则的话，你在多线程之下并行的训练之下，其实这种方式调试也会特别困难。而这两种方式是 TensorFlow 做调试的一些方法。就特别少，而这一块看起来虽然它有这个功能，实际上还是我们在开发过程中遇到的非常困难的问题，基本上在调试方面会有很多问题，不是那么顺利。
测试
最后是测试。无论是人工智能还是大数据，测试这一块其实是一个特别头疼的事。首先来讲，我们的大数据和人工智能的测试和传统测试不一样。
对于传统测试来讲，我们的输出是固定的，我们只需要定义好 AC 或者写好单元测试，就能够保证这个结果输出是对的。但是在大数据来讲，我们没有办法写一个测试说，这个模型 AC 应该怎么写。另外对于大数据来讲，我们也没有办法预先定义好AC。比如说我们通过大数据配合人工智能训练了一TB 的数据或者一 PB 的数据，最终计算出来一个值，那我们怎样去证明计算出的这个值是对的？就我们可以简单到一个什么场景，我们对于 TP 的数据求了一个累加，最终计算出来一个值，那我们怎么证明我们这个值是对的？
我们不太可能人工一条一条计算，所以这也是 AI 系统和大数据相关所面临到的一个问题，就是我们怎么去测试我们的 AI 系统。对于这一块，我们有各种不一样的尝试，但目前也没有一个最终的定好的方法，就是我们可以证明这件事，这个运行测试是对的。
最后一个是验收。在做这种项目的时候，我们会面临验收场景。我们把模型训练出来了，怎么去定义这件事？比如说我们训练出一个模型，说有 90% 的成功率，那我们这个 90% 的成功率怎么去证明，怎么去让别人相信这件事就是 90%？所以前面提到的测试配合验收，其实是在我们整个开发过程中所面临的一些问题。应该说目前来讲，都没有一个特别好的一个解决方案能把这个事情很好地证明好。
今就到这里，谢谢大家的收看，现在大家有什么问题，相关的东西相关的问题大家都可以提好，今天的课程就到这个地方，谢谢！
