开源大数据专场PPT下载
2019阿里云峰会·上海开发者大会于7月24日盛大开幕，本次峰会与未来世界的开发者们分享开源大数据、IT基础设施云化、数据库、云原生、物联网等领域的技术干货，共同探讨前沿科技趋势。本文整理自开源大数据专场中英特尔资深架构师利智超先生的精彩演讲。
一、Why Analytics-Zoo
1. 项目背景
英特尔先后发布了两个开源的项目，BigDL项目和Analytics -Zoo项目。在2015到2016年左右，如果想找到一个深度学习的项目直接搬迁到Apache Spark里面是比较困难的，因为当时PyTorch，TensorFlow都还没有兴起。英特尔发现了使用Lua实现的Torch框架，所以顺势借鉴了Torch的很多设计理念，并重新开发了Java版的Torch，叫BigDL。英特尔使用MKL和MKL-DNN加速单机版的训练速度，再结合Spark的分布式计算能力，便可以把一个单机版的Java Torch在Spark上分布式执行。
随着PyTorch, TensorFlow的流行，英特尔发现很多的合作客户的反馈是希望自己用TensorFlow完成一个模型的开发之后，不需要改代码，让TensorFlow、PyTorch或Caffe的模型直接无缝对接到Spark上，直接进行分布式部署。因此，英特尔希望通过Analytics-Zoo直接对接TensorFlow、BigDL以及Caffe，再借助Spark分布式的处理能力，做分布式的部署和训练。
2. 开发背景
数据分析pipelines：
下图展示了实现一个分布式的端到端的数据分析的流程。数据分析的过程非常复杂，不仅黑色部分模型定义或者模型训练本身复杂，完成一个端到端的流程需要大量的组件配合使用。比如，完成一个分布式项目，需要考虑集群如何管理，资源怎样调度。回到数据本身，数据有多种格式，数据存储有非常多的数据源。无论是存在阿里云OS或在亚马逊，异或自己管理的HDFS和HBase，都需要对接不同的数据源。访问数据源之后还需要考虑如何做数据清洗、特征提取以及特征转换等方面的工作。
大数据数据分析平台版图：
英特尔希望在完成整个端到端的大数据 + AI平台时，并不是重新开发各个组件，而是拥抱整个开源的社区，拥抱整个大数据的生态。从下面的版图可以看到，在整个大数据生态里面有非常多方便使用的组件。比如，基于YARN完成整个集群的管理，通过对接Kafka，Spark Streaming完成流式的处理。此外，Spark本身也提供了非常多Data Storage的支持，帮助操作者很方便的读取HDFS、Parquet、Avro和HBase等格式。解决了以上问题之后，Spark还提供了大量有用的API。如基于Spark Core，使用Spark SQL和Spark DataFrame完成数据的ETL，特征提取，数据清洗等工作。同时，还可以利用Spark MLlib做一些传统的机器学习工作。
深度学习框架无缝对接大数据分析平台：
上面的版图中唯一缺失的是深度学习的框架。如何将现有的流行的深度学习框架（TensorFlow、PyTorch以及Caffe），无缝对接到Spark或Hadoop的整个生态中？直接将TensorFlow等深度学习框架定义的模型嵌入Spark并不是自然的。因为深度学习框架在研发时更多是托身于深度学习领域，主要为了更好的使用深度学习算法训练模型和调试模型，但并没有过多考虑到现有的大数据的生态和开源的组件。可以发现深度学习框架与大数据分析平台中间存在断层，而Analytics-Zoo正是想弥补这个断层，帮助大数据工程师们拥抱AI的框架，在自己所管理的数据集上提供AI能力。
以图搜图：
实现以图搜图的功能最关键的环节是图片特征的提取。做POC时候有两个步骤，首先使用SSD模型完成特征检测。如下图所示，把小鸟背景的噪音去掉，提取出小鸟主体，再借助DeepBit Model完成特征提取。尽管通过Caffe1完成POC非常方便，但在真正生产线上部署时需要面对十亿级以上图片，并不是很容易。客户方没有那么足够的GPU集群，但有大量的CPU集群可供使用。那么Spark + Analytics-Zoo便是最好的组合，Spark可以对接HBase和HDFS，完成数据的分布式的预处理。同时Analytics-Zoo可以直接加载Caffe模型。无需改任何代码，就可以方便地把将整个HBase到HDFS的端到端的流程打通。
3. Analytics-Zoo设计理念和目标
无论用户开发的环境是Laptop或是单机Server，Analytics-Zoo希望实现将开发完成的原型，在基本不改代码的前提下，在Spark集群中做分布式的训练以及分布式的部署。目前的分布式训练包含Data parallel和Model parallel。Analytics-Zoo实现的是Data parallel模式,同时也在积极的考虑引入Model parallel的支持。
二、What is Analytics-Zoo
1.Analytics-Zoo具体功能
Backend：Analytics-Zoo可以直接支持TensorFlow、Keras、Caffe1和BigDL等，同时英特尔正在积极开发对PyTorch的支持。
High level Piplines：这层支持一些具体的API。比如，表示用户在使用Spark对数据进行加载和转换时，拿到一个Dataframe，nnframes直接将Dataframe放到TensorFlow模型中进行训练和部署。
Feature Engineering：在单机训练时，很多有用的特征工程的Python库是可以直接使用的。但Analytics-Zoo更需要一个分布式库的特征工程的应用，所以英特尔基于Spark Core的一些能力，为用户提供了分布式特征工程的应用。
Model and UseCase：再往上是一些传统的工作。这一层需要预置大量模型，参数以及预处理的pipeline，Analytics-Zoo中这些都是直接提供好的。若用户没有特殊需求，理论上可以打开即用或者基于这一层做一些扩展就可以运用在生产线上。
2. Analytics-Zoo具体实现：
Spark Job执行流程：
从Analytics-Zoo的具体功能中可以发现它是一个标准的Spark Job。下图展示了一个Spark Job的执行流程。首先，用户只需要把环境在Driver中准备好。之后，Analytics-Zoo将用户需要的所有依赖打包，自动把模型序列化，上传到远端的集群。而大部分Python用户使用YARN跑的时候常常遇到一个痛点，在本地装好Python的dependency，但真正部署的时候没有特别好的方式。Analytics-Zoo借助Spark Core的能力，把Python的dependency自动打包好帮助用户自动上传。同时，用户大量依赖的英特尔MKL和MKL-DNN，在其集群上部署时也不需要安装，Analytics-Zoo已经把所有的依赖打包好。在实现一个分布式的模型训练时，不需要到每一台机器启动额外的进程进行训练。依赖于Spark功能，Analytics-Zoo会把整个工作流程透明化，处理好，为用户提供干净，直接的体验。
通讯方法改进：
其实Spark本身以及Spark ML都是依赖下图的AllToOne模式。首先，Spark会把数据切成很多份，每一份数据都会对应一个Worker，训练出一个完整的模型。模型本身有梯度和参数，这些梯度和参数会全部发送到Driver做聚合。显而易见，这种AllToOne通讯模式存在很多缺点，在Driver节点会形成单点瓶颈。如果要大规模的训练深度学习的模型，光靠AllToOne模式肯定是不行的。
业界广为使用的模式，无外乎是加入All Reduce或使用其它服务器帮助加速整个参数的聚合过程。在Analytics-Zoo中，较为特殊的一点是整个过程中没有引入任何外部的PS和外部进程，只是依赖Spark本身的API做本地实现。Analytics-Zoo会把模型梯度切成很多份，每一份都交由不同Block Manager机器聚合，相当于把压力从一台Driver交给多台机器。没有引入外部PS的好处是用户在做模型训练或模型部署的时候，他们看到的就是一个标准的Spark task，用户可以使用现有的Spark的Web工具做debug，monitering等操作。
3.编程举例
TF & Keras：第一部分是数据。用Spark去读RDD，只要Spark能够识别的数据源都能支持。拿到Spark RDD之后，无论是使用Spark原生的Transformer，还是Analytics-Zoo的Transformer异或用户自己实现的Transformer，都可以把原始RDD转换成模型所需要的rdd。
第二部分，模型定义。下图中间代码就是原生的TF的模型代码，用户在单机用TF转POC之后，模型直接就可以用。
第三部分，TFOptimizer。TFOptimizer是一个分布式的Optimizer，只要提供一些优化方法，如LOSS function，它就可以自动将TF的Graph序列化，然后广播到Spark的各个节点完成分布式训练。参数同步也都是完全透明化，用户只需要在操作端节点提交一个Spark Job就可以。
Dataframe + Keras：第一步，用Spark读Parque，转成Dateframe，拿到Dateframe之后再做转换，最后拿到模型所需要的Dateframe的输入。
第二步使用完整的Keras API，定义Sequential的模型。下图的例子中加入了卷积层，pooling层和Flatten层面。
第三步利用NNEstimater将模型序列化，做broadcast以及模型同步。用户唯一需要做的就是告诉NNEstimater，LearningRate和Batchsize的值，训练多少Epoch，指定FeaturesCol。可以发现，NNEstimater的语法与Spark ML Pipeline基本一样，已经熟悉或者大量使用过Spark ML pipeline的用户是非常好上手的。
3. Distributed Model Serving
Model Serving方面Analytics-Zoo并没有做特别多的工作，但是给用户提供的是一个Java的API, 帮助用户无缝对接现有的Java Backend server。如果是Flink，可以使用Flink + Model Serving Java API，完成oneline的inference工作。Inference和training的执行过程不一样，如果只是做inference，则可以改变graph模型，大大提升整个inference速度。Analytics-Zooy依靠OpenVINO框架，帮助加速整个inference过程。
三、Analytics-Zoo Use Cases
1.美的实践案例
美的在云上已经申请了一个YARN的集群，同时也在TensorFlow Zoo上发现了非常好的模型SSDLite，稍作修改后就能够非常好的实现产品缺陷检测的功能。美的希望打通从端到端的数据源，在云上YARN集群做模型的训练和部署。实现过程是美的会安排一个机器人实时检测流水线上微波炉的生产情况，如拍照检查微波炉的标签是否贴好，螺丝是否拧紧等。检查数据会实时反馈到后面的YARN集群，再结合Analytics-Zoo数据，直接加载TensorFlow的模型，训练模型。最后结合Model Serving Java API，将训练好的模型直接在美的的Web Service上进行部署，完成端到端的产品缺陷检测。
4. MasterCard案例
MasterCard已经有了大量的CPU集群，Spark集群和Spark MLlib ALS的模型，基于Spark完成了整个端到端的推荐工作。随着深度学习的算法的兴起，MasterCard希望引入NCF以及较流行的WAD的深度学习的模型的算法。Analytics-Zoo可以用TensorFlow定义NCF和WAD的模型，之后便可以直接对接原来写好的Spark整个数据流的pipeline，打通端到端的数据预处理，模型训练和模型部署，加载深度学习的推荐能力。
除对外输出技术影响力，英特尔也十分重视在开源社区的投入，近期也与 Apache Flink 社区深度合作举办了首届 Apache Flink 极客挑战赛，致力于造福更多开发者。大赛聚焦机器学习与计算性能两大时下热门领域，参与比赛，让自己成为技术多面手，还有机会赢得 10W 奖金。
大赛详情请点击： https://tianchi.aliyun.com/markets/tianchi/flink2019
