本周四，雷锋网 AI 研习社邀请了跨国 IT 巨头 ThoughtWorks 的资深数据架构师白发川，主讲线上公开课，为大家讲解 TensorFlow 在工程项目中的应用。
此前，白老师与 ThoughtWorks 高级咨询师佟达接受了雷锋网(公众号：雷锋网)的采访，就新手入门 TensorFlow 容易遇到的一些问题，以及他们的入门经历，进行了分享。请参考：万事开头难！入门TensorFlow，这9个问题 TF Boys 必须要搞清楚。
另外， ThoughtWorks 的线上培训——"TensorFlow & 神经网络算法高级应用班”，将于下周二在 mooc.ai 上线，由两位老师授课。报名请点击。
闲话少说，本次公开课承接对两位老师的采访，对两个话题进行了梳理：
企业大数据平台
TensorFlow 应用场景
这是公开课的录制视频：
公开课文字版
不方便看视频的童鞋，可阅读以下对本次公开课的文字转录。
由于篇幅较长，本次公开课的文字转录被拆为上下两部分。本篇为上篇，讲的是企业级的大数据平台及其架构。这是由于 TensorFlow 的商业工程应用必以靠得住的大数据基础设施为前提。
TensorFlow 的应用场景请关注下篇。
白发川：大家晚上好，欢迎大家这次参加本次公开课，同时也作为 "TensorFlow & 神经网络算法高级应用班”开题前的宣讲。
本次讲的是 TensorFlow 在工程方面的应用场景，更多偏向工程上的实践。也就是说，从工程上来讲，一个 TensorFlow 项目在各个方面要做哪些工作。
TensorFlow 作为一个深度学习框架，在整个工程开发的项目中，它只是其中的一部分——我们实际上做开发，面临的是一个非常庞大的体系。因此我们面临的问题是：
在整个体系中，我们的工程应该怎样去开发？
应该怎样去使用 TensorFlow？
在哪种场景之下，TensorFlow 会是一个比较好的选择？
自我介绍一下，我是 ThoughtWorks 白发川，之前一直从事大数据，后来我们开始做人工智能方向的一些尝试和工作。我们致力于将人工智能、机器学习、大数据结合在一块。在研究了了很多相关的机器学习框架之后，我们也做了自己的深度学习框架——deeplearning.scala。它由 scala 编写，目前是开源的，大家可以了解下。
这是关于我们公司。大家可以在网上了解到，ThoughtWorks 是“敏捷”的倡导者。比如说《重构》，还有《Web开发敏捷之道》，这些书都是由我们公司的同事编写的。
下面进入本公开课的第一个环节。
从大数据开始
做人工智能也好，做其他机器学习相关的项目也好，本质上我们是离不开数据的。因此，怎样去规划我们的数据、怎样去设计我们的架构，是非常重要的。以我的经验看来，一切不做大数据架构的人工智能项目，都不会有特别好的效果。
人工智能项目和数据项目是可以完全独立开的。假设我们只有几条数据，倒也可以做人工智能。但真正面临生产的时候，如果没有做底层数据规划，你的整个人工智能的效果基本会是负的，不会产生特别大的效果。
在数据方面，从早期到现在，我们经历了不同的迭代周期：
- 最早期的数据处理方式很简单，可能就是搞搞 Excel，现场就把数据计算出来了。
- 慢慢地，我们的数据管理方式会倾向于使用数据库。多个客户端连接同一个数据库，来做数据处理。
- 再后来我们发明了 Data Warehouse。BI时代，我们的所有数据都是经过 Data Warehouse 之后统一地产生报表。
- 之后进化到目前的阶段，随着计算机硬件的发展，我们出现了数据湖——Data Lake。数据湖是在 Data Warehouse 之上更加扩充的一个方面，而它为机器学习做了很好的支撑。
在数据分析这一块，早期大家的需求只是一个数据可视化：我根据数据可视化的结果来做决策、来做判断，然后给出关键决策指导下一步的发展方向。到引入机器学习之后，有一部分相关分析工作其实是让计算机去做了。当我们的数据计算出结果之后，可以由计算机作出初步的决策给人提供参考，然后再由人来做最终的决策，这也是目前人工智能方向最常见的方式。
虽然我们在做人工智能，但还没有达到不做任何干预、百分之百由计算机出结果的层次.。所以本质上，目前的人工智能还是对人的一个辅助参考。我们还是需要人来做处理。当然，人工智能最终的进化方案，我们一定是希望完全靠计算机来做处理，不用人来处理了。
这个架构图是一个企业界的大数据架构平台。对于一个企业来讲，从历史发展过程中它会有一个非常庞大的 IT 体系，它的数据源遍布于不同系统之中。在很早的时候我们会提出一个概念叫做数据整合，就是因为同一批次具有相同业务含义的数据在不同的系统里边，它的存储方式、表示方式完全都不一样。所以为了做这部分工作，诞生了早期的 Data Warehouse。我们以规整化的数据、元数据，把这一批数据做处理。
对于一个企业级的大数据平台，我们除了要做 BI 的这部分工作，还有一个额外的需求，就是机器学习。我们希望我们的大数据架构可以用来支撑机器学习。可以在架构图中看到，在前面会有数据通道。数据通道可以理解为 BI 里 ETL 的这一部分，但本质上它高于 ETL，对于数据通道来说，它和ETL的差别在于ETL需要对数据做转换，而数据通道仅仅是同步数据，其次ETL相对是个独立模块，而数据通道是平台的一部分，受调度器管理的，比如我们的数据通道的功能可以是爬虫。
数据湖
接下来我们会进入数据湖。数据湖是大数据里边提出的一个概念，从本质上来讲，它主要负责的是数据存储，对于数据存储来讲，它在大数据之下，它要解决好几种问题，即结构化数据、半结构化数据、非结构化数据这些不同数据类型的存储。
其次的话，它要解决的是数据安全性、数据可靠性。在这个基础之上，大家目前看到的 Hadoop 的底层数据实现hdfs它也是数据湖会常用到的一种实现。
数据探索
再往下，我们可以看到数据探索。当你成为一个企业级大数据平台之后，会面临这样的情况：
我给企业做了数据整合，我们的数据湖都存在了，但在接下来要做机器学习的时候，会发现一个问题——我没有办法快速的知道，在企业里边我到底需要哪些数据；或者说企业现在已有的这些数据，但是这些数据特别大，我们怎么才能够知道目前有哪些数据？都是什么格式？
在这个之上诞生的服务叫做 data discovery，翻译过来是数据探索。这一项工作本质上是为数据科学家做准备的。我们在搭建了数据服务平台之后，我们需要做一系列的调研，从数据科学家的角度来审视这批数据，来看它代表的特征和维度到底能不能给我们提供一个非常好的人工智能的支撑。
所以，这部分工作更多的是由具有丰富经验的数据科学家来承担的。他们需要的就是一个简单的数据探索工具，因为并不需要全部拿出去。而对于数据湖来讲，我们里面放的数据基本上都是 PB 的。在我们所做的项目里面，TB 和 TB 以上的数据特别常见。所以对于数据科学家来讲， 没有必要 load 完整的数据，代价太大，更希望的是快速检索到数据格式，然后哪几条要列数据出来，看一下这个数据符不符合我的需求，所以在这个之上，我们需要一个数据探索的服务，给他提供这样的支撑。
另外，本质上来讲它还有一个功能：管理数据服务的云数据。因为我们既然需要快速的查找数据，那么对于数据湖来讲，我们的数据（元数据）是不是需要被管理起来？比如说，如果我们提供的是一个数据平台，从数据通道进来的数据到底是属于哪一个业务系统的，是怎么规划的，都会在里边。
Data Warehouse vs. 数据湖
再下边的话到了数据预处理。
它的数据来自于数据湖。这里提一下数据湖和数据仓库的差异。在传统 BI 系统里，数据源到数据存储之间有一个过程叫做 ETL。做数据规整之后，ETL 会再把数据送入 Data Warehouse，而在大数据架构里面我们我们会发现，其实我们的基本处理，是在数据湖之上做的数据预处理。
这个时候，数据湖和 Data Warehouse 的区别在哪个地方？
首先对 Data Warehouse 的所有数据都是被规整过的，意味着它的数据是结构化的，结构化就意味着信息被丢失了。丢失的数据，可能对于你的静态业务需求并不是那么明显——比如说我只是出个报表，或者只是做一些统计，求平均之类的计算，那我可能把数据规整了，没有什么问题。但如果要做机器学习，我们更希望提取到全量的数据特征。而一旦数据被规整，很大一部分信息就丢失了。这样以来，当通过机器学习做特征提取的时候，就会出现非常不准确的问题。
另外，对 Data Warehouse 来讲，它更注重的是对结构化数据的管理。而在大数据之下，其实结构化数据只是我们要处理的一部分数据，并不是全量的。除此之外，我们有非结构化数据和半结构化数据，而对于这种数据的处理，Data Warehouse 并不是特别的有效。
数据湖的概念因此诞生。我们的所有数据都放在数据湖，我们的处理放在数据预处理这一块。预处理会跟随我们的业务，当我们需要一个什么样的业务的时候，会通过数据预处理来处理。这里的话，我们把之前提到的工作，从数据通道到数据湖之间的这个位置，挪到了后面的数据预处理。
对于企业来讲，我们的组织结构都能良好的运作。因为在 BI、Data Warehouse 来讲，会有一个团队或者说一个角色，专门负责 ETL 这个工作；或者把数据从另外一个地方做处理之后迁移过来。这样的话，当我们的业务发生变化，我们的整个数据源要从新数据接触的地方重新清洗过来，重新打通。这一个响应周期会特别长，
而在大数据架构之下，由于有数据湖，这一块业务发生变更的是我们所做的，挪的只是计算。我们的计算规则发生了变化，但数据湖里面的数据照样在里边。所以计算的代价肯定是远远小于挪数据的。
数据预处理
数据预处理之后，会有两个分支。上边的分支是在线分析、数据可视化。这一块来讲，都是为了符合和囊括早期我们在做 BI 系统所需要的那些东西。比如说我们要做静态报表展现，在 BI 系统里最终出来的报表有上钻和下钻。这些需求方式其实用在线分析都可以做到。而目前在大数据方面，我们也会把传统思想、传统BI 方式里边的一些思想借鉴过来，它们是特别优秀的。比如说 Olap 和创建 Cube 的这种方式，在整个数据分析里边有非常好的作用。所以目前来讲，这一块我们是可以完全涵盖的。
下边是机器学习和决策分析。数据预处理本身并不是做一些静态的报表分析相关的工作，而数据预处理囊括了特征提取，这是用来给机器学习做支撑的部分。这样的话，我们数据预处理出来的分支既可以满足它静态的数据分析，也可以满足我们要做机器学习相关的操作。
最下层有一个服务调度。我们可以看到我们的服务调度，从基数到最终，都是被整个服务调度起来的，就我们会建立一个统一的大数据调度系统，而这样一个好处在于，所有的任务被调度系统统一调度，会有一个非常好的任务编排按序执行。
另外一种方式。对于早期做 BI 系统时的 ETL 工具，像大家见得比较多的 Kettle 这种工具，相对来讲会缺乏调度功能。第一它缺乏调度，第二的话它不是特别友好的支持分布式运行。比如说我们运行一个 Kettle的脚本，它可以把数据从一个数据源抽到另外一个数据源，但本身来讲，你这个工具没法像 Spark 那样分布到不同节点，并行得做处理。所以，当我们有一个服务调度层的时候，可以把所有的任务全部调度起来。这样的话，我们既保证了所有的 job 是可被监控的，其次也可以保存一部分状态，比如说我某一个 job 失败，我知道从哪个地方再次恢复。当我们有了服务调度，我们能够拿到它的所有状态。对于最右边这块，我们可以给它做到很好的监控。
企业数据成熟度模型
前边我提到，对于一个企业来讲，我们无论是做人工智能还是做数据分析，前提一定是规划好它的大数据平台。大数据平台直接决定了后面所有的效果到底好不好。所以我们定义了一个企业数据成熟度的模型。在目前来讲，可能很多需求或者说我们所见到的场景，大家都会说我们就是要做人工智能，我们的目标是做人工智能。但实际上，从现实情况来讲，要到达真正的成熟的人工智能，它中间有很大的跨度。
那这个跨度到底怎样去衡量？
在这之上，我们提出一个数据传输模型，评估当前你所在的状态在哪个位置；其次，你想要的是一个什么结果。
比如说在第一个阶段，我们想要知道的，只是从数据里面发现问题。这时的需求很简单，我只是做一个订单报表，展示相关的工具。这个时候，你可能并不会实施人工智能的一些功能，因为还没有到达这个层次。你当前所具备的需求，或者说你所具备的数据源，根本不支持你做这件事儿。
有了该评估之后，除了可以梳理出它的现状，和给它做评估之外，我们还可以根据前边的整个大数据方案来决定你可以实施到哪一层。前边我们看到的大数据架构方案，本质上它的每一块可以独立出来，作为一个循序渐进的过程。这里我们可以看到好几个阶段：
- 首先，看它发生了什么。
- 第二，分析它为什么发生。
- 第三个阶段，知道它将会发生什么。
这个阶段会涉及人工智能。也就是说，只有到达第三个阶段的时候，我们才认为对企业来讲，你的所有的业务需求和数据支撑已经到达了人工智能需要介入的阶段。这个时候，我们会在你的大数据平台之上，考虑把你的整个机器学习接入。
所以，达到这种不同阶段实现不一样的功能，也是对数据平台的一个非常严格的考核。就是你的每一个阶段可以无缝的递增到下一个阶段。之后，当我们预测了将会发生什么事的时候，我们一定会想怎样去优化它，这就到了最后一个阶段。
当我们的机器有了数据、有了模型，机器学习的整个体系已经非常完善了，就可以达到一个自选型的功能。它可以根据你的数据，找出你自己依靠人的经验都没有发现的东西。这是我们希望达到的终极目标。
大数据平台架构
在这一节将为大家展示，我们所做过的、或我们看到总结下来的大数据架构的不同实践方式。
传统架构
这是一个传统的架构。在机器学习很早之前有一个过程：做 BI 系统之后会有一个阶段——当数据量上来， Data Warehouse 的数据处理会出现瓶颈。这时候，我们需要一种架构，保持原来的业务不变。保持外围需求，替换底层的技术部分，这样整体性能会得到提升。这种架构的实现一般会比较简单。从最简单来讲，就是我们根据左边的数据源，它可能是数据库或者其他的 FTP，通过 ETL 工具把数据放到数据存储层里边。在最右边给大家提供一个和原来效果差不多的服务，在中间的话会有一个数据存储和一个搜索引擎。这种搜索引擎主要提供检索的功能。这种传统架构发展起来之后的话，我们又有了另外一种架构，叫流市架构。
上文提到，传统架构本身是一个线性的服务。相对而言，它的响应比较慢，ETL 更多是一个定时的。对于定时的数据，我们的接入更多的是面对别人的备份数据库，或者说，是在业务系统真正把数据落地到数据库之后，我们才接入的。在这个角度来说，我们的所有数据是严重滞后于业务发展的，即业务产生数据。当业务产生数据之后，你需要隔很长时间才能拿到这批数据。
流式架构
在这之上我们提出了流式架构。流式架构就是：当数据进来之后，我们直接以流的形式把数据接入，甚至拿到流数据之后，我们把流数据以消息的形式直接推送到前端。这样能很好地满足仅仅具有预警类的功能。比如说我是做运维的，那我可能需要一个流式数据，来更好地满足我当前的一个实质性。
Lambda 架构
在流式架构之后，演变出了 Lambda 架构。
前几年，这个架构在我们所有的系统里边、涉及社交大数据架构平台的时候都被广泛实施。Lambda 架构在很长一段时间都是优先的选择。它主要分为两个批次，整合了传统架构和流式架构的一些优点。在前面的话，对于数据处理这块它是一样的，是将数据接入。但在数据接入之后，它会分为两个部分：
首先，你的数据会进入数据湖，被永久存储起来。
其次，数据会进入流处理。流处理的数据，根据你的一部分计算结果，立马会以消息的形式直接推送给前端。流式处理，和上边的 batch 处理，也就是数据存储和数据预处理，这一层我们一般称为 batch job；而下面的流处理，我们称为实时处理。这两者的逻辑是一样的，但面对的数据不一样。上面数据存储、数据预处理这一块，面对的是全量数据；而下面流式处理面对的是增量数据。在 Lambda 架构里边有一个技术叫做前端 view 合并，就是我的流式处理是根据增量数据计算出来的结果，立马就给前端展示；数据进来之后它会触发一个 batch job，触发全量计算。当全量计算完成之后，它会把这个结果集和流式处理计算出来的结果集进行合并，保证最终一致性。因为流失处理有可能会出错，毕竟它是增量计算，那么全量计算一定要保证最终结果是正确的，所以这个时候会用 bash job 出来的结果去覆盖流式处理，我们叫它最终一致性，就可以保证数据的正确性。
Kappa 架构
它相对于 Lambda 架构做了一部分的改进：在 Kappa 架构里边，我们认为数据都是流式的，就是说我们的所有数据都可以被流式处理。数据接入时，我们的数据进入了消息队列，那么它会放入数据存储里边， 同时也会进入流式处理。流式处理就和之前一样：在做了处理之后以消息的形式推送到前端。
那为什么在数据存储这一块，它没有了 batch job 这一层？它不再做离线计算，因为我们的所有数据是可重播的，当我们发现某个某一个结果计算不正确的时候，我们需要重算。对于 Kappa 架构来讲，它认为重算就是把之前的数据接入这个动作再重复一遍。所以说，它把所有数据都以流式的方式去处理，这样避免了进行一模一样的逻辑计算。
我在前面提到， Lambda 架构分为两部分，一个流式的，一个 batch job 。它们面对的数据集不一样，但计算逻辑都一样。而 Kappa 架构就省掉了，把相同这一部分进行了合并。
Unified 架构
相比起来，它和 Lambda 架构有一点相似。不同之处在于，它的流式处理变成了模型相关的东西。它是目前，我们做大数据架构和机器学习架构整合起来非常完美的一个架构，在这个架构里面我们可以很好地把机器学习放过来。 在 batch job 这一层它主要做的是模型训练。当模型训练之后，新数据进来，以流式的形式经过模型就会预测出结果。这个结果可以消息的形式被推送出去。这样的话，在最外层，你就可以拿到流式处理被预算出来的结果。
未完待续，请关注雷锋网AI 研习社后续整理。
本文作者：三川
本文转自雷锋网禁止二次转载，原文链接