第四点，这个平台不是面向机器学习零基础的开发人员，更多的是面向专家和半专家的算法工程师，让他们提高建模的效率。同时这个平台要支持多租户，确保保障数据安全。
以下是我们自己的整体方案，主要分成两大块：
下半部分是建模平台，也叫实验平台，它主要供算法工程师使用，建模平台包含：
1、对应IDE。在这个平台上进行数据探索、做数据的实验，并且它能支持项目的管理和共享。
2、我们希望把已经开发好的特征数据管理起来，方便所有平台用户看到数据资产的情况。
3、样本匹配时候，样本ID可能与内部ID不统一，这个时候需要做统一的ID匹配服务。
4、帮助算法工程师从万亿级数据里快速地抽取所需数据，这也是非常重要的一点。
5、做机器学习的过程中，除了基本的算法，实际上还有很多代码是重复或者相似的，我们需要把这些常用代码进行函数化封装。
6、支持对模型服务进行打包部署。
7、模型还要支持版本管理。
8、在实际业务中应用模型，需要实时监控起来，跟进模型的可用性、准确性等。
上半部分是生产环境，运行着数据处理pipeline，同时与数据建模平台对接着。
在生产环境中，模型对应的特征数据分两类：
一类是实时特征数据，比如数据实时采集，生成一些实时的特征，根据不同的业务需求存储在不同的集群里。
另一类是离线特征数据，离线数据加工后存到Hive，供模型应用侧进行使用。
在生产环境中，我们可以提供在线的预测API或 离线预测好的数据 供业务线使用。
五、方案实践具体要点
第一点，我们讲讲jupyter这块：
选择Jupyter作为主要建模IDE而不是自研可视化拖拽建模工具，这样的好处是可以做交互式的分析，建模效率也很高，扩展方便，研发成本低。当然类似微软Azure这样的可视化拖拽建模平台，可以非常清晰地看到整个流程，适合入门级同学快速上手。但我们的目标用户是专家和半专家群体，所以我们选择了最合适的Jupyter。
使用Jupyter时候，为了支持多租户，我们采用Jupyterhub。底层机器学习框架我们用了Tensorflow、Pyspark、Sklearn等。数据处理探索时候，结合sparkmagic，可以非常方便地将写在Jupyter上的Spark代码运行到Spark集群上。
对于Jupyter没有现成的版本管理控制和项目管理， 我们结合git来解决。
另外为了提高建模人员在Jupyter上的效率，我们引入了比较多的插件，例如：把一些典型挖掘pipeline做成Jupyter模板，这样需要再做一个类似业务的时候只需要基于模板再扩展开发，比较好地解决了不规范的问题，避免了很多重复代码，也为实验代码转化为生产代码做好了基础。
第二点，说下工具函数：
我们内部提供了主要机器学习相关的函数库和工具：
1）标准化的ID Mapping服务API。
2）创建数据抽取的API，无论是哪种存储，分析人员只要统一调这个API就可。3）可视化做了标准化的函数库和工具类。
4）Jupyter2AzkabanFlow: 可以把原本在Jupyter上写好的代码或者脚本自动转化成AzkabanFlow，解决了特征工程阶段的代码复用问题。
第三点，关于使用Tensorflow：
使用Tensorflow时，我们的选型是TensorflowOnSpark，原生的Tensorflow的分布式支持不够好，需要去指定一些节点信息，使用难度较大。
TensorflowOnSpark能够解决原生Tensorflow Cluster分布式问题，代码也很容易迁移到TensorflowOnSpark上，基本不用改。
同时利用yarn可以支持GPU和CPU混部集群，资源易复用。
第四点，关于模型交付应用：
在模型交付的问题上，我们把整个预测代码框架化了，提供了多种标准的框架供分析人员直接选用。对输出的模型文件有格式进行要求，例如：只能选择 pmml格式或者tensorflow pb格式。标准化之后，只要使用标准的预测函数库，就可以把建模人员的工作和系统开发人员的工作解藕出来。
最后分享下我们的一些经验：
第一，TensorflowOnSpark上的PS数量有限制，而且Worker和PS节点资源分配不是很灵活，都是等大。
第二，Jupyter在使用的时候，需要自己做一些改造，一些开源库版本兼容性有问题。
第三，使用PMML有性能瓶颈，一些是java对象反复重建，还有一些是格式转化损耗，具体大家可以抓取下jvm信息分析优化。
第四，在落地过程使用Spark、Hive的问题上，需要提供易于使用的诊断工具，建模人员并不是Spark、Hive的专家，不一定熟悉如何诊断优化。
第五，要把模型和特征库当成一个资产来看待，对它的价值定期做评估，要管理好它的生命周期。
第六，一些更偏底层的问题，比如: 硬件的选型可能要注意带宽、内存、GPU平衡。
最后，需要平衡技术栈增加和维护代价，避免引入太多新工具新技术，导致运维困难。