本周完结第三部分：
经过Elyra完结Pipeline的图形化构建。
Elyra的构建逻辑：如何在每个环节代替原生构建办法？
组件的运行环境
如上图，将Pipeline分为三个部分：
- 下载数据
- 练习模型
- 上传模型
不再需求为每个部分组件独自构建镜像，直接将ipynb或py文件拖拽上画布即可。
运行时，每部分仍运行在独立的容器中，可认为各部分设置它们独立执行环境的基础镜像。
Pipeline的自界说参数
在(二)中，终究pipeline有一些自界说参数，需求咱们手动设置控制：
其时是经过自界说pipeline函数参数完成的：
在Elyra中，这点是经过设置环境变量完成的：
在脚本中,经过 os.getenv()设置参数及其默认值：
在该Notebook的Properties中，则能够修改其环境变量：
若某个环境变量仅想坚持其默认值，则直接在Properties中删去该环境变量即可。（不然它就等于”了）
环境变量在不同的Notebook中并无继承联系；某个Notebook的环境变量在上一个Notebook中已经出现，若想坚持共同，则仍需求在该Notebook中手动设置。
Pipeline的文件输出
在运行Pipeline时，某个组件可能会输出新的文件，并将作为下一个组件的输入。
在原生办法中，咱们为每个组件都挂上了同一个PV卷；因而，每个组件尽管运行在各自的独立环境中，但又享有一起的存储空间。
但在Elyra中，咱们有必要清晰界说其输出文件，该输出文件才可被下一个组件所拜访。
如上图，咱们在load_data的Properties中界说了该ipynb文件的输出文件为： dataset/objectname（object_name（object_name为需求咱们手动设置的环境变量），则之后的组件都能够拜访该文件。
注：
感觉，Output Files 得这样界说才是对的…:
不然，其他组件连dataset/都没看到，应该更看不到dataset/$object_name了。
Pipeline的文件输入（文件依靠）
在原生办法中，组件在封装成镜像时，除了主要的逻辑代码外，咱们可能还会在镜像中额定打包一些辅佐脚本？如utils.py等；
而这在Elyra中，是经过File Dependencies完成的。
与原生办法共同的是，所依靠的文件需求放在脚本的文件目录或子目录下。
编写脚本并运用Elyra代替原生办法
环境变量的设置
在上文中，咱们处理了自界说参数、文件输出同享、文件依靠的问题，而脚本的代码逻辑是不变的；
因而，咱们能够运用Elyra代替原生办法了。
在load_data.ipynb（load_data.py）中，咱们运用os.getenv代替argparse的自界说参数办法:
原生：
Elyra：
在train_model.ipynb,load_model.ipynb中相同进行该操作。
各组件中Pipeline的文件输入输出联系
在原生办法中，咱们在组织Pipeline时，界说了同享PV卷，并在PV卷中新建了dataset,model文件夹，各组件能够经过拜访所需文件夹获取相应文件：
但是，在Elyra办法中，咱们需求经过显式界说以同享不同组件的输出文件。
在load_data的Properties中，设置数据集保存途径：
之后，在train_model将拜访途径为dataset/$object_name的数据集以用于模型练习；
在train_model中，设置练习模型的保存途径：
之后，在upload_model中，该模型将被上传至MinIO中。
在Jupyterlab本地环境中，跑通该Pipeline：
成功将模型上传至MinIO。
Elyra的不足
Elyra的运行环境问题
留意，方才咱们跑通时，挑选的Runtime Platform为：
Run in-place locally
这样做有什么问题呢？这样的跑通其实不是真正的导通；由于它其实仅仅按你的Pipeline编排次序将Pipeline中的一切ipynb文件顺次跑通了一遍，只能证明其代码逻辑，环境变量等设置是对的；
但是，首先是ipynb节点的Runtime Image：
你即便选了Pytorch的Image，
定心，待会儿import torch肯定是会报错的，由于它的Runtime环境仍是Jupyter lab。
是的，如果挑选Run in-place locally，你的一切节点Runtime环境都是在这个Jupyter lab内的，不受Runtime Image影响；
相同的，还有一个问题：即便你的节点没有显式指定的Output Files，你的下一个节点仍能拜访该文件；由于一切节点的Runtime环境都是在这个Jupyter lab内的，ipynb文件直接在自己运行环境的当时文件目录下找需求的文件就好了，底子不需求你显式指定。
所以，咱们仍是得将Runtime Platform改为Kubeflow Pipelines。
Elyra的文件存储、办理问题
若要使Elyra能在Kubeflow中跑通，还要进行如下设置：
分别装备Kubeflow Pipelines和Cloud Object Storage;
这就涉及到一个很有趣的问题：装备Kubeflow Pipelines是很正常的；但为什么要装备Cloud Object Storage？
由于：
Elyra 使用对象存储在管道处理期间耐久化工件。
notebook(或py)处理完结后，对文件系统的一切更改（例如新文件或修改的文件）都将被丢弃。若要保留这些文件，有必要在其节点特点中将这些文件声明为OutFiles,将这些文件存储在云存储中。
咱们先装备完一下：
这边还有个有意思的点，就是Cloud Object Storage Endpoint也是有要求的：
咱们在本地装备了一个MinIO，但它目前只能经过IP地址拜访，即： xx.xx.xxx.xx:xxxx/
这样装备是不能经过的，
它说，这个endpoint不是一个”uri”.
所以只好用咱们的腾讯云MinIO来装备,至少这样endpoint是个”uri”： cos.ap-shanghai.myqcloud.com
装备完后，咱们就能够将Runtime Platform改为Kubeflow Pipelines了。
噩梦就来了： 这是我提交后的结果：
发现了两个大问题：
-
相比于原生的镜像构建Pipeline组件办法，这个办法明显要慢了许多；
-
网络问题
先说第一个问题：为什么会慢许多？
检查一下已成功的load-data的log:
能够看到，不仅是需求耐久化存储的输出文件，组件运行时，部分必要文件相同要存放在MinIO中；
上图我用绿色所圈的部分，Pipeline进行了如下操作：
- 对MinIO建议Connect连接
- 发送Head恳求
- 经过Get恳求得到load_data.xxx.tar.gz
- 解压，得到load_data.ipynb
很多时刻花在了网络通信上。
上图我用绿色所圈的部分，则经过PUT和POST恳求将需求耐久化存储的输出文件dataset/$obeject_name，渐渐提交至MinIO的bucket内。
登录腾讯云MinIO检查，相同能验证咱们的想法：
除了显式界说的输出文件外，以load_data部分为例，该MinIo除了存储了load_data的ipynb文件外,还存储了html,及tar.gz。
再来看第二个问题：
这里为什么报错？留意我用绿色所圈的部分： 在Pipeline执行:
Command '['/opt/conda/bin/python3', '-m', 'pip', 'install', 'minio==7.1.2', 'nbclient==0.4.1', 'papermill==2.1.2', 'urllib3==1.26.5']'
最终发生了ReadTimeoutError错误。估量网络也不大行？我感觉可能是由于腾讯云MinIO在墙内，Kubeflow或Elyra服务在墙外的原因？
顺带一提第三个问题：
在挑选镜像时，依然遇到了网络问题：由于镜像也是Pipeline提交后Run实时拉取的；因而常常出现在镜像拉取时就报错的问题。除了第一个镜像能够拉取下来，后面几个镜像都会报网络问题的错。
